Show HN: A Fortran web framework | Hacker News Reader

Show HN: A Fortran web framework

github.com

227 pointsmapmeld88 comments

I would love it if these projects were accompanied by a little blog post stating who the person is, why they decided to do it etc. for projects where it is obviously a labor of love.

Especially because of the effort it would take to get this working on a "dead" language. Like who are you? How did you decide to work on this for the pure joy of it? Why not Cobol? Why a web framework?

Some digging uncovered mapmeld's appreciation for the Fortran community on Github https://medium.com/@mapmeld/fortran-culture-on-github-a257dd...

>It could be about scientific coders’ culture versus web developers like me.

That's basically it. Scientific programmers are from a different era and a different culture.

Also, their focus is more on what they can do with the code, not the code as an end in itself.

When discussing pull requests and changes, having less ego involved makes a big difference.

> "dead" language

In the world of traditional engineering, you will still encounter senior PE's that pump out Fortran. Luckily, it usually isn't fixed form.

Also revisiting older projects can also mean visiting Fortran, and sometimes that can be fixed form (looking at you, wind hazard modelling of tornadic winds for nuclear powerplants).

I love it I'm imagining a sixty year old dude, revered by all around him, who spend the last forty honing his fixed-form Fortran skills. Young engineers gather around him just to marvel at this masterpiece: https://www.youtube.com/watch?v=_DTpQ4Kk2wA

We have a heap of heat and mass transfer simulation code at my work written in Fortran. It is heavily used in the world of fluid dynamics.

As far as I know, Fortran is not a dead language, but is actively used in the scientific computing & mathematics niche.

I would guess compiled Fortran accounts for the majority of processor cycles on supercomputers worldwide, given how common it is in applications modeling weather, fluid mechanics, nuclear physics and quantum chemistry.

Yes, NumPy depends on BLAS/LAPACK libraries which are written on Fortran. In turn TensorFlow and Theano which used for implementation of most state of the art deep neural networks depend on NumPy, so Fortran is still alive and gearing such modern research.

All of this is wrong. Numpy does not depend on fortran code and TF and theano implement their arithmetic without fortran code.

From http://docs.scipy.org/doc/numpy/user/building.html

> Various NumPy modules use FORTRAN 77 libraries

    $ pip show tensorflow theano
    
    Name: tensorflow
    Version: 0.7.1
    ...
    Requires: six, protobuf, wheel, numpy
    ---
    Name: Theano
    Version: 0.8.2
    ...
    Requires: six, scipy, numpy

You are right that arithmetic in both of them is not written on Fortran, but the packages do use NumPy as you can see in the pip output.

I'm Nick and I'm usually a full-stack JS developer. Fortran is something foundational to languages we use today, and my professors and parents would talk about it, but I didn't even know what it looked like. I noticed recently that Fortran repos on GitHub accept nearly every pull request (https://medium.com/@mapmeld/fortran-culture-on-github-a257dd...).

