Irreal

On the The Unix Heritage Society mailing list, someone started a
thread commemorating the death of John Backus, who, in addition to
inventing the Backus-Naur form, lead the team that developed the
original FORTRAN. Someone else made a disparaging remark about FORTRAN
and that precipitated a long discussion of the good, the bad, and the
ugly of FORTRAN. Most people who’ve never used FORTRAN—and many who
have—aren’t aware that except in strings and a couple of other places,
blanks don’t affect the syntax and can be omitted. I recall once
looking at a FORTRAN compiler where the first thing it did after
reading a card image was to eliminate all the blanks.

Steve Johnson, the inventor of Yacc, the Portable C Compiler, and
Lint, offered a funny story about FORTRAN and blanks at Bell Labs. His
post is worth reading as an interesting piece of Bell Labs history but
what struck me was how the choice of the right tool for a job enabled
Johnson to complete a task much more quickly than even the world-class
engineers and computer scientists at the lab expected.

The TL:DR is that Johnson, just out of college, had a summer job at
the labs. He was assigned to write a program implementing a state
minimization algorithm. His supervisors expected it to take him the
summer to complete the program. But Johnson had heard about this new
language, SNOBOL, that seemed perfect for the task. Once he got SNOBOL
running, it took him only 3 weeks to do the job.

All of us have go-to tools that we turn to first. In terms of
languages, it might be C, Lisp, Python, Ruby, JavaScript, R, or
whatever we’re most comfortable with. But stopping to consider what
tool will make the job easiest can yield large dividends.

The other day I followed a reddit link to a blog post about forking on
GitHub. I didn’t find the post that interesting but I did find one of
the comments on reddit provocative. Chrisgseaton takes exception to
the notion that “real” programmers have to think about hardware¹.
As far as I can tell he wants to think of his programs as running on a
virtual construct that implements a logical model but—ideally—with no
actual hardware underneath.

That’s often a useful model and I don’t consider programmers that
adhere to it “lesser programmers” but I do think that great
programmers always have the underlying hardware in mind. Not
necessarily the actual piece of hardware the program will run
on—because, really, how can you know—but at least some sort of
idealized piece of hardware².

That sounds almost like the “logical model” that chrisgseaton wants to
think about but it’s really a bit more. Every architecture that I’ve
ever worked on has load, store, arithmetic, and some sort of logical
if commands. Their mnemonics and exact operation will differ, of
course, but to a first approximation they’re the same.

That means that as I code I can imagine—again to a first
approximation—what code will be generated. If you can do that, you can
make intelligent decisions between functionally equivalent ways of
coding an idea. If you can’t do that, I don’t see how you can hope to
produce the best code.

I may feel that way because most of my professional development was
done in C, which is often considered a “high level assembly language.”
On the other hand, I can mentally imagine the final machine code even
when I’m coding in a language like Lisp. Languages like Python are
harder because they’re running on virtual machines but even there it’s
possible to predict what “code” will be generated.

So for me, yes you do have to think about the hardware as you code.
Of course, that’s just me. What do you think?

Even though I mostly program in some form of Lisp these days, the
majority of my programming over the years was in C. That’s not hard to
understand: most of my work involved low level communications software
such as radio network controllers and message switches. Not very long
ago, C was used for virtually everything—even things for which it
wasn’t really suited.

These days, C use tends to be restricted to its more natural role as a
language for systems programming and specialized applications where
speed is essential. Even in those niches, C is feeling pressure from
languages like Go and Rust. Many younger engineers have never used C and
are inclined to think of it as a crusty, old language whose time has
passed. Pretty much like the programmers of my generation viewed, say,
COBOL.

Still, C is far from dead and is still the language of choice for many
types of programming. It has a lot going for it: it’s fast, doesn’t
require a run-time engine, and can even get by with a very small
run-time library. The folks over at the SQLite Project have a page in
which they explain why they still use C and have no plans for
changing.

In addition to the reasons above, the SQLite page also calls out C’s
stability. The very fact that it is an “old” and established language
is a plus for them because the developers don’t have to worry about
the language changing out from under them in the way that a new
language still undergoing development—such as Rust—does. C is still
evolving, of course, but very slowly and always with an eye on
backward compatibility.