5 ms·

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 langua

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+Differences+From+MATLAB® http://julialang.org/manual/getting-started/#Major+Differenc...), which was the point of syntactic similarity to Matlab.

muuh-gnu 15y ago
> 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.
- ViralBShah 15y ago
  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. :-)
  - muuh-gnu 15y ago
    > So, please do not lose heart, not just yet. If I weren't excited about it, I wouldnt even be commenting on it. ;)
- warmfuzzykitten 15y ago
  Seems like an easy fix.
  - StefanKarpinski 15y ago
    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.
    - vorg 15y ago
      > 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... ⦃⦄⦅⦆⦇⦈⦉⦊⦋⦌⦍⦎⦏⦐⦑⦒⦓⦔⦖⦕⦗⦘⧘⧙⧚⧛⧼⧽〈〉《》「」『』【】〔〕〖〗〘〙〚〛❨❩❪❫❬❭❮❯❰❱❲❳❴❵⟦⟧⟨⟩⟪⟫
      - Inufu 15y ago
        Yeah, but those don't sit directly on your keyboard.
        vorg 15y ago
        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.
    - crntaylor 15y ago
      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.
- dkarl 15y ago
  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.
  - mietek 15y ago
    Whitespace-based layout works quite well in Haskell: http://www.haskell.org/onlinereport/lexemes.html#lexemes-layout http://www.haskell.org/onlinereport/lexemes.html#lexemes-lay...
sitkack 15y ago
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.

muuh-gnu 15y ago

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

ViralBShah 15y ago
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. :-)
- muuh-gnu 15y ago
  > So, please do not lose heart, not just yet. If I weren't excited about it, I wouldnt even be commenting on it. ;)
warmfuzzykitten 15y ago
Seems like an easy fix.
- StefanKarpinski 15y ago
  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.
  - vorg 15y ago
    > 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... ⦃⦄⦅⦆⦇⦈⦉⦊⦋⦌⦍⦎⦏⦐⦑⦒⦓⦔⦖⦕⦗⦘⧘⧙⧚⧛⧼⧽〈〉《》「」『』【】〔〕〖〗〘〙〚〛❨❩❪❫❬❭❮❯❰❱❲❳❴❵⟦⟧⟨⟩⟪⟫
    - Inufu 15y ago
      Yeah, but those don't sit directly on your keyboard.
      - vorg 15y ago
        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.
  - crntaylor 15y ago
    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.
dkarl 15y ago
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.
- mietek 15y ago
  Whitespace-based layout works quite well in Haskell: http://www.haskell.org/onlinereport/lexemes.html#lexemes-layout http://www.haskell.org/onlinereport/lexemes.html#lexemes-lay...

sitkack 15y ago

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.