One day I wondered if there was a Fortran server, did some Googling, and found a tutorial from 8-10 years ago (http://flibs.sourceforge.net/fortran-fastcgi-nginx.html). I started out updating the tutorial, requesting some missing files and missing instructions from the authors (almost every Fortran info on the web assumes that you already know how to compile and run your program). Once I was halfway down the rabbit hole, updating this tutorial, it felt right to keep it going

Great job! Reason being is I had those same tutorials that I used in language debates. Someone would eventually claim you couldn't do modern apps with (insert "ancient" language). So, I cited Fortran on FastCGI or COBOL on Cogs. Reactions are usually silence or serious revision to points being made.

Yours is a nice improvement. If you want to add to the prank, then maybe do a modern-style app or clone of popular one that would definitely delight people. Relatively small app to not take too much time. Offer them a link to the source in case they want to check it out. Let them find out it's Fortran on thdir own. Observe the reactions while recording the best ones. ;)

Very nice. How long did it take you?

I only started looking into it two weeks ago, so setting aside some time here and there on a few weekends, sending emails when it wasn't working. Main challenge was how to go beyond the original tutorial, without getting too deep in the weeds with Fortran

Takes me back to the 80's when I worked on a project (for British Telecom) to build a billing system running under Dialcom's custom version of Primos in Fortran and PL1/G and building a forms based input system in Fortran 77.

Hey, I wrote an emulator for Prime minicomputers. It's online:

  $ telnet em.prirun.com 8001
  Trying 74.131.82.133...
  Connected to em.prirun.com.
  Escape character is '^]'.

  Welcome to the Prime Computer 50-series emulator, running Primos rev 19.2!

  Login as user guest, password pr1me
  After logging in, use the Prime HELP command for assistance.
  You are welcome to create a directory under GUEST for your files.
  The line erase character is ?
  There are other Primos revs running on ports 8001-8007
  Prime manuals at: http://yagi.h-net.msu.edu/prime_manuals/prirun_scans
  To report bugs or contact the author, send email to prirun@gmail.com

  Enjoy your time travels!   -Jim Wilcoxson aka JIMMY

  Login please.
  login guest
  Password?

  GUEST (user 2) logged in Wednesday, 22 Jun 16 16:39:52.
  Welcome to PRIMOS version 19.2.
  Last login Sunday, 12 Jun 16 16:37:20.

  OK,

Chears will have to have a play with that

I used to think, like you, that Fortran is a dead language. Later I learned that it's still used in SciPy[1] (and I believe NumPy, but can't find a reference).

[1] https://www.scipy.org/scipylib/faq.html#how-can-scipy-be-fas...

LAPACK [1] is written in Fortran. It is still heavily used in scientific computing. And to be honest, I don't know if there are good alternatives for it in other languages (except for CLAPACK, which is just a transpiled version of LAPACK in C).

[1] http://www.netlib.org/lapack/

Numpy specifically doesn't require Fortran. (That was the reason for the original separation of numpy and scipy.)

Numpy will compile f2py (to allow running fortran code in python) and I think it uses the Fortran lapack bindings in some cases if a Fortran compiler is present. However, both of those are optional. Numpy deliberately avoids requiring Fortran in any way.

Scipy, however, uses quite a bit of Fortran in addition to C and requires a Fortran compiler to build.

At any rate, as you noted, it's hardly dead. Modern Fortran is a domain-specific language, for the most part, but it's quite popular within that domain (scientific computing and HPC).

It's also used heavily in R itself and in many R packages. In fact some people go as far as to say R is a wrapper around Fortran libraries.

So yeah Fortran is not dead by any means. Tons of people are using it every day, but perhaps not writing code in it. Just like your OS and browser are written in C/C++ but your applications might not be.

Fortran is actually still in major widespread use, particularly in the scientific and engineering fields. This is partly because it has unparalleled speed in some domains, better even than C or C++.

Fortran is ubiquitous in ocean and atmospheric modeling. I believe this is the case for all earth sciences.

Especially Fortran in a unix MPI cluster.

I have a buddy at US Fish and Wildlife where they do river flow modeling with Fortran routines from the seventies formerly compiled on Windows machines. He was finding it increasingly difficult to get his all-powerful shadowy IT division to install a compliant MS Fortran compiler, and linux (somehow deemed governmentally untenable?) was out of the question. So i helped him get his ~2000 Fortran lines into C/C++. woowee... but did i see some hairy spaghetti code. A favorite maneuver was to jump out of a loop, change the loop counter on a subroutine branch, and jump back into the middle of the loop.

Change the loop counter? That's supposed to be impossible in Fortran, isn't it? Maybe that's a language extension?

This was from code originally from about 1978ish, which compiled on a Microsoft Fortran compiler from the 2000s. It looked something like (without indents):

    DO I=1,10000
      ...
      IF (QQQ .LT. RIX70) THEN
         CALL IXNARF( I, J, R1, R7, XL23 )
         GOTO 23
         ...
      END IF
      111 CONTINUE  
    ...
    END

