Show HN: A minimal Fortran TCP client and server
github.com
github.com
https://github.com/CodethinkLabs/fortrantools/blob/master/RE... (And related repos...)
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?
The Fortran I touched was actually in an unrelated department; to what I was doing. Basically there was some old code that needed to be ported to an newer system; it was largely following the Fortran 77 spec so all they needed was an intern to copy the code over to a newer machine, and fix the compiler bugs.
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.
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.
A slight performance gain of 1% by using Fortran has a noticeable effect on long-term economic gains. (It was usually in the range of 5-8% performance improvement, but at the worst was 1%).
Thankfully, the reason I can tell you this, is because they tested it in the real world, splitting all transaction across a large-scale A/B test.
The real-world economic gains from the faster performance more than paid for the occasional development costs of a Fortran-familiar developer, hence why those systems persist in Fortran. They also scheduled re-assessment of this once every five years, knowing it might change one day.
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
Not to mention all the unsafety issues. while fortran is bleeding fast while keeping safety on.
Back in the day I worked on billing system for BT written in Fortran 77 and Pl/1G and that was ok to pick up - we did have an actual genius as a team leader and designer though YMMV
Fortran has been Turing complete since its inception in 1957 :).
In C (the abstract machine with arbitrary-sized ints) you can allocate an arbitrary amount of memory. It may, of course, not run on any given machine. But the language itself allows it.
Unlike a Fortran77 program, a portable C program doesn't have to change to support orders of magnitude changes in problem size.
> Doesn't it imply that it must be finite, because you can use sizeof() to find its size, which yields something of type size_t, which has maximum size SIZE_MAX?
That's a very interesting question that got me thinking for quite a while and the only conclusion I reached is that you deserve an upvote.
So (in reference to tombert's comment), f90 and beyond doesn't have those limitations. It also introduced conveniences like operator overloading and element-wise array operations, so I think it's a really simple/convenient language for basic scientific computing, if you want to code up some algorithm. That said, I always reach for Julia instead.
[1] http://math-atlas.sourceforge.net/
[2] https://bitbucket.org/eigen/eigen/src/default/Eigen/src/misc...
... which means they buried the lead pretty deeply, because libdill is an interesting little library: Structured Concurrency in C! From the FAQ:
> 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
> 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.