12 ms·

Show HN: A minimal Fortran TCP client and server

110 points by milancurcic 7y ago

tombert 7y ago
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?
- mhasbini 7y ago
  Out of topic. I recently finished reading "Skunk Works Memoir" and I'm interested in the day-to-day life for a developer there. Would you mind sharing a bit of your experience?
  - tombert 7y ago
    I was only an intern, and I haven't read that book, but it was overall a fun job. I was of a bleeding-heart-pacifist, so I made it pretty clear that I didn't want to work directly on weapons or anything like that and as a result, around 90% of what I worked on was actually C++ working on a camera to help detect mines. 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.
- ajxs 7y ago
  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.
  - grumpy8 7y ago
    I mean, when you have millions of line of code, it takes many many years to rebuild the system. It may make more sense to abstract away a part of the code and treat it as legacy-API-that-works-fine, and write new code in a new language.
  - shakna 7y ago
    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 7y ago
      > 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.
      - sampo 7y ago
        In the areas where you'd want to use modern Fortran (numerics, not TCP servers), it is easily also more maintainable than C++.
- milancurcic 7y ago
  > I haven't touched any later standards after 77; is Fortran still technically not Turing complete? Fortran has been Turing complete since its inception in 1957 :).
  - tlb 7y ago
    The argument against f77 being Turing-complete is that you can't dynamically allocate memory, or specify infinite arrays, or recurse. You have to declare a finite size for everything. So a program embodies a fixed limit on how big a problem it can handle. 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.
    - jcranmer 7y ago
      If that makes F77 not Turing-complete, nor is C. There is a finite amount of memory you can allocate in C, since a pointer must have finite size, implying there is a finite number of things it can point to.
      - tlb 7y ago
        The C language specification doesn't require a pointer to have finite size. Just because every C implementation has a limit, it doesn't mean the language itself does.
        tzs 7y ago
        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?
        trillic 7y ago
        The idea is that theoretically a perfectly portable C program could be written and work on problems of any size given sufficiently large hardware and a compiler implementation that takes advantage of that hardware. Unlike a Fortran77 program, a portable C program doesn't have to change to support orders of magnitude changes in problem size.
- pm90 7y ago
  Many of the libraries used by popular Data Science/Vis tools today (Matlab, Numpy etc) use BLAS and LAPACK which are written in FORTRAN
  - lordgrenville 7y ago
    Plus on the topic of Data Science, R is written in a mixture of FORTRAN and C!
    - Annatar 7y ago
      Yes, the core of R is written in Fortran because short of writing assembler code by hand, Fortran compilers generate the fastest machine code.
  - Annatar 7y ago
    Yes, for performance. If you need something to be fast and yet portable, Fortran is still the #1 language of choice, especially in supercomputing and finite element analysis fields.
  - alexhutcheson 7y ago
    BLAS now has a number of non-Fortran implementations, inlcuding ATLAS[1] (C) and and Eigen[2] (C++). LAPACK is still Fortran-only, although many libraries (including the two mentioned above) implement a subset of LAPACK in other languages. [1] http://math-atlas.sourceforge.net/ http://math-atlas.sourceforge.net/ [2] https://bitbucket.org/eigen/eigen/src/default/Eigen/src/misc/blas.h https://bitbucket.org/eigen/eigen/src/default/Eigen/src/misc...
- yiyus 7y ago
  Modern Fortran is practically a totally different language (although, maybe surprisingly, still compatible with older standards). In fact, it is a quite comfortable language to use if you need to work with vectors and matrices. In very rough lines: numpy array syntax with better than C performance.
basementcat 7y ago
Note this is free form FORTRAN 90 code; not your grandparent's f77 optimized for card punch entry.
- vallismortis 7y ago
  Wow, ageist much? My wind model is F77.
  - basementcat 7y ago
    Should have picked my words better; great grandparents. I still use f77 code for my day job on occasion.
  - wycy 7y ago
    Is this code on github/online somewhere? As someone who does fluid dynamics in Fortran 90/2018, I'd be interested in taking a look.
- wycy 7y ago
  Somewhat interestingly, I believe this is actually Fortran 2003 at a minimum based on the use of iso_c_binding[0]. [0] http://fortranwiki.org/fortran/show/iso_c_binding http://fortranwiki.org/fortran/show/iso_c_binding
sevensor 7y ago
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 7y ago
  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/README.md https://github.com/CodethinkLabs/fortrantools/blob/master/RE... (And related repos...)
