What's the FASTEST Computer Language? C++ vs Fortran vs Cobol: E04 

Reading COBOL code is just like reading an angry person's text message

I had to take a COBOL course in college... we had to turn our programs in on a floppy. In 2009.

Fortran is still a popular language and receives updates. I just downloaded the AOCC Flang compiler, optimized for Zen 3 processors and the AMD Epyc platform specifically.

Another old joke: Q: How are COBOL and pregnancy similar? A: Miss one period and you're in trouble.

Fortran is the bedrock of computational physics. It was my first programming language. Ever. In 2016!

I've known FORTRAN since 2011 (Atmospheric Sciences), it is still a main language used in computer weather modeling.

As someone that has coded in FORTRAN 77 and Fortran 95 (yes, they changed the case of the language name), I can say they are very different beasts. The former is close to the original versions, with strict column formatting to fit on punch cards. The latter is heavily influenced by C, and could be arguably considered a completely new language.

Fortran is a language of now, the best to do linear algebra in by far. Mostly because of the big daddy library of them all, glorious LAPACK. When I did linear algebra in C++ I still called back into Fortran. FYI, I am 30.

So "implicit none" kills God. Got it.

That was great. I've not heard the God is real joke for at least 20 years! Really looking forwards to the top 5 episode!

one comment in COBOL's defense - this is not what it was designed for. The fact that it can crunch these numbers at a not-too-shabby rate is pretty cool, but it was designed as a "Business Oriented Language" (it's right there in the name). Having said that, as a (former) COBOLer, if/when you do find that your code is not performing, you find the "hot-spot(s)" and you rejig & optimise them. Usually the Pareto (80/20) principle applies, where 80% (ish) of the work is being done in 20% (ish) of the code - so you find that 20% and work it over and get a bump in performance - perhaps even coding it in another language (assembler being popular ;) - and then call that from within the COBOL code.

No offense to Mr. Van Bakel, but this was his first COBOL program (as he stated in the notes for the code). I've been slinging code for 40 years with about 30 working in COBOL. Most of that has been in processing huge volumes of transactions, and one of my focuses has been efficiency. I'd have written that very differently. There are optimization tricks I'd have used, such as avoiding COMP-3 and coding the core loop in line (since PERFORM does a jump).

This series is one of my favorites on RU-vid. Really like the short dives into each language.

Looking forward to more of this series. The mini dives into each language are awesome.

Cobol is actually quite an important skill because lots of businesses are looking for people to maintain their legacy code

Some say The Stack materialized out of the result of the first punch card ever executed Love this series!

I've found that different language libraries can have wildly different efficiencies in their "get_current_time" functions, and it can be a heavyweight call in any case (relative to any purely CPU-based calculation). As such, by putting the time function in every pass of your loop as you do, you may be measuring the speed/slowness of the "time" function more than your "calculate" pass. I'd suggest instead doing an initial "get time", then a fixed (large) number of your calculation passes, then a final "get time" to determine the total elapsed time and dividing number_of_passes by elapsed_time.

Thank you and in my freshman days at UMass in 1967 I programmed in FORTRAN, yes using punchcards and turned them over to the night shift Data General card shredder. We got the mangled cards and a green bar printout saying, run failed. Lol. It took weeks to get a simple program completed. Used slide rule too so yes I am a dinosaur. Enjoy the videos and look forward to the next. Cheers

I've written hundreds of thousands of lines of COBOL, it is not exceptional nor is it difficult. Like most early languages you can write extremely bad code but you can also write very comprehensible and well structured code. One rule is to use the "Section" statement as an equivalent to a "Sub" so you do NOT use "Perform x Through y" but instead Perform a whole "Section". That works well unless the provider of your COBOL has gone terminally stupid and decided to do something incredibly stupid with "Section".

I'd like to notice that the Github repository also contains an object-oriented Fortran proram that shows a more modern Fortran code (the performance is similar or slightly faster than the shown version).

Come on Dave it's been 6 months since a new episode! You can't keep us in suspense for this long!

Did the next episode of this ever come out? I don't see it on your channel

