Earlier quoted context omitted.
What are some examples of limitations you've run into with various non-Fortran languages?
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 disciplin…
Fortran is back on the top 20 TIOBE index list
31–40 of 44 posts
Re: Fortran is back on the top 20 TIOBE index list
#32Earlier quoted context omitted.
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 disciplin…
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 be…
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.
Re: Fortran is back on the top 20 TIOBE index list
#33Earlier quoted context omitted.
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 be…
> 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 pat…
Re: Fortran is back on the top 20 TIOBE index list
#34Earlier quoted context omitted.
> 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 pat…
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...
Re: Fortran is back on the top 20 TIOBE index list
#35Earlier quoted context omitted.
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 disciplin…
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 be…
Re: Fortran is back on the top 20 TIOBE index list
#36Earlier quoted context omitted.
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 be…
Can you elaborate on why it "is actually better to program in than Fortran"?
EDIT: Also, having a REPL, and a nice one, is a big deal.
Re: Fortran is back on the top 20 TIOBE index list
#37Earlier quoted context omitted.
Can you elaborate on why it "is actually better to program in than Fortran"?
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.
OK, admittedly I also need complex numbers (two floats) and ad numbers (however they are represented, typically by two floats also). But that's it. They are numbers after all, associative and commutative. The "dispatch paradigm" that these types require seems really simple, as it is implemented by e.g. generics in C as in tgmath.h. I'm wholly unconvinced--or more honestly, wholly ignorant--of the interest of a really complicated and powerful type system with multiple dispatch, broadcasting and whatnot that is offered by Julia. Fortran really seems enough for me. [And I do not care at all for the REPL, but that is a separate issue.]
Re: Fortran is back on the top 20 TIOBE index list
#38Earlier quoted context omitted.
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.
Can you expand a bit on the need for "types" in numerical computation? They sort of seem like overkill to me. The only types I use are float and double, but I could really do with just doubles. OK, admittedly I also need complex numbers (two floats) and ad numbers (however they are represented, typically by two floats also). But that's it . They are numbers after all, associative and commutative. The "dispatch paradi…
It’s not that other types are “needed”, but that they let you do some pretty powerful things with surprising ease. And the nice thing is that in Julia, you can ignore them. You can just compute with floats or doubles as if the type system doesn’t exist. But it’s there in case you would like, for example, to apply the differential equation solver that you just wrote to quaternion-valued functions with no extra work.
Re: Fortran is back on the top 20 TIOBE index list
#39Re: Fortran is back on the top 20 TIOBE index list
#40Earlier quoted context omitted.
Can you expand a bit on the need for "types" in numerical computation? They sort of seem like overkill to me. The only types I use are float and double, but I could really do with just doubles. OK, admittedly I also need complex numbers (two floats) and ad numbers (however they are represented, typically by two floats also). But that's it . They are numbers after all, associative and commutative. The "dispatch paradi…
I think I have a pretty good answer to your question in this article: https://lwn.net/Articles/834571/ It’s not that other types are “needed”, but that they let you do some pretty powerful things with surprising ease. And the nice thing is that in Julia, you can ignore them. You can just compute with floats or doubles as if the type system doesn’t exist. But it’s there in case you would like, for example, to apply th…
https://github.com/SciML/BoundaryValueDiffEq.jl/issues/52
This is how I found out it worked in the differential equation solver: users were using it. The issue was unrelated (they didn't define enough boundary conditions), so it's quite cool that it was useful to someone. It turns out the quaternions have use cases in 3D rotations:
https://en.wikipedia.org/wiki/Gimbal_lock
which is where this all comes in. Anyways, it's always cool to learn from users what your own library supports! That's really a Julia treat.