
Show HN: A minimal Fortran TCP client and server - milancurcic
https://github.com/modern-fortran/tcp-client-server
======
sevensor
In grad school, I revived some FORTRAN66 code for aircraft sizing. (You can
probably download an equivalent model from Dan Raymer's website as an Excel
workbook.) This was not its first revival, according to the comments in the
code. That was when it was transferred from paper tape and adapted to run on
VAX/VMS. Nor was this its second revival. That was when my advisor had made
the VAX/VMS version work on SunOS when he was in grad school. No, this was its
third revival, wherein I took the SunOS version and made it run on modern
Linux. I'm sure a seasoned veteran would have known about the magic compiler
flags that made it not produce garbage, but it took me several days of trial
and error, and reading the gfortran man page. Along the way, I got to learn
about Hollerith constants! Some day, I'm sure another generation of grad
students will renew the great tradition, adding their own comments below mine.

~~~
apaprocki
You would have been much better off nowadays, because the legacy vendor-
specific features have mostly landed into gfortran (recently) behind flags.
This is specifically to aid porting off old compilers onto GCC/Clang.

[https://github.com/CodethinkLabs/fortrantools/blob/master/RE...](https://github.com/CodethinkLabs/fortrantools/blob/master/README.md)
(And related repos...)

------
tombert
I had to touch a little bit of Fortran 77 when I interned at Lockheed Martin
nine years ago.

While I don't know that I would use Fortran for anything nowadays, I do kind
of have to appreciate how completely _simple_ Fortran was in comparison to my
favorite language of the time, C++ (I hadn't learned Haskell or Lisp very well
at the time so I didn't know better :) ).

I haven't touched any later standards after 77; is Fortran still technically
not Turing complete?

~~~
ajxs
I find it hard to justify why, but I'm always so curious about those legacy
systems still running in enterprise-scale companies. I doubt that working on
them is anything short of terrifying, but I find it so interesting to hear
about what important systems are still out there running just fine on ancient
tech.

~~~
shakna
Linking COBOL and Fortran against C is actually one of the easier things to
do. So with these multi-million line systems, often new features are written
in C++, minor minor minor bugfixes in the original language, and general
maintenance is a toss-up if it's a re-write in C++ or just fix it in the old
language. Depends on how fast they need it.

I did some Pre66 Fortran work for a bank, and that was basically the idea.
They were in the process of converting internal assumptions of the program
from a very particular older mainframe type to a mix of Z/OS and Solaris, and
the Fortran/COBOL into something they could continue working with.

Some of the code was very specifically marked as "not for C++", because modern
Fortran (2003 at the time) was better for some specific number-based things.
But that code becomes a library rather than part of the original monolithic
structure. And modern Fortran is actually quite a nice low-level language to
play with.

It was actually easier than expected - when the original program was written,
and for about the next twenty years following, the entire program and changes
were very well specified in multi-thousand page specifications. The newer code
was harder to keep track of, rather than the oldest, because at the oldest
those documents were 99% accurate, even if you never trusted them to be
because of the intervening time.

~~~
lallysingh
_> Some of the code was very specifically marked as "not for C++", because
modern Fortran (2003 at the time) was better for some specific number-based
things._

Was that a you-can't-do-that-in-c++ thing or slightly-faster-in-fortan thing?
I'm always skeptical about the latter guiding major maintainability decisions
on often-specious performance benefit claims.

~~~
m_mueller
To expand a bit on other answers: There is a qualitative difference Fortran
has by offering

1) built-in multidimensional arrays including Matlab-like array operations.
That means every library supports the same format, it's standardized and
convenient as opposed to the many formats in C++ Land.

2) performant defaults. When performance is more important than safety,
Fortran programs are easier to write and maintain. Arguments are by default
pass-by-reference, non-aliased (a major assumption Fortran compilers can
usually make to optimize) and their intent as in/out/in out can simply be
marked as such.

Fortran:

real(8), intent(in) :: foo

C:

restrict const * const double foo # if I remember correctly

~~~
goerz
I’m not sure what you mean by “When performance is more important than safety,
Fortran programs are easier to write and maintain.” The fact that arrays are
not based on pointers makes Fortran a much safer language than C. It’s very
hard to shoot yourself in the foot with Fortran. It’s fast _and_ safe

~~~
m_mueller
Fortran offers a better developer experience overall for Numerical
applications yes. But it is still very foot shootable as I remember - point a
pointer at allocatable and the fun can start. Or make everything inout for
convenience and/or performance. But yes, compared to C the defaults are also
safer, just don't expect Rust.

------
basementcat
Note this is free form FORTRAN 90 code; not your grandparent's f77 optimized
for card punch entry.

~~~
vallismortis
Wow, ageist much? My wind model is F77.

~~~
basementcat
Should have picked my words better; _great_ grandparents. I still use f77 code
for my day job on occasion.

------
msla
All the complexity is in libdill, which is written in C:

[http://libdill.org/](http://libdill.org/)

... which means they buried the lead pretty deeply, because libdill is an
interesting little library: Structured Concurrency in C! From the FAQ:

[http://libdill.org/faq.html](http://libdill.org/faq.html)

> How does libdill's concurrency differ from Go's concurrency?

> No interaction between threads. Each thread is treated as a separate
> process.

> Channels are always unbuffered.

> choose, unlike select, is deterministic. If multiple clauses can be
> executed, the clause closest to the beginning of the pollset wins.

> chdone signals the closing of a channel to both senders and receivers.

> Coroutines can be canceled.

And:

[http://libdill.org/structured-
concurrency.html](http://libdill.org/structured-concurrency.html)

> What is structured concurrency?

> Structured concurrency means that lifetimes of concurrent functions are
> cleanly nested. If coroutine foo launches coroutine bar, then bar must
> finish before foo finishes.

