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?
[1] http://math-atlas.sourceforge.net/
[2] https://bitbucket.org/eigen/eigen/src/default/Eigen/src/misc...
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.
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.
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.
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.
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
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.
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
Not to mention all the unsafety issues. while fortran is bleeding fast while keeping safety on.
... 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.