> he begin/end is due to Matlab

Octave has solved this by allowing both matlab-style "end", as well as block-specific endings, like "endif", "endfunction", "endfor", etc.

Having several end end end endings without any hint of what they are closing is one of the ugliest parts of matlab. Even though you are reimplementing this for compatibility reasons, it is rather sad that you chose to make this the default behaviour for Julia.

I agree. If all they say is "end end end" you might as well use braces. I'm depressed to hear that Matlab is an inspiration to the language design at all; the Matlab language is by far the worst aspect of Matlab, and it has nothing to recommend it. Think of the damage that Sun did to Java to make it look familiar to C programmers; no need to repeat that mistake (though if you're cynical, you might think it was the smartest thing they ever did.)

Braces would be better than ending keywords, in my opinion, but I'm disappointed not to see whitespace-defined blocks of a la Python. Perhaps that doesn't work in a statically-typed, type-inferred language, but if it does, I think it would be much better. Scientists have no problem with it (certainly less of a problem than programmers do) and Python is pretty well accepted in the scientific computing community.

Whitespace-based layout works quite well in Haskell: http://www.haskell.org/onlinereport/lexemes.html#lexemes-lay...

The language is still quite young and is certainly going to mature. Also, it is open source. So, please do not lose heart, not just yet. :-)

> So, please do not lose heart, not just yet.

If I weren't excited about it, I wouldnt even be commenting on it. ;)

Seems like an easy fix.

Using curly braces for blocking is a non-starter because they're used for a lot of other things, and honestly, bracket pairs like (), [], {} are way too precious, imo, to squander on something like blocks. Parens () are exclusively for function application; square brackets [] are exclusively for indexing operations; curly braces {} are for type parameterization. The other option that C++ popularized the use of is <> — but that's syntactically sketchy since both < and > are valid by themselves. It makes parsing a complete nightmare — both for machines and, to a lesser extent, people. I wouldn't be completely averse to indentation-based blocking, but I'm not really a huge fan of it either. I'm cool with the way both Matlab and Ruby do it, which is using `end`. Could conceivably change, but relatively trivial syntactic alterations like this are a really low priority. What we have now works well and is familiar to both Ruby and Matlab programmers.

> bracket pairs like (), [], {} are way too precious, imo, to squander on something like blocks

I disagree. Besides (), [], {}, and <>, there's plenty of other paired punctuation available in Unicode, such as...

⦃⦄⦅⦆⦇⦈⦉⦊⦋⦌⦍⦎⦏⦐⦑⦒⦓⦔⦖⦕⦗⦘⧘⧙⧚⧛⧼⧽〈〉《》「」『』【】〔〕〖〗〘〙〚〛❨❩❪❫❬❭❮❯❰❱❲❳❴❵⟦⟧⟨⟩⟪⟫

Yeah, but those don't sit directly on your keyboard.

Neither do many foreign language tokens like 我是加拿大人 but that doesn't stop me typing them in quickly using the IME. Admittedly those brackets aren't in any IME I know, but maybe they should be.

Matlab already allows you to omit the 'end' from function definitions, which many people find easier to read, and my experience seeing people transition from Matlab/Octave to Python+Numpy+Scipy is that people get on board with indentation-delimited blocks, because that's the way they write code anyway. But I agree - at the moment it's a pretty trivial thing. As a heavy user of Matlab, R and Py+N+S I'm looking forward to trying out Julia.

I personally found it worse to read, because it makes function blocks different from other blocks. Also, if you define nested functions in Matlab, all functions in the file have to be closed with end anyway.

Nothing is as bad, though, as the default Matlab behavior of not indenting first-level function code. This makes it really hard to scan a file with multiple functions and see where they separate.

I was referring specifically to supporting the Octave conventions, a superset of Matlab's, which make it easier to match up begins and ends.

When I said "easy fix" I meant "a trivial extension to the parser" without realizing you would translate that to "really low priority". Guess I'll save my non-trivial suggestions. :)

While you are at it could you support alternate syntaxes for the same Expr ? Perhaps encoding the syntax version at the top of the file or setting the reader at the top of the file? For those porting matlab code over either provide a tool to translate the source or put the reader in matlab compatible mode.