Fortran (Was: The "does Python have variables?" debate)

[Mark H Harris]

On 5/12/14 3:44 AM, Alain Ketterlin wrote:
> multiple-dispatch (i.e., dynamically testing types, converting to a
> common type, and selecting the version of sqrt to use). That's probably
> more than the time it takes to actually perform the computation, a bit
> like what happens with x+y on integers with Python, where only a
> fraction of time is spent on adding integers.
>
> When you are doing scientific computation, this overhead is
> unacceptable, because you'll have zillions of computations to perform.
>

     I'm still trying to sort that out. I have not tested this yet, but 
it looks like Julia is fully dynamic (yes it has types too), and it does 
parallel processing at its core, so the zillions of computations are 
being handled all at once, depending on how many processors|cores you have.

> Julia provides a way to make things fast: typing. If you provide
> explicit types, the dynamic typing part obviously disappears, and
> the overhead is removed.

     Julia is dynamic (depending on how far you want to go with that) 
but what makes it fast is the JIT. It is almost accomplishing C/C++ and 
FORTRAN speeds (even though dynamic) because it is compiling on-the-fly.

>
> But then, you're not too far from Fortran, or C/C++.
>
     Right.  Again, this is really about the design goals and the JIT.

>> The following code will produce over 100,000 digits of π (pi) in less
>> than 2 seconds on a low-end processor, like my mac mini dual core
>> 2Ghz:  {snip}
>
> You seem to be discovering the power of the libraries that are behind
> all this (MPFR in that case)...

     Yes, and more+  Gnu GMP & MPFR are not new to me, but the wrapper 
and repl are !  I am just realizing the power behind the libraries in 
this context, but I am very impressed with the functionality wrapped 
around the Gnu stuff... the interface is quite nice.

>
>> But, like lisp, Julia's internal structures are lists, so, it can
>> create and modify its own code on-the-fly. [...]
>
> Sorry, I was comparing to Fortran, and it's use in scientific computing.
> Self modifying code is totally irrelevant there.

    no, no, no...  there has to be a value add for scientists to move 
away from R or Matlab, or from FORTRAN. Why go to the trouble?  FORTRAN 
works well (its fast too), and there are zillions of lines of code 
cranking away on huge linear arrays.  Enter Julia... over the next ten 
years; seriously. Because of the value adds!

    Why?, glad you asked.  Enter self modifying code for one. The 
influence of Lisp|Scheme is potentially huge here. For scientific 
computing the reason for making the switch is that the array functions 
being calculated now in FORTRAN can be calculated (as fast) but more 
elegantly with Julia; because the language has the ease of use of 
Python, the stats of R, the array capabilities of MatLab (on steroids) 
and the almost speed of C/C++ (all together in one package). There is 
enough of a value add in this language to make FORTRAN users (also NumPy 
SciPy) take notice.

    Yes, its on a development curve right now (very much beta); but very 
much out there with some serious capability --- right now. It will take 
some time to mature, but I really think this language has the potential 
to be around for a long long time. There needs to be some serious bench 
marking on the parallel processing model, and there needs to be some 
uptake on the user base to find out what 'they' really need from it, but 
I think this dev group is on the ball. (maybe a little too smart for 
their own good, we'll see)

    I noticed from the MIT videos 
http://julialang.org/blog/2013/03/julia-tutorial-MIT/  from a year ago 
that the project has grown with leaps and bounds... but, there is very 
much an intellectual edge here vs. a usability edge... um, the computer 
scientists are still very much in control.  It might be time for a 
larger user group to get involved with the development direction, and 
code base.

    I agree with D'Aprano that languages come and go. But I think Julia 
is different... like Python... for the scientific community; seriously. 
And, if they really are working together with certain Python group(s) to 
merge technologies, this could be big for years to come!

    I'm excited about it.


    Don't get me wrong anybody, I'm still a Pythonista!   :)


marcus