Fun video, but you have to choose your drag race if you want your language to shine. I would choose or at least value the languages for the following sweet spots: C/C++ for systems programming: operating systems, compilers, dynamic memory usage scenarios (heaps, pointers). Fortran for highly performant mathematical programming using arrays (matrices) Cobol for efficient business data processing. Think fixed format records, requiring business logic and transactions to manage them. TLDR; Speaking as someone who has professionally programmed in Fortran, Cobol and C#. Two things have happened over the last 30-40 years which has undermined Cobol and Fortran in the mainstream: object orientation and non fixed format data processing (XML etc). Back in the 1960s and 70s mainframe business data was inputted on cards (one per line) in fixed format, read by card readers. Files were organised as a sequence of records not bytes. Cobol (and Fortran) were designed to process data in that format. Cobol supports fixed format record structures (which would all be pulled in from source code include files in a library) that may have been generated and managed through data dictionary products and processes. Such that a single read IO on a file on disk would read in sometimes hundreds of fields of data for many records straight into the memory buffer of the file description format in the program. Which would then be immediately available for processing by the Cobol business logic. No tedious and very compute expensive XML parsing and deserialisation (yada yada) required like in OO languages. Cobol was far more efficient in compute, and needed to be because of the cpus of that time. Also, although Cobol is verbose (literally), I would contend that there are more function points per 1000 lines of code than your typical C#. This doesn't mean I like Cobol, I don't. It's not fun if you come from a Comp Sci background. I would never want to write a Cobol sort algorithm, or parse free format data or XML in Cobol. Just wasn't designed for it. Surely, you ask, businesses that still depend on Cobol (and it's the largest ones that do) need efficient sorting, so how does that work? External sorting routines of flat file data using sort keys etc were executed before the Cobol program started. Tools were SYNCSORT, DFSORT on the mainframe. These tools were highly optimised for IO and compute using virtual page management fixing and other tricks. Fortran on the other hand, by design, is highly performant for array processing. All the most optimised numerical libraries are (or at least were) written in Fortran. Converting them to C/C++ is likely to be less efficient, at least in the default configuration. One reason is the native support of complex numbers. The other big reason is that subroutine parameters are assumed to not overlap each other in memory. In C/C++ any two function parameters are assumed that they might overlap in memory (unless you tell the compiler otherwise). That's the assembler view of the world but without bringing the knowledge of the programmer to the machine code. Why is that unperformant? When the C/C++ compiler generates the machine code for manipulations of multiple passed in arrays, it sometimes has to re-fetch from memory the first array parameter because an update was done to the other array parameter and the compiler doesn't know the first one hasn't been altered. So it can't retain it in a register. That *kills* array performance when you have multiple arrays being processed in an inner loop. The fix in C/C++, I think, is to tell the compiler that the parameters are not aliases of the same address (if it supports it, and the programmer knows about this stuff). C/C++ is more like assembler, you can do anything but you might blow off your leg in the process. You have to be much more sophisticated to get the same performance and consequently stability when trying to play in the other languages areas of strength. Old style Fortran (Fortran 66), was a bit dangerous because it was white space insensitive, so if you missed out critical tokens the statement would mean something quite different but still compile. For example, the beginning statement of a FOR loop (called a DO loop): DO 1000 I=1,200 to repeat a section of code ending at line 1000 iterating variable I to 200 could be accidentally written as DO 1000 I=1.200 which with the blanks stripped out was an assignment statement of the value 1.2 to an implicitly typed REAL variable DO1000I rather than a loop declaration! Apocryphally, this "." instead of "," caused a rocket to crash. Fortran 66 didn't have string variables, you had to store string constants in INT arrays, if you had to use them, and you outputted them as Hollerith literals in FORMAT statements. String concatenation? Forget it. The solutions were not pretty and were not very reliable. So drag racing such different languages is kind of pointless. Eratosthenes sieve is not going to be the best fit. Fun though it is.

when is the 'top 5 fastest languages' video coming out?

This surely took a while. But I'm glad it's finally here.

Glad to see the continuation of the series. I had never seen any Cobol code before, and now I hope to never see any more of it.

Am I the only who thinks COBOL's syntax looks neat and interesting?

Yay! Was looking forward to the next installment in this series.

Finale is where?

I think the engine revving sound is too loud compared to the rest of the video.

I started programming when I first got a basic spectrum aged about 10. After school, I went to university to study a B.Eng in Electronics and Comp sci. (was about 1991) I was lucky enough to have a holiday job where I still work, and learned Assembler (Z8, 8052 etc) and straight C. They taught me C++ at uni and I remember the physics guy showing me Fortran. Anyone remember Zortech C? Graphics on an ms-dos screen.

