Why does julia use END for block end?

[Ford Ox]

Is there any reasoning behind it? It seems to me like a weird choice since you have to type three letters, which is the complete opposite of the goal of this language - being very productive (a lot work done with little code).
On top of that, brain has to read the word every time your eyes look at it so you spend more time also reading the code - tho this should be easy to omit, by highlighting this keyword by other color than other keywords (the current purple color in ATOM just drives me crazy, since it is one of the most violent colors, so my eyes always try to read that useless piece of information first, instead of the important code).

[Stefan Karpinski]

There is a long history of languages using this syntax, including Algol, Pascal, Ruby and Matlab.

[Ford Ox]

Good that I didnt meet them yet :]

[Adrian Salceanu]

The only place where I find the "end" requirement annoying is for one line IF statements. When you have a short one liner, the "end" part just does not feel right. It would be nice if the "end" could be left out for one liners. Even PHP allows one to skip the accolades in such cases. 

If there's some other way of achieving this I'd love to hear about it. I don't like the ternary operator in this situation cause it forces me to add the 3rd part as "nothing" or whatever. And doing "expr1 && expr2" only works when expr2 is "return" for instance, otherwise the compiler complains about using a non-boolean in a boolean context. 

[Tom Short]

You can make a quick macro for one-line if statements:

macro when(condition, expr)

    esc(:( if $condition; $expr; end))

end

@when 4 > pi  x = 2

For even more compact syntax, you can replace `when` with `?`.

[Stefan Karpinski]

I proposed this once upon a time: https://github.com/JuliaLang/julia/issues/1657; it wasn't popular. Please don't start commenting on that long-dead issue – keep the discussion here instead.

[David Anthoff]

See also https://github.com/JuliaLang/julia/issues/6823

[Yichao Yu]

On Fri, May 6, 2016 at 3:12 PM, Adrian Salceanu
<adrian....@gmail.com> wrote:

> The only place where I find the "end" requirement annoying is for one line
> IF statements. When you have a short one liner, the "end" part just does not
> feel right. It would be nice if the "end" could be left out for one liners.
> Even PHP allows one to skip the accolades in such cases.
>
> If there's some other way of achieving this I'd love to hear about it. I
> don't like the ternary operator in this situation cause it forces me to add
> the 3rd part as "nothing" or whatever. And doing "expr1 && expr2" only works
> when expr2 is "return" for instance, otherwise the compiler complains about
> using a non-boolean in a boolean context.