IXNARF could change 'I' (because Fortran 77 passed arguments by reference not value) and sometime after line (er... "card") 23 it might jump back into the loop at 111.

oh and there was like three comments in the whole several thousand lines, including my favorite at the top of one of the main loops:

    C  CHUGGA CHUGGA CHUGGA

I remember you could change the value of 3 in Fortran 77.

Then there was the proposal for a Fortran COME FROM statement.

http://www.fortran.com/fortran/come_from.html

I believe Intercal implements the COME FROM statement.

`C CHUGGA CHUGGA CHUGGA`

I laughed way harder at this that it warranted.

> Change the loop counter? That's supposed to be impossible in Fortran, isn't it?

It is impossible inside the loop, even in F77.

But if a global variable is used as a loop counter, and the variable is altered in a subroutine, then the code altering the variable is not inside the loop. At least not in the eyes of the Fortran compiler.

    $ cat test.f08

    program test
        integer i
        do i = 1,3
            call sub
            print *,i
        end do
    contains
        subroutine sub
            i = 3
        end subroutine sub
    end program test

    $ gfortran --std=f2008 test.f08 
    $ ./a.out 
           3

... just because it does that in gfortran doesn't mean it's standard-conforming code.

What is the "standard" fortran compiler for scientific computing? Do a lot of people use gfortran? Or something commercial?

There is no "standard" compiler. There is a Fortran standard, and there are standard-conforming compilers and standard-conforming programs.

There are popular compilers, like gfortran and the Intel compiler.

