Julie 2.0 definitely needs to import this Python 4.0 fix!
So you know how Googling Julia is hard and C++ came after C and the defining characteristic of Julia is Unicode support? I propose Julie ÷÷.
I know what you’re thinking: how will people Google that if they don’t know how to type ÷? They can copy it from the Julie website. Boom.
Also, starting arrays on 0.5 seems like a good compromise.
You know, I’ve never much cared for LLVM. Maybe Julie 2.0 should compile to powerpoint instead. More people are familiar with it and it is much more user-friendly. It’s hard to keep up with LLVM anyway, isn’t it?
How about resurrecting the COBOL ALTER verb? Then you have traceless self-modifying code!
“perform … alter” conjures long-buried memories of PERFORM ( … ) VARYING and the loveliest of all, PERFORM ( … ) THROUGH, maybe claiming the crown of un-traceability.
The suffix of Juliæ 2.0 files shall be .jæ
I know Julia could reuse Python code, I want a similar thing for Brain Fuck and Whitespace. 
What about selling out Julia to M$ like Github did?
I guess that would give us Visual Julæ
and the new extension .jlx for Julie files…
Ooh, and it could be a compressed file format, so there is no risk the source is viewed or edited in unauthorized software!
Can we also have a @goto across files? I think that would improve readability and help the user avoiding Insufficient IQ errors.
I would like to see array indexing set straight for good. Arrays should be row-major, but with the first index moving along the row. In other words A[3, 2] would refer to the third column, second row.
This fixes the confusion between xyz-ordering of 3D space and the yxz-ordering of array indexing. It also makes the innermost dimension consistent with text, thereby improving printing to screen: flat, 1D vectors would then be interpreted as ‘row-like’, and would be printed as
[1,2,3]
# instead of
1
2
3
The ‘switchy-orderiness’ of x and y when working with arrays interpreted as spatial positions would then finally go away. This post is based on a lot of frustration over time.
After fixing Julia, we simply add a pull request to “united nations/mathematics/linear algebra” where we make vectors into row vectors by default, and change matrix indexing to conform with Julia 2.0.
Also, I would like to have:
.j, .jh, .jlh - for declarations
.jc .jlc - for definitions and compilation units
.jjit .jljit - for interpretable code, that cannot be compiled
.jm, .jlm - for modules (they are also important guys to have their own format)
Historically, Julia used 0-based indexing [citation needed] because it is better, but in 1.0, we switched to 1 based indexing to add a more unique flavor to the language. Due to the increasing popularity of 2-based indexing, and to improve adoption, we’re migrating this key part of the package ecosystem into base and enabling it by default in Juliæ 2.0.
For high performance code designed to operate on all versions of Julia/æ, we recommend assuming indexing starts at VERSION.major rather than utilizing the more complex firstindex function.
(Not joking) Actually I’ve always used .jlx as the extension for files produced by Julia’s Serialization module. Is there a more standard alternative extension?
.jls
That seems to be inventing history. I’ve been using Julia since v0.3, and (apart from the obvious OffsetArrays) haven’t seen 0-based indexing.
One person saying they prefer it, doesn’t make it better. Or worse.
I programmed C/Java/Ruby/etc for a long time, so was used to 0-based indexing. Now I program almost exclusively Julia, so think in terms of 1-based indexing. It’s not better or worse, just different.
I think you’ll find that comment was entirely sarcastic.