[TUHS] Follow-on to the Pascal/C/etc. discussion

[Steve Johnson]

A great question, Jon.

Here are some things that I've stressed at times when teaching or
mentoring.

	* Realize that programming is a service profession.  A program's
users probably don't care what language it was written in or what
editor was used to write it or why it wouldn't run on their operating
system.  They have a job to do.   The challenge here is that
programming can be a lot of fun, so it can attract people who love the
act of programming and fill their programs with "neat hacks" that make
them feel good but do nothing for their users.  This is the ethical
equivalent of waiters in a restaurant standing around joking and
flirting when you are hungry and want to order.
	* Like music, programming often rewards people who get a bit obsessed
with it as youngsters and spend most of their time with it.  This can
leave the programmers very short of basic social skills such as
writing and communicating with other team members and their users. 
This opens the door to the worst kind of bugs -- not doing something
wrong, but doing the wrong thing.
	* To oversimplify, every instruction in the computer either serves
the customer or the programmer.   The customer may want to multiply
matrices.  In their mind, the program is a triply nested loop with a
lot of multiplies and adds.  Those instructions belong to the
customer.  Instructions to set up call stacks, create and destroy
processes, do context switches, execute in device drivers, etc. etc.
belong to the programmers.  The more you can attack and simplify this
kind of bureaucracy in the computer, the happier both you and the user
will be.
	* If a program speeds up by a factor of 10, it becomes qualitatively
different.  Or if it slows down by a factor of 10.  Consider how
Google would feel if it took 5 seconds to respond instead of .5
seconds...   Speed is important.  In many cases that I've seen, slow
programs are slow because the "programmer's instructions" didn't
support well what the customer wanted to do...
	* Interactive programs (Shell, Python, MATLAB, etc.) are great ways
to prototype.  But beware of them as bases for production programs. 
The problem is that bells and whistles can and do creep into the
language and be unnoticed because they happen within human reaction
time.  At the keyboard, you don't notice, or may even like the
features, but when you are doing something a trillion times they can
cause the "programmer instructions" to dominate the run time.  Also,
typos can lurk for years before detonating if you don't have a strong
typing and procedure definition environment.

	Hope this was the kind of thing you were looking for...

	Steve

----- Original Message -----
From: "Jon Steinhart" <jon at fourwinds.com>
To:"The Unix Heritage Society" <tuhs at tuhs.org>
Cc:
Sent:Fri, 01 Sep 2017 16:29:22 -0700
Subject:[TUHS] Follow-on to the Pascal/C/etc. discussion

 Hi everybody. I'm new to this list as a side-effect of my question
about
 the provenance of strcmp and the convention of returning <0, 0, >0.

 I had to learn Pascal as a freshman in college which was challenging
coming
 from BTL knowing C. Kept wondering how Pascal could be used for
anything
 useful. The answer that I later saw in industry was "by adding
non-standard
 extensions".

 Language discussions often turn to the issue of whether programming
languages
 should prevent programmers from making mistakes or whether that's the
job of
 the programmer. This is, of course, independent of discussing the
 expressiveness of languages.

 I agree that a lot of "programming" today consists of trusting and
bolting
 together random library functions. That's not me; I often work on
safety
 critical devices and I'm not going to rely on libraries of unknown
provenance
 when building a medical device that I make be hooked up to it
someday.

 Years ago I inherited a project written in hodgepodge of programming
languages
 including ruby. My first reaction to ruby was "Wow, how do I get some
of
 what they're smoking because it's better than anything I have?" I
eventually
 asked Ward Cunningham about it because he was working for ruby house
AboutUs
 at the time. His answer went something like this:

 Jon, you're an engineer and you understand engineering.
 You know programming and programmers and understand programming.
 Then, there are the people with whom we entrust our confidential
credit card data.
 That's what ruby is for.

 This nicely summarized the current state of affairs in which the most
critical
 tasks are assigned to the least competent people. I see this as a
management,
 business, and political problem which can't be solved by different
languages.

 I have often made the statement that "I would never hire someone who
had to use
 glibc in order to implement a singly-linked list." I get push-back
such as "Oh,
 and people can create bugs rather than using the debugged library?"
to which I
 glibly respond "debugged library like OpenSSL?"

 I am more than a little terrified by the "everybody must learn to
code in high
 school movement". What they're learning is something at a level akin
to the
 ruby example above. The goal is clearly to make "coding" a minimum
wage job
 and to many the distinction between "coding" and engineering is lost.
I've
 spoken with many kids in the "future engineer" category who are
frustrated at
 the lack of depth in the curriculum. I'd summarize it as teaching
people to
 program without teaching them anything about computers.

 Anyway, I have been volunteering to teach technology to kids for
years as
 karmic payback to my BTL explorer scout advisors Carl Christensen,
Heinz
 Lycklama, and Hans Lie. Not to mention all of the amazing people that
I met
 there when my dedication to hitchhiking up the the Labs after school
and
 talking people into signing me in turned into a series of summer
jobs.
 I'm in the process of turning my class notes into a book. The goal of
the
 book is to teach kids enough about computers that they can understand
what
 their code is actually doing and why one can write better code with
an
 understanding of the hardware and environment.

 The book is in the editing phase so it's beyond wholesale changes.
But I'm
 curious as to what you all think should be in such a book as I'll
find a way
 to wedge in anything important that I missed.

 Thanks,
 Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170903/851867cd/attachment.html>