What is the advantage of Julia over Fortran?

General Usage
82

Re reproducibility: It is certainly nice to take an old Fortran code and make it compile on your current system. However, that is not all reproducibility is about. There is the little matter of legibility of the code: checking what has been programmed, otherwise one does not need the source code at all, assembly would work just as well to get something compiled.

Now, concerning legibility of old Fortran code: There is a well-known finite element textbook that includes Fortran codes. That source code is a testament to how things have changed. Would it be possible to compile this code? Probably, if one could get hold of it. That is how far it goes though, to make sense of the Fortran code one will need a lot time and effort. At first sight it is a horrible spaghetti mess, the marinara spilling out of the pages of the book.

So, is this what we mean by “reproducible”?

I will bet my bottom dollar that, with the same distance in time between the “write” and the “read”, Julia will lead to a lot more reproducibility than Fortran currently does.

3 Likes
83

I mean, since Julia encourage people to write concise/easy-to-understand code,
because after all, majority of the users do want to use Julia to solve the problem, get the job done, as efficient as possible. When a relatively good code has been written, I guess people would prefer not to spending too much time optimizing the code itself, such as add some tricky macros here and there, etc.

Although in the rand! example, I believe many people will generate the random number array outside the loop, then just use corresponding random number in the loop. Or, if in the loop, there are many other stuff are being done and therefore the allocation of the rand array does not affect the speed by too much.

Overall, I am just saying, some dirty jobs always need to be done, since Julia intend to release the people from doing dirty jobs, as an exchange, the Julia compiler may need to take as much responsibility as possible to do the dirty jobs such as optimize the code automatically wherever possible.

My feeling is (well it can be absolutely wrong),

Fortran is like Formula 1. In order to travel from one place to another, we need to pave the special track for it to run. The ''paving the track" process is like writing the code, sometimes can be cumbersome and time consuming. But for some reason, Formula 1 is always there, it is not dying.

Python is like a everyday car, like Toyota Camry. Perhaps you can pick and go, and easy to fix problems and parts since it is popular. But the speed may not be great. After all, it is designed just as an every car, and as popular as possible.

Julia, perhaps is like a Bugatti, Lambo or something? While it has the speed roughly the same as Formula 1, it is still a regular car and people can still pick and go. Although in order to achieve the highest performance, the road need to be the flat the better the straight the better (this process is like optimization). I wish the compiler could do more at optimization.

Or, perhaps Julia is more like electric car like Tesla? Which simply represents the new concept of cars.

3 Likes
84

Thank you so much!

Indeed, the reason that I am using Julia is because the existence of DifferentialEquations.jl.

Could you perhaps give a tiny example, I know it is a stupid question, but why like you said, “the prototyping is so much faster in Julia”?

Uhm, from my very shallow and stupid experience (I am not good at Julia), it seems the grammer of Juia and modern Fortran are basically the same.
Eh, Julia has some macros like @ eval, @ inline, @ avx, blablabla, which seems to be just doing some optimization by hand, while in Fortran those seems are automatically handled by the compiler.

However Julia do have the advantage such as it is much more easy to draw some plots and even making some videos, and also check the functions on the fly.

1 Like
85

Thanks! :slight_smile: I am glad I could help a little bit.

In my case, the fast prototyping comes with the fact that Julia seems interpreted and can be used as a scripting language. Using REPL, I can, for example, code one function, create inputs, check outputs, plot the results etc. in an interactive way. If I use Fortran, for example (or C++, or any compiled language), I would have so much more work to create the inputs and plot the output.

2 Likes
86

The fact you can try a single line of code to see if the syntax works, the line makes what you want, and benchmark it if it is for a critical part of the code, makes a huge difference.

2 Likes
87

