Yeah, we've been waiting for a while for Fortress too. It seems like a lot of time and effort has gone into a WYSIWYG IDE and not as much into the actual language implementation :-(

Chapel has made a lot of progress in the past 2.5 years (while we've been working on Julia) and is certainly a contender.

Julia certainly aims to be more dynamic like Clojure, but specially designed to be good for numerical and technical stuff, and yes, the begin/end is due to Matlab — scientists who have a lot of code in Matlab already are a major target demographic. As it is, a lot of Matlab code ports over with relatively trivial changes (see: http://julialang.org/manual/getting-started/#Major+Differenc...), which was the point of syntactic similarity to Matlab.

> 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.

I think i've been waiting for Chapel more than X10 or Fortress, but scala and clojure are assuming the mantles as general purpose languages.

http://bartoszmilewski.wordpress.com/2011/11/07/supercomputi...

http://lambda-the-ultimate.org/node/4405

Languages built on the JVM have to deal with boxing and unboxing. Scala still doesn't have efficient arrays of unboxed values. Progress here: http://docs.scala-lang.org/sips/pending/value-classes.html

After that proposal is implemented (perhaps in version 3 of Scala, almost ten years after its first release, though granted it wasn't their top priority) they'll still have to write at least a little bit of boilerplate for each type they want to store in unboxed arrays, and they'll be limited to types that can be stored as Java primitive types under the covers. That seems like a pretty nasty limitation for a general-purpose scientific computing language, not only because it decreases native performance but because it makes C interop much more difficult.

For a general-purpose scientific language, I think it is imperative to adopt the principle that any user-designed type should be able to achieve the same power, performance, and elegance as if it were a built-in type. To the best of my knowledge, that rules out JVM languages.

(Scala was never meant to be a "JVM language," but in terms of its strengths, its weaknesses, its user base, and its future, it is very much a JVM language, and the obstacles to implementing efficient user-defined types is one of the trade-offs they accepted when they went with the JVM.)

I agree, and I think Julia's designers have chosen correctly not to use the JVM (although, in the comments below you'll find that Julia uses boxed types for "structs" as well, though it would be far easier to build true array-embeddable complex types on LLVM than on the JVM). However, value types for the JVM are a work in progress (as well as tail-calls), and I think they might have already been implemented in the DaVinchi project (future JVM improvements), and so will find their way to the JVM in due time (see https://blogs.oracle.com/jrose/entry/tuples_in_the_vm). Until then, scientific computing languages will most likely choose a different platform.

It's worth looking at the PPL project

http://ppl.stanford.edu/main/publications.html

example, this scala DSL:

http://liszt.stanford.edu/liszt_sc2011.pdf