Live data from Hacker News

Fortran Package Manager

github.com

41–50 of 73 posts

Re: Fortran Package Manager

#41
post #8

Earlier quoted context omitted.

"I don't know what the language of the year 2000 will look like, but I know it will be called Fortran." —Tony Hoare

I have seen this quote thrown around a lot and have never had the proper context to understand what Hoare was getting at. The quote is from 1982[1], which seems a bit too late for any “Fortran juggernaut” jokes to have been relevant, and even in 1982 I would have guessed that Fortran was considered a bit old-fashioned. Was he commenting on its comparatively simple design, compared to “flashier” languages like Pascal?…

In 1982, I knew of someone at a university who was working on the Fortran 8x specification that became Fortran 90. I don't remember it being thought of as old-fashioned, maybe just less of a general purpose language than in earlier years.

Re: Fortran Package Manager

#42
post #20

For folks who have never used Fortran, how is the day to day life compared to Python or Java?

Never or ever? I have to use it for a work project. It's ok when dealing with numbers or matrices, but very painful in many respects. It's missing quite a few features found in more recent languages. I don't recommend it personally unless you're working with other big fortran codes.

* Missing standard data structures, like hash maps. I just wish I had something like a Python dictionary built in.

* Strings are pretty awful. You can now have resizeable strings but using them is very painful (and buggy in gfortran). You'll have to constantly strip spaces off the ends of strings to even print them.

* Some of the compilers are very immature (gfortran), if using any fairly recent features (e.g. resizeable strings). I've hit several (still unfixed) compiler bugs and my code contains some terrible workarounds.

* Available libraries are hit and miss, particularly outside the numerical area.

* Linking to C/C++ is possible, but painful with the binding support.

* Documentation (including books) just isn't good compared to what's available for C/C++/Python, etc.

* No templates (would come in very handy for some routines which handle different numerical types).

* Ok for numerics, though can't use C/C++ intrinsics for AVX/SSE maths.

I suppose what I like better than C/C++ is the module system and built-in support for N dimensional arrays with proper slicing, etc. The allocatable array thing is quite nice - it's like smart pointers in C++.

Re: Fortran Package Manager

#43
post #22
post #20

For folks who have never used Fortran, how is the day to day life compared to Python or Java?

It depends on what you are doing. If it is numerical work with matrix operations, then Fortran is fast and pretty intuitive. Some of the annoyances come from dealing with legacy code and mixing it with modern standards.

Nail on the head with the mixing of standards. Every FORTRAN codebase Ive had to use at work always has a mix of 77, 90, and even pre 77 code mixed all together

Re: Fortran Package Manager

#44
post #36

Earlier quoted context omitted.

The intuition is similar to "why C over other languages?": speed. Many programmers treat C as the fastest/lowest-level cross-platform language, but Fortran sometimes has a slight edge (especially with specialised compilers, e.g. I remember Intel's producing very fast binaries). Although it's general-purpose, Fortran skews heavily towards numerical calculations, which is probably why it's not used much outside science…

But interfacing with Fortran from other languages is easy (well, barring some compiler assumptions that everyone seems to be making anyway). Why not leverage the general purpose strength of languages like Rust or C++ or Python (or even C), while still retaining access to the vast trove of numerical Fortran libraries? (Not that I'm judging, people should use whatever language they prefer).

That's what tends to happen, at least in the code I've worked on. C/C++ for the bits that need to "talk" to the OS, python/perl/bash for scripting purposes, and Fortran for the number-crunching core.

Re: Fortran Package Manager

#45
post #8

Earlier quoted context omitted.

"I don't know what the language of the year 2000 will look like, but I know it will be called Fortran." —Tony Hoare

I have seen this quote thrown around a lot and have never had the proper context to understand what Hoare was getting at. The quote is from 1982[1], which seems a bit too late for any “Fortran juggernaut” jokes to have been relevant, and even in 1982 I would have guessed that Fortran was considered a bit old-fashioned. Was he commenting on its comparatively simple design, compared to “flashier” languages like Pascal?…

Since you honored me by referencing my article, I’ll offer my interpretation. Notices he says “the language”. At the time, Fortran was the language for numerical/scientific computing. By 1982 it had evolved significantly from its origins 30 years earlier, but was still called Fortran. He is saying that it will continue to evolve, but no matter what it will look like in another 30 years, it will still be the language, and will still be called Fortran. He was prescient: Fortran 90 included radical advances to the language, but it remained, pretty much, the scientific programming language, and was still called Fortran. The last sentence of the article, which is from 2014, refers back to the epigram, and predicts that Julia may be the language that finally supplants Fortran for use in science and engineering. Now, Fortran is still dominant in high performance scientific computing, C++ has a niche in particle physics, but Julia is, in fact, making rapid headway across a wide variety of disciplines. So I think my prediction is turning out to be pretty good.

Re: Fortran Package Manager

#47
post #32

Earlier quoted context omitted.

Yes, but I think not as much as advocates of it would suggest.

Just like SQL, it suffices to rule on one specific use case to keep being used.

Yeah exactly - it's great for numerical computing.

I get a bit annoyed by Fortran advocates complaining about people using C++/Python instead of it, when there aren't libraries for doing really basic things. I think Fpm is a really good step in the right direction though.

Re: Fortran Package Manager

#48
This is really cool. There are definitely problems with security when it comes to package managers, but I think it has become apparent that having a dedicated package manager for your language is almost as important as the language features your language offers.

As a side note. I've never used Fortran, but I see it around from time to time (R & Python packages that have fortran dependencies). Is Fortran seeing a bit of a resurgence? Is there any reason to use Fortran over say C, C++, Rust, or some other language? Or is it simply down to Fortran's maturity providing robust libraries in certain areas that other languages haven't?

Re: Fortran Package Manager

#49
post #20

For folks who have never used Fortran, how is the day to day life compared to Python or Java?

I do an awful lot of baseball stats work .. for fun .. and quite a bit of it is done in FORTRAN. Working with numbers, large matrices and some pretty hairy calculations is much easier, to me, that using R or Python. There are also some really nice libraries available.

Of course, you have to overcome decades worth of ``stuff'' but it certainly is the right tool for what I am doing. It has a purpose but there is a learning curve to getting things done the FORTRAN way.

Re: Fortran Package Manager

#50
post #34

Earlier quoted context omitted.

Also Compared to Python Fortran is an old school compiled language - you have to get used to working with a compline/link cycle without the interactivity that Python has. This isn't any better or worse but does require a shift in mind set. Though I believe some people are trying to build a Fortan Repl

> Also Compared to Python Fortran is an old school compiled language - you have to get used to working with a compline/link cycle without the interactivity that Python has. I mean, yeah, Fortran is a bit old school, but being compiled is not exactly old school. Plenty of modern languages are compiled. I'd even say that Python and JS are the odd ones out from a modern perspective.

It might be a bit of a shock for those coming only from interpreted languages though.
Post reply on HN