Most scientific code is written in a remarkably primitive and largely unintelligible language – Fortran – which has impeded scientific progress for generations. Below is a code fragment which had me baffled for much of the day.
CALL GBYTE(Z,I4,(K+0)*8,4*8)
CALL GBYTE(Z,I1,(K+7)*8,1*8)
IF(I4.EQ.1196575042.AND.(I1.EQ.1.OR.I1.EQ.2)) THEN
IF (I1.EQ.1) CALL GBYTE(Z,KG,(K+4)*8,3*8)
IF (I1.EQ.2) CALL GBYTE(Z,KG,(K+12)*8,4*8)
Tomorrow I will post the equivalent C code.
Ever tried APL? 🙂
Ever tried FORTH?
Ick Fortran, it gets worse when you look at this NCARS code. It’s shocking if they still use it.
http://dss.ucar.edu/datasets/ds090.0/software/prepdecode/grabbufr/grabbufr.f
It’s amazing that they are still using this, ahem, super duper program coding language. My engineer dad had mastered it in the late 1950’s a few years before I was born.
He learned C, then to massively improve his and his teams productivity and give his business a technical edge I taught him Smalltalk and that was a huge breakthrough for him as it let him do 90% engineering while only needing 10% computer science.
With a number of successes with him and other clients in the engineering, scientific, financial, business and gaming fields I have designed and am now implementing a next generation language for science, engineering and advanced business applications that inherits aspects from Smalltalk, Lisp, Assembly, and a few other languages plus a few innovations in the mix that I’ve not seen elsewhere; it’s known as ZokuScript ™. It shall be intriguing for science use in part because of Zoku’s extensive auditing features and it’s capability at providing a safe parallel programming model that works on N-core multicore chips as well as massively distributed cloud network computing for huge speed increases when needed.
If NCARS and other climate scientists are still using Fortran it’s like cavemen lighting fires with sticks.
Ah the good old days. JCL, Assembler, Fortran, Cobol … remember it well.
This is precisely the the type criticism I lashed out at Gavin Schmidt after my brief evaluation of the ModelE code. What a pile of crap it all is. I engaged in a rather robust argument with Gavin about things like Source Control Management (SCM), as I found it utterly amazing that his (their) view of SCM is non-existent. Set aside the fact that they are using a primitive technology to begin with, they also don’t deem it necessary to perform peer review and SCM on billion dollar software.
I found it all quite remarkable and indeed, it told me all I needed to know about the state of the so-called “climate modeling” .. bunch of garbage.
The other problem is, you have mathematicians believing they can write software. Hahaha, what a laugh.
hahaha … another problem with this, 45 lines of comment for 13 lines of code … ROFLMAO … no wonder a production of 10 lines of production code per day per programmer, was the norm back in the late 70’s early 80’s.
Nowadays, you had better be able to produce a few hundred or your gonna be out of a job.
Nonsense. Fortran is unbeatable at tasks for which it was intended, namely scientific and engineering number-crunching. I’m talking modern Fortran (versions 95 and later), as opposed to outdated FORTRAN (e.g., FORTRAN 66 or 77). Sure, you can find crazy code from 1977, written specifically for a particular machine, and make fun of it. But that’s a straw-man argument. Straight out of the box, F95 understands complex numbers and matrices, and all of F95’s intrinsic functions are already overloaded for them. The learning curve for using C to do S&E calcs is MUCH steeper. Furthermore, F95 can draw on thousands of well-documented, well-tested, and superbly optimized subroutines and libraries, all in the public domain. Typically, many of these are bundled with the F95 compiler, and often are automatically used to optimize the user’s code. Yeah, C programmers can use this stuff too — if they don’t die before they figure out how. Lastly, if you get really good at S&E programming and decide to do it for a career, you’ll have to learn Fortran (and maybe even FORTRAN), because almost all of the huge S&E number-crunching programs are written in Fortran, not in C.