8 ms·

I wonder what they think about or have learned from http://en.wikipedia.org/wiki/Fortress_(programming_language) http://en.wikipedia.org/wiki/Fortress_(programm

by mjw 15y ago

I wonder what they think about or have learned from http://en.wikipedia.org/wiki/Fortress_(programming_language) http://en.wikipedia.org/wiki/Fortress_(programming_language) , another recent-ish attempt to deliver a modern and powerful scientific programming language. Personally I'm a little wary of being ghettoised into something overly domain-specific for scientific/numerical computing. Really good interop may mitigate that -- something which can navigate the unholy mix of C, C++, fortran, matlab, octave, R and python routines one comes across trying to reproduce others research work, would indeed be awesome. I do wonder if some of the noble demands of this project might be better delegated to library developers though, after adding a bare minimum of syntax and feature support to a powerful general-purpose language. For now Python+numpy+scipy seems a great 90% solution here.

wbhart 15y ago
And what should the library writers use? The great advantage of this is that much of it can be done in one language. From the article: "The library, mostly written in Julia itself, also integrates mature, best-of-breed C and Fortran libraries for linear algebra, random number generation, FFTs, and string processing."
fijal 15y ago
Python+numpy+scipy does work only if you actually don't write much python or at least not run much python. Otherwise it sucks
- joelthelion 15y ago
  Just wait for Numpy on PyPy to be available :)
  - FraaJad 15y ago
    Do you realise you are talking to a PyPy core dev? ;)
    - infinite8s 15y ago
      In particular, one who has worked on numpypy (http://lostinjit.blogspot.com/2011/12/personal-view-on-pypys-future.html http://lostinjit.blogspot.com/2011/12/personal-view-on-pypys...)
- ViralBShah 15y ago
  I wouldn't say that it sucks - that's way too strong. I am one of the authors of Circuitscape (http://www.circuitscape.org http://www.circuitscape.org), which uses python+numpy+scipy. The community loves it, the fact that its python, open source, embeddable in other tools, etc. However, much of the code is written in a vectorized style for performance reasons, as is the case with many high level scientific computing languages. This leads to unnatural code in some cases, and also uses too much memory. First I thought IronPython was the way, but have been looking forward to pypy+numpy+scipy eagerly. If I were to use julia, the code would be a lot more natural, because type inference and all the compiler goodies make it possible to simply write loops over arrays when I need them. This was one of the reasons we started working on julia, because everything else just seemed to fall just a little bit short.
  - andreasvc 15y ago
    What do you think of cython+python+numpy? I've used it successfully to do NLP work.
- mjw 15y ago
  OK, perhaps I should have qualified that. It's a good 90% solution for a lot of use cases, although obviously more useful for implementing algorithms in terms of numerical building blocks, than ultra-performance-critical code where you want to write a lot of your own tight inner loops. Is that what you meant? The parallelisation story isn't great at the moment either, although seems like it has the potential to improve. Still 'sucks' is pretty harsh. For me, looking at how far it's come since I first played with it, I'm impressed. For machine learning, the majority of the building blocks one needs are there, and you get to sit back and put them together using a nice, clean, widely-adopted general purpose programming language. And unlike MATLAB still maintain a decent amount of control over things like memory usage and which BLAS routines it's calling. Adding bindings for new libraries is more of a pain than it should be though on the occasions where you do really need some fortran or C++ library that doesn't have bindings yet. A language which bridges the gap between high and low levels (not C++!) and has great interop would be very interesting. I guess I'm just hopeful that this kind of thing can be achieved in a general-purpose language (new or existing) which like Python is adopted across the wider software engineering community. Perhaps that's my unreasonable demand to add to their list :)
- pwang 15y ago
  > Otherwise it sucks Seriously? I mean, I know you are very excited about your work on PyPy, but why do you have to go around saying baseless stuff like this? There are many, many thousands of people who write lots of Python code every day that rely on Numpy, Scipy, and Matplotlib to get their work done, and who seem to be quite pleased with it. There is a lot of work left to do on all parts of that stack, but that's a far cry from "it sucks".
  - fijal 15y ago
    I guess I should clarify that - performance sucks. There are obviously various ways around it, but you just can't write a lot of performance critical python that way and I guess this is one of the reasons why julia exists in the first place.
    - pwang 15y ago
      But if you look at the actual cutting edge research work in the HPC and scientific space, they are working on languages that allow domain experts to express computation using higher level primitives, not on fancy compiler techniques to make general purpose imperative languages like C or Python "automagically" run faster on single cores. The general consensus, if you look at languages like Chapel and Fortress and X10, seems to be that most scientific codes shouldn't be written using for-loops. That is the low-level control flow construct dating from the age of assembler. Instead, what scientists generally want to say is, "Apply this kernel across this domain, with these windowing conditions", or "Reduce values from this computation along these keys in my dataset". As software developers, our job is to provide the language runtime to allow them to do that; such a runtime will be the most robust, correct, maintainable, and performant.
      - fijal 15y ago
        Right. I think we actually violently agree with each other on that :) Note that in general it's ok to not write much python and live very happily just using it for non-performance critical parts. No doubt we both know a lot of people who are quite happy with that. The problem with numpy's performance is twofold: * Numpy expressions might not be fast enough. I believe you guys at continuum are trying to address that one way or another. In general the kernel expressed using high-level constructs in python should not be slower than an equivalent loop in C. * Sometimes you actually want to write a for loop, because you don't care, because it's faster, because it's a single run, because the data is manageable etc. You should not be punished for doing that with 100x performance drop. You can still be punished for that with 2x performance drop.
