4 ms·

What are some examples of limitations you've run into with various non-Fortran languages?

enriquto 6y ago
None of them seems "tailored" to the job of numerical computation (mostly linear algebra algorithms) like Fortran seems to be. C: it is mostly alright, especially since C99 with VLA and complex numbers. Yet the aliasing rules are a bit annoying, and multi-dimensional arrays, while possible, do not really feel natural. C++: an unholy clusterfuck... I almost ended crazy trying to use it properly. With extreme discipline maybe you can get to do some work with it. But not me. Octave: very beautiful language with a natural, concise notation for math. Excellent out-of-the-box support for sparse matrices. Shame that loops are so slow; needs a serious effort on a JIT. lua: my favorite general-purpose language. The luajit interpreter may be one of the fastest and easiest alternatives to Fortran. I wrote a matrix product using an explicit triple loop, and it multiplied huge matrices just slightly slower than an optimized blas. Extremely impressive! I'm very sad that the project is sort of "abandoned". python+numpy: My least favorite, but the one that I use the most... what can I say: this is a general-purpose language where you can sort of do math in it. But it is not a language tailored for math. The base language has natively strings and dictionaries (for which I have no use) but it doesn't have native multidimensional arrays of floats. I do not understand why the numeric computing community is shifting so much to python, it makes no sense in my eyes. Also, loops are insultingly slow. Julia: may be the best of the bunch, but launching the interpreter is excruciatingly slow, and it does not suit my usage. In the time that julia uses to compile a three-line program to plot "sin(x)", you can run one hundred times the Fortran compiler on the equivalent program (or simply call gnuplot). All in all, it keeps pretty much the promise of "matlab with fast loops", which is just what I need. But I feel that it's still a bit far from being there.
- leephillips 6y ago
  Have you tried the recently released v.1.6.0 of Julia? Precompilation is dramatically faster. Also, for serious numerical work, startup time is eclipsed by run time, so it tends not to be relevant. I did most of my physics simulations in Fortran, which is a great language for the task, but if I were writing a new simulation code today I would use Julia. It is the only language in the petaflop club that is actually better to program in than Fortran. (+1 for gnuplot.)
  - enriquto 6y ago
    > Have you tried the recently released v.1.6.0 of Julia? Precompilation is dramatically faster. Yes, I tried it upon its release and, while much faster, the startup time is still dramatically sub-par, especially when loading packages. This means that when I call Julia scripts from makefiles, etc., a considerable amount of running time is spent in re-compiling over and over the same packages. I agree that my usage pattern is not at all representative, but still it seems that Julia is not a good "unix citizen", since it tries to force you to do everything inside its own REPL, instead of the native one. This is indeed my main point of friction with Julia. If it started instantaneously it would be essentially perfect. This is not a matter of dividing the startup time by 2, but at least by 200.
    - leephillips 6y ago
      I understand. I haven’t tried this myself, but others have had luck, for this use case, in using sysimages: https://julialang.github.io/PackageCompiler.jl/dev/sysimages/ https://julialang.github.io/PackageCompiler.jl/dev/sysimages...
      - enriquto 6y ago
        Thanks! I was told about this on a previous HN thread, but I have still to try it. Will do as soon as I have some time. It looks really promising.
  - TheRealKing 6y ago
    Can you elaborate on why it "is actually better to program in than Fortran"?
    - leephillips 6y ago
      The type system and dispatch paradigm provide a powerful method of code and project organization, and facilitate a type of code reuse that you don’t get with Fortran: the ability to pull other people packages into my project and use their types and methods. That’s one thing. EDIT: Also, having a REPL, and a nice one, is a big deal.

None of them seems "tailored" to the job of numerical computation (mostly linear algebra algorithms) like Fortran seems to be. C: it is mostly alright, especially since C99 with VLA and complex numbers. Yet the aliasing rules are a bit annoying, and multi-dimensional arrays, while possible, do not really feel natural. C++: an unholy clusterfuck... I almost ended crazy trying to use it properly. With extreme discipline maybe you can get to do some work with it. But not me. Octave: very beautiful language with a natural, concise notation for math. Excellent out-of-the-box support for sparse matrices. Shame that loops are so slow; needs a serious effort on a JIT. lua: my favorite general-purpose language. The luajit interpreter may be one of the fastest and easiest alternatives to Fortran. I wrote a matrix product using an explicit triple loop, and it multiplied huge matrices just slightly slower than an optimized blas. Extremely impressive! I'm very sad that the project is sort of "abandoned". python+numpy: My least favorite, but the one that I use the most... what can I say: this is a general-purpose language where you can sort of do math in it. But it is not a language tailored for math. The base language has natively strings and dictionaries (for which I have no use) but it doesn't have native multidimensional arrays of floats. I do not understand why the numeric computing community is shifting so much to python, it makes no sense in my eyes. Also, loops are insultingly slow. Julia: may be the best of the bunch, but launching the interpreter is excruciatingly slow, and it does not suit my usage. In the time that julia uses to compile a three-line program to plot "sin(x)", you can run one hundred times the Fortran compiler on the equivalent program (or simply call gnuplot). All in all, it keeps pretty much the promise of "matlab with fast loops", which is just what I need. But I feel that it's still a bit far from being there.

leephillips 6y ago
Have you tried the recently released v.1.6.0 of Julia? Precompilation is dramatically faster. Also, for serious numerical work, startup time is eclipsed by run time, so it tends not to be relevant. I did most of my physics simulations in Fortran, which is a great language for the task, but if I were writing a new simulation code today I would use Julia. It is the only language in the petaflop club that is actually better to program in than Fortran. (+1 for gnuplot.)
- enriquto 6y ago
  > Have you tried the recently released v.1.6.0 of Julia? Precompilation is dramatically faster. Yes, I tried it upon its release and, while much faster, the startup time is still dramatically sub-par, especially when loading packages. This means that when I call Julia scripts from makefiles, etc., a considerable amount of running time is spent in re-compiling over and over the same packages. I agree that my usage pattern is not at all representative, but still it seems that Julia is not a good "unix citizen", since it tries to force you to do everything inside its own REPL, instead of the native one. This is indeed my main point of friction with Julia. If it started instantaneously it would be essentially perfect. This is not a matter of dividing the startup time by 2, but at least by 200.
  - leephillips 6y ago
    I understand. I haven’t tried this myself, but others have had luck, for this use case, in using sysimages: https://julialang.github.io/PackageCompiler.jl/dev/sysimages/ https://julialang.github.io/PackageCompiler.jl/dev/sysimages...
    - enriquto 6y ago
      Thanks! I was told about this on a previous HN thread, but I have still to try it. Will do as soon as I have some time. It looks really promising.
- TheRealKing 6y ago
  Can you elaborate on why it "is actually better to program in than Fortran"?
  - leephillips 6y ago
    The type system and dispatch paradigm provide a powerful method of code and project organization, and facilitate a type of code reuse that you don’t get with Fortran: the ability to pull other people packages into my project and use their types and methods. That’s one thing. EDIT: Also, having a REPL, and a nice one, is a big deal.