The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Clem Cole <>
Subject: [TUHS] Re: Generational development [was Re: Re: Early GUI on Linux]
Date: Tue, 28 Feb 2023 10:28:57 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 4708 bytes --]

On Tue, Feb 28, 2023 at 3:00 AM <> wrote:

> As Dan said, this is nuanced.
That is so true  - I suspect it is a multi-edged sword, probably more than
two edges.

> While I'm sure there's lots of mediocre programmers writing mediocre code,
> (a) there probably always has been [think COBOL on mainframes] and (b) it
> is not universal.

Sure. CS students are still not getting introduced to FORTRAN even though
over 90% of all production supercomputer code uses it. Again I don't
program it, but I accept that modern Fortran is not a terrible language -
because I looked at it and know a bit about it (I'm not too snooty
to do so).  So modern FORTRAN courses are now taught in science departments
and passed from professor to student (and it paid my salary as long as I
made systems that ran it well).  My 30 yr CS major daughter, who has
been at Google for a few years, never saw FORTRAN (or Snobol - much less
awk/sed) in her comparative languages course. I think that's a sin.   She's
fluent in Python and Java - as well as a ton of tools for 'cloud
development and deployment.'  Clearly these are valuable skills and the way
a lot of modern programs are deployed.   She can work with C++ and Go (and
I think Rust) and saw a dialect of LISP (racket) in her
comparative languages course. In her university time, they taught they all
about regular expressions and made her and her classmates all use
grep/awk/sed in her original algorithms course years ago.

> I have generally been fortunate to find interesting
> and challenging work in a fairly long career; there's lots of interesting
> problems out there that need solving which can't be dealt with by just
> stringing together existing class libraries using an IDE on autopilot.
> You have to look for it, and then hope you're qualified enough that they'll
> hire you.

However, the cool things that we are yet to see will be created by Matt and
my daughter's generation, and I'm sure they will be great and *just as
important in the long run* as some of the neat things a few of us on this
list created. As Dan said, CS did not stop in 1989. Dennis said it well: *“From
an operating system research point of view, Unix is if not dead certainly
old stuff, and it’s clear that people should be looking beyond it.”*

The important thing is not to reject something just because it is old and
jump to something because it's new.   I find the current
class-library/frameworks cruft as bad (and not a lot different from) the
'access methods' that IBM created in the 1960s, and Multics and UNIX boldly
rejected with all the worlds a 'segment' or later file.

This is the importance of teaching and exposing students to ideas (good and
bad) from the past so as not to repeat them. BTW: just because an idea
failed previously does not mean it will not work later or that such an
idea is a good or bad one now.  This is why experience is so important -
for a >>great read<< Peter Novigs  Teach Yourself Programming in Ten Years

I often refer to this as picking up 'good taste.'   I agree with Arnold
that learning an IDE often seems like you are losing the ability to have a
foundation.   I've pointed out reading >>and doing the exercises<< in Rob
and Brian's excellent text: The Unix Programming Environment
should be part of all young programmers' experience (even learning to use a
document compiler like the runoff family. Once you master ed, regular
expressions and the like make you a better programmer.        I'm not
saying you must be fluent/use vi or emacs as your primary editor to be a
great programmer. Still, I would place a large bet that the best
programmers all know how to use at least one of those tools - and I'll also
bet that they all could use a QED-derived line editor if that is what was

The key to the UNIX philosophy is teaching to think *vs.* spoon-feeding a
current answer.

Sometimes, the latter has its place (I use many GUI-based applications on
my mac), but I always have several 'iterm2' windows open with a shell
prompt. The problem is that when the former is all you know, your only real
experience, I think people that have a wider field of view and a more open
mind are going to understand that your experience is quite limited and thus
the ability to judge the good/bad-ness of a something might be a tad

Curmudgeon-ly yours,


[-- Attachment #2: Type: text/html, Size: 7971 bytes --]

  reply	other threads:[~2023-02-28 15:29 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-25 21:31 [TUHS] Early GUI on Linux Paul Ruizendaal
2023-02-25 22:49 ` [TUHS] " Dan Cross
2023-02-26  1:27   ` Larry McVoy
2023-02-26  0:39 ` Warner Losh
2023-02-26  1:14   ` Steffen Nurpmeso
2023-02-26 15:50   ` Leah Neukirchen
2023-02-26 16:13     ` Larry McVoy
2023-02-26 16:23       ` Leah Neukirchen
2023-02-26 16:32         ` Warner Losh
2023-02-26 16:39         ` Will Senn
2023-02-26 19:58       ` Dave Horsfall
2023-02-27  0:16         ` Adam Thornton
2023-02-27 10:09       ` Ralph Corderoy
2023-02-26  2:21 ` Jonathan Gray
2023-02-27 17:22   ` Paul Ruizendaal
2023-02-27 18:32     ` Warner Losh
2023-02-26  2:27 ` Will Senn
2023-02-26  2:30 ` Will Senn
2023-02-26  2:40 ` Theodore Ts'o
2023-02-26  3:28   ` Dan Cross
2023-02-26  3:45     ` Warner Losh
2023-02-26  5:24   ` John Cowan
2023-02-26  5:36     ` Steve Nickolas
2023-02-28  3:35     ` Dave Horsfall
2023-02-27 17:22   ` Paul Ruizendaal via TUHS
2023-02-27 17:59     ` Arno Griffioen via TUHS
2023-02-27 18:07     ` Warner Losh
2023-02-27 20:04     ` [TUHS] Generational development [was Re: Re: Early GUI on Linux] arnold
2023-02-27 20:08       ` [TUHS] " Chet Ramey
2023-02-27 20:22         ` arnold
2023-02-27 20:46           ` segaloco via TUHS
2023-02-27 21:04             ` Dan Cross
2023-02-28  7:59             ` arnold
2023-02-28 15:28               ` Clem Cole [this message]
     [not found]                 ` <>
2023-02-28 15:50                   ` [TUHS] Fwd: " Adam Thornton
2023-02-27 20:50           ` [TUHS] " Chet Ramey
2023-02-27 20:55             ` Bakul Shah
2023-02-27 21:01               ` segaloco via TUHS
2023-02-27 21:15                 ` Chet Ramey
2023-02-27 21:22                   ` Dan Cross
2023-02-27 20:30     ` [TUHS] Re: Early GUI on Linux Dan Cross
2023-02-28  1:10       ` Alexis
2023-02-28  1:27         ` Dan Cross
2023-03-01 16:39       ` Paul Ruizendaal
2023-03-01 16:54         ` Larry McVoy
2023-03-01 17:22           ` Paul Ruizendaal
2023-03-01 17:52             ` Larry McVoy
2023-03-02  1:17               ` Jonathan Gray
2023-03-02  4:28               ` Larry McVoy
2023-03-02  6:46                 ` [TUHS] X timeline Lars Brinkhoff
2023-03-01 18:59         ` [TUHS] Re: Early GUI on Linux Theodore Ts'o
2023-03-02  7:27         ` arnold
2023-02-28  1:08     ` Jonathan Gray
2023-02-28  1:15       ` Clem Cole
2023-02-27 20:56 ` Will Senn
2023-02-27 22:14   ` Andru Luvisi
2023-02-27 22:31   ` David Arnold

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).