- teoliphant 15y ago
  Nice, Fijal. It's good that I can count on you for un-biased opinions.
pron 15y ago
I've been waiting for Fortress for a LONG time, but either progress has been real slow or the Fortress team has trouble communicating their progress to the community. Probably both. From a quick look I can tell that while Fortress is more similar to Scala, with classes, mixins and static typing, Julia is closer to Clojure, with no encapsulation, dynamic typing, homoiconicity, and separation of behavior (methods) from concrete types (akin to Clojure's protocols). I really like the choices Julia's designers have made, particularly multiple-dispatch methods, final concrete types and lispy macros. The language seems very elegant. Not too crazy about "begin" and "end" syntax, though :)
- StefanKarpinski 15y ago
  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. :-)
StefanKarpinski 15y ago
I huge part of the goal here is to reduce the need for the "unholy mix of C, C++, fortran, matlab, octave, R and python routines" in both academic research work and machine learning / data science code in industrial settings. The whole project kicked off with me ranting about how I was sick of cobbling things together in six or seven different languages. So interop is a very, very high priority. We have pretty good C ABI interop now. You can just call a C function like this: ccall(:getpid, Uint32, ()) and it works. It works in the repl too and you can dynamically load new libraries in the repl. See this manual page for more details: http://julialang.org/manual/calling-c-and-fortran-code/ http://julialang.org/manual/calling-c-and-fortran-code/. We still want better C/C++ interop though. I've already looked into using libclang so that if you have the headers you don't even have to declare what the interface to a function is. That was very preliminary work, but I got some stuff working. Making Julia versions of C struct types transparently would be another goal here. Another major interop issue is support for arrays of inline structs (as compared to arrays pointers to heap-allocated structs). C can of course do this, but in any language where objects are boxed, it becomes very tricky. We're working on it, however, anyone who wants to discuss, hop on julia-dev@googlegroups.com :-)
- pron 15y ago
  > Another major interop issue is support for arrays of inline structs Oh, so arrays of complex numbers are implemented as arrays of pointers to objects? That would give really bad CPU cache performance.
  - sparsevector 15y ago
    It sounds like he's saying it's hard for Julia to interop with languages that don't support arrays of inline structs (e.g. Java). I could be misreading it though.
  - StefanKarpinski 15y ago
    No, currently it's an inline array of immutable 128-bit numeric values and we use bit-twiddling to pull the real and imaginary parts out. However, that's a temporary hack. (It's also why the mandel benchmark is relatively slow — all the bit-twiddling is not very efficient.) The longer-term approach is still up in the air and that's what I was talking about above. My favorite approach at this point is to allow fields to be declared as const — which in Julia means write-once. Then if all fields are const the object is immutable and can automatically be stored in arrays inline.

by mjw 15y ago

wbhart 15y ago

And what should the library writers use? The great advantage of this is that much of it can be done in one language. From the article: "The library, mostly written in Julia itself, also integrates mature, best-of-breed C and Fortran libraries for linear algebra, random number generation, FFTs, and string processing."

fijal 15y ago

Python+numpy+scipy does work only if you actually don't write much python or at least not run much python. Otherwise it sucks

joelthelion 15y ago
Just wait for Numpy on PyPy to be available :)
- FraaJad 15y ago
  Do you realise you are talking to a PyPy core dev? ;)
  - infinite8s 15y ago
    In particular, one who has worked on numpypy (http://lostinjit.blogspot.com/2011/12/personal-view-on-pypys-future.html http://lostinjit.blogspot.com/2011/12/personal-view-on-pypys...)
ViralBShah 15y ago
I wouldn't say that it sucks - that's way too strong. I am one of the authors of Circuitscape (http://www.circuitscape.org http://www.circuitscape.org), which uses python+numpy+scipy. The community loves it, the fact that its python, open source, embeddable in other tools, etc. However, much of the code is written in a vectorized style for performance reasons, as is the case with many high level scientific computing languages. This leads to unnatural code in some cases, and also uses too much memory. First I thought IronPython was the way, but have been looking forward to pypy+numpy+scipy eagerly. If I were to use julia, the code would be a lot more natural, because type inference and all the compiler goodies make it possible to simply write loops over arrays when I need them. This was one of the reasons we started working on julia, because everything else just seemed to fall just a little bit short.
- andreasvc 15y ago
  What do you think of cython+python+numpy? I've used it successfully to do NLP work.
mjw 15y ago
OK, perhaps I should have qualified that. It's a good 90% solution for a lot of use cases, although obviously more useful for implementing algorithms in terms of numerical building blocks, than ultra-performance-critical code where you want to write a lot of your own tight inner loops. Is that what you meant? The parallelisation story isn't great at the moment either, although seems like it has the potential to improve. Still 'sucks' is pretty harsh. For me, looking at how far it's come since I first played with it, I'm impressed. For machine learning, the majority of the building blocks one needs are there, and you get to sit back and put them together using a nice, clean, widely-adopted general purpose programming language. And unlike MATLAB still maintain a decent amount of control over things like memory usage and which BLAS routines it's calling. Adding bindings for new libraries is more of a pain than it should be though on the occasions where you do really need some fortran or C++ library that doesn't have bindings yet. A language which bridges the gap between high and low levels (not C++!) and has great interop would be very interesting. I guess I'm just hopeful that this kind of thing can be achieved in a general-purpose language (new or existing) which like Python is adopted across the wider software engineering community. Perhaps that's my unreasonable demand to add to their list :)
pwang 15y ago
> Otherwise it sucks Seriously? I mean, I know you are very excited about your work on PyPy, but why do you have to go around saying baseless stuff like this? There are many, many thousands of people who write lots of Python code every day that rely on Numpy, Scipy, and Matplotlib to get their work done, and who seem to be quite pleased with it. There is a lot of work left to do on all parts of that stack, but that's a far cry from "it sucks".
- fijal 15y ago
  I guess I should clarify that - performance sucks. There are obviously various ways around it, but you just can't write a lot of performance critical python that way and I guess this is one of the reasons why julia exists in the first place.
  - pwang 15y ago
    But if you look at the actual cutting edge research work in the HPC and scientific space, they are working on languages that allow domain experts to express computation using higher level primitives, not on fancy compiler techniques to make general purpose imperative languages like C or Python "automagically" run faster on single cores. The general consensus, if you look at languages like Chapel and Fortress and X10, seems to be that most scientific codes shouldn't be written using for-loops. That is the low-level control flow construct dating from the age of assembler. Instead, what scientists generally want to say is, "Apply this kernel across this domain, with these windowing conditions", or "Reduce values from this computation along these keys in my dataset". As software developers, our job is to provide the language runtime to allow them to do that; such a runtime will be the most robust, correct, maintainable, and performant.
    - fijal 15y ago
      Right. I think we actually violently agree with each other on that :) Note that in general it's ok to not write much python and live very happily just using it for non-performance critical parts. No doubt we both know a lot of people who are quite happy with that. The problem with numpy's performance is twofold: * Numpy expressions might not be fast enough. I believe you guys at continuum are trying to address that one way or another. In general the kernel expressed using high-level constructs in python should not be slower than an equivalent loop in C. * Sometimes you actually want to write a for loop, because you don't care, because it's faster, because it's a single run, because the data is manageable etc. You should not be punished for doing that with 100x performance drop. You can still be punished for that with 2x performance drop.