My first year at university (1987) doing Chemical Engineering for 1 term (I think) we had computing lectures on Pascal, because the Computing Science Dept. said this was the "best" language. Then in the last 2 weeks of the year we had a crash course in FORTRAN because that was what industry actually used. I think that variables I, J, K, L, M, N. are implicitly defined as integers, because these variables are used for loop counters.

Recently subscribed, great series and channel Dave, found your channel via a friend linking me to the inverse square root discussion for quake 3.

Why should C++ be discussed in high school health class? - Because every other line has an STD

When I was younger, I used to hear a lot of jokes and warnings regarding Fortran. How old it is, how ugly the code is, how outdated. However, in many academic fields, especially those involving linear algebra, it's still a very common language. It received multiple updates over the years, and it is certainly possible to write nice code in it. I think it's mostly just bad rep from ancient (Fortran 77) code written by amateurs (scientists and the like). True, there is a lot of very ugly, old code written in Fortran. Some people still didn't receive the memo that you can use more than 6 characters for your variable names. But old C code is sometimes just as ugly. Doesn't have much to do with the language, rather than just the different priorities (readable, easily extendable code vs one-time-use, specific, performant code).

The Fortran language is specifically designed to allow the compiler to do a better job of optimization. So a program that conforms to the standard but that is not specifically manually optimized is more likely to be better optimized than in other compiled languages. However, you can very often manually optimize your code in most any language and achieve close to maximum possible performance with very little difference between languages that are similarly manually optimized. Fortran has increased its support for object orientation dramatically over the years however and is increasingly challenging for compilers.

My first college programming course was Fortran on punch cards. Good times.

So are you ever going to release the video that shows the fastest languages?

I was once told at uni that with punched cards the information is not actually stored on the cards at all. The cards are just used to make sure the holes stay in the right place. !!

Some friendly nitpicking on Fortran :) At 10:15 the video says "there's no equivalent of a "main" function - it appears that program flow starts at the top of the file and flows on down" In fact there is an equivalent to a "main" method, and that is the "program primes_fortran" statement at line 1 of code. That is the entry point to the code. 10:40 "the contains keyword indicates where the subroutine and functions begin". Not wrong, but not the whole story: you could have put all functions and subroutines outside of the "program primes_fortran" (eg they could be in other files), in which case you don't need to use "contains". Using "contains" makes the corresponding functions internal, and allows more checks to be done at compile-time (eg that the type of passed arguments is correct) and gives some extra functionalities (eg you can recover an array's size and shape with size()/shape() build-in methods; otherwise you explicitely have to pass the dimensions as further parameters). 15:21 "Fortran doesn't use a conventional less than and greater than symbols". Starting from Fortran 90 it is totally possible to use =, ==, /= for comparisons. BTW, /= is used for "different from" (NOT 'divide by'!) because "!" is used to indicate comments; a small quirk is that for comparing boolean values you shouldn't use == and /= but .eqv. and .neqv. (equivalent/not equivalent). ASAIK boolean operators were kept separate from standard ones because they are assigned higher priority.

FORTRAN is not that retro though. The latest FORTRAN standard is 2018, and it is still used, perhaps as much as C++, in HPC and scientific computing.

Sad that IBM's PL/1 language was once again ignored - it was the 3rd major language of the System 360/370 era. I coded a lot of it from mid-70's to mid-80's. It is essentially what you'd get if COBOL and Fortran had a child... a language good for both scientific programming and business programming. In fact IBM's DB2 database is largely written in it as I understand it.

On the FORTRAN side, there is one feature that is still unbeaten that is how it stores matrices. Fortran stores matrices as COLUMNS, not as rows. That may seem unintuitive, but think about it: you populate matrices by rows, say you read several data points at the same time from sensors, but then, all calculation is done over columns. Also, you are allowed to reference and pass subsets or dimensions as parameters. So if you have a 3x3x3 matrix, you may call determinant(M[1]) where M[1] is a 3x3 matrix itself. Very handy !

Can't wait for the next episode!

I've had to read what I believe was Fortran 77 during my PhD, and reimplement a part of the code into something more modern. I've no formal CS education, so that was a trip. The one presented here was miles more readable. Not having to interpret characters placed at specific columns helped a lot.

Did Dave ever reveal what language did the 4000 passes or what the top 3 were?

Wheres the reveal????????????????

Way to keep up with the promise of the BIG reveal. :)

"Some say he actually returned from a function before evn calling it, others say he was the actually developer steve balmer was yelling about". You destroyed me with that line XD

Thanks for this episode 😊I am truly surprised that Cobol is that close to Fortran!