It shouldn't. Unless you are using the result in a boolean context.
The only case where this doesn't work is assignment, where `a && b =
c` is parsed as `(a && b) = c` and not `a && (b = c)`. This can be
workaround by adding parenthesis as shown above and maybe we can also
change the parser too?

[Tom Breloff]

Seems like a parser change is more correct.  What exactly does it mean to say "true = 5"?

[E. Tadeu]

Is it too late to support dedentation (removing indentation) as a block terminator, like in Python? :)

[Stefan Karpinski]

Yes.

[Tim Holy]

I think the problem was expr1, not expr2: you probably didn't make expr1
return a Bool. (Julia deliberately does not support "if cond" unless cond is a
Bool.)

Demo of correct usage:

julia> x = 5
5

julia> x == 4 && "hello"
false

julia> x == 5 && "world"
"world"

Best,
--Tim

On Friday, May 06, 2016 12:12:28 PM Adrian Salceanu wrote:
> The only place where I find the "end" requirement annoying is for one line
> IF statements. When you have a short one liner, the "end" part just does
> not feel right. It would be nice if the "end" could be left out for one
> liners. Even PHP allows one to skip the accolades in such cases.
>
> If there's some other way of achieving this I'd love to hear about it. I
> don't like the ternary operator in this situation cause it forces me to add
> the 3rd part as "nothing" or whatever. And doing "expr1 && expr2" only
> works when expr2 is "return" for instance, otherwise the compiler complains
> about using a non-boolean in a boolean context.
>
> vineri, 6 mai 2016, 20:37:49 UTC+2, Stefan Karpinski a scris:
> > There is a long history of languages using this syntax, including Algol,
> > Pascal, Ruby and Matlab.
> >

> > On Fri, May 6, 2016 at 2:26 PM, Ford Ox <ford...@gmail.com <javascript:>>

[E. Tadeu]

Then I guess we can get used to the end statement. I don’t see it as big deal, it's just one extra line and after some coding we learn to ignore it. ;)

​

[Adrian Salceanu]

That's a good point, with the parenthesis it does work as expected in case of an assignment, thanks! 

[Adrian Salceanu]

That's right Tim, it does work! Huhm... I can't exactly remember where I tripped into this one, as since I've abandoned this style and it's been a while. But yes, the explanation must be that the _first_ expression was not a boolean. 

Loving this, thanks very much! 

[DNF]

I find 'end' to be the best choice of block terminator among the ones I have seen. 

It is very clear and explicit, there is no doubt as to what it means, unlike '}' which is way too small and ambiguous (does it mean end of block, or end of dict definition, etc.), and just does not jump out at you the way it should.

You are also wrong that it takes longer to read, since you read it as a single unit, you don't parse every single letter, unless you are in the process of learning to read. And since it is so unambiguous, it is much faster to read than any alternative I've seen.

As for whitespace-dependent, Python style, block delimiters, I have been working with those over the last few months, and have learned to abhor them. They are very brittle, outdent something by accident and the code breaks, perhaps completely invisibly. If you share code with someone that uses 2-space indentations (as I have), fixing that is a big headache. Last, but not least, it completely lacks the tidy symmetry and definitiveness of begin-end blocks, the code seems to slide across the page and then just trail off like a bad idea abandoned in mid-thought.

I love 'end', please keep it :)

[randm...@gmail.com]

Also, since you're using Atom you could just edit your stylesheet (go to Settings => Themes and click the link at the top) to include something like

atom-text-editor::shadow .keyword.control.end.julia {
  color: gray;
}

which would make the end a bit more subtle.

[Didier Verna]

DNF <oyv...@gmail.com> wrote:

> It is very clear and explicit, there is no doubt as to what it means,
> unlike '}' which is way too small and ambiguous (does it mean end of
> block, or end of dict definition, etc.), and just does not jump out at
> you the way it should.

'end' is extremely verbose, just like 'function', 'global', 'local' etc.

You are also wrong about the curly brace's ambiguity. If you find it
ambiguous, that is because you live in a world overflown with
syntax. You don't need end of blocks or dict definitions to be
different things. You only really need an end of /expression/. And
BTW, I have a hard time figuring out why 'end' wouldn't be ambiguous
while '}' would be, especially since 'end' ends so many different
things in Julia.

Finally you are also mistaken about the size (yes, size matters). The
curly brace isn't too small. It's too big. It's too noisy. See this
little nasty peak in the middle, on the right? It's aggressive, it's
impolite, it hurts my eyes.

No, really, the only 'end' that makes sense, should be soft, discreet,
gentle, almost invisible, in perfect harmony with the
Universe. There's only one candidate. It's... the right parenthesis
')'.

--
ELS'16, May 9-10, Krakow, Poland: http://www.european-lisp-symposium.org

Lisp, Jazz, Aïkido: http://www.didierverna.info

[Kevin Squire]

Hi Didier,

I appreciate your recent interest in Julia, and especially that you've uncovered a few inconsistencies/bugs that have been addressed, and I've found many of your questions thought provoking. 

That said, when it comes to opinions and holy wars, we very much like it more peaceful around here.  Specifically, we discourage things like calling someone's opinion "wrong" or "mistaken".  It's certainly ok to disagree, but please do so respectfully.

Facts, of course, are subject to verification. ;-)

(I realize that much of what you wrote was tongue in cheek, and I'm not taking exception with what you wrote--just how it was said.)

Cheers,

   Kevin 

[Didier Verna]

Kevin Squire <kevin....@gmail.com> wrote:

> That said, when it comes to opinions and holy wars, we very much like
> it more peaceful around here.

That message was a joke, sorry if it was taken too seriously...

[Kevin Squire]

Hi Didier,

Sorry to throw some cold water on your joke.  I half realized that it was a joke at the end of your email. 

One of the things we pride ourselves on is the welcoming nature of our community.  We're not perfect, but we try pretty hard to keep conversation respectful at the least. So when I or others see something that might be construed as unwelcoming or disrespectful, we often speak up.

At this point, knowing you meant the message as a joke, I'd love to say something snarky about lisp and parentheses... But the truth is I rather like lisp. ;-)

Cheers!

   Kevin 

On Saturday, May 7, 2016, Didier Verna <didier...@gmail.com> wrote:

[spaceLem]

Personally I love end tags. If I were allowed to make one change to Python, it would be to add them in!

As for verbose, I'm used to Octave where you also have the option of the even longer endif, endfor, endwhile, endswitch, and endfunction, which I find very handy for figuring out what level you're at in long functions. I'm actually still writing end #if in my Julia code (I'll probably get over it at some point).

On the other hand, Julia allows you to write for i=1:n, j=1:n, k=1:n; ... end which is nicely terse, and I use it so often that I really miss it in Octave.

Jamie

[Siyi Deng]

Well said. +1.