[u-u] Some thoughts on programmer productivity

[D. Hugh Redelmeier]

| From: Giles Orr <gilesorr at gmail.com>
| 
| I should admit up front that I gave up in disgust after about five
| minutes of the video - so I haven't seen the whole thing.

Ditto.  But I let it roll to the end while typing this.

I felt that almost every paragraph was at best not quite correct.

Just about the Ken Thompson part (From my memory):

- ed(1) was so simple that no significant number of people would be 
  willing to use it today.  I, for example, implemented an extended 
  version of ed for my Altair that fit in 7k along with an assembler, a 
  debugger, an EPROM burner, audio tape drivers, serial drivers, etc (self 
  hosted on a bare machine).

- Ken wrote ed as a minimal subset of QED.  Ken previously wrote QED for 
  CTSS and and another for Multics.  So he had lots of practice.

- writing for one machine is different from writing portable code.
  The first UNIX ran only on a single PDP-7.

- An assembler is really easy to write.  Especially when it has no 
  creature comforts (e.g. no macro processor) and it is for a very simple 
  machine (e.g. the PDP-7).  The PDP-7 was considerably simpler than an 
  Intel 8080 (that's a Good Thing).

- an OS for a PDP-7 is pretty simple.  What's notable about UNIX is that 
  it had good bones (but no pipes yet).  But Ken had been using and 
  contributing to several operating systems before this.

| But
| here's another thing: he was writing an OS for raw hardware in an
| environment TOTALLY UNCONCERNED WITH SECURITY.

Right.  The PDP-7 had no mechanisms to implement security.  No MMU, for 
example.  So there was no thought of security.  The (later) PDP-11 was 
different.

Just like security, there are a host of other things we require these days 
that were impossible back then.

- GUI

- user-friendly

- provision for change

- co-existence with other programs on the same playground

- interoperation

- support multiple developers and even teams

- portability

- support for version migration

| I'm not saying he's wrong - but he failed to back up his point in a
| useful way, or look like he was going to address multiple other
| mitigating factors.

Right.

I'm looking at 0:22 for his strata of programming languages.

I wonder why he mentioned C# and not Java?  Is that a tell?

When we wrote in machine language, we could be masters of the machine.  
But the cost was that you burned so many of you cycles on book-keeping 
that all programs really ought to be short.

Assembler helped a lot.  Especially with changing your program.  When you 
added a line of assembler, a large portion of the machine language 
program changed.  Better to let the assembler look after that 
book-keeping.

You did lose a bit of feel for the machine.  Especially with really 
helpful assemblers.  Powerful macro languages let you go crazy.  As a 
machine language programmer, more puns were available to you.  I once used 
a constant word in a PDP-8 program for three different purposes

- to hold the address at which to enter the OS

- to hold -(page size)

- to be an instruction

C was a great step forward.  Sure you lost machine efficiency but not a 
lot and, if used carefully, could make programs portable-ish.

FORTRAN (which I hated because it was imposed on me) really made it 
possible for area specialists to program.  What could be more important?

C++ is no friend of mine.  But it does let programmers enough leverage to 
build big systems, beyond what C can support.

Haskell is very productive for those who understand it.  It is very 
different from those previous languages.

JavaScript is horrible and wonderful.  It doesn't support much discipline 
but its ubiquity means that it can be used to solve many important 
problems.  It's a low road Java that succeeded at Java's goals.  I mean 
who would have thought something like WASM would be useful.  This links 
us back to machine language.

It's dinner time, I'll stop.