My Dad used to write fortran for the Allianz. Thanks for giving me a look at what that stuff actually looks like! Great episode as always!

Cool series! I love hearing the history.

In the COBOL course which I assisted (1994) during university, the use of the COMPUTE command was strongly discouraged. Our professor would tell us that the use of COMPUTE command to solve simple math was like "dropping an atomic bomb to kill an ant". Therefore, I never used it.

This isn't really testing languages, but specific compilers. And you could disassemble whatever is the winner and use that as the entry for assembly language. You can always match any other language by assembly in that way (or in c++ using inline assembly).

I dont know, but there is a certain cleaning'ness in COBOL that i like. code that is declarative like that certainly looks easier to maintain and check the validity of. I mean, if it dint work it wouldn't still been around.

Is BPCL in this race? I've forgotten everything I learnt 30 odd years ago (which was fairly minimal) apart from the name.

I see what you did there with The Stack - Top Gear reference.

Now I'm super curious! I can't wait!

Would love to see you come back to this series. I'm particularly curious about languages that use JVM like Scala and Clojure, how they compare to Java, and perhaps how they compare to themselves when programmed using OOP vs FP, as well as on JVM vs compiled to native executables, which I know you can do at least with Scala.

I'd be curious to see how this would play out on a mobren Mainframe like a Z15 and the latest COBOL compiler from IBM (V 6.3) with a ARCH setting of 13 vs fortran and C++. Not that would be a software race on the the best hardware.

while we get the final racing results i wonder what parts the time actually gets lost in. if zig is #1 is it just due to its fast default memory allocators? Id assume that the emitted assembly should be pretty similar for all the llvm backended languages. Is there some function in the fastest language that gets just very good assembly output?

Love this series!

I taught Fortran at uni in late 70s/early 80s, and it didn't look anything like the structured Fortran here. GOTO might have been considered harmful, but we still hadn't adopted versions of Fortran that thought so! And writing Cobol was like speaking Shakespearian English!!!

Hi Dave !! , I can't find the next videos after the E04, you said there are 3 faster programming languages , where can I find your next video after E04 ? thanks a lot !

Heck, I wanna know how Rust and Go places amongst the 40 y/o (matured/evolved) langauges.... Please, don't wait too long to publish ep05 Dave. And thank you so much for the series. REAL FUN TO WATCH

i had to learn fortran90 for a computational physics course, and i actually enjoyed it. covid hit after i finished that semester. it's also possible to split up the fortran90 code into separate pieces, and then make use of a makefile to link up their dependencies. at least, that was what i was taught in order to keep the code modular. it's also worth noting that it can be threaded to take advantage of multicore processors. dunno about cobol.

My favourite feature of COBOL from my 80's programming days was the ability to write variable length records by using a level 88 redefine with a PIC X OCCURS DEPENDING UPON VARIABLE and writing that redefine having defined the maximum records lentgth with the 01 definition. This was Honeywell BULL DPS mainframe era back in the 80's. The days of no GDB or indeed any real debugging tools and your friend being able to do dump analysis by hand - fun times.

I don't know why, but I enjoy these videos. Even though I already knew the answers before this series began.

I had the pleasure of meeting Admiral Grace Hopper in 1984 when she gave the annual Grace Hopper lecture at what is now the University of Greenwich (in London). In that lecture, she spread the "myth" that she invented the "bug" term when she found a moth bridging the contacts of a relay. That really is horrible COBOL though. PERFORMing paragraphs rather than sections is very poor practice, and surely, "SUBTRACT 1 FROM..." is less obtuse than "ADD -1 TO..."

When I was working on my maths degree in the 00s, I had to learn F77 because all the research going on in numerical analysis used it. I asked my prof once why we didn't use F95 and was told that it didn't do anything new they needed.

I am slightly confused. How the leader is not an assembly language? You can disassemble the code that leader provides and here it is. Or do I miss something?

which compiler are you using (ie ifort, gfortran, etc) and compiler flags?

Fortran is still used today for very specific applications, primarily when doing massively complex simulations (such as simulating the motion of an entire galaxy for example). I find that really fascinating.

I'm fascinated. While I felt like I was going to get nauseated when I looked at COBOL, I felt almost wonderfully nostalgic looking at Fortran.

Remember good times working in COBOL in college. My carefully crafted code for my course assessment project chucked out over 10,000 error messages at compile time. Just because I missed out one full stop.

