Gratuitous, Annoying Changes for Julie 2.0

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 
    c = -999
    n = 0 
    t = 0 
    d = 0 
    @label j20
        n += 1
    @goto j60
    @label j40 
        if t==20 
            @goto j200
    @goto j20
    @label j60 
        d = 0
    for f in 1:Int(round(n/2))
        if mod(n,f) == 0
            d += 1
    if d > c 
        @goto j120
    @label j70 
        @goto j40
    @label j120 
        c = d
        t += 1
    @goto j70
    @label j200 
        println("the 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 blah with 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 like import Foo and then interspersed with that are these hideous from Bar import baz statements, 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.


I don’t know if this is the right direction. I don’t think we should be copying MATLAB’s design philosophy.


:laughing: :sweat_smile: :rofl: :troll:


Your comment reminded me that I left something out!

Julie 2.0 will cost $5000 (per user) to download. Each package you download will cost $1200 (per user).

Per year.


It’s not April fools, bad timing

1 Like

No one wants to litter the code base with . everywhere. I want Julie 2.0 to use R like broadcast to make my life easier. It’s just so much faster and easier on the eyes

1 Like

There are use cases of julia in which this is negligible cost.

1 Like

If this will not be in Juliae 2.0 I insist, that syntactic indentation is recognized and end keyword is optional. I finally want my loops to be:

for i = start:end
println("Isn't that so much more readable?")

If not I change to Tuplex as my only language for all future:
Good bye.

The R assignment operator ← would be great as well!


Excellent! I shall get some of my old card decks ready to run then.
Hollerith constants are good enough for anyone.


I know this thread is in offtopic and tagged humor, but I’m afraid the mocking of other language designs will look very arrogant and uninviting to people from other communities.


The Pascal assignment operator would be excellent :=
I always read that as ‘becomes equal to’


I would suggest to use Pascal := for assignment by value, and R operator ← for assignment by reference. Then the equal sing = can be used in comparisons, eliminating the source of many errors.


That’s true. Let’s mix some Julia oddities in (because any language has some):
…Well I am bad in doing this, but I think Julias Scoping Rules are quite special …

Let’s make them more confusing for Juliae 2.0!


Let’s make AbstractArrays covariant by simply defining

const NewAbstractArray{T,N} = AbstractArray{<:T,N}

(and making this type the new default AbstractArray)
Then finally, in Julie 2.0 we can happily write

f(x::AbstractArray{Number}) = my definition
1 Like

And to think I almost skipped over this thread because of the title…


from Julie 2.0 humor will be banned, so enjoy it while it lasts!


Julia already has @goto for Julie 2.0 I think we really need @comefrom


Humor is banned but Humour is not.

1 Like

One thing that Julie 2.0 definitely needs to adopt from Matlab is displaying a gratuitous, annoying plot for a couple of seconds before giving you a REPL.

That will stop people complaining about the time to first plot.