My point had nothing to do with popularity. My point is that non-standard-conforming programs can have anything happen when they execute, including starting World War III (see https://www.google.com/search?q=fortran+"start+world+war"), and showing output from one compiler doesn't prove anything.

> What is the "standard" fortran compiler for scientific computing?

Not so long ago, supercomputers typically had Portland Group, Cray and Pathscale compilers installed. Nowadays it's pretty much Intel and gfortran.

To elaborate: When people mention that supercomputing relies on Fortran code because it runs faster, that's primarily because the compiler knows the program can't modify a loop counter. So an optimizer can shovel off big arrays to array processors (1970s), GPUs (now), registers, etc, and do parallel or superscalar computation.

The FOR loop become a hint that tells the compiler it can take extraordinary measures on the nested instructions.

You could do the same thing in C if you use compiler directives, or in other languages like Pascal, but there's a critical mass of Fortran code, so that's where vendors put the effort.

Aliasing also complicates matters in C.

It's been many years, but I seem to remember porting the NCAR Graphics Package written in FORTRAN IV to FORTRAN 77 on a Data General MV series box.

If memory serves, they had a trick to create simulated pointers, by declaring a one element array somewhere in memory, and then indexing way outside of its bounds in order to point into other areas of memory.

I don't remember the details, but I seem to remember there was a statement ("EQUIVALENCE"?) that facilitated this magic.

Why was there such an issue I have to ask? Intel do Fortran compilers as do many other suppliers.

All fluid modeling at least. I once worked for a company that built heat exchanger simulations. I spent limited time in Fortran but was able to successfully integrate some C++ and C# libraries. The language isn't bad at all.

I know a popular thermal modeling program requires you to buy the Intel Fortran compiler to run as well.

If anyone knows about a single climate or weather prediction model that is not in Fortran, I'd like to hear.

Me too. I know peeps who are developing an assimilation system in C++, but that's in development...

there is one in ocean sciences. I don't remember which one although if you are really interested I can find out. Somebody translated it into C as part of their phd.

I used to work with a bunch of ex-Cray engineers back in the '90s. They'd rant and rave about how FORTRAN was faster than C due to eliminating one memory dereference on linear algebra operations (linear algebra being the reason to own a Cray).

I can certainly verify this. Look no further than Nastran [1] which is ubiquitous in the aeronautical / aerospace industry. Using fixed width fields isn't even uncommon--column edit and a few clever regular expressions go a LONG way. Even newer software [2] follows this paradigm, and I think with good reason. Mechanical engineers, as they insist on frequently reminding me, are NOT computer scientists. Nastran bulk data operates like a very tangible, physical-ish relational database free from some of the more advanced abstractions of more modern languages.

1. https://en.wikipedia.org/wiki/Nastran#Software_architecture 2. http://www.zonatech.com/ZAERO.htm

It's only unparalleled if you've never heard of the C99 'restrict' keyword. The major reason is like every other legacy system still in wide use, inertia. LAPACK alone will guarantee Fortan's life for decades to come.

I've said it before - leveraging "restrict" is far from trivial.

In practice, what you do is look at the assembly of your inner loops, scratch your head, and try putting "restrict" in various places that seem like they'd make sense, and then look at the assembly of your inner loop. Which requires building a mental model of what the assembly of your inner loops ought to look like, and then actually looking at it, and then running it to see if your idea of what the assembly out to look like was actually a good one.

If your expertise is in numerical methods first and assembly-level optimization second (or, like, nth), Fortran can save you a lot of ballache.

If only every compiler vendor supported C99 (coughMicrosoft), perhaps C99 would be a usable alternative.

And, inertia isn't the only reason for Fortran remaining popular. Put simply: if you tell a mech.eng./physicist/whatever to write code in Fortran, whatever is produced will likely be fast and relatively readable. Do the same with C/C++, and it will be significantly slower and a horrible mess. Templates-all-the-way-down type of stuff.

Sure, a software engineer could write a C/C++ version that was elegant and as fast/faster than the Fortran code. But scientists don't have the money to hire software engineers. You're lucky if these projects are even under version control.

More importantly, if your simulation software is made by a computer engineer without the direction of a scientist you might just end up with a really slow and biased random number generator.

Another major advantage over C and C++ is a language level support for multidimensional arrays, i.e. you don't have to reasearch available libs, depend on them, convert between them, etc. I fully understand resistance of scientific community to trying alternatives like C++.

L-BFGS-B is a hugely popular algorithm for box-constrained minimisation and the best implementation is still in Fortran. This is commonly used in machine learning. Things like scipy.optimize.fmin_l_bfgs_b are just wrappers for the Fortran code.

IIRC, Fortran is bundled with NumPy and SciPy packages..

Fortran is not a dead language. It's got a strong stable niche in science and engineering.

I put the "dead" in quotes!

My freshman year I asked my professor why we had to do this one program in Fortran, and after that response, I will never refer to Fortran as "dead" without quotes.

Fortran is still in widespread use in scientific and numeric computing. It's far from "dead".

Hello,

I wrote the 'fortran+fastcgi+nginx' thingy. It has evolved into https://github.com/rlcarino/heeds. Production live runs (and a little blog post about it) may be found at http://heeds.csu.edu.ph. Some students from a university connect to the runs with their Android phones without cell data cost via Facebook's Free Basics which is available in that part of the world. Usage instructions for students are in the FAQ of https://www.facebook.com/groups/csuheeds/.

Why do it? Somebody pays for it.

Ric Carino

Also relevant: https://github.com/azac/cobol-on-wheelchair

The views are a little disappointing, using just plain mustache style. Shouldn't a cobol web view have something like

    HEAD DIVISION
    META-TAGS SECTION.

    BODY DIVISION.

I know it runs on Apache, but the install scripts should be written in JCL, just because.

DIV DIVISION?!

HR DEPARTMENT.

Fun fact: the framework's author [1] is a member of the governing board of a major Polish political party (Razem).

[1]: https://en.wikipedia.org/wiki/Adrian_Zandberg

There is a webframework called Z WebPortal from a US company, Zortec Intl. that has a COBOL-like backend that will run 'real' COLBOL code too, with a js layer and xml to draw the output in the browser as html.

It is proprietary, but very fast and the backend code is much simplified over COBOL.

Writing to a log file looks like:

    fd ?logthis-txt  reclen 80
    def logthis-usr      gp 80
        logthis-date     an 10
        logthis-time     an 8 

    open extend logthis using '/var/log/logfile.txt'
              on error next sentence
         else display date lj upon   logthis-date
              call GETIME using      logthis-time
              move usrid          to logthis-usr
              write logthis 
              close logthis.

You can see that a lot of the (unnecessary) typing done in COBOL has been removed. It has its limitations as most web-frameworks do, but if you have mainframe COBOL and want to present it in the browser with fancy colors and graphics it has more pros than cons.

Seeing this gave me a subtle but definite frisson of nostalgia for Fortran (first language, learned in late 60's).

Hello,

Why do it? It is a consulting gig.

Ric Carino

For those wondering why it's used, here's a write-up I found on Eric Raymond's blog comparing Fortran and C:

http://www.ibiblio.org/pub/languages/fortran/ch1-2.html

Some comparisons are dated. However, I think the older variants still have advantages in readability, more clear semantics, semantics closer to algorithm itself (esp mathematical functions), less guessing by compiler for optimizations, and maybe a few others. Those I listed seem to still be advantages over C in general or as it's commonly used.

Also of note is that the implicit typing system of Fortran is held up as an advantage (although a bit reluctantly)

This reminds me of the time I actually found myself charged with integrating a chunk of Fortran code compiled into a Windows DLL with an Excel sheet via VBA. The VBA side was straightforward if a little icky, but handling strings in Fortran was really giving me headaches. Documentation on Fortran, even down to basic syntax, seemed inconsistent and hard to find online. I think I got the project mostly working before I left that company for unrelated reasons.

I'm mostly used to Fortran 77 and that was ages ago, that actually looks quite readable...

Reminds me of: https://github.com/azac/cobol-on-wheelchair

Nice work! That home page, while admittedly simple, renders incredibly fast. Have you done any benchmarks / performance comparisons to other web frameworks?

No, not yet. It ought to be comparable to C++ in most cases. The difficult part is extending Fortran to do something that you want / hasn't been shared yet on the web.

Just because you can?

For some reason I've been seeing more and more Fortran lately. Maybe it's the trendy thing to do.

Honestly, High Performance Fortran has really nice support for parallel arrays. For computational programming I see a lot of value.

The issue is what you give up. Yes the FORTRAN compiler/runtime is fast but concurrent primitives weren't added until FORTRAN03, and recursion wasn't fully supported until FORTRAN90 [1]. It hides almost all the implementation details from the programmer.

Fortran is a really good language for number crunching. Academics who don't know how to code can build very fast number crunching tools without really any CS or hardware knowledge. This the target use case and target audience.

If you want to do low level system things with it, it'll be painful.

[1] Some fortran70 compilers had limited support for recursion it wasn't added to the official language standard until 20 years later tho.

>The issue is what you give up.

This is the feature, not a bug. The purpose of fortran and why it is a fast efficient tool for scientists to write software is is exactly that it hides implementation details and is a bad systems language.

It allows you to define the important math parts of your program and hides the implementation part exactly so the compiler has a lot more power to optimize.

I got into it a couple years ago pretty heavily just for kicks and found that it was actually a pretty fun language if you're doing lots of math, especially matrices. I wish people would use it more for libraries, but I would be lying if I said you couldn't write something just as fast in C or C++ with a little bit more work. That being said, its actually a great language for people who just want to spit out some number crunching code.

My first thought was Why? But after thinking about it this actually could be helpful. There are still a lot of legacy systems that rely on Fortran. Perhaps this framework could help glue a lot of these legacy systems together over a network.

Given Ruby on Rails, COBOL on COGS, silly naming pattern, I'm a bit disappointed this isn't called something like Fortran on Flumes.

I am definitely going to try this! Would love to see a bit more about the creator!

Thanks! You can find my name on GitHub and Google around to find more info / e-mail address

Finally!

An accomplishment, certainly, but...

http://i.imgur.com/TnQRX6v.gif

Reply on news.ycombinator.com