Weekly Edition
Return to the Announcements page
| |||||||||||||
|
| |||||||||||||
John Backus dies
John Backus, the creator of the Fortran programming language, has passed
on. There is an
obituary in the New York Times. "In an interview several years
ago, Ken Thompson, who developed the Unix operating system at Bell Labs in
1969, observed that '95 percent of the people who programmed in the early
years would never have done it without Fortran.'"
(Log in to post comments)
John Backus dies Posted Mar 20, 2007 13:54 UTC (Tue) by richo123 (guest, #24309) [Link] Still my main programming language. Scientists are very conservative plus C is hard to read imho. Like the obit said, Fortran reads a bit like English shorthand.
John Backus dies Posted Mar 20, 2007 15:19 UTC (Tue) by bronson (subscriber, #4806) [Link] And, Fortran offers more optimization opportunities than hackish C. It's still used in many performance-critical scientific simulations.
Fortran Optimization Posted Mar 20, 2007 16:32 UTC (Tue) by samth (subscriber, #1290) [Link] First, while I'm certainly not a C booster, I don't know what you mean by "hackish". Second, the major optimization opportunity for Fortran (aside from lack of expressiveness) is that Fortran compilers are allowed to make unsafe assumptions about aliasing. This allows for transformations that C compilers can't do. So that comparison is pretty unfair.
Fortran Optimization Posted Mar 20, 2007 16:55 UTC (Tue) by Ed_L. (guest, #24287) [Link] Well, I'm willing to be corrected on this, but my understanding is you've got it just backward. Neither traditional Fortran-77 nor ISO-Standard C99 allow unsafe assumptions about aliasing. As a former colleague once said: "Fortran's greatest strength? No pointers. Fortran's greatest weakness? No pointers."
Of course, the other way of looking at it is that in Fortran *everything* is a pointer, all variables passed by reference, etc. But you can't have more than one of them (reference to the same variable). So the compiler can stick a variable in register, with complete knowledge of everything that will be affected when its value changes. Not so in C, so the compiler must be conservative about what it keeps in registers, and when it must copy out their values.
There are constructs in Numerical C that allow the programmer to tell the compiler when it has all aliases to a variable, which allows the same sorts of optimization as does Fortran. Of course, the programmer can also be wrong... I don't know enough about Fortran-95 to say whether ot not it faces similar issues. Someone else may correct me, but my guess is the Fortran community is waaaaaaay too conservative to have agreed to such a thing. But do let me know...
Thanks!
Fortran Optimization Posted Mar 20, 2007 17:36 UTC (Tue) by stevenj (guest, #421) [Link] There are constructs in Numerical C that allow the programmer to tell the compiler when it has all aliases to a variable, which allows the same sorts of optimization as does Fortran. I don't know what you mean by "Numerical C", but the C99 standard has a As
Fortran Optimization Posted Mar 20, 2007 18:02 UTC (Tue) by bronson (subscriber, #4806) [Link] Sure, once people actually start using the restrict qualifier! :)
Fortran Optimization Posted Mar 20, 2007 20:09 UTC (Tue) by stevenj (guest, #421) [Link] But now it's a question of the limitations of the programmers, not the limitations of the language semantics.Besides, most of the performance in large-scale computation these days is determined by things like cache issues and not by micro-optimization. The real problem is that most programmers don't have a good handle on how to deal with this—it seems the intuitive mental model that most programmers have of what goes on inside their CPU doesn't match very well with the messy reality of pipelines, caches, and limited associativity. I recall a discussion with one programmer (who happened to be a Fortran programmer) who was astonished at all the effort that went into optimized BLAS libraries like ATLAS, and at the order-of-magnitude performance difference that it makes (for the same N3 number of arithmetic operations). He exclaimed, How many ways can there possibly be to implement a matrix multiply? It's just three loops!
Fortran Optimization Posted Mar 20, 2007 17:38 UTC (Tue) by JoeBuck (subscriber, #2330) [Link] The Fortran standard states that arguments to procedures never alias, and if you violate that, your code might not work. This is only "unsafe" to users who don't know the rules. In Fortran, if you pass two arrays to a procedure, and they overlap, and either is written to, you've written an incorrect program, and it won't do what you expect.C, on the other hand, converts arrays to pointers when passing to functions, and a C compiler must consider the possibility that two distinct pointers to the same type might point to the same data. This means that it has less freedom than Fortran to re-order computations, and for scientific code this often results in slower code. The ISO C standard does have type-based aliasing rules, but it appears that most C programmers don't understand them, so GCC breaks their code when it takes advantage of this fact (so there's a -fno-strict-aliasing flag to keep GCC from breaking your code even if you have unsafe casts).
Fortran Optimization Posted Mar 20, 2007 17:44 UTC (Tue) by gnb (subscriber, #5132) [Link] You can certainly create aliases in fortran using the EQUIVALENCEstatement, in the sense that you can end up with (for example) two arrays whose storage overlaps. And they are indeed unsafe in that the compiler, faced with a subroutine that takes two array arguments, doesn't need to consider the possibility that they overlap. So you're right about the sorts of optimisations the compiler is free to apply, it's just that the rationale isn't "there will never be two references to the same bit of memory" so much as "if there are and you're not extremely careful how you use them it's your problem rather than the compiler's".
Fortran Optimization Posted Mar 20, 2007 17:57 UTC (Tue) by bronson (subscriber, #4806) [Link] By hackish, I just mean how much C feels like PDP11 assembly. For instance, on the 68K, a real looping construct could have saved one instruction per for loop. Sorry I don't remember the specifics; I investigated this for some postdocs at UCSB back in 1994. Memory's a little hazy... I suppose better optimizers may have solved this by now.
"unsafe" aliasing assumptions? Depends on your perspective I guess.
Don't get me wrong, I use C every day. I like the language a lot. I guess I like it the way I like some of my family members: idiosyncracies, wrinkles and all.
68K looping Posted Mar 23, 2007 4:09 UTC (Fri) by ldo (subscriber, #40946) [Link] For instance, on the 68K, a real looping construct could have saved one instruction per for loop. You're probably referring to the fact that the 68K subtract-one-and-branch instruction stopped branching when the counter hit -1 instead of 0. Many people were mystified by this, when in fact the reason was quite simple, and I never understood why the idea was not more widely copied.
Fortran eventually replaced by... Posted Mar 20, 2007 16:21 UTC (Tue) by endecotp (guest, #36428) [Link] I remember a talk from a C.S. professor about planning subsid programming courses for physics and engineering students. For years - decades - he had been trying to persuade them to teach something other than Fortran. Over time the suggested alternative changed depending on the curent fashion: Pascal, Modula-2, ML, Java, C++ - but they always decided to stick with Fortran. Until one year, quite recently, the engineers decided themselves that they were going to change.
To Microsoft Excel.
Sad but true.
Fortran eventually replaced by... Posted Mar 20, 2007 17:40 UTC (Tue) by stevenj (guest, #421) [Link] Usually, the replacement for Fortran in numerical/scientific computing classes these days is Matlab.
Fortran eventually replaced by... Posted Mar 20, 2007 18:38 UTC (Tue) by asamardzic (guest, #27161) [Link] IMHO that's very unfortunate, if true (am using Fortran, along with C/C++, on a more or less regular basis in a scientific computing field, but haven't noticed anything alike) - not much to like in Matlab. So, pity if Fortran is loosing ground indeed, and on the other side pity that at least Python with NumPy+SciPy+Matplotlib+... is not used more instead of Matlab in cases when fastest possible computation is not of utmost importance.
Condolescences to J. Backus family, CS field lost another of its giants.
Fortran eventually replaced by... Posted Mar 23, 2007 4:06 UTC (Fri) by ldo (subscriber, #40946) [Link] The high-energy physics types seem quite fond of C++, if libraries like CLHEP and GEANT4 are anything to go by.
John Backus dies
Link changed Posted Mar 20, 2007 14:52 UTC (Tue) by corbet (editor, #1) [Link] Oops, my mistake, sorry. I've switched the article over to this link, thanks.
Link changed Posted Mar 20, 2007 22:09 UTC (Tue) by arcticwolf (guest, #8341) [Link] You're welcome. :)
The 'B' in BNF Posted Mar 20, 2007 15:17 UTC (Tue) by AJWM (guest, #15888) [Link] My first programming language was ALGOL, so I knew Backus more for Backus-Naur Form grammar notation (sometimes misnamed Backus Normal Form).
Not that I escaped learning FORTRAN.
Languages, languages, languages Posted Mar 21, 2007 3:59 UTC (Wed) by jd (guest, #26381) [Link] Just open source compilers alone, there's an Algol compiler for Linux, two MUMPS compilers, a PL/I compiler, a PL/M compiler, a Fortran 77 compiler (G77), a Fortran 90 compiler (GFortran), a Fortran 95 compiler (G95), two partial implementations of COBOL, three Smalltalk implementations, numerous implementations of Lisp, and four or five of Forth. Oberon, Occam, Prolog, BASIC, SML, Icon, Scheme, Java, Intercal... The list of languages is endless.However, of all of those listed above, how many have seriously impacted not just one specific community of programmers, but the way people program -- and write programming languages -- in general? Not many. Of all the languages I've listed, I'd say Fortran (and its later forms) is the only one that has significantly changed the way people think of languages. More work has gone into developing and optimizing Fortran compilers than almost any other, and many techniques that are used elsewhere came from that work. This is not by chance. Fortran was not the first compiled language and was not the most widespread. But it was remarkably well engineered for the day and was far more amenable to the software engineering techniques being developed at the time. Which is why there's a Fortran 95 and only an Algol 65. It's why MPI has a Fortran interface but none for COBOL or PL/I. It's why more Universities today have courses in Fortran than they do for Occam or Modula-3. BNF/EBNF may be barely used outside of Comp Sci classes, and Fortran may be better known for legacy code than the latest in modern marvels, but this is a guy whose impact on computing is not just a few historical echoes, but is still reverberating throughout the industry. It'll be another 50-60 years before we will really understand what happened and why. Until then, whatever lists anyone comes up with for the positives and the negatives (both exist and are important) can only be partial and potentially misleading. All I think anyone can genuinely say now is that nobody can have an impact so far into the future from an event so far into the past unless they were truly amazing.
Languages, languages, languages Posted Mar 21, 2007 13:08 UTC (Wed) by eru (subscriber, #2753) [Link] Just open source compilers alone, there's an Algol compiler for Linux, two MUMPS compilers, a PL/I compiler, a PL/M compiler, a Fortran 77 compiler (G77), a Fortran 90 compiler (GFortran), a Fortran 95 compiler (G95), [...]However, of all of those listed above, how many have seriously impacted not just one specific community of programmers, but the way people program -- and write programming languages -- in general? Not many. Of all the languages I've listed, I'd say Fortran (and its later forms) is the only one that has significantly changed the way people think of languages. [...] Algol is another equally influential. Of course nobody these days actually uses Algol, but it has very heavily influenced the design of more common languages Pascal, Modula, Ada - and of course C ! Replace "{" and "}" with "begin" and "end", and "if (expr)" with "if expr then", and some other replacements in similar vein, and your C program will look almost exacly like an Algol program... Even the feature of allowing variable declarations at the start of any block comes from Algol.
Languages, languages, languages Posted Mar 22, 2007 12:24 UTC (Thu) by nix (subscriber, #2304) [Link] Lisp too, although its influence is so pervasive that nobody remembers the little features (like functions, the conditional, `cond', and so forth) that originated with McCarthy and the earliest Lisps. People just remember that Algol had those featuers, but not where Algol got them from.
Languages, languages, languages Posted Mar 22, 2007 12:29 UTC (Thu) by nix (subscriber, #2304) [Link] Replace "{" and "}" with "begin" and "end", and "if (expr)" with "if expr then", and some other replacements in similar vein, and your C program will look almost exacly like an Algol program...Ah, BOURNEGOL, we barely knew ye...
John Backus dies Posted Mar 21, 2007 4:30 UTC (Wed) by mbottrell (guest, #43008) [Link] Good to see that an obituary to what could be classed as the father of programming has turned into a comparison of C Vs Fortan. :-/
R.I.P. J.W. Backus.
John Backus dies Posted Mar 21, 2007 8:38 UTC (Wed) by bronson (subscriber, #4806) [Link] I feel that he would have appreciated the discussion. If nothing else, it illustrated that Backus's ideas will live on for... well, probably for as long as mankind programs computers.
John Backus dies Posted Mar 22, 2007 2:41 UTC (Thu) by jd (guest, #26381) [Link] I could be totally insensitive and point out that an obituary is nothing more than a stack trace after the dereferencing of a null pointer, but I'll be kind.Whilst some have indeed been talking about C versus Fortran, others have noted the wonders of BNF notation, the impact Fortran has had on Comp Sci thought, the fact that John Backus was a genius, etc. The biggest thread isn't really the most significant, merely the loudest. That happens with anything, so I'm not sure it's worth paying much attention to. IMHO, a much more valuable line of thought would be why Fortran is still a living, evolving language, when many languages contemporary to the original implementation of Fortran, especially those that were initially far more heavily used, are either dead (ie: not evolving) or extinct (nothing meaningful is written in it).
Fortran reminiscences Posted Mar 23, 2007 4:44 UTC (Fri) by ldo (subscriber, #40946) [Link] I remember reading a piece Backus wrote about the origins of Fortran for some SIGPLAN publication decades ago. Apparently the state of the art for during scientific-type computations in those days was software interpreters (and I think floating-point hardware was quite rare at the time). There were also things called "Autocodes", which were a step up from assembler in that you didn't have to worry about details of storage layout or the machine instruction set. But you still couldn't write arbitrary mathematical expressions: instead of
Fortran improved on these systems in a number of ways:
|
|
||||||||||||