[HN Gopher] Is Fortran "A Dead Language"? (2022)
___________________________________________________________________
Is Fortran "A Dead Language"? (2022)
Author : rsecora
Score : 114 points
Date : 2024-01-12 09:59 UTC (13 hours ago)
(HTM) web link (cpufun.substack.com)
(TXT) w3m dump (cpufun.substack.com)
| pjmlp wrote:
| Not only it is doing quite alright, latest versions 2003 onwards
| (latest is 2023), are quite confortable to use, offering almost a
| Python like experience, with a performance experience of 60+
| years in compiler optmizations.
| mapreduce wrote:
| "offering almost a Python like experience"
|
| Do you mean Python like easy syntax or do you mean Python like
| extensive std library?
|
| Never used Fortran but really curious to understand whether
| Fortran has good standard library support to try my hand at it.
| I've been doing Go and Python mostly and willing to learn one
| more language now and I'm trying to decide if it should be
| Fortran!
| medo-bear wrote:
| If you do anything related to numerical computations (which
| is a pretty huge field) learning Fortran wont be a waste of
| time. If you are doing anything else your time might be
| better spent elsewhere
| mapreduce wrote:
| Can I request some more insights about it? If I want to be
| doing something else, why isn't Fortran a good fit? Lack of
| extensive stdlib like Python and Go?
| medo-bear wrote:
| Mine was not a statement about its stdlib or if Fortran
| can do something else well. Great majority of people in
| Fortran community are focused on numerical methods.
| rnhmjoj wrote:
| Basically the only "stdlib" that Fortran gives you are
| some mathematical functions, super basic string and file
| operations and that's it. There are no APIs for
| networking, sockets, IPC, threads, etc. that pretty much
| al modern languages come with.
|
| Can you write a parser in it? Sure, but it's going to be
| painful dealing with strings. Can you write a web server?
| Yes, but you'd have to link to a C library that exposes
| the kernel TCP/IP interface to Fortran. And so, on.
|
| So, essentially it would be like using C without a libc:
| it's doable, but it doesn't really make sense.
| ivanpribec wrote:
| A few of these things exist already: - http:
| https://github.com/fortran-lang/http-client - sockets:
| https://github.com/modern-fortran/tcp-client-server -
| threads: https://github.com/interkosmos/fortran-unix
| omgmajk wrote:
| It's a use the right tool for the job thing. Fortran is
| very fast, used primarily for scientific computing in
| various fields - not a lot of people are writing general
| purpose code in Fortran. Of course you can do it, but
| it's not a great experience and you'd spend a lot more
| time doing work you'd rather already have tools for.
| rnhmjoj wrote:
| Unfortunately it's pretty much the opposite: Fortran doesn't
| have standard library, just a small set of "intrinsic"
| functions that a compiler must implement.
|
| Nonetheless, Fortran has built-in support for N-dimensional
| arrays, with vectorised operations (including custom
| functions), so the experience is pretty similar to Numpy.
| medo-bear wrote:
| Except that Numpy makes calls to foreign functions which
| are written in C, Cpp, or Fortran. It is also not in
| Python's stdlib.
|
| From the numpy website: NumPy brings the
| computational power of languages like C and Fortran to
| Python, a language much easier to learn and use.
| AnimalMuppet wrote:
| Depends on your definition of "standard library".
|
| There are libraries that may not be "standard" (that is,
| included in the standard) but are standardly available on
| Fortran. You need a matrix solver that will efficiently
| handle large, sparse matrices of complex variables, that
| will not degrade when faced with a stiff problem? Fortran
| has one of those. You can get it on pretty much any Fortran
| installation. It's solid, stable, and there's decades of
| experience with using it.
|
| So, from that perspective, Fortran has a _huge_ library.
| For numeric algorithms, virtually anything you want, it
| has.
| matrss wrote:
| I think they mean "python like easy syntax", fortran
| certainly does not have a std library that contains e.g. a
| HTTP client or SMTP server (to my knowledge).
|
| Although I would say the "easy syntax" mostly applies to
| numerical code only, i.e. numpy code and the same
| computations in fortran would look very similar since fortran
| has similar syntax for vector-based computations, something
| that e.g. C does not have at all.
| labster wrote:
| Do people actually use modern versions of Fortran though? I
| learned it in university in 2004, and we used Fortran 90
| because F95 was considered "too new", and one still encountered
| a lot of Fortran 77.
| ivanpribec wrote:
| They do. Some national HPC centers offer Fortran courses
| including elements of Fortran 2018 [1,2], including the
| latest features. (Disclaimer: I work at one.) The Intel
| Fortran compiler already includes some Fortran 2023 features
| [3].
|
| [1] https://doku.lrz.de/programming-with-
| fortran-10746212.html [2] https://doku.lrz.de/prace-course-
| advanced-fortran-topics-107... [3] https://www.intel.com/cont
| ent/www/us/en/developer/articles/r...
| kergonath wrote:
| I'd evolved since then. Support for Fortran 2018 is
| reasonable in gfortran and you can count on almost all of
| Fortran 2008 and before.
| enriquto wrote:
| > offering almost a Python like experience
|
| If you do scientific computing, the fortran experience is much
| better than python's. You never feel out of place. Multi-
| dimensional arrays of floats are a native type, loops are fast,
| and the system is extremely stable.
|
| What does python offer you? Lists, dictionaries, strings (none
| of which is of any use to scientific computing) and a plethora
| of slightly incompatible external libraries for dealing with
| matrices. Worse, there's no hope [0] that your algorithms based
| in numpy/scipy/numba/tensorflow/torch/jax will run unchanged in
| a decade, not to say in 50 years.
|
| [0] https://pythonspeed.com/articles/numpy-2/
| Galanwe wrote:
| Yet reality contradicts you.
|
| > What does python offer you? Lists, dictionaries, strings
| (none of which is of any use to scientific computing)
|
| pandas/numpy/scipy/etc, so basically you get a blas/la pack
| equivalent, with a R/matlab feel.
|
| > there's no hope that your algorithms [...] will run
| unchanged in a decade, not to say in 50 years.
|
| Very few people care about that.
| bitcharmer wrote:
| I have no idea why you're getting down-voted. I've worked
| in finance/algo-trading for 15+ years. Went through shops
| like Goldman Sachs, Morgan Stanley, UBS, HSBC. Quants
| everywhere use CPP and Python, sometimes R. I've never seen
| Fortran used anywhere.
| medo-bear wrote:
| If they use Numpy in Python they surely use Fortran under
| the hood.
|
| Did you work in HFT? I would be very surprised if they
| used Python for that, and almost equally surprised if
| they all dismissed Fortran as an option.
|
| Besides the things you named, quants also use Excell (of
| course) but probably less known is K, which is an APL
| type language
| Galanwe wrote:
| > If they use Numpy in Python they surely use Fortran
| under the hood.
|
| Even that is disappearing. It was common practice even 10
| years ago to use MKL as backend.
|
| > Did you work in HFT?
|
| Yes, I've done (and still do) HFT and mid freq since
| around 15 years.
|
| > I would be very surprised if they used Python for that
|
| Surprise!
|
| Nobody would dare do any heavy computation in e.g. C++ or
| Fortran or Cobol. It's just too unpractical, and slow to
| develop.
|
| You calibrate your models in Python/pandas/... , offline
| on historical data, and just use the prebuilt model to
| make the real-time prediction in C++, which doesn't
| involve much more than simple linear algebra.
|
| I would estimate conservatively that 80% of quants use
| Python, in both HFT and mid freq. There should be some
| niche where they use matlab, R, kdb or stata, but that's
| definitely a small fraction.
| bitcharmer wrote:
| I still work in HFT yes. A sibling comment lays it out
| better than I could, and I'm surprised that so many
| people here insist on Fortran's popularity when it's
| clearly absent from whole industries where you guys would
| expect to see it.
|
| Python is very widely used for prototyping and there's
| nothing anyone can do about it. In production the algos
| would be implemented in Cpp though. I'm merely stating a
| fact, not here to argue about anything. Raw K is almost
| never used but there's a lot of Q, depending on the shop.
| merolish wrote:
| Live trading systems are in C++ or Java, but like others
| have said Python is used for day-to-day research,
| sometimes R if the particular quant likes it.
|
| I never saw any Fortran in my time at Bloomberg in the
| 2010s but allegedly there was still a lot of it running
| in the nether regions.
| BeetleB wrote:
| Although financo/algo-trading is math heavy, it does not
| fall into the category of scientific computing.
|
| Just as you haven't experienced Fortran, there are
| several areas in science that have not experienced
| C++/Python, and rely on Fortran.
| Galanwe wrote:
| > Although financo/algo-trading is math heavy, it does
| not fall into the category of scientific computing.
|
| Care to elaborate on why this wouldn't be the case?
|
| As far as I can see, half of my desk is ex
| CNRS/CERN/CEA/... , the other half is the top brightest
| PhDs and engineers. When I look at weather forecast
| models, or biological DNA white papers, I don't see much
| difference in terms of scientific process or category of
| problem than what we see in quantitative finance.
|
| It may be sad, but the truth is finance phagocytates an
| immense chunk of the scientific community,abd it
| provides. There are interesting and hard problems to
| solve, virtually unlimited compute resources, etc.
|
| Most top quant HF have yearly double digit million dollar
| infrastructure bills, compute and storage clusters
| rivaling or surpassing academic ones, dedicated hardware
| manufacturers, etc.
| BeetleB wrote:
| I'm not disputing that there is seriously heavy math
| involved - many of my fellow PhDs in physics/engineering
| went to finance.
|
| It's just not what people consider as "science" :-)
|
| My point is that branch of HPC developed somewhat
| independently of most of other science disciplines. It's
| also relatively newer, so it doesn't rely heavily on
| legacy code from the 70's/80's. Generally, newer
| disciplines (computational biology, modern ML, etc) don't
| use Fortran. Older stuff (physics, electromagnetics, most
| engineering, etc) are full of Fortran, and continue to
| be.
| fastneutron wrote:
| > Very few people care about that.
|
| While it may be true that the absolute number of people
| involved is small compared to the wider tech industry,
| long-term code reproducibility is critically important for
| engineering-heavy industries with long-lived, high
| consequence physical assets. Think aerospace, nuclear,
| petrochemical, electrical, and other civil infrastructure.
| If something in the environment changes and you need to re-
| analyze the performance of that asset to ensure safety &
| reliability under the new conditions, the first thing you
| do is re-run the benchmark cases to verify the answers
| didn't change from the last time you ran it. If they did,
| it throws your entire basis for design into question unless
| you can conclusively resolve the inconsistency.
| kergonath wrote:
| > Very few people care about that.
|
| In the general population, probably. There is quite a large
| overlap with people doing HPC and scientific computing in
| general, however.
| DeathArrow wrote:
| There's also Julia.
| v9v wrote:
| Julia (and MATLAB) have large, heavy runtimes making them
| non-ideal for applications where size and startup speed
| matter, eg. libraries, edge computing.
|
| Their dynamic nature makes them much better at exploratory
| programming compared to Fortran though.
| internetter wrote:
| But OP isn't talking about edge computing, they are
| talking about scientific computing. Use the right tool
| for the job.
| pjmlp wrote:
| Julia might get there in confort, but still a lot of catch
| up to do with a compiled language designed for scientic
| computing, which also had to win the hearts of Assembly
| programmers in speed and code size, as the first high level
| language with an optimizing compiler (there were some
| failed attempts before FORTRAN).
| michaelt wrote:
| _> If you do scientific computing_
|
| For people whose needs are "I want to write a weather
| forecasting simulator, it needs to simulate very efficiently,
| we're modelling immutable physical laws so this code will
| still be good in several decades" then absolutely.
|
| OTOH for people whose needs are "I need to do some ad-hoc
| analysis on this CSV of experimental results, I gotta rush
| out a paper to not get scooped but nobody's going to build on
| this or use it again" or "I need to do a corporate data
| science project to forecast demand for this upcoming
| superhero movie based on social media buzz" - FORTRAN
| probably isn't the best choice.
|
| Unless you happen to already be such a master of square pegs
| that you're comfortable and productive at fitting them into
| round holes :)
| jhbadger wrote:
| It depends on what you mean by "scientific computing". I
| can't imagine doing scientific computing in the sense I do
| (using computing to analyze scientific data) without strings,
| lists, dictionaries, and (not that you mentioned them) data
| frames, which means R and Python are far better tools for
| doing my kind of scientific computing (yes, I know that R,
| and maybe Python, use libraries like BLAS underneath and
| those were written in Fortran).
| manx wrote:
| https://en.wikipedia.org/wiki/Computational_science
| jhbadger wrote:
| Okay, but this mentions exactly my own field of
| computational biology. I don't think many computational
| biologists are using Fortran (except indirectly through
| libraries like BLAS) in the 21st century.
| ginko wrote:
| > What does python offer you?
|
| The main offering of python is bindings and easy glue to
| pretty much any data source/sink imaginable.
| fastneutron wrote:
| > Lists, dictionaries, strings (none of which is of any use
| to scientific computing)
|
| Disagree on this one. In my experience, the computational
| kernels of our newer scientific & engineering codes (Fortran
| or C++) are almost never invoked as standalone applications,
| and are instead embedded within much more complex workflows
| that are orchestrated with a Python API or Java application.
| The string handling, data containers, and support for
| standard file formats in these higher level languages are
| indispensable at this level, and add negligible overhead
| compared to the computational expense of the main solvers.
| Yes, these things are more ephemeral, but they are also more
| interchangeable. Confining them to a higher abstraction layer
| lets you more cleanly decouple this stuff from the essential
| numerical parts of the code.
|
| The historical lack of support for these basic amenities in
| Fortran (and the C-family to a lesser extent) has resulted in
| the need to maintain innumerable ad-hoc I/O formats, home-
| rolled nonstandard parsers, and other bizarre, Rube Goldberg-
| like abuses of the language. Since the original developers of
| these legacy codes were scientists and engineers first, and
| developers second, these constructs inevitably wind up being
| tightly coupled to a larger, organization-spanning workflow
| whose input-output mapping has remained bitwise identical for
| three decades, and must continue to do so for just as many
| more.
|
| Higher-level languages like Python have greatly alleviated
| this nightmare, at least on a go-forward basis.
| goku12 wrote:
| When you say 'python like' experience, does it support slicing
| and broadcasting like in Numpy or MATLAB? I'm preparing to
| learn Fortran as a complete beginner. I'm curious about the
| ergonomics of the language.
| sampo wrote:
| > does it support slicing and broadcasting
|
| Slicing: yes.
|
| Broadcasting: I think only so, that you can operate on arrays
| by scalars, the scalar gets broadcasted.
| v9v wrote:
| not sure if it's different from what you are saying, but
| the elemental specifier[0] makes functions broadcastable,
| such functions operate on each element of its input
| separately.
|
| [0] https://fortranwiki.org/fortran/show/elemental
| medo-bear wrote:
| I think broadcasting in numpy is over rated. Its rules are
| complicated and ironically non-mathematical. Why should
| this be obvious? a = 5 b =
| np.array([1, 2, 3]) a + b >>>
| array([6, 7, 8])
|
| Looking through the documentation you get the feeling you
| are learning a whole new language whose syntax could change
| under your feet. They would have done better to use
| something like APL :)
| enriquto wrote:
| > Why should this be obvious?
|
| This is very natural, and consistent with standard
| mathematical notation. It's an abuse of notation so
| common that is barely ever mentioned in elementary
| mathematics. For example, when you work with functions
| f:R-R, like f:x-3x2, it is common to denote constants by
| their value. Thus you write 7 instead of x-7. Then you
| can write simply f+7, where f is a function and 7 is a
| value, and everybody understands what you mean. No need
| to write ridiculously correct stuff like f+(x-7) .
|
| Broadcasting with arrays is very natural if you interpret
| an array as a function of its indices. It is exactly the
| same thing as above!
|
| I second that we should be using APL anyways.
| medo-bear wrote:
| > This is very natural, and consistent with standard
| mathematical notation.
|
| Which mathematical notation? One of the first things a
| student of linear algebra gets taught is that you cant
| add scalars to vectors. The example you gave is not what
| is taught in most math classes, and seems weird to
| everyone unless you come from Bourbaki camp.
|
| > Broadcasting with arrays is very natural if you
| interpret an array as a function of its indices. It is
| exactly the same thing as above!
|
| But an array is just a contiguous data structure, not a
| function of its indicies.
| enriquto wrote:
| I don't understand what you mean. Precisely the Bourbaki
| camp would be the only people who would avoid the
| broadcasting notation that is commonly used in math.
| medo-bear wrote:
| > Thus you write 7 instead of x-7
|
| I meant this. Very few people look at a number 7 and
| think of it as a constant function
| enriquto wrote:
| My point exactly. That's what makes broadcasting natural!
| medo-bear wrote:
| Our positions diverge because you take the extra-formal
| specification in mathematics as basis, and then say, "nah
| thats too formal", broadcasting is more natural. On the
| other hand I take elementary to undergrad mathematics as
| basis and say that rules about adding (using a standard
| '+' symbol) a scalar to a vector in numpy via
| broadcasting is confusing.
| ayhanfuat wrote:
| Julia requires you to explicitly specify if you want to
| use broadcasting (i.e. `[2, 4, 8] + 3` fails so you need
| to do `[2, 4, 8] .+ 3`). When I first came across this I
| thought it was unnecessary but the more I use it the more
| I like it because I think it improved my mental model of
| broadcasting. With numpy it was mostly trial and error.
| enriquto wrote:
| > But an array is just a contiguous data structure, not a
| function of its indicies.
|
| When you do signal processing, you pretty much interpret
| 1d arrays as functions of time, 2d arrays as functions on
| the plane, etc. In that case, it is very natural.
|
| If I have an array "A" that represents an image, I can
| change the britghtness and contrast of the image by doing
| an operation like "B = a*A + b". This notation requires
| broadcasting because b is a constant, not an array (or,
| equivalently, a function).
| medo-bear wrote:
| > If I have an array "A" that represents an image, I can
| change the britghtness and contrast of the image by doing
| an operation like "B = a*A + b".
|
| But you dont write it like this in linear algebra. You
| write B = aA + b
|
| where b is just a vector. Or at least you would make b
| bold to distinguish it from a scalar
| enriquto wrote:
| I'm not talking about matrices as in linear algebra, I'm
| talking about functions. If you interpret a vector or a
| matrix as a function of its indices, then
| B = a*A + b
|
| means just B(t) = a*A(t) + b
|
| for all relevant t. This broadcasting is used
| _everywhere_ in signal and image processing, and it would
| be extremely unnatural if your language forced you to
| write some monstrosity that modified the constant b so
| that it has the same type as A.
| medo-bear wrote:
| > If you interpret a vector or a matrix as a function of
| its indices
|
| What exactly does this mean?
| enriquto wrote:
| A vector v = (v[0], v[1], v[2], ..., v[100]) is exactly
| the same thing as a function v taking a number i and
| returning a value v[i].
|
| Since you can sum scalars to functions, it is natural to
| sum scalars to vectors.
| medo-bear wrote:
| Perhaps this is really a personal preference, but in
| maths I really dislike ambiguity. There are is just way
| better notation for this. For example Einstein notation
| or Rici calculus? Besides being succint, it is explicit
| and well understood. Even just using plain i,j indicies
| is not too cumbersome. But for a b scalars and A a matrix
| B = aA + b
|
| is not well defined.
| sampo wrote:
| What else could 2*A + 1 mean, than this?
| [1 2] [3 5] 2 [ ] + 1 = [ ]
| [3 4] [7 9]
| medo-bear wrote:
| What's wrong with, [1 2] [1
| 2] 2 [ ] + 1 = 3 [ ] [3 4]
| [3 4]
|
| or, better yet, nothing. Mathematically that operation is
| not defined.
| ivanpribec wrote:
| For "broadcasting" an array along a particular axis, you'll
| need to use the function "spread(source,dim,ncopies)". But
| mixed array/scalar expressions are indeed supported.
| inkyoto wrote:
| Indeed, just like the rumours about the premature death of
| INTERCAL have been grossly overstated. For the INTERCAL
| freemasons have been tirelessly working in the midst of
| countless nights in the Lodge to complete the proposal to add
| support for Mayan numerals to INTERCAL.
|
| ---------
|
| Proposal for integrating Mayan numerals into INTERCAL
|
| Title: <<The Mesoamerican rejuvenation of compiler language
| (MAYA-INTERCAL enhancement)>>
|
| Objective: To intricately weave the ancient Mayan numeral
| system into the rich tapestry of INTERCAL, further enriching
| its already delightful amalgamation of Daedalian syntax and
| tangled operations.
|
| 1. Background and rationale
|
| As INTERCAL stands as a paragon of bleeding edge programming
| practices, it is only fitting that it embraces the Mayan
| numeral system, known for its base-20 vigesimal structure. This
| proposal promises to add another layer of intricate
| sophistication and enigmatic charm to INTERCAL, further
| challenging the brave souls daring enough to penetrate its
| nebulousness.
|
| 2. Mayan numeral representation
|
| Symbolic encoding:
|
| - Furry dot (*), representing the value of 1.
|
| - Prostrated bar (_), representing the value of 5.
|
| - Shell (O), representing zero.
|
| Example: The Mayan number for 19 (3 prostrated bars and 4 furry
| dots) would be represented as ___** in MAYA-INTERCAL.
|
| 3. MAYA-INTERCAL - syntax extensions
|
| New keywords:
|
| - MAYANIFY to declare a Mayan numeral.
|
| - TRANSMOGRIFY to convert between Mayan and standard INTERCAL
| numerals.
|
| - CALCULON for performing calculations with Mayan numerals.
|
| Syntax example: PLEASE MAYANIFY .#1 AS ___** -
| declares a Mayan variable. DO CALCULON .#1 WITH .#2
| GIVING .#3 - performs an operational ritual with Mayan
| numerals. PLEASE DO NOT GIVE UP
|
| 4. Numeric operations
|
| Operations in MAYA-INTERCAL will follow an intentionally
| intricate system:
|
| - Addition involves a ritualistic dance around the base-20
| system, where carrying over is not merely a matter of
| arithmetic, but a rite of passage.
|
| - Subtraction will be termed as the 'Reverse Ritual', involving
| comparable, yet not exceeding, complexities.
|
| 5. Entering Mayan numerals Mayan numerals, being sacred, can
| only be entered and accepted under very certain celestial
| conditions and divinations, otherwise the program will
| sacrifice itself.
|
| Syntax example: PLEASE ABSTAIN FROM READING
| MAYAN INTO .#1 UNLESS MERCURY IS IN RETROGRADE AND JUPITER
| ALIGNS WITH MARS IN VIRGO
|
| 6. Printing Mayan numerals
|
| Printing is not just a linear process; it is a multi-
| dimensional ceremony of revelation where the numeral eventuates
| in a complex Mojibake art form, respecting the vertical
| stacking and also adding a horizontal narrative and exquisite
| ASCII art. If a programmer has recently been penalised with a
| sacrifice, the output might be partially obscured or altered,
| representing the displeasure of the MAYA-INTERCAL dieties.
|
| 6. Error messages
|
| Error messages will be enigmatic, inspired by Mayan mythology
| and history.
|
| Example: <<The gods are displeased with your sacrifice at Line
| 10. Consult the oracle (compiler log) for penance.>>
|
| 7. Documentation: the Codex of MAYA-INTERCAL
|
| The documentation will be an epic saga, resembling ancient
| codices, filled with:
|
| - Detailed explanations professed to be chimeric tales.
|
| - Hieroglyphs and illustrations demonstrating concepts.
|
| 8. Community engagement: The Convocation of Coders
|
| Ventilate the proposal at the Grand Convocation, where devotees
| of INTERCAL foregather, preferably in thematic attire, to
| deliberate over the addition of these ancient numerals.
|
| 9. Implementation and compiler augmentation
|
| This involves:
|
| - Solidifying the proposal by way of embossing it into clay
| tablets and baking them in an oven until medium rare.
|
| - Consummating the compiler extensions to support Mayan
| numerals.
|
| - Ensuring that the new features introduce delightful
| mannerisms and whimsical behaviours.
| xioxox wrote:
| As someone who has to use Fortran for their job fairly
| frequently, I say Fortran is a pretty awful experience compared
| to Python.
|
| Although Fortran is good at arrays, it is terrible at any other
| kind of data structure. You don't get a standard set of useful
| data structures (e.g. associative map, k-D tree). Unless you
| like implementing such stuff, you have to look through a bunch
| of possibly-working half-implemented codes found using google.
|
| For something focused on numerics, it's lacking in standard
| IEEE numerical things such as a function to check for nan (GNU
| extension?!). There aren't an easy ways to do SIMD, excepting
| hoping the compiler does it for you. There aren't even standard
| numerical constants, so you get the joy of defining your own PI
| and hoping it doesn't clash with someone else's.
|
| Strings in Fortran are beyond awful, even with the new ability
| to reallocate string length.
|
| Then we come to the compilers. The commercial ones may be ok. I
| know the free ones are very buggy.
| jabl wrote:
| > For something focused on numerics, it's lacking in standard
| IEEE numerical things such as a function to check for nan
| (GNU extension?!)
|
| The IEEE_ARITHMETIC module has been part of the Fortran
| standard since Fortran 2003, and includes, among others, the
| IEEE_IS_NAN() function.
|
| (Supported in GFortran since version 5:
| https://gcc.gnu.org/gcc-5/changes.html)
| ivanpribec wrote:
| The "!omp simd" works very well IMO. In general however, the
| auto-vectorizer tends to do a pretty good job.
| Koshkin wrote:
| > _You don 't get a standard set of useful data structures
| (e.g. associative map, k-D tree)_
|
| Well, C does not have those, either... (I would not call
| using C "pretty awful experience" though.)
| gumby wrote:
| I think the meaningful definition of "dead language" is "nobody
| will begin a new code base in it any more, except as a hobby or
| research project".
|
| Pretty likely that's the case with COBOL, definitely Algol, PL/1,
| Pascal, and Prolog.
|
| Though uncommon or domain specific, not the case with APL (well
| J), Common Lisp, Forth, or Haskell.
|
| I think there's more new code being written in FORTRAN these days
| than in those last four combined.
| jjgreen wrote:
| The all-caps spelling marks you out as an F77 veteran (or
| earlier!)
| gumby wrote:
| Ha ha yes, though I haven't written a line of FORTRAN (nor
| fortran) in decades.
|
| It pains me to call CommonLisp obscure or uncommon because I
| used it heavily for a long time, but that's the tough truth.
| It's funny to think that one major criticism at the time was
| "its standard library is too massive" and now "its standard
| library is too small".
|
| I don't remember anyone even thinking such a thing about
| Fortran, perhaps because standard library didn't really mean
| anything for Fortran and because there have been tons of 3P
| Fortran libraries in the PD since before I was born.
| fortran77 wrote:
| WHAT'S WRONG WITH THIS?
| augustk wrote:
| AN APOSTROPHE IS MISSING.
| jjgreen wrote:
| PEDANT
| withinboredom wrote:
| The Dutch really need to teach mierenneuker to more
| people. Antfucker is such an amazing term.
| kergonath wrote:
| I am quite partial to sodomising flies, which is the
| French equivalent (used for the action, however, not the
| person doing it).
| kergonath wrote:
| You forgot the 23H before your character constant. Good
| mark for starting in the right column, though!
| sspiff wrote:
| There's still a small-ish community working on and building new
| things with FreePascal.
| gumby wrote:
| I may not be a Pascal fan but still I'm delighted to learn
| this.
| DeathArrow wrote:
| Same for me. After using Basic on ZX Spectrum, Pascal was
| the first evolved programming language I've learned. And,
| at it's time, it was quite good.
| LeFantome wrote:
| Alive, kicking, and actually supported by some decent
| cooling.
|
| https://www.lazarus-ide.org/
| ahoka wrote:
| Some people learn Latin and it's used for naming organisms.
| Still a dead language.
| arghwhat wrote:
| Not by OPs definition.
|
| You also wouldn't call the newer invented languages like
| Esperanto dead, and yet there's more people who know and
| can speak Latin (using one of the modern pronunciations)...
| sandworm101 wrote:
| It is the official language of the Vatican. That isnt
| nothing and probably saves latin from formal dead status
| imho. And lots of military organizations use it for mottos.
| So someone is out there creating new sentences with it on a
| semi-regular basis.
| moffkalast wrote:
| Last I checked there were no people being born in Vatican
| nor had Latin as their first language, citizenship is
| only given based on the office you hold. It's pretty
| close to nothing, it's a corporate HQ with a language
| requirement.
|
| Dead languages aren't those who aren't being spoken or
| used anymore, it's those that have no native speakers.
| It's not something that's in any way compatible with
| programming languages.
| fasterik wrote:
| Latin has no first-language speakers, so that makes it a
| dead language by definition. That's different from being
| an extinct language, which means that it would have no
| first- or second-language speakers.
|
| https://en.wikipedia.org/wiki/Extinct_language
| andylynch wrote:
| Classical languages like Latin are a bit of a special
| case - for instance new works and translations /imto/
| Latin are still occasionally published (Hobbitus Ille for
| instance is stocked in certain bookstores here)
| olddustytrail wrote:
| > It is the official language of the Vatican
|
| For a second there I thought we were still talking about
| Pascal! I'd wager it should be...
| sspiff wrote:
| Looking at the activity on the Free Pascal compiler[0]
| compared to some other, non-dead languages like Crystal[1],
| I would say Pascal isn't dead.
|
| They had a major release to their most popular IDE just a
| few weeks ago[2].
|
| A lot of these projects built with FP aren't as visible in
| the HN community, because they related to different
| hobbyist fields, aren't keystone components in the startup
| ecosystem etc. But they for sure exist.
|
| [0] https://gitlab.com/freepascal.org/fpc/source/activity
| [1] https://github.com/crystal-lang/crystal/activity [2] ht
| tps://forum.lazarus.freepascal.org/index.php/topic,65631.0.
| ..
| livrem wrote:
| The Castle Game engine is not mentioned often, but it
| looks pretty mature from the screenshots and has been in
| active development for many years. Most recent news
| update was a few weeks ago. I have not gotten around to
| try it yet. Only started playing around with FreePascal a
| bit last year after not having used Pascal at all for
| some 25 years.
|
| https://castle-engine.io/
| sspiff wrote:
| I was looking for this before when writing my reply to
| show as an example but forgot the name of the project,
| thanks!
| pid-1 wrote:
| Dead language has a very specific definition tho.
| lp4vn wrote:
| Using your definition I would argue that VBScript, Ceylon and
| CoffeeScript are also dead.
|
| Perl is seeing a strong decline and I think it will join the
| dead group in a few decades.
| HeckFeck wrote:
| > Perl is seeing a strong decline and I think it will join
| the dead group in a few decades.
|
| A shame - I much prefer its take on a versatile, unixy
| scripting language.
|
| Much has been done to keep it alive - the comprehensive book
| Modern Perl, and the well-integrated Mojolicious web
| framework. But it doesn't seem to be enough. I'm the only one
| in my circles and age range who knows it, everyone else would
| reach for Python, shell or even JavaScript.
| nordsieck wrote:
| > everyone else would reach for Python, shell or even
| JavaScript.
|
| The rise of Go as a sysadmin/devops tools language has also
| probably hurt Perl quite a bit.
| macintux wrote:
| I'm skeptical. Perl was in steep decline long before Go
| became a known quantity.
| Koshkin wrote:
| Also TCL.
| that_guy_iain wrote:
| I think Perl is pretty much dead, who is starting a new
| project in Perl? I haven't seen a Perl project in years. It's
| just still heavily used in legacy applications too big to
| rewrite.
| moffkalast wrote:
| Every time anyone uses Latex on Windows it uses Perl to
| compile the pdf. One has to stand back and think how
| absolutely ridiculous that is in 2024.
| einpoklum wrote:
| Yeah, I guess it is kind of ridiculous that Windows is
| still a thing :-)
| moffkalast wrote:
| Both indeed are :P
| pjmlp wrote:
| It isn't for lack of trying the Linux Desktop thing.
| einpoklum wrote:
| Actually, I would say it is almost entirely for lack of
| trying the Linux Desktop thing.
|
| These days, (the more friendly) Linux desktop
| distributions are about as easy to install as Windows;
| about as easy to use as Windows; and about as
| maintainable by a novice user as Windows.
| w4 wrote:
| Why is it ridiculous? The goal of a computer program is
| to solve a problem. The Perl script solves the problem.
| It handles all of the weird edge cases a re-write would
| rediscover. Re-writing it would take engineer time away
| from other priorities. And a re-write in a new language
| offers no guarantee that Microsoft wouldn't find
| themselves in the exact same situation 10 years hence if
| the language they chose for the re-write falls out of
| favor.
|
| If it ain't broke, don't fix it.
| moffkalast wrote:
| Because it's an external dependency that must be
| installed manually in certain cases? A site must be up to
| host downloads for this prehistoric thing, and those
| binaries must be built, tested, and kept up to date by
| someone who might one day just vanish once they become
| bored of thanklessly maintaining a holy relic.
|
| Yes it may take more effort to rewrite it natively now
| into whichever language the latex compiler is written in
| otherwise, the real braindead decision was not starting
| out that way. I mean shit, a modern equivalent would be
| of having to install python to use rustc or something.
| kergonath wrote:
| > Because it's an external dependency that must be
| installed manually in certain cases?
|
| It is everywhere. About the only case where you'd need
| that is on Windows but then if you are installing LaTeX
| on Windows getting Perl is a tiny bit of the complexity
| of the whole thing.
|
| > A site must be up to host downloads for this
| prehistoric thing, and those binaries must be built,
| tested, and kept up to date by someone who might one day
| just vanish once they become bored of thanklessly
| maintaining a holy relic.
|
| It's not any more prehistoric than emacs, bash, or GCC;
| its latest version was published about a month ago. The
| CPAN is perfectly able to handle downloads. And it's
| going to be in the repositories of all Linux
| distributions for the foreseeable future, considering how
| many tools depend on it. It is under active development;
| I don't know where you got the idea that it was one guy
| in his basement doing it.
|
| > Yes it may take more effort to rewrite it natively now
| into whichever language the latex compiler is written in
| otherwise, the real braindead decision was not starting
| out that way.
|
| The real braindead decision is to jump on every language
| du jour just because. There is an optimum and I am sure
| at some point it will get rewritten in something else
| (see lualatex for example), but we cannot rewrite
| everything that works from the ground up every time a new
| shiny language shows up. Latex does not rust but I am
| sure at some point someone will find a clever pun and
| there'll be a Show HN about it. In the meantime raging
| because a bit of software use some random language is not
| very productive or helpful.
|
| > I mean shit, a modern equivalent would be of having to
| install python to use rustc or something.
|
| From my experience rustc is not easier to install on
| Windows than Perl. On Linux it does not matter as
| everything is in the repos anyway.
| deciduously wrote:
| There is a huge amount of perl on your average Linux
| system, and it's integral to the GNU Autotools suite which
| is still widely used in many critical system components. I
| have trouble imagining it going anywhere at this point.
| that_guy_iain wrote:
| You seem to be confusing "new projects" with "maintained
| projects".
|
| Perl like all the other languages that are heavily used
| aren't going to be going anywhere. They're used in legacy
| code. However, the original comment had a definition.
| Which says nobody would use it to start a new project.
| Talking about currently maintained projects doesn't
| really change the fact it doesn't seem anyone is using it
| for new projects.
|
| > I think the meaningful definition of "dead language" is
| "nobody will begin a new code base in it any more, except
| as a hobby or research project".
| empath-nirvana wrote:
| Are new programmers learning perl? That's probably the
| real question. I think the answer is no. So it'll be dead
| as soon as all the people coding in it today retire.
| DeathArrow wrote:
| Isn't Delphi still used? And isn't Delphi still Pascal?
| projektfu wrote:
| Pascal is definitely somewhat alive, but way far from its
| heyday on DOS and Macintosh. For dead languages in the class,
| Modula-2 is mostly dead and Modula-3 is definitely dead.
| Forte TOOL is dead.
|
| Pascal has its niceties, especially enabling one-pass
| compilation and pretty clear code. It's neither
| overcomplicated like Ada nor relatively unknown like
| Modula-3.
| pjmlp wrote:
| GNU Modula-2 just joined the set of official GCC supported
| languages on a full install, and is now listed on the set
| of languages that matter on Compiler Explorer.
| grose wrote:
| While Prolog is niche it's still alive and kicking IMO. The go-
| to example for a 'modern' project is TerminusDB. I'm currently
| using Prolog for a greenfield expert system project at $work.
| There's been a bit of a Datalog resurgence as well, you can see
| it in the Biscuit authz system for example. As a fundamental
| pillar of logic programming, I don't think it will ever die
| (akin to Lisp and functional programming). Pure speculation
| here but I think we might see more interest towards symbolic AI
| in the coming years coupled with LLMs to ground answers against
| well-defined knowledge bases, as a sort of anti-hallucination
| measure.
| MichaelZuo wrote:
| Yeah for 'a dead language' there would only be ALGOL, PL/1,
| and not much else. Excluding really niche languages that
| never made it out the research lab in the first place.
| LeFantome wrote:
| I didn't even see Pascal on that list. Certainly not dead.
| Lazarus just had a release the other day.
| Koshkin wrote:
| Undead, then? :)
| JeffSnazz wrote:
| > against well-defined knowledge bases, as a sort of anti-
| hallucination measure.
|
| Given that humans don't have anything resembling well-defined
| knowledge I'm somewhat confused why this keeps coming up as
| something desirable.
| pjmlp wrote:
| Embarcadero is still in business selling Delphi licenses, a new
| version was released last quarter, and there are enough
| companies in Europe, to at least have them in two German
| conferences, alongside Windows and .NET developers.
|
| COBOL and PL/I are still pretty alive for anyone working today
| on IBM and Unisys mainframes and microcomputers, regardless of
| bug fixes or new features.
| AnimalMuppet wrote:
| > COBOL and PL/I are still pretty alive for anyone working
| today on IBM and Unisys mainframes and microcomputers,
| regardless of bug fixes or new features.
|
| Are they alive by gumby's definition of alive? Is anyone
| beginning new codebases in COBOL or PL/I, even on mainframes?
| pjmlp wrote:
| A dead language is something like BLISS or Concurrent
| Pascal.
|
| Brown field development moves much more consulting money
| per year than green field development.
| jcranmer wrote:
| New versions of the COBOL standard are still coming out, so
| I'd guess that the answer is "yes".
| kjs3 wrote:
| Yes, there are new COBOL code bases.
| araes wrote:
| The issue with COBOL (opinion) is that its used in
| "business, finance, and administrative systems for
| companies and governments" (development sponsored by the
| DoD) which all tend to be high money, secrecy, and
| competition. Plus, back in 2012, 60% of all companies
| surveyed still had COBOL in the back somewhere (2017: 43%
| of banking systems still used COBOL with over 220 billion
| lines of COBOL code).
|
| There might be stuff written COBOL, except they're never
| gonna share it with you, cause its far too important to the
| fight over the $100 trillion stock markets.
| ivanpribec wrote:
| Personally, I like to think of Fortran as the language of
| large-scale numerical PDE and eigenproblem solvers. Most
| scientific and engineering problems boil down to one of these
| two.
| gh02t wrote:
| At least in the US national lab system Fortran is nominally
| being phased out in a lot of projects. It's just gotten too
| hard to find highly skilled Fortran programmers to maintain
| these complicated projects, so a lot of codebases are
| gradually being moved away from it. However the reality is
| it's mostly aspirational; some of the large codebases have at
| least made big progress towards migrating onto C++ but the
| tail is very long indeed and it's still entrenched with many
| of the greybeard HPC folks. It's also tough to imagine some
| of the big legacy codes that are still heavily used in the
| nuclear industry (e.g. MNCP) migrating away due to the sheer
| amount of experimental validation that has been done on the
| existing Fortran code.
|
| I personally know and like Fortran in its modern form, at
| least within its little niche. But the ability to maintain
| these codes long term is really important and it's tough to
| see that being viable with the supply of professional-level
| developers withering to nothing.
| wbl wrote:
| National labs should be able to attract people who can
| learn Fortran well enough to maintain those codes. After
| all the hard part is the math, not the programming.
| kazinator wrote:
| The hard part is probably getting those who are good at
| the math to be _interested_ in crap like Fortran.
| gumby wrote:
| I don't think it's fair to call Fortran "crap",
| especially given most of the alternatives.
| sfpotter wrote:
| You'd be surprised. People who aren't particularly
| interested in programming qua programming don't typically
| have strongly held opinions about it. Using the same
| programming language as the group you're working in is
| usually the main consideration. Speaking from experience
| as someone who has worked in an applied math group where
| the predominantly used language was Fortran.
| Solvency wrote:
| I don't get this. It's highly difficult to find vast troves
| of military reserves (ie: bodies who can do military stuff)
| in war time. That's what bootcamp and sergeants are for.
|
| Hell my sister (print sales) joined a new firm and she had
| to spend six weeks in an intense classroom style training
| program the company ran to get new staff prepared for the
| nuances of their product.
|
| It seems straightforward to setup a Fortran internal
| bootcamp for experienced developers at these massive legacy
| institutions, worth the upfront investment...no?
| gh02t wrote:
| Yeah, all of that is part of the long tail. Fortran isn't
| going away, but with younger people who grew up without
| Fortran getting into leadership positions momentum is in
| the favor of moving HPC and sometimes more mundane
| computational code to C++. It's not just that developers
| are harder to find, it's that C++ is also offering
| advantages with better tooling, better libraries and
| community support, etc. Leveraging (and contributing to)
| open source is also important for DoE, which is tough in
| Fortran.
|
| Of course you could make the case for even more modern
| languages like Rust etc as well, but the national labs
| are still on the conservative side when making decisions
| for their big projects. C++ does hit a nice sweet spot in
| terms of performance, features, and longevity despite the
| warts.
| dtech wrote:
| The problem is who is willing to do this?
|
| If you go into such a bootcamp as a fresh grad, you
| basically pigeonhole yourself into working in that niche
| forever. You would have a massive setback when switching
| jobs compared to taking a bogstandard Java job or
| whatever.
| sfpotter wrote:
| There are loads of people who'd be willing to do this at
| a national lab. The bigger problem is that very few
| national labs are located in places many young people
| want to live. For the ones that are (LBL), it's
| competitive to get a job there.
|
| You're also wrong about the setback and being stuck in
| that niche. Once you learn the first language, more
| likely than not you'll have opportunities to continue to
| grow and develop in the role and learn new things. Most
| people are pretty adaptable.
| segmondy wrote:
| Wow, folks are writing new code bases in Pascal and Prolog. At
| least that I know.
| sheepscreek wrote:
| I think Prolog is still used in some niches. But that
| definition is apt. Fortran is far from dead. It might even be
| on the verge of a renaissance.
|
| Numpy took inspiration from Fortran and MATLAB. Most scientific
| computing libraries use Lapack and BLAS libraries under the
| hood (which were written in Fortran).
|
| Honestly, I think if Fortran had a few intuitive higher order
| abstractions/libraries - one wouldn't need to mess around with
| C++. And now thinking more about it - it would be very cool to
| have a Numpy to Fortran transpiler.
| lagniappe wrote:
| I still write Pascal today. N=1 but I wouldn't call it dead,
| there's a lot of us.
| nequo wrote:
| Do you use it for new non-hobby projects? If yes, do you mind
| sharing what you build with it?
| omgmajk wrote:
| One of the new PS4 emulators is written in FreePascal, I see
| new projects popping up every now and then.
| z3phyr wrote:
| A great game I play which was relatively recently released
| (HROT) is written in Pascal.
| LeFantome wrote:
| Prolog is dead? I was thinking of learning it.
| kaba0 wrote:
| Haskell is definitely not like the others and your last
| statement would be untrue with that on the list.
| Koshkin wrote:
| It is believed that Prolog is "a better version of SQL."
| kazinator wrote:
| Is there such a voracious need for more and more new numerical
| libraries?
| emadb wrote:
| The TIOBE Index [1] ranks Fortran at 12th place! Consider that
| Ruby is at 18th. In my opinion, this says a lot about the value
| of the index.
|
| [1] https://www.tiobe.com/tiobe-index/
| sspiff wrote:
| TIOBE index is sometimes very strange, but it takes into
| account available jobs as well. That said, their methodology
| has been challenged forever.
|
| Still interesting to see that languages like Fortran (12th) and
| Pascal (13th) are ranked higher than the most popular languages
| for mobile app development (Swift for iOS, ranked 16th, and
| Kotlin for Android, ranked 17th) or a highly praised and
| adopted language for new projects like Rust (only 19th!).
| AnimalMuppet wrote:
| Pretty sure that Kotlin is _not_ the most popular language
| for Android development. That would still be Java.
| nairboon wrote:
| One day, dlang might even overtake cobol in the TIOBE index...
| daniel-s wrote:
| Sorry to be negative on the web, but the TIOBE index has no
| value whatsoever and is complete gibberish. Nobody should be
| paying attention to it.
|
| https://youtube.com/shorts/m76vWNr83wo
| fasterik wrote:
| I don't care one way or another about the TIOBE index, but
| that video is obnoxious and isn't making an argument or
| presenting data. Not sure why anyone would be convinced by
| this.
| daniel-s wrote:
| I just linked a short because I figured it fit into the
| attention span of a typical internet user.
|
| If you want something more reasoned there's this:
| https://blog.nindalf.com/posts/stop-citing-tiobe/
| BrandoElFollito wrote:
| So what would be the property reference for "average language
| popularity"?
| kibwen wrote:
| Even if TIOBE wasn't garbage (and let's be clear: TIOBE is
| and always has been garbage for a litany of reasons), no
| such reference would exist, because the question is ill-
| specified.
|
| Are you a non-technical manager? Then hire people who know
| the language your company has always used, or otherwise
| whatever languages your hiring pool is familiar with.
|
| Are you a technical manager? Then you evaluate languages
| based on the intersection of hiring availability and
| technical merits.
|
| Are you a student? Then use whatever language looks most
| interesting.
|
| Are you an educator? Then use whatever language best
| expresses the concepts of the specific curriculum.
|
| Are you an open source contributor? Then select a language
| to work in based on technical merits, personal taste, and
| community interaction.
|
| "Popularity" is not one thing, it's dozens of things which
| all vary based on context.
| bitcharmer wrote:
| TIOBE is as reliable as Gartner.
| bartlettD wrote:
| Jim's article pretty much confirms my assumption that Fortran
| isnt "dead" but is instead more of a de-facto domain-specific
| language. If you're a meterologist, you'll probably be using
| Fortran just because all of the existing libraries are built for
| it.
|
| Unless you're doing scientific computing, Fortran is effectively
| dead.
| medo-bear wrote:
| > Unless you're doing scientific computing, Fortran is
| effectively dead.
|
| Thats kind of like saying, unless you are
| doing systems programming C is effectively dead
| bartlettD wrote:
| Good point, from a certain perspective all programming
| languages are dead and we're actually historical computer-
| lingusts.
| tovej wrote:
| C is very much also alive in games programming, binary
| security research, embedded systems, HPC, and as a target
| language for simple compilers. Oh, and as the lingua franca
| of all foreign function interfaces. And there's still a
| thriving vommunity of people writing C purely for fun (e.g.
| see obfuscated c programming competition).
|
| I think it's completely fair to say that Fortran is dead
| because only physicists use it. And there is no way to
| justify any similar statement for C.
| medo-bear wrote:
| I understand that C is far more used than Fortran. Of
| course I also dont think C is dead. I was trying to make a
| statement about saying Fortran is just alive in scientific
| computing. While this is mainly true, scientific computing
| is so huge that it is quite a big thing to be alive in it.
|
| And no, I don't think only physicists use Fortran. If you
| really think this then you probably dont quite understand
| the ecosystem of numerical computing. Besides if only
| Physicists use Fortran and is otherwise dead, I hardly
| think, for example, that AMD, Intel, and Nvidia would
| bother releasing optimizing compilers just for Fortran.
| Zababa wrote:
| I think a difference here is that for lots of people they can
| through the stack of things they use and find C. This is less
| the case for Fortran.
| Wwhisperer wrote:
| Jim's observation seems to be generally similar on other HPC
| clusters in other countries.
|
| A lot of scientific software, as I can confirm especially in
| numerical fluid dynamics, is written in FORTRAN or at least uses
| some libraries written in FORTRAN.
|
| The basis of numerical computing in form of the BLAS/LAPACK
| libraries is written in FORTRAN and has had a huge impact on
| everything in this part of computing.
|
| If I am not mistaken even the python libraries depend on
| BLAS/LAPACK, although they might be using implementations written
| in C or the like.
|
| Nevertheless, FORTRAN is still the work horse in a lot of
| computational scientific disciplines and should not be
| disregarded as being dead.
| physicsguy wrote:
| "ECMWF's Integrated Forecast System"
|
| I had to get this compiling and running this for a University HPC
| cluster a few years ago, and good lord, it was hell. Manually
| patching things all over the place to get it running.
| btbuildem wrote:
| It's one of my go-to models (for checking the weather, not for
| computing the results myself!), I didn't know that most meteo
| stuff runs on FORTRAN.
|
| In my experience with data-science and engineering code.. well,
| the fiery gauntlet of getting a large old project to run in a
| new place might not be the language's fault, but be related to
| the goals of the folks who first set it up.
| sampo wrote:
| > I didn't know that most meteo stuff runs on FORTRAN.
|
| Not just most, but all. All weather models, all climate
| models. And I venture to guess: All ocean circulation models.
| dvh wrote:
| I went to local job website and searched new jobs in last month:
| 365 java 324 javascript 299 python 69 c#
| 59 c++ 59 php 5 delphi 0 fortran
|
| So yes, I would say fortran is dead language
| sjducb wrote:
| Was that all of the languages?
|
| Where are Go and Scala
| dvh wrote:
| 15 scala 9 golang
| wiz21c wrote:
| And rust ??? C'mon it's HN! :-)
| jokteur wrote:
| It's because all these jobs using Fortran are scientific
| research projects. It is not explicitly asked, but if you are
| doing high performance computing, chances are you will be using
| Fortran. Scientific codes live for decades.
|
| For example, I'm using a code that has been started in 1981. It
| is still very relevant and performant. Of course I wish I could
| use C++ or even Rust, but the fact is that (high performance)
| numerical computing is first class citizen in Fortran, which is
| not the case in C++ or Rust. I wish however that the tooling
| around Fortran wasn't stuck in the nineties.
| ivanpribec wrote:
| Bjarne Stroustrup on Fortran users [1]:
|
| > Fortran is harder to compete with. It has a dedicated
| following who [...] care little for programming languages or
| the finer points of computer science. They simply want to get
| their work done.
|
| [1] https://ieeexplore.ieee.org/document/4263269
| Scarblac wrote:
| 3 of our 15 devs write Fortran, but we don't find them through
| dev job sites. They have PhDs related to hydrodynamic
| simulations and many of the people in the field know each other
| through conferences.
| ok123456 wrote:
| The jobs that use Fortran will be more concerned that you know
| things like crystal plasticity and molecular dynamics at the
| Ph.D. level.
| francisofascii wrote:
| When I search Fortran, all I see are aerospace jobs. So yeah,
| nothing fun an exciting. /s :)
| _s_a_m_ wrote:
| Who care who thinks what, a tweet, really? As if we have to agree
| on some pointless statements. In certain areas it is used, in
| others not. Now what?
|
| I really don't know what the point of such posts are. It is only
| relevant for people who want to go into scientific computing, and
| even there you have some GPU rewrites going on. So not everyone
| is using it but physicist etc. do. Also the legacy code is huge,
| like with C++.
| stabbles wrote:
| I don't know what the state of things is right now, but if
| Fortran is the language of choice for HPC, then explain to me why
| it's so hard to write portable code that targets accelerators.
|
| Some folks have attempted to port Fortran projects to CUDA
| fortran, but that only targets Nvidia GPUs. Then there was openmp
| 5, but barely any compiler to target AMD gpus.
|
| New HPC projects are written in C++ exactly because it's much
| easier to target various GPUs in the same code base.
|
| Happy to be convinced otherwise, but this is what I've observed
| ivanpribec wrote:
| Historically, it has been easier for vendors to work in their
| own walled gardens, and get customers locked in, than it is to
| collaborate on open standards and APIs.
| jokteur wrote:
| I agree with you.
|
| The thing is, compared to some of the scientific codes out
| there, GPU are quite recent. Sometimes, slapping OpenMP pragma
| on the code is not sufficient to take advantage of
| accelerators, and thus you would need a significant rewrite.
|
| But rewriting a scientific code is a daunting task. Often you
| have a code where there have been two decades of PhD and
| Postdocs fine tuning the scientific code, and the numerical
| schemes in the code do not correspond to the original article
| anymore. Nobody knows anymore exactly how the code works, and
| rewriting the code would require that the rewrite matches all
| the features of the original code (and reproduces the same
| results). It is basically an impossible task, especially when
| the labs don't have the resources to hire software engineers.
|
| In practice, nobody wants to rewrite scientific codes for GPU
| (and sometimes, the problem is fundamentally incompatible with
| GPU architecture). So as a compensation, they slap some OpenMP
| pragmas on some parts of the code, hope for the best, and
| anyways Nvidia clusters are more common than AMD (at least in
| the scientific world), so OpenMP barely compiling for AMD is
| not a problem.
|
| This means that legacy scientific codes are pretty much stuck
| with the CPUs. And in the scientific world, Fortran for HPC
| CPUs is still the language of choice.
| ivanpribec wrote:
| OpenMP support in Fortran will improve as flang matures. In
| OpenMP 5.0 "#pragma omp requires unified_shared_memory" was
| introduced. At LLNL, they are are currently building El
| Capitan (https://www.datacenterknowledge.com/supercomputers/l
| awrence-...), a supercomputer using AMD MI300A accelerators
| which support this concept. LLNL is also one of the OpenMP
| ARB members (https://www.openmp.org/about/members/).
| wiz21c wrote:
| And some phd's don't write unit tests... So you're completely
| blind in case you want to refactor/rewrite code.
| pjmlp wrote:
| Historically only NVidia cared to support Fortran, Khronos
| folks never understood why it should matter.
|
| Yet another reason why CUDA is winning.
| ivanpribec wrote:
| For fun, I wrote a CHIP8 interpreter in Fortran recently [1].
|
| Fortran is still heavily used in computational chemistry,
| computational fluid dynamics, marine engineering, nuclear
| engineering, reservoir engineering, and numerous other
| engineering fields. Volcanologists use it to predict ash
| dispersal [2]. Biomedical companies use it for cardiac
| electrophysiology. Econometrists use it to do tax research [4].
| Plasma physicists use it to design magnetic confinement fusion
| devices [5]. Astrophysicists use it for relativistic
| magnetohydrodynamics [6]. NASA uses it for all kinds of fluid
| dynamics-related purposes [7] (read jet engines and rockets), and
| so do they at CERFACS [8]. For all I know, some integrated
| circuit manufacturers probably use it use it [9]. It's also used
| in ham radio and probably some military agencies [10]. It's used
| in vehicle crash testing [11]. It's used in combustion simulation
| software [12], fire dynamics [13], hydrometallurgy (ore leaching)
| [14]. US Geological Survey uses it for ground-water flow
| modelling [15]. We could go on and on.
|
| [1] https://news.ycombinator.com/item?id=38920486 [2]
| https://doi.org/10.1016/j.cageo.2008.08.008 [3]
| https://www.elem.bio/index.html [4] https://taxsim.nber.org/ [5]
| https://doi.org/10.1016/j.cpc.2021.107986 [6]
| https://doi.org/10.3390/fluids9010016 [7]
| https://fun3d.larc.nasa.gov/ [8] https://www.cerfacs.fr/avbp7x/
| [9] https://en.wikipedia.org/wiki/SPICE [10]
| https://en.wikipedia.org/wiki/Numerical_Electromagnetics_Cod...
| [11] https://www.openradioss.org/ [12]
| https://en.wikipedia.org/wiki/CHEMKIN [13]
| https://en.wikipedia.org/wiki/Fire_Dynamics_Simulator [14]
| https://youtu.be/-dvG270QttE?si=AO-ky0fGwkIEmXDx [15]
| https://www.usgs.gov/mission-areas/water-resources/science/m...
| wiz21c wrote:
| > For fun, I wrote a CHIP8 interpreter in Fortran recently
|
| What was the fun part ? CHIP8 or Fortran ? :-)
| ivanpribec wrote:
| Both. :)
| dudeinjapan wrote:
| Wait... you guys don't program using punch cards? How are you
| supposed to do it then?
| Vaslo wrote:
| This comment is dead on. People here are somehow trying to sell
| a bunch of dead languages that only a small niche of people
| care about. Anything that can be done with these languages can
| be done with Python, Rust, etc just as easily if not easier.
| There's a reason why they teach Python and not Fortran.
| fortran77 wrote:
| While I love and and still make a big chunk of money from Fortran
| consulting (mostly translating old Fortran to Python or Matlab)
| it's not dead...but there's little reason to start a new project
| in today.
|
| I hit a wall recently getting SciPy to work on a Windows Arm
| machine -- because of lack of a Fortran compiler needed to build
| SciPy.
| osigurdson wrote:
| I didn't read the article, but I'll bet $5 that the conclusion is
| it is not dead.
| Rayhem wrote:
| Perfect example of Betteridge's law of headlines[1].
|
| [1]:
| https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
| Eddy_Viscosity2 wrote:
| See [1]
|
| [1]
| https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
| coliveira wrote:
| Fortran is more alive today than it was 10 years ago. If you
| didn't notice, a lot of numpy libraries is Fortran code, and they
| are improving this all the time. It is more used for scientific
| and machine learning programming nowadays than it ever was.
| ivanpribec wrote:
| The NumPy part is a misconception. Fortran is used in SciPy
| however.
| kergonath wrote:
| Isn't a chunk of Numpy's C code just f2c'd Fortran code,
| though?
| osigurdson wrote:
| The same is being asked about Python:
|
| https://news.ycombinator.com/item?id=38969390
| mrhashem wrote:
| YES. (if not, please kill it)
| pklausler wrote:
| Fortran is hardly dead, but neither is it is well.
|
| On the plus side, Fortran has more actively developed
| implementations than any other language. It is critical to some
| of the most important applications that exist. One can write code
| in the portable subset of Fortran and extract very high
| performance from very expensive HPC systems over many generations
| of processor and systems architecture.
|
| On the down side, advancement of the language has become moribund
| -- the last major standard was in 2008 and the two revisions
| since then have been minor. The standards committee creates new
| features from whole cloth without prototyping them, and without
| fixing the bugs in the spec when bugs are discovered eventually
| by implementors. There has been no standard public test suite
| since F'77, so implementations vary. There are highly portable
| features that are not standard and there are standard features
| now that are not portable.
|
| I'm working hard to try to improve this situation on the compiler
| side.
| buescher wrote:
| Fortran would have been a great programming language for embedded
| if the real-time extensions of the seventies had caught on.
|
| https://en.wikipedia.org/wiki/Industrial_Real-Time_Fortran
| aworks wrote:
| Interesting that I had never heard of this.
|
| I graduated in computer science from Purdue in 1981, my first
| job was working on a FORTRAN compiler and other development
| tools for commercial avionics embedded systems and then as an
| early adopter of Ada for same. But I don't know how much that
| domain overlaps with process control.
| redandblack wrote:
| For HPC, are there missing language features that Fortan coders
| need?
|
| Helpful to understand any HPC requirements
| PeterStuer wrote:
| In case like me you wondered about 'VASP', it is a reference to
| the Vienna Ab initio Simulation Package, a computer program for
| atomic scale materials modelling, e.g. electronic structure
| calculations and quantum-mechanical molecular dynamics, from
| first principles.
|
| https://www.vasp.at
| codexb wrote:
| This looks more like a case study of program language use for a
| specific set of scientists.
|
| Can someone explain why Fortran remains popular within the
| scientific community and not elsewhere?
| speedgoose wrote:
| Legacy scientific code is my guess. Fortran isn't that
| efficient[0] and many programming languages are preferred[1].
|
| 0: https://states.github.io/files/j2.pdf 1:
| https://survey.stackoverflow.co/2023/#section-admired-and-de...
| kergonath wrote:
| Because it's simple to grasp, easy to write, well-suited to the
| fields in which it is used (things like first-class
| multidimensional arrays, native complex numbers, good auto-
| vectorisers, things like OpenMP...), and quite efficient.
|
| It is quite interoperable (it's easy to use anything that is
| callable from C).
|
| It's easy to archive some code and be sure that it'll run in
| the foreseeable future.
|
| Overall, it is a nice language to work with if you're doing
| scientific computing. The rest of the world does not care much
| about its strengths.
| flobosg wrote:
| List of projects using Fortran:
| https://github.com/Beliavsky/Fortran-code-on-GitHub
| ReleaseCandidat wrote:
| What certainly died during the last years has been some of the
| last Fortran compiler companies:
|
| Absoft: https://fortran-lang.discourse.group/t/absoft-ceases-
| operati...
|
| Lahey: https://fortran-lang.discourse.group/t/lahey-computer-
| system...
|
| Looking at the licenses that I have had, which are SGI (+ 2009),
| Pathscale (+ 2011), Absoft (+ 2022) and Intel - Intel is to shut
| down in 2042.
| google234123 wrote:
| It's unfortunate c++ hasn't added the few features needed to
| completely replace Fortran.
| fastneutron wrote:
| std::mdspan can't come soon enough...
| pklausler wrote:
| What are those few features?
| Koshkin wrote:
| IMHO Fortran 66 was the best Fortran ever. Simple, efficient,
| true to its nature. Fortunately, some of the modern compilers
| (like e.g. Intel's) still support it.
| seanhunter wrote:
| Fortran will never die because a sufficiently determined real
| programmer[1] can write fortran code in any language. I have had
| the misfortune to encounter plenty of fortran code written in
| perl, C, C++, Java, SQL and even Python.
|
| [1]
| https://sac.edu/AcademicProgs/Business/ComputerScience/Pages...
| Koshkin wrote:
| In all seriousness, some of those could be actual translations
| from Fortran!
___________________________________________________________________
(page generated 2024-01-12 23:01 UTC)