deleted 7y ago
[deleted]
deleted 7y ago
[deleted]
deleted 7y ago
[deleted]
deleted 7y ago
[deleted]
msla 7y ago
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.

110 points by milancurcic 7y ago

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?

mhasbini 7y ago
Out of topic. I recently finished reading "Skunk Works Memoir" and I'm interested in the day-to-day life for a developer there. Would you mind sharing a bit of your experience?
- tombert 7y ago
  I was only an intern, and I haven't read that book, but it was overall a fun job. I was of a bleeding-heart-pacifist, so I made it pretty clear that I didn't want to work directly on weapons or anything like that and as a result, around 90% of what I worked on was actually C++ working on a camera to help detect mines. 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.
ajxs 7y ago
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.
- grumpy8 7y ago
  I mean, when you have millions of line of code, it takes many many years to rebuild the system. It may make more sense to abstract away a part of the code and treat it as legacy-API-that-works-fine, and write new code in a new language.
- shakna 7y ago
  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 7y ago
    > 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.
    - sampo 7y ago
      In the areas where you'd want to use modern Fortran (numerics, not TCP servers), it is easily also more maintainable than C++.
milancurcic 7y ago
> I haven't touched any later standards after 77; is Fortran still technically not Turing complete? Fortran has been Turing complete since its inception in 1957 :).
- tlb 7y ago
  The argument against f77 being Turing-complete is that you can't dynamically allocate memory, or specify infinite arrays, or recurse. You have to declare a finite size for everything. So a program embodies a fixed limit on how big a problem it can handle. 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.
  - jcranmer 7y ago
    If that makes F77 not Turing-complete, nor is C. There is a finite amount of memory you can allocate in C, since a pointer must have finite size, implying there is a finite number of things it can point to.
    - tlb 7y ago
      The C language specification doesn't require a pointer to have finite size. Just because every C implementation has a limit, it doesn't mean the language itself does.
      - tzs 7y ago
        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?
        trillic 7y ago
        The idea is that theoretically a perfectly portable C program could be written and work on problems of any size given sufficiently large hardware and a compiler implementation that takes advantage of that hardware. Unlike a Fortran77 program, a portable C program doesn't have to change to support orders of magnitude changes in problem size.
pm90 7y ago
Many of the libraries used by popular Data Science/Vis tools today (Matlab, Numpy etc) use BLAS and LAPACK which are written in FORTRAN
- lordgrenville 7y ago
  Plus on the topic of Data Science, R is written in a mixture of FORTRAN and C!
  - Annatar 7y ago
    Yes, the core of R is written in Fortran because short of writing assembler code by hand, Fortran compilers generate the fastest machine code.
- Annatar 7y ago
  Yes, for performance. If you need something to be fast and yet portable, Fortran is still the #1 language of choice, especially in supercomputing and finite element analysis fields.
- alexhutcheson 7y ago
  BLAS now has a number of non-Fortran implementations, inlcuding ATLAS[1] (C) and and Eigen[2] (C++). LAPACK is still Fortran-only, although many libraries (including the two mentioned above) implement a subset of LAPACK in other languages. [1] http://math-atlas.sourceforge.net/ http://math-atlas.sourceforge.net/ [2] https://bitbucket.org/eigen/eigen/src/default/Eigen/src/misc/blas.h https://bitbucket.org/eigen/eigen/src/default/Eigen/src/misc...
yiyus 7y ago
Modern Fortran is practically a totally different language (although, maybe surprisingly, still compatible with older standards). In fact, it is a quite comfortable language to use if you need to work with vectors and matrices. In very rough lines: numpy array syntax with better than C performance.

basementcat 7y ago

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

vallismortis 7y ago
Wow, ageist much? My wind model is F77.
- basementcat 7y ago
  Should have picked my words better; great grandparents. I still use f77 code for my day job on occasion.
- wycy 7y ago
  Is this code on github/online somewhere? As someone who does fluid dynamics in Fortran 90/2018, I'd be interested in taking a look.
wycy 7y ago
Somewhat interestingly, I believe this is actually Fortran 2003 at a minimum based on the use of iso_c_binding[0]. [0] http://fortranwiki.org/fortran/show/iso_c_binding http://fortranwiki.org/fortran/show/iso_c_binding

sevensor 7y ago

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 7y ago
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/README.md https://github.com/CodethinkLabs/fortrantools/blob/master/RE... (And related repos...)

deleted 7y ago

[deleted]

deleted 7y ago

[deleted]

deleted 7y ago

[deleted]

deleted 7y ago

[deleted]

msla 7y ago

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.