I found a number of points in the blog that I think are relevant to Julia design (what follows is meant as constructive criticism, I think these issues can be addressed in the future, maybe during 1.x, maybe at 2.0, Julia is already wonderful, but nothing in this world is perfect):
The language must try really hard to catch programming mistakes, especially the mundane ones that happen to everyone all the time. When it finds a mistake, it must point to the true reason for it, preferably with an error message that humans understand.
Julia does have problems with rather inscrutable error messages, and that is something that can be improved at any time during the release cycle. Also, many times a full stack trace is shown, that is not that relevant (and may be rather scary) to most Julian programmers (the technical/scientist/mathematician types who use Julia instead of R / Matlab / Python) (maybe the verbosity could be controlled, so that you can get the full stack when you are actually tracking down the problem in question)
Should programming bugs be discovered by the programmer or by the user? The answer seems pretty clear. Therefore, a language should be designed so that as many programming errors as possible are discovered early on, that is before the program is sent to the user. In fact, in order to speed up development (remember that the development time is expensive) the programmer should be told about errors without having to run the program and directing its execution to the place where the latest code change actually gets executed.
Better support for Lint.jl maybe would be helpful here?
More support in the language for indicating what should be part of the public API of a package or module, even when a name is not exported, might also be helpful.
On the whole though, I feel that the blog actually vindicates a lot of the design of Julia, so kudos to all of the people who have been involved in that, from the original creators to all the people (like Tim and Matt among others) who’ve extended it in important ways (Holy traits for example).
I would advise you to wait until both Julia and JuliaParser stabilizes (both are version 1.0 at least), I have been planning on making a Spanish version of Julia AKA Julieta, this way, that would aid me in teaching programming to non native English speaking children, specially for those that have already experience with Scratch and want to go beyond.
You could study JuliaParser source code, it’s 100% Julia, no Scheme (Femtolisp) knowledge needed, and you could probably meta program most of your changes.
Thanks for the note. The point is that I am not familiar with the general principles/methods of parsing – regardless of the specific language.
I have to find a simple & concise tutorial, “Parsing for Dummies”.
You can ping me anytime you like, I’ll try to help, but I am no parser expert by any means. I just red the JuliaParser code and with the help of the community was able to refactor a bit of it and understand how it works a little in the process.
I don’t see why you would have to touch a parser in order to experiment with this. Julia already parses := as an operator with the same precedence as =, for example. You can just use the Julia parser as-is, and then rewrite the parsed code with a macro.
For example, if you define a macro explicitmutation, you could use it with
@explicitmutation function foo(x)
y := x
z = sqrt(x)
y := y + z
return y - x
end
and transform/interpret the parsed code however you want (e.g. to throw an error if you assign something with = and later mutate it).
“Transients are interesting and we should steal them.” — note from a Haskeller on Reddit
The idea of transient data structures in Clojure is quite similar to what I had in mind in my proposal (a sort of “mapping” from mutable data structures to immutables ones), though, in Clojure, the idea is to make a temporary mutable from an immutable, for short use; see eg.,
< Clojure - Transient Data Structures >
One useful but much simpler change compared to what the OP suggests, is to have a different syntactical notation for defining vs changing a binding. For ex, keep = for defining, and introduce := or =: (or other) for changing the binding of the previously defined variable (re-assignment).
I think when we program we already have this different intent in mind (“I’m going to define this to be…” , “I’m going to change that var to…”), so it will not be any mental cost to actually convey that intent when we write the code.
So it’s a low-hanging fruit that I think most dynamic or scripting langs don’t collect.
I suspect doing so, can result in compiler being able to catch more errors, and perhaps optimize the code better, and perhaps also give more options to solve the scope problem (as this github reply by @jeff.bezanson ).
I guess it could be introduced at first as optional, and if most agree, then in future mandatory.
EDIT: I found that this(or essentially this) idea was also proposed, independently, by @Balance
,and with more background details, here , here
I just red the JuliaParser code and with the help of the community was able to refactor a bit of it and understand how it works a little in the process.