1) What makes a language like Fortran so intimidating?
I know it's the butt of many jokes (together with Cobol and Assembly - especially in the context "really hard to learn/use languages) but just scrolling through the github repo (frontpage), the code doesn't seem that intimidating (or any less confusing than Go would seem for someone unfamiliar with its nuances).
2) What makes Fortran so much 'faster' at computation than C?
C is the go-to for any low-level performance, but in terms of computation, Fortran seems to do better (or so we're told). Is/Was Fortran a better-designed language, that allowed it to perform better than C at computation?
Modern fortran dialect is actually not so bad. It's actually pretty awesome and let you develop program that take advantage of distributed computing and gpu processing easily. Also, I don't think any mainstream languages these days have vector operations as good as what fortran currently have. But the old one is pretty horrible though, just like most other languages from 30 years ago when compared to modern languages. The things that annoy me the most when working with legacy fortran code a while ago (does not apply to modern fortran dialects):
- very terse and cryptic variable naming. Understandable since fortran 77 only allows variable to contains up to 6 characters. But it makes working with large codebase very painful.
- You had to use upper case only. It may not sounds a big deal, but you'll get tired of it eventually when working with lots of fortran code.
- Implicit typing: If your variable starts with i-n character, it will be treated as integer. Otherwise it's a float. You better not forgetting this one or terrible bugs will appears on your code.
- Source code fixed format: your source code must conform to this format or the compiler won't recognize it:
- only the first 72 chars get parsed;
- first 5 characters/columns of the line must be blank or contain numeric label
- if your code is not going to fit in one line, you can extend to the next line by marking it with a non-numeric character in the 6th columns. otherwise it should be blank.
I think there are more annoyances but those are the ones that I still remember to this day.
> You had to use upper case only. It may not sounds a big deal, but you'll get tired of it eventually when working with lots of fortran code.
Fun fact: Nowadays people are doing the same with SQL - even though there is absolutely no reason to do so.
select * from mytable
is as good as:
SELECT * FROM MYTABLE
Nowadays, upper case SQL seems to be a sign that the code is either 1) auto-generated by an ORM, or 2) written by a novice, or 3) written by a project with very strange coding styles (the last two seems to be some kind of cargo culting).
I also like to stylistically indent my SQL to make it easier to follow. This works well for most typically use cases, but it can fail horribly when you start to certain kinds of JOINs and such - the indenting will make things more difficult to read.
Of course, once you start doing really wild things with SQL, no amount of casing or indentation will save you.
Indeed, this is a common workaround when your editor has no proper syntax highlighting. Still, in today's world nobody would write in that style in other programming languages.
You see the same issue with other relicts, for example, Pascal back in the 90s. Old text books wrote Pascal in uppercase style:
PROGRAM HelloWorld(output);
BEGIN
...
END.
But in reality, everybody using e.g. the Turbo Pascal IDE wrote lowercase instead, because it easier to type and because of proper syntax highlighting:
program HelloWorld(output);
begin
...
end.
Maybe this is not so much about the maturity of the developers (as I assumed in the previous comment), but about the maturity of the tooling.
There's also a good argument for not relying on "proper" syntax highlighting which is not always available -- especially not for such a divergent language family as SQL.
Every RDBMS has its own set of keywords and reserved words, so it's pretty much impossible to maintain a "proper" syntax highlighting mode.
It's exactly the same story with the original BASIC, VB6 and modern Visual Basic. There is a lot of hostility (including on HN) to VB, but usually meant against the early BASIC or VB6. Modern VB.net is very similar to C#, just case insensitive and with words instead of special characters. Microsoft broke backward compatibility when moving to .net, precisely to avoid the sort of legacy annoyances you are describing with Fortran.
Personally I wish VB6 had the class declaration capability of what the Actuate Reporting suite had for it's "VB-like" language (from what I remember from back then). It was like having everything you have in Java/C++ - but for VB.
Probably the closest you can get today would be one of the more modern BASICs out there (QB64 or GAMBAS - maybe FreeBASIC?).
"modern" stuff such as free format and identifiers up to 31 chars have been available ever since F90[0] (all the while being compatible with F77 code) released in 1991. AFAICT people stuck with writing (and complaining about) F77-like code because habits.
I can recall at my first job (muble years ago) being considered a bit flash because I used Mixed case in my Hollerith statements for prompts ;-)
The Fixed code format went away a long time ago (it was to fit on a 80 col punched card) any one using F77 and later in the last 30+ years will have used free format
And the MAGIC is REAL unless declared INTEGER - professional Fortan programmers declare everything! (well apart form loop indexes I j etc)
> fortran 77 only allows variable to contains up to 6 characters
I never knew that! I've always wondered why the BLAS / LAPACK routines had such frustratingly concise names (dgesv, dgbsv, dposv, ... just grabbing the top few from [1]).
This is quite common in legacy Fortran codes. The reason is that these reciprocals are probably later used in many multiplications (e.g. for scaling a vector) which is faster than doing many divisions. Well, nowadays the compiler would optimize that for you, but back then either compilers wouldn't do that, or people woudn't want to rely on it.
> the old one is pretty horrible though, just like most other languages from 30 years ago when compared to modern languages
Maybe 50? To put modern into perspective, 30 years ago is 1986 and Python is from 1989.
A bunch of other mainstream languages are only slightly younger: Ruby, Java, JavaScript, PHP. I think C++ is not much older than that.
I was using the PGI compiler. I'm not aware of any open source implementation that can automatically take advantage of cuda gpu back when I was still working with fortran-related projects. Not sure about now.
Allegedly GCC support GPU (ptx in particular, for NVIDIA) offloading. I don't know whether the performance is competitive and whether it can be used to speed-up fortran co-arrays (which I, as a non-fortran programmer, would expect to be the way that functionality would be made available to fortran). OpenMP should work as well.
All of the formatting restrictions are because the language was developed in the punch-card and teletype era. You had 80 columns per card/line and only upper case.
> 2) What makes Fortran so much 'faster' at computation than C?
I think it's more like this: As long as the numerics is vectors, matrices and multidimensional arrays (no complex graph or tree data structures implemented with pointers, no string manipulation, no bit-level fiddling), a scientist or engineer who spent less than a week learning Fortran, can write code, almost in a first pass, with nice array notation, that is close to as performant as a relatively seasoned C-expert could write.
Is it true that pointers are completely non-existent in Fortran? This may be related to your point about data structures.
I've heard there is no null dereferencing and pointer nonsense - all without the need for a garbage collector - which ultimately leads to Fortran's great reputation for speed.
Fortran has pointers since Fortran 90. But you don't always need to resort to pointers like in C, as Fortran also has allocatable arrays. You can still follow a null pointer, though, if you don't test for it first.
Wow. This should be the canonical answer for all Why Fortran performance questions. Never thought about this effectiveness/experience advantage in Fortran's favour.
1) Lack of heap-allocated convenient strings, dynamic lists and a dict/hashmap structure. They would not need to be fast, but the total lack of such types built in means that you cannot even deserialse a JSON or YAML config file without it getting very verbose.
2) Main reason it is faster than C is all arrays are nonaliasable by default (e.g. if you have two arrays as arguments to a function you know they do not occupy the same memory). This enables some important optimizations. In C99 there is the __restrict__ intrinsic to declare the same thing in which case C99 is just as fast. However you still need to write a lot more code in C99 since you need to write loops, while in Fortran "a+b" can add together two arrays (with full compiler support for optimized array expressions).
As of Fortran 2003, there's allocatable scalars, including strings (type "character" in Fortran). There's also "allocate on assignment", which is also nice (that is, you don't need to manually allocate an empty character first before writing stuff to it).
> dynamic lists and a dict/hashmap structure.
As of Fortran 90, with pointers and derived types, you can do it yourself, just like in C. But yeah, sometimes it's frustrating that the standard library is so limited (again, not that much worse than C, but compared to many modern languages, certainly).
Heap-allocated was a bad choice of words. I mean strings that allow you to do "a+b" or similar simple concatenation built in almost any other language has (not C though, although there null-termination and stdlib helps a lot more than Fortran character arrays does). Though I guess one could roll one own here too, same as with lists and dicts and so on.
> I mean strings that allow you to do "a+b" or similar simple concatenation
Meet "//", the character concatenation operator. Part of Fortran at least since the FORTRAN 77 standard.
With the F2003 additions I mentioned, one can do stuff like
program stringtest
implicit none
character(:), allocatable :: s
s = "hello"
s = s // " world"
print *, s
end program stringtest
where the first executable statement (s = "hello") allocates space for "hello" on the heap, and the second statement reallocates that heap space to now have room for the previous contents + " world".
And since Fortran allocatables are a bit like C++ RAII, they are automatically deallocated when they go out of scope.
Is this as convenient as doing string handling in, say, python? IMHO, no, but better than plain C + stdlib.
> 1) What makes a language like Fortran so intimidating?
FORTRAN 77 (and FORTRAN 66) was a pretty primitive language. Source code still used line numbers, no malloc, no recursion (there is a workaround, though), very cumbersome text manipulation.
When Pascal and C got popular in the 70s and 80s, FORTRAN 77 felt ancient in comparison.
I guess the jokes originate in the 80s, and from then on they have lived in the folklore, told to new generations. Fortran 90 came only in 1992 (and then later 95/03/08) and while it is much modernized, I don't think the people telling the jokes have yet looked at it.
1. I think it's that most people remember the bad old Fortran, with horrors like EQUIVALENCE (telling the compiler to use the same memory for various arrays that you just _knew_ would never be used at the same time, honest! OTOH, back in the bad old days of not much memory, you didn't have much choice) and COMMON blocks, as well as the fixed format layout and stuff others have already mentioned. Early versions of Fortran didn't necessarily support recursion. Spaces weren't significant, and Fortran had no notion of what Algol 68 called "stropping" to mark keywords, hence the infamous
DO 100 I = 1.10
which the programmer thinks sets up a DO loop to run ten times but instead assigns 1.10 to a variable called DO100I, thanks to the period that should be a comma. Then there was the infamous H (Hollerith) format item; to get a literal string int formatted output you had to use it and had to count characters rather than using a string literal, so
100 FORMAT(10HHELLO WORLD)
has an off-by-one error.
2. Pointers. Fortran explicitly states it will make assumptions that let it ignore impediments to optimization that pointers can cause. C has the "strict aliasing rule" and the "restrict" keyword that help, but not enough.
1) Old Fortran code was intimidating. New Fortran isn't.
2) C can be faster than Fortran (not by a lot mind you). But when it comes to math-y type things, Fortran code can be made very, very fast, and can be parallelized with little to no effort.
One interesting feature of Fortran that might help with the second question is how restricted the use of pointers is. A Fortran compiler has very strong guarantees that any two arrays do not overlap, hence some optimizations can be easier to prove safe.
> One interesting feature of Fortran that might help with the second question is how restricted the use of pointers is.
There is no restrictions in the use of pointers in Fortran, the compiler knows pointers can overlap. The restriction is when arrays are passed as arrays (passed by reference internally), not pointers.
1) What makes a language like Fortran so intimidating?
I wonder the same thing: there is irrational contempt towards Fortran here on Hacker News. I think it says more about the attitude than it does about Fortran.
2) What makes Fortran so much 'faster' at computation than C?
two things: the compilers are excellent, and produce really fast machine code, and intel has invested tremendous amount of engineering, with focus on exploiting the newest features of their processors (such as AVX2). The new ifort compiler comes out every six months. Others like PGI have produced a Fortran compiler which can generate NVidia GPU code. Fortran compiler technology and Fortran the language standard / features are on the cutting edge of the domain Fortran is designed to handle, computing. And since Fortran can actually handle strings and has regex support, I've often wondered what it would be like for web applications...
1) What makes a language like Fortran so intimidating?
I'm not sure, I would like to know the answer to this. At least for modern Fortran.
2) What makes Fortran so much 'faster' at computation than C?
I don't know if the computation of Fortran is always faster than C (I thought they were comparable), but at least in development time, it was a huge improvement for me. I was forced to use Fortran 2003 at university for numerical simulations etc and expected it to be terrifying but found it very pleasant. Instead it was when programming C later on that I got slightly frustrated.
- It's easy to learn. No need to learn about pointers etc.
- It's very math friendly. The fact that you can easily extract and use sub matrices/array is probably my favorite feature. In C I needed to write loops, pass around array length or matrix sizes, etc. Multi dimensional arrays got annoying to work with and ended up writing matrices as column-major vectors.
- It has some nice built in functions such as matrix multiplications (no loops for this). It also has great math libraries like BLAS/LAPACK
- Offers OOP
I haven't made use yet of the advantage I hear most often i.e. for HPC.
"What makes a language like Fortran so intimidating?"
Some versions of Fortran are optimised at compiler level for hardware, hence question #2 is moot. [0] Note the level of optimisation on linux [1] required to speed the code up.
"What makes Fortran so much 'faster' at computation than C"
What I mean is the reason C isn't faster is because of the hardware support at processor level and extra library support for example in IFort. Is writing/re-writing a problem in another language when there is an existing well documented body of code is premature optimisation?
re 1. It is (too) simple and lacks higher level features
re 2. It is simple so easier to optimise.
Regarding 1 again, I can't find it right now but the fact that Fortran could not even read it's own source code was one of the motivations for Ratfor; a C-like preprocessor for Fortran. By the esteemed Brian Kernighan.
This actually looks really neat. Linear Algebra as a service, anyone?
Speaking more broadly - I hope we see more web stuff in the statically typed, machine code compiled camp. It is my understanding that web apps do more and more client side these days and only really need a "thin" server. Ruby or Python seems over kill.
It's funny to me; when I got my first taste of "web apps" it was writing c apps to process cgi requests a bazillion years ago. It is neat to see people advocating for native compiled code in this area. I do lots of node these days and full stack so I appreciate the client side leaning for routing and rendering. If you don't need SSR then I'm sure you could create a very performant server in rust or c. Sounds fun!
I sometimes toy with the idea of using fastCGI C++14 scripts for a RESTful JSON service, to be able to handle a lot of requests on not much hardware. Though maybe spending a lot of time shaving 10's of dollars on your monthly VPS bill is not a fantastic use of your time :D
Yes, CHICKEN Scheme. Although I imagine Gambit would work equally well. I have ~3/4 of a single-file CGI framework on my hard drive. It's feature complete: the other 1/4 is just some optimizations and sugar over GET and POST handling, as they are by far the most common methods used.
In the future, I might add some wrappers over access of CGI environment vars, but you can already look those up by hand, using the standard environment access routines.
It is faster. Seriously as a teenager I FORTRAN would run circles around everything but Assembly. It is still in use even in R and many statistic languages/programs (Why reinvent the wheel)
This is pretty cool. And it's even semi-practical, unlike some web frameworks.
But I do have a question: Can this new FORTRAN framework match the performance of the best web framework out there, INTERCAL on Interstates? http://www.intercaloninterstates.org/
His homepage: http://mapmeld.com/
Fascinating person. Has worked with various languages and does educational work throughout the world with OLPC laptops.
I'm normally an advocate for Fortean for numerical computing, but web servers seem unholy. However, I do appreciate the code reference on querying SQLite from Fortan.
I really like seeing things like this come out. I don't know any Fortran, probably never will learn it, and will probably never use this framework. But, I can imagine this was an immensely enjoyable project for the author. Projects like this, in my opinion, are the definition of a labor of love.
Fun fact : I informed the author (which I'd a good fortune to get to know him for some time) this morning (east time zone) that his project is (again) on the front page on HN. He was in the air on his way to Taiwan. We both wished it doesn't break but it seems like it did and he restarted it again.
I know it's the butt of many jokes (together with Cobol and Assembly - especially in the context "really hard to learn/use languages) but just scrolling through the github repo (frontpage), the code doesn't seem that intimidating (or any less confusing than Go would seem for someone unfamiliar with its nuances).
2) What makes Fortran so much 'faster' at computation than C?
C is the go-to for any low-level performance, but in terms of computation, Fortran seems to do better (or so we're told). Is/Was Fortran a better-designed language, that allowed it to perform better than C at computation?