Arg! I was hoping for more blinkie bits, and here ya got a cool language drag race eating up your time, and IM torn, heh... so with that set up, any chance to see a drag racing lights episode? couple of comets in various colors to represent different data outputs, and away they go! heh

Wait, wait, WAIT! There's something out there twice as fast as C++? That's gonna be an interesting episode...

Wonderful to see the FORTRAN video has arrived! Great work! I'm not going to lie I'm a bit disappointed that my optimised object-oriented version didn't make the video but I can absolutely see why from a storytelling point of view :-)

Is Fortran the reason why by default we call the for loop variable "i"?

I haven’t seen the top 5 languages yet. When did you release it?

You crack me up and you Sir, are the quintessential programmer's Programmer!

Subbed! For an old burned out programmer like me after 40 years of it (Delphi, Pascal, Java, C#, Vb, Assembler etc..) this has been a fantastic series to watch! Very interesting and seems to be rekindlling my interest in programming, maybe some on the side hobby stuff again :) I did a cobol course years ago and last two lesson and that was is, holy shit what a crap language! hah

Thanks for the video and the opportunity to compare my programming efforts to others in your open source repo. At the end of this video, you mention your upcoming episode on the fastest computer languages and that the fastest are "not C/C++". That isn't quite fair to those languages, as the only reason for that is that no aficionados of those languages have adapted the techniques used in the fastest contributes to them. As I show in my contributions to your "Drag Race", writing fast versions of this benchmark is just a matter of the right techniques applied to any language that can emit efficient "native" machine code for the host CPU. The languages currently at the top of your "Drag Race" all do this to varying degrees of success, but you'll notice some common things among them: they all either produce their output CPU machine code through LLVM (the languages V, Crystal, Haskell - a back-end option, Julia, and Rust - contribuitions written by my cohort, Mike Barbar), through a C/C++ back end as more of a "transpiler" from one form of code to another as does the language Nim, or implement their own optimizing compiler from the ground up as in the language Chapel sponsored by Cray/HPE. This last way of writing one's own custom compiler is the hardest and generally needs a corporate sponsor in order to provide enough resources to do as in Chapel, and can even then only be moderately successful as in the language Go from Google. Languages that use LLVM as the back end are most successful when they manage to tune their output LLVM intermediate code and optimization options to best suit the LLVM native code generation process, with the most successful being Rust sponsored by Mozilla followed by Haskell,, Julia, etc. One of the fastest entries here is my Nim contribution using either the C back-end as submitted but also about as fast using the optional C++ back end. So, indirectly, the C/C++ languages are represented at the top of the chart, and there exists some Nim generated C/CPP files as in intermediate code step in compiling my Nim contribution, although they are hard to read by humans as they are computer generated with "mangled" names to automatically prevent name collisions and "boilerplate" code as automatically generated by the Nim compiler. To be fast for this benchmark, all that is required is extreme optimization of a very few very tight loops that do the marking of composite number representations which is only a tiny fraction of the overall code setting up those loops. My point is this: the C/C++ languages are in fact still as fast as the best and if the Nim language can transpile to fast code using them, then my techniques could also be used directly in C/C++ code. If I were to do such a thing, I would likely use C/C++ templates/"macros" to replace my Nim true hygenic Abstract Syntax Tree (AST) macros otherwise using the same techniques, and the resulting code would likely be at least as fast as that emitted by Nim; I am surprised that no C/C++ aficionados have yet done that in your "Race". The reason that I haven't done it myself is that I regard C/C++ code as ugly and difficult compared to writing code in Nim or other languages, and no longer work directly with C/C++. So the point needs to be made: There is more than just being able to write fast code in whatever language as there are all kinds of ways to be able to get speed as I demonstrate in your "Race" in the "top Fuel" class using an assortment of languages; code needs to be effective and elegant as well, written using modern paradigms that produce safe(r) and relatively easy-to-read-and-maintain code (if one is familiar with the languages and paradigms - such as functional programming). Note: I am not a proponent of "everything is an object" as used in mostly Object Oriented Programming (OOP) languages although I use that paradigm when it makes sense or when it is forced on me by the language. Just as one retired Saskatchewan native to another - formerly East of Davidson...

What Fortran and COBOL compilers did you use for these tests?

70 languages...heck. Loving it Garage Dave.

Hahaha.. I took Cobol in College back in the Mid 80's.. It was an 'old' language back then.. Can't believe it's still around.. And keeps up with Fortran ? That does not speak well for Fortran IMHO. I can't wait to see the conclusion. Who reaches 4K ?

Hi Dave, Great Video. After working for Micro Focus for 20 years, COBOL is a language I got to know rather well. COBOL has its uses and certainly the latest implementations provide almost every feature you could want. Is that a good thing? I leave that down to the individual to decide. Certainly the source code provided was somewhat verbose and modern COBOL could be written in a more streamlined form. As a matter of interest, which compiler did you use for the test? When I was a mainframe programmer, I preferred PL/1 - are you going to look at this too? Micro Focus has/had a PL/1 compiler when I worked for them.

I'd ask how much faster compiling the COBOL code would make it, but having checked prices for COBOL compilers, I feel that may be an unreasonable request... Also, out of curiosity, which compiler was used for the C++ application? Sorry if it was mentioned and I missed it, but I am curious after recent revelations I found around certain compilers effecting speed.

That's some pretty gaudy Fortran, compared to what I used in 1964, to program the state-of-art IBM 1410. We also soon learned how to streamline the code for maximum speed, and that fixed-point calculations were much faster than floating point, so we used integer variables whenever the accuracy permitted. The secret to look-up tables, e.g. for interpolation, was to compute an integer value of the independent variable. as an array index for the stored values. Compiled COBOL subroutines tended to run a little faster for some applications, so those were occasionally called from FORTRAN, for repetitive calculations. When I first disassembled some of the early OS code on the IBM PC, I was horrified at the inefficiency and redundancy of the code. Clearly, it was written for clarity and ease of maintenance, while sacrificing efficiency. I since have learned that software gets slower, faster than hardware becomes faster.

Enjoyed the video. I'm curious : what Cobol and Fortran compilers did you use? The only Fortran compiler I've found that is readily available (and at no cost), is GNU? Maybe the same for Cobol? Thanks

Appreciate the stats and data, Wow, who would have thought how widely used Cobol is!

I started as an assembly language coder in the 70s with the pre-requisit of being able to read object code in hexi-decimal format working for Rockwell Intl. I then graduated to ForTran coding at IBM working as senior programmer and supervisor of various manufacturing engineering projects. I currently am self employed coding in PGI ForTan 99 on a Windows XP system developing and supporting manufacturing engineering applications used for post-processing CAD/CAM data to machine code data for various CNC macine tools in mostly aerospace industy. I also have personnaly met many key people in the computer and manufacturing business including John Backus the inventor of ForTran.

Considering how the bitfield is static and predetermined, I can't help but feel like it can be calculated at compile time if you just use the right attributes and modifiers in modern c++.

I used GoTran in about 1962-64. GoTran was a Fortrash subset but with very limited ability to write expressions. As best I recall, one could write A = B+C; but not A = (B+C)/D; GoTran ran on a 1620 or 1710. Then in grad school I used Fortran IV on an IBM 7040 in 1965. Fortran itself had a design error in that it ignored blank spaces when parsing programs and this led to what is probably an urban myth about crashing a rocket in South America. Later in my career I used Cobol, APL, PL/1, RPG, C and C++ plus lots of assembler on various architectures. In the early Fortran language, at least, it was illegal to pass 2 arrays etc to subroutines where the arrays etc aliased each other BUT it was not necessary for the compiler or runtime to detect such. This can result in considerable performance improvements in the running code.

I can't wait. Personally I'm rooting hard for Fortran, although I think C++ will almost always win in this type of tests, mostly because 1. in C++ you can do some low-level things which aren't easily achievable in Fortran 2. I assume the C++ implementation have received much more attention, especially by C++ optimization gurus... this is a consequence of it being a much larger community. 3. C++ compilers have probably received orders of magnitude more in effort than Fortran ones, and hence might be better at optimizing code.

Fortran is still quite widely used in science. More so than C, let alone C++. Normally, if Python (or R) is too slow, you see people resorting to writing the critical piece in Fortran. And, oh boy, do we still have old Fortran programs still around that require very, very specific input. :-D

13:29 ... You've gotta love a Top Gear reference... POWER!

I really like this series. This is last episode so far, right? I wanted to see which language won!

Wouldn't a truly optimal compiler unroll such a deterministic algorithm and precompute the values into an array that the final executable just spits out repeatedly? I mean unless you hold back some critical value to prevent pre-calculating and enter it at runtime.

This was cool. When I took "Data Processing" it included learning those two languages. Then in "Computer Information" I learned Visual Basic Net and fell in love with it.