Really thoughtful questions here. I'll try to say something about a few of them--maybe others will have more thoughts.
On Friday, January 2, 2015 7:05:48 AM UTC-5, Ismael VC wrote: > > Thank you Jason! > > When we say that Julia's macros are Lisp style macros, what are we > *exactly* talking about? Most of the people I know associate the word > macro with excel macros (vbnet), (not even C!), most have never ever heard > about lisp (I blame the forced Java culture in schools mostly!). > > But now that I went in search for more information about lisp-like macros, > it turns out that "lisp-like", is a very ambiguous term, since it seems > there are a lot of macro implementations and a very big lot of things to > talk and know about them: > > http://c2.com/cgi/wiki?LispMacro > > So I wish that instead of assuming we all know what a lisp-like macro is > like, we should say something like: "macros are more like lisp than C..." > and then go on to explain specifically what Julia macros are* without* > assuming prior experience, their limitations, common gotchas, etc., most of > the people I've seen that come from Python like me, just try different > combinations of escaping and evaling, because it's just simply something > most python guys like me have never used. > I'm going to say something controversial here: I think Julia's syntax (and python's, and c's, and many others) makes it difficult to learn about macros *as a beginner*. In Lisp, the syntax is a very direct representation of the "Abstract Syntax Tree". In Julia and most other languages, the surface syntax must first be translated into a more uniform tree representation, and you have no reason to know about or understand this hidden uniform structure until you start trying to write macros. This isn't actually much of an obstacle for people who already know how to write macros, because the translation isn't complicated--it's just hidden--and once you have intuition about the AST, you can fairly easily see it through the surface syntax. As a personal aside, I first learned to write macros in a language called Factor http://factorcode.org/. It's a "concatenative" programming language (like Forth, Postscript, and RPN calculators). I claim that concatenative languages are even more suited to learning to write macros than lisp is, because the syntax of a concatenative language expresses a linearization of the parse tree--i.e. the order that things will actually be evaluated--and linear sequences are simpler than trees. So I'm going to claim (and this claim brings me no happiness) that you aren't likely to learn macros easily as a beginner to Julia, and that the only two ways I know of to get intuition for the relevant concepts are to either learn a language like lisp (or Factor!), or to implement a parser and compiler for a c-like language with syntax (this is a huge effort the first time, and most people will not do this). I'd love to be proven wrong here, and I eagerly await a great book or blog post that teaches macros effectively in a language like Julia. Maybe one already exists, and I just haven't heard about it yet. In the mean time, Jeff recommended Paul Graham's "On Lisp" a while back, and I don't know of anything better. BTW, what all the syntaxful language get in return is readability. People can claim otherwise all day long, but I think python is easier to read than lisp (or Factor). > I fear the same is going to happen with staged functions (and whatever > else advanced and awesome techniques the devs can come up with), they sound > great but I hope I'll get to know how to use them to be productive not just > to amaze me. > Frankly, I think that is likely. One consolation is that you don't have to use every feature of a language in order to program with it effectively. I know I try pretty hard to not use every feature of Javascript, and I understand that one tries not to use all of C++. You can still benefit from the fact that library writers will use staged functions to write more efficient and more generic libraries. > I know the problem is just that I'm ignorant about this (but that's > fixable), I regret that Julia seems more focused in already made > professionals or students with already made professionals behind them?, > leaving behind newcomers (even with the matlab-python-like syntax, > interactivity and elegance). > > I regret it because I feel it's gonna be ages before some one starts > teaching Julia here in Mexico and using outdated books, because translating > the already outdated English versions we may have available by that time > and realizing Julia's importance will also take ages (which is why I want > to translate the docs ...with the hope to understand them also, I want my > language to be first class citizen in this community). Honestly here > education sucks, there is so much to learn and I have to learn it alone. > > And by the time they start attempting to teach with Julia, I'm afraid we > would have Java even more entrenched and of course we will be less > competitive in this regard (most schools either want to teach you to do > *everything* with Java or just use something closed source and expensive > (this is Mexico and piracy is rampant, so every one just uses pirated > windows, matlab, ....,<anything-else>)). > > We should be aiming for even better documentation than in this examples: > > - > > http://docs.scipy.org/doc/numpy/reference/generated/numpy.zeros.html#numpy.zeros > - http://reference.wolfram.com/language/ref/BesselJ.html > - http://www.mathworks.com/help/matlab/ref/inv.html > > They use a lot of examples per function, not just: > zeros(*type*, *dims*) > > Create an array of all zeros of specified type. The type defaults to > Float64 if not specified. > zeros(*A*) > > Create an array of all zeros with the same element type and shape as A. > And also they don't assume we'll just get what a short acronym or > abbreviation is for, or that we already know lisp, matlab, r, python, and > C, etc. > > Even if they look like extremely simple functions to use (which they are). > But I was once told that the manual should stay short, why is that? At > least I also heard about making the docs into ipython notebooks, which > would be even better that the previous examples, I wonder when that'll > happen. > > Even if Julia aims to solve the multi-language approach, people still have > to know those multiple languages in order to get what Julia is about, even > if I never write a line of Lisp for production code, I'll have to read a > lot about it before I understand what you guys are talking about, which > kinda beats the purpose of not having to use (learn) multiple languages to > do something. > > Would you be interested in a more extensive reference? Do you absolutely > like it short as it is now? Am I the only one who is a little frustrated > about this? > I think Julia's manual is excellent because of its clean writing and narrative structure. A lot of languages have to wait for someone to write a book (e.g. Dive Into Python, the Pickaxe book for Ruby, etc.) to get such a document, and we should be grateful to Stefan and the other contributors to the manual that Julia got something like it so early. Of course, there's always room for further improvements. Julia's reference documentation, on the other hand, is not yet excellent for just the reasons you give (but it's pretty good!). I think a lot of people would agree with you about ways to improve it, so it's "just" a matter of getting the resources and creating the procedures that result in documentation like the good examples you linked to.