teoliphant 15y ago
Nice, Fijal. It's good that I can count on you for un-biased opinions.

pron 15y ago

I've been waiting for Fortress for a LONG time, but either progress has been real slow or the Fortress team has trouble communicating their progress to the community. Probably both. From a quick look I can tell that while Fortress is more similar to Scala, with classes, mixins and static typing, Julia is closer to Clojure, with no encapsulation, dynamic typing, homoiconicity, and separation of behavior (methods) from concrete types (akin to Clojure's protocols). I really like the choices Julia's designers have made, particularly multiple-dispatch methods, final concrete types and lispy macros. The language seems very elegant. Not too crazy about "begin" and "end" syntax, though :)

StefanKarpinski 15y ago
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. :-)

StefanKarpinski 15y ago

I huge part of the goal here is to reduce the need for the "unholy mix of C, C++, fortran, matlab, octave, R and python routines" in both academic research work and machine learning / data science code in industrial settings. The whole project kicked off with me ranting about how I was sick of cobbling things together in six or seven different languages. So interop is a very, very high priority. We have pretty good C ABI interop now. You can just call a C function like this: ccall(:getpid, Uint32, ()) and it works. It works in the repl too and you can dynamically load new libraries in the repl. See this manual page for more details: http://julialang.org/manual/calling-c-and-fortran-code/ http://julialang.org/manual/calling-c-and-fortran-code/. We still want better C/C++ interop though. I've already looked into using libclang so that if you have the headers you don't even have to declare what the interface to a function is. That was very preliminary work, but I got some stuff working. Making Julia versions of C struct types transparently would be another goal here. Another major interop issue is support for arrays of inline structs (as compared to arrays pointers to heap-allocated structs). C can of course do this, but in any language where objects are boxed, it becomes very tricky. We're working on it, however, anyone who wants to discuss, hop on julia-dev@googlegroups.com :-)

pron 15y ago
> Another major interop issue is support for arrays of inline structs Oh, so arrays of complex numbers are implemented as arrays of pointers to objects? That would give really bad CPU cache performance.
- sparsevector 15y ago
  It sounds like he's saying it's hard for Julia to interop with languages that don't support arrays of inline structs (e.g. Java). I could be misreading it though.
- StefanKarpinski 15y ago
  No, currently it's an inline array of immutable 128-bit numeric values and we use bit-twiddling to pull the real and imaginary parts out. However, that's a temporary hack. (It's also why the mandel benchmark is relatively slow — all the bit-twiddling is not very efficient.) The longer-term approach is still up in the air and that's what I was talking about above. My favorite approach at this point is to allow fields to be declared as const — which in Julia means write-once. Then if all fields are const the object is immutable and can automatically be stored in arrays inline.