Indentation and the end statement

My surgestion is that you can some how be able to switch to an indentation version of Julia at the top of your document. So you both have a version with end statement and a version without. I know the developers of julia wanted the notation of end statement to be more like MATLAB and I agree with them on their points. But I still prefer pythons indentation when their points like copy pasting and presenting are not met. I know there have been many others before me who have raised this question but I thought I would write about my take on it.

using indentation
for i in 1:10
   if i < 5

function f(x,y)
# The return statement functions just like python

The same notion of while loops and struct ect. so the end statement becomes the indentation instead to make it more readble and you don’t have to write end statement.

Are you sure you want to create you totally own syntax that diverges from every one else’s? How does this impact collaboration and code sharing?

But actually the worst thing that could happen was if this were allowed, and the end-less syntax became popular, causing a schism in the language. The whitespace sensitivity of Python is imo its single worst feature, and I would be very unhappy for it to become a Julia feature.


I don’t mind Python’s use of whitespaces or Julia’s use of end, but I would really dislike having both in the same language.


I suspect this applies here, even though the proposal is for an option rather than a breaking change:


It’s a tradeoff with some good and bad points, but in any case it’s something that the Julia developers decided against early in the language’s development and it doesn’t make sense to revisit that decision now.

(The Julia developers also rejected my suggestion to remove all vowels from the language to improve terseness.)


I don’t see any real arguments for indentation sensitivity there. In fact, the one argument ("end is 3 characters") is easily countered by " is 4 characters".

I want to extend some praise here for Julia developers making the sensible choice - this is one of the reasons I have never wanted to learn Python.

1 Like

The arguments for indentation sensitivity, as I understand it, are not just saving typing; they are mainly (a) eliminating the “visual noise” of end statements to enhance readability (whereas whitespace introduces no “noise”), (b) forcing people to follow good indentation practices, and (c) eliminating DRY bugs due to indentation not matching the syntactic blocks. You can find plenty of arguments online in favor of indentation-sensitivity on these grounds, e.g. here and here and this stackexchange thread.

There are also a lot of downsides, of course … we don’t need to re-hash the disadvantages here!

I’m pretty happy with Julia’s choice, personally, but this kind of surface-syntax issue is the least interesting question for me when comparing languages. If you wrote a “Pyulia” front end for Julia with significant indentation instead of end statements, it would still be essentially the same language, albeit a variant that seems unlikely to gain much traction at this point.


I tend to think of it as ‘signal’, not ‘noise’. It carries useful information. I wouldn’t say that whitespace isn’t noisy. It certainly looks disturbing to me.


What about an editor plugin? In the situations where indentation matches and the end is on a line by itself, you could just hide the line. Editors can currently also automatically insert ends and indent.

That seems far more tractable — then it’s not a dialect of Julia or even an option. It’s a display option for people who want it. Your code would still be completely readable by plain old Julia (even older versions) and others.

I don’t want it, so I won’t be driving this forward, but it seems like an interesting possibility.


Fun fact: Juno displays end with lower opacity for this reason


My Julia color theme for VS Code also colors the end keyword a darker color:


begin print("hi"); print("is this still in the block?");
println("What about me"?");
@sync @spawn ()->sleep(5) && println("a"); @spawn sleep(2); println("b"); 

As far as I know I don’t suffer from OCD. But to me the lack of explicit end block markers in Python still triggers an OCD-like feeling of wrongness. Indented code just hangs in the sky, unsupported, in much the same way that bricks don’t. It’s quite disturbing in a vague way (sort of like reading text with unclosed brackets.


Interesting, for me Python code is exactly right, as it visually shows the logical tree-structure of code (class, method, blocks, etc). Having extra brackets/keywords to close blocks just seems superfluous to me :slight_smile:


That’s a very assymmetrical tree, with branches hanging on one side, and tilting dangerously.


To me, the end statement represents formality and is part of the grammar of programming Sure, you can read things just fine without it, and we type less if we drop it, but our code is simply incomplete without it Much like this post is totally readable, yet contains no end of sentence markers (periods)


If Julia and Python were LISPs


((() () ()) (() ()) ())


(    (        (        (        (    (        (        (    (

The end of the end statement would be the end for me. After all, where would it end?

(My main reason for disliking Python before I’d even heard of Julia.)

@TheGrowingPlant443 Obvs. Making white space a big part of Julia’s syntax would create a new and incompatible language. Just write a plugin for VSCode that displays the code with Python indentation and with no end in sight. Then you can be happy without mucking up Julia. :grinning: :grinning:

1 Like

I think this is a very important point - code which is incorrectly idented (i.e. where the identation does not match the actual code blocks) is very difficult to read and error-prone.

Is there a linter or autoformatter available in Julia which checks / enforces it?

There is

but I haven’t tried it (although I think the VSCode extension was planning to switch to this at some point, so I might be using it unknowingly…)