In a another thread (that has gone on way longer than I expected) @StefanKarpinski stated
we are not interesting in making gratuitous annoying changes in Julia 2.0.
Where some may hear an idea and say, “Why?”, I see it and say why not?
Below, therefore, are a list of gratuitous annoying changes for Julie 2.0. I’m pretty sure some changes, like switching to the EBCDIC character set are locked-in, so I’ll just concentrate on those changes that are in the final stages of development and just require a little polishing.
Name and Logo
The existing name, “Julia”, was thought to be a little pretentious and off-putting. Therefore, the language will be renamed to Julie, which is considered to be more informal, friendly, and accessible. The new logo may look something like this:
Scoping Rules
A lot of confusion has been experienced with the existing scoping rules. Is it a global variable? Local? Who knows?
Therefore, the decision has been made to put everything in the global scope. There will no longer be any local scopes.
A big side benefit is that the syntax can be simplified by eliminating functions entirely. Instead, the existing @label @goto syntax will be used.
For example, here is a Julie 2.0 program that prints several anti-primes:
# print anti-primes; natural numbers with more factors than any smaller than itself
begin
c = -999
n = 0
t = 0
d = 0
@label j20
n += 1
@goto j60
@label j40
if t==20
@goto j200
end
@goto j20
@label j60
d = 0
for f in 1:Int(round(n/2))
if mod(n,f) == 0
d += 1
end
end
if d > c
@goto j120
end
@label j70
@goto j40
@label j120
c = d
t += 1
println(n)
@goto j70
@label j200
println("the end")
end
Isn’t that so much clearer and understandable that Julia 1.x.x. code? Recent research has shown that Dijkstra was wrong, and the GOTO statement is essential for writing clear, maintainable code. J̵u̵l̵i̵a̵ Julie 2.0 be at the cutting edge of the renaissance of the GOTO statement.
One Import Keyword
In Issue #39235, discussing having just one import keyword for J̵u̵l̵i̵a̵ Julie 2.0, an offhand suggestion was made to copy the Python from module import * syntax. To which, @StefanKarpinski replied:
I hate
from Module import blahwith all my guts and will die on that hill. One of the major benefits of being able to do all imports with a single keyword is that a block imports can look more consistent and is easier to read. If some imports look likeimport Fooand then interspersed with that are these hideousfrom Bar import bazstatements, then not only is that benefit lost, but I might as well just stick needles in my eyes and then I don’t have to worry about this problem anymore.
Well, everyone agreed that they really wanted to see that, so from module import * is a mortal lock to be in Julie 2.0.
Simplified Error Messages
Current error messages often try to indicate the cause of the error, and sometimes even suggest how the user might correct the problem [which brings up the question, if the compiler knows how to correct it, why doesn’t it just fix it? It’s like the infamous “missing semicolon error” in Pascal – if the compiler knows the semicolon is missing, why doesn’t it put one in? But I digress.]
Informative error messages have been a tremendous burden on the developers, so most Julie 2.0 error messages will be simplified to:
Batteries Included – Including FORTRAN!
In order to end the What is the advantage of Julia over Fortran? thread, the decision was taken to just add all the Fortran syntax to Julie 2.0. Julie 2.0 will be able to compile and run Fortran programs, even those written 70 years ago. An additional benefit will be the users will be able to code Do loops, as God intended.
A suggestion was made to include all of Python syntax as well, but so many people in the meeting started barfing that the meeting had to be adjourned and no decision was taken.
Your Turn
The definition of Julie 2.0 has not yet been finalized, so you still have a change to suggest gratuitous and annoying changes. The success of Julie 2.0 depends on the contributions of users like you.
