There a sentence from a famous women in the history of computing, I don't recall which one, about C setting the progress of compiler optimizations back to the dawn of computing.
Perhaps it was Fran Allen. In Coders at Work, she has quite a few things to say on the topic:
--- Begin Quote ---
-Seibel-: When do you think was the last time that you programmed?
-Allen-: Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization.
The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue. The motivation for the design of C was three problems they couldn't solve in the high-level languages: One of them was interrupt handling. Another was scheduling resources, taking over the machine and scheduling a process that was in the queue. And a third one was allocating memory. And you couldn't do that from a high-level language. So that was the excuse for C.
-Seibel-: Do you think C is a reasonable language if they had restricted its use to operating-system kernels?
-Allen-: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve.
By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are... basically not taught much anymore in colleges and universities.
Great quote. I had never read that one. The irony of language wars about the monolith that is C vs. the many higher-level languages that allow a human to code according to his mental abstractions and cognitive ability, rather than memorizing machine-specific, or os-specific facts that don't translate over to newer machine architectures. All this on HN, running on a Lisp, Arc, that once sat upon an academic scheme now called Racket.
I agree C is necessary for low-level programming, but for the meat of all the other applications and usages, higher-level languages are needed. I don't mind programming certain things in C, but I thoroughly enjoy the mental exercise when programming in the J programming language, Lisp, or Forth. Yes, Forth. C programmers can have the Earth; I would like to be coding with the fellas who design mission-critical software for satellites like Rosetta, and groups like NASA and the ESA, using Forth in Rosetta's case [1].
Slim Whitman sold more records than the Beatles, or so I think I heard that on a late-night TV commercial back in the 80s, but I never owned a record from him ;)
This is a bit off topic, but would you mind sharing what resources you used to learn forth? I'm interested in the language myself, but I don't really get how to use it. I've learned the basics about defining words and manipulating the stack, but whenever I try to apply it to an actual problem, I have a very hard time even understanding how to approach, wheras if I were using a procedural or OO language, I would know where to start.
There are the main books everyone refers to like 'Thinking Forth' [1], and others, but I really learned faster by picking up Factor [2] and Retro [3]. The community on Factor is very helpful and smart. I actually wrote my first real Forth program for work in Factor. I had written a lot of one-liners, and some curiosities, but this was a business need met in one night. It was basically a program to munge a whole lot of tab-delimted text files, and do some math on fields and then generate a report. It was all < 100 LOC, and it was easy to interactively test if I was missing anything in the interpreter.
Retro is cool, since it is so minimal, and there are add-ons for Chrome so you can run it in your browser locally to try it; otherwise, you download the image file for your platform, and Retro itself. Retro was built on a VM called Ngaro, which is an interesting diversion, but not Forth.
There are also microcontroller ports of Forth [4], which I found a lot easier than using the assembler for a particular microcontroller. FlashForth has been recently updated, and is featured in a 'Circuit Cellar' magazine article. I have also purchased iForth [5], since I had stopped dual-booting linux at the time, and it offered a lot for Windows, and mathematics (fast).
I hope these help you get started. If you are a maker, using an Arduino or PIC-like chip with FlashForth is great. The whole dictionary, or word list (all the defined functions called 'words' in Forth, are listed in the reference I provided). In Forth, you can easily add to the dictionary, it is concise enough to know your whole system in a short time, and add to it when you need it. Good luck!
> I agree C is necessary for low-level programming, but for the meat of all the other applications and usages, higher-level languages are needed.
I actually disagree with this for the most part.
C's main advantage as a systems language is its ubiquity -- virtually every platform released in at least the last 25 years has had a reliable C compiler available. Before JavaScript hit it big with Web 2.0, C was a lingua franca among programmers. Starting in the late 80s and continuing throughout much of the 90s, pretty much every textbook that had used Pascal or Pidgin Algol for code listings was edited to contain code listings in C instead.
Of course, as Java gained momentum in the education space in the late 90s and early 00s, many were again updated for code listings in Java. Although a great deal of computer science curricula now crowd around Java, most of them also have at least one required course either on C or that makes good use of C (my own track at NC State contained, beyond the introductory Java courses, "C & Software Tools", "Operating Systems", and "Computer Graphics", all in C).
That all being said, there were historically quite a few systems languages that were better than C in almost every way[1]: they were (typically both memory- and type-) safe, they were higher level in the sense that they offered more and better tools for abstraction (and were therefore considerably more expressive), they offered more opportunities for automatic optimization, they were easier to port to new platforms, many of them were easier to read and had far fewer nuances/"gotchas"/"footguns" than C, the languages themselves were designed in such a way that better tooling was possible, the list goes on and on. The one thing that C had on them was that it was already default. Programmers could (and can) count on the target platform having a C compiler. C programs have access to the wide assortment of C libraries. C was good enough. In a sense, C's popularity was and is perpetuated by the fact that it's the path of least resistance. Once C managed to get into that position, of course it became the "king of systems languages".
I think C's days are numbered. There was a time when systems programming was how you went about learning to program professionally on microcomputers. (Unstructured) BASIC was popular among hobbyists but right-out for professional programs due to abysmal performance. So, you learned assembly/machine language, or, if you were lucky, Turbo Pascal, a similar-in-spirit C system, or QuickBASIC (a compiled, structured language that I'd actually classify as a systems language, given that its feature set is mostly isomorphic to C's). Nothing else offered the level of performance you needed for commercial applications. This continued from the mid 80s through to the early 00s, yielding several generations of programmers who were systems programmers by training.
But things are different now: most programmers nowadays are cutting their teeth on high-level languages like JavaScript, Ruby, Python, Lua, etc., and if they become systems programmers it's due to their own desires and interests rather than out of any real necessity. These programmers know better, and are in an excellent position to notice the many shortcomings of C, and some even outright reject it due to its gnarliness in comparison with the high-level languages they're accustomed to. They know, deep down in their bones, that systems programming doesn't have to be so unsafe, so intricate, so field-of-landmine-ish, so... shitty. And some of them intend to do something about it.
I think we're already seeing the results of this: languages like Rust, Nim, and Myrddin strike me as products of these happenings. And now, I think, is a good time for it, because C's ubiquity has never been less relevant since its rise to power: there's only a handful of platforms anyone needs to support nowadays (POSIX and Windows, desktop and mobile; you can count OS X/iOS as a separate platform if you're feeling squirrely, but even then you haven't reached an unattainable set of targets, and it seems as if soon you may be able to strike Windows from the list as well); if you offer ABI compatibility with C, you get libraries for free; parsing is practically a solved problem; .... And then there's the LLVM, which can handle roughly a third of the compilation process for you -- and it's the backend: the hardest part!
I imagine that within another 20 years to 30 years, C will be hiding within its final strongholds of legacy code and embedded programs. Outside the embedded space, new projects in C will be exceedingly rare, and another decade or two after that will see even the embedded programmers breathing a collective sigh of relief as they become gradually liberated from the tyranny of C.
Only time will tell if the newcomers can usurp C's throne, but I have my fingers crossed. When C gasps its last breath, I will say "good riddance", and happily return to my safe, expressive, pleasant systems language, whatever that may happen to be at that time.
[1]: Just to name a few: Algol 60, Modula-2, Oberon, Ada, Modula-3(one of my personal favorites), ATS, even several non-standard dialects of Pascal such as the ones from UCSD, Apple, and Borland. Then, of course, there are the newcomers: Clay, Rust, Go, D, (does Nim count?), Myrddin (definitely one to keep an eye on), even some dialect(s) of C# were used at Microsoft Research for systems programming. I'd also be remiss not to mention PreScheme (another one of my favorites), used by Jonathan Rees and Richard Kelsey to implement the Scheme48 virtual machine, and its nephew RPython, used for implementing the PyPy JIT framework. I'm sure there are quite a few I'm leaving out, but these are the ones that come to mind at the moment (also, do keep in mind that I'm restricting this to systems languages that are strictly better than C, so some otherwise neat ones like BCPL and BLISS have been intentionally omitted).
Great summary. I especially like your point about the programmers migrating to systems programming having a different mindset than an older person like me, who started with assembly. Thanks for that.
Not sure if by 'disagree with this' you mean the whole piece, or just the quoted sentence. Addressing the obvious quoted sentence:
Don't get me wrong, I like C. I am currently writing a Lisp in C, playing with ImGui and Nuklear immediate-mode GUI kits. That is why I used the word 'needed' vs. something like 'are majorly used'. C pulled me from my Vic-20 6502 assembly language days (I lie, I had moved to Basic before C!). When I program in a higher-level language (Lisp/Scheme, Python, Julia), I find I am dealing with what I actually want to get done, and in the end my programs are not AAA games, or large deep learning neural networks, so they are plenty fast for my needs. I start out clearly with an objective in C, but usually get mired in some C-specific, non-goal-related task, whether I need to refresh my knowledge of pointers, or platform-specific idiosyncrasies. I certainly would choose C over Java any day, or move to another higher-level language. I think Java's VM is a fantastic piece of work, and Java syntax is very C-like, but I'd rather not use it. I use a lot of programs written it though! I prefer Lisp/Scheme, and compiled SBCL is fast. And now with the opensourcing of Chez Scheme, I will be busy this next week. The Spring 2016 Lisp Game Jam is starting in about 24 hours [1].