Thank you! Well, indeed, it is more cumbersome to check function/subroutine in Fortran since we have to write some minimal drive code (Some guys here suggested an interesting project called LFortran which is basically doing the REPL stuff for Fortran, but still need a little bit more work, https://lfortran.org/). From this aspect, Julia does have advantage.

2 Likes
88

If one visits the Rosettacode.org site, solutions to many problems written in Fortran and in Julia can be compared (linked for example, the Heronian triangles problem).

After having met Julia who are those, with all their heads, who would still like to write Fortran, unless forced too?

1 Like
89

Indeed, LFortran, when ready, will be very nice for Fortran developing.

But prototyping “single-liners” and more or less arbitrary fractions of a function will be still only a Julia thing. Actually the fact that these fractions of code will actually work and perform as in the final code is quite unique to Julia, as far as I know. If you prototype in Python or Matlab, you can test things, but that has nothing to do with the performance of the final code (for instance if you will use numba, or pypy, etc).

2 Likes
90

Thanks for the clarifications! It’s good to have these options. Still, to promote reproducibility, I wish the default for non-package code were to only look in the local project and stdlib. My guess is that the scenario outlined above happens quite a bit in the wild (people depending on packages from v1.x without realizing, therefore sending/archiving incomplete TOML files).

Also, is there a value of JULIA_LOAD_PATH that uses the local project and stdlib and falls back to v1.x as project if there is no local project? (I think that’s really the behavior I’d like by default…)

91

I. But maybe that is because I have only one head.

2 Likes
92

I think what happens is that people have some development only packages i.e BenchmarkTools Revise OhMyREPL etc, and it would be a bit annoying, but I dunno.

93

Consider also the tape read heads poised at the beginning of the next FORTRAN 77 file on the tape.

94

Sorry, I don’t know what that means, so probably the joke is lost on me.
I have never done anything with tapes or written in Fortran 77.

95

I think there are good reasons to keep using Fortran (small static binaries, building libraries that can be used from Python and others, more secure long term support).

Julia may in the medium, long term, beat those, but in some ways it is still a promise. In particular, I was really impressed by @ChrisRackauckas demonstration of how the R interface of DifferentialEquations can symbolically read a function in R, convert it to Julia, compile it an integrate it into the solver to make it fast… Apparently the equivalent Python functionality is still under development, but if that turns out to work well the development of Julia libraries for these higher level languages will become by far the best option.

Anyway, by looking at that page, I can only congratulate the Julia people for the great syntactic choices they have made.

4 Likes
96

I’m curious what is the use case for a compiled Fortran program to be small. I thought Fortran was usually run on machines no smaller than a PC? So what is the advantage of smallness for a Fortran program?

97

Well, if each package takes 100mb and suppose we ship 100 packages in a Linux distro, that is ~10gb. My hard drive has 250gb, and my local Julia packages are taking 30gb already (I need to clean up).

Probably this will be all irrelevant in the future, but it isn’t now. Anyway it is not an advantage.

2 Likes
98

Imagine writing some code to do analysis of network performance on an embedded router so that the router can auto-tune its queue management software so that people will not complain about buffering and stuttering and dropped packets during their video calls or online gaming sessions. Just an example.

99

Do people write embedded programs in Fortran?

100

I assume the answer is yes. I bet a bunch of space satellite stuff is still Fortran for example. Who knows. The point is it’s not impossible.

101

A better analogy in my opinion would be this one, from a talk I gave about Julia a few months ago. Say you want a toy truck.

The Python/R solution is to look for the appropriate package–like buying a Playmobil truck. It comes pre-manufactured, well-engineered and tested, and does 95% of what you would ever want a toy truck to do.

The Fortran/C solution is to build the truck from scratch. This allows total customization and you can optimize the features and performance however you want. The downside is that it takes more time, you need woodworking skills, and might hurt yourself with the power tools.

The Julia solution is like Legos. You can get the truck kit if you want–which will require a bit more assembly than the Playmobil, but way less than building it from scratch. Or, you can get the component pieces and assemble the truck to your own specs. There’s no limit to what you can put together, and because the pieces all have the same system of bumps, everything snaps together quickly and easily.

image
image1593×897 102 KB

Ok, sure. Toy trucks are like linear algebra, though, a common request, and every “toy system” will have an implementation that works basically fine. But what if you want a time-traveling sailing/space ship with lasers AND dragon wings? And it should be as easy to build and use as a basic dump truck?

image
image829×903 114 KB

There’s a reason that only Lego ever made anything like Dr Cyber’s Flying Time Vessel :wink:

63 Likes