From: Jon Steinhart <email@example.com>
To: TUHS main list <firstname.lastname@example.org>
Subject: Re: [TUHS] more about Brian... [ really GC vs malloc/free languages ]
Date: Sun, 06 Feb 2022 10:36:55 -0800 [thread overview]
Message-ID: <202202061836.216IatiC3502688@darkstar.fourwinds.com> (raw)
Larry McVoy writes:
> Let's keep it civil and non-personal, I don't think Rob was pointing
> at anyone, I think he was pointing at some not so forward thinking.
> I have to side with Rob on this one, even though I'm squarely in the
> I like C best camp.
> While I _can_ do all the malloc/free stuff myself (and have decades of
> working code to prove it), it's become harder and harder to find other
> people who can. Younger programmers just sort of stare at you with a
> "I have to do what?" look. They think you are a dinosaur for working
> like that when other reasonable languages do that work for you.
> When I did little-lang.org, granted, not widely used but we used it a
> lot, it did all the memory management behind the scenes, used reference
> counting so you never had the big GC sweep that some languages used,
> worked great. And super pleasant to not have to do all that memory
> Having the languages do more for you, and put up guard rails so people
> can't make stupid mistakes, seems to be the way of the future. It's
> not my future, I love C, it does what I want and I can live with what
> it needs me to do to have working code. But I'm a dinosaur and I
> know it. I'm not trying to push C where people don't want it.
I look at this from a different perspective.
The world needs a lot of programmers these days. It takes a lot of work to
have internet-connected refrigerators push advertising, to make washers and
dryers sing about their work, to have Bixby piss off Samsung phone users,
to ensure that IoT devices are insecure, and of course to leak personally
identifying information on government web sites. This is critical work
and there just aren't enough "good" programmers to go around.
I view people that programming for Android, making web pages unusable,
and so on, as if they're using domain-specific languages. The difference
is that while many of us grew up loving domain-specific "little languages"
these languages are huge. While I'm not an expert here, I'm sure that
being an expert in the Android, IOS, Java, or WWW ecosystems involves more
"learning" than many of us had to do when we learned our craft.
A big problem with our profession is that we have no agreed on terminology
to distinguish among practitioners. A story told to me by a co-worker in
the '80s illustrates this well. Ken had gone home for Christmas with his
family. One of his uncles took him aside and asked something like "Hey,
you're a computer guy. Can you help me with this .COM and .BAT stuff?"
Ken replied "Don't have a clue what you're talking about." When Ken
related this story to me, he said "The funny thing about it was that
we both walked away thinking that the other person didn't know anything
I think some of what we're debating here is whether or not "programmers"
need to understand fundamentals. Many of us think that they do, but
we're not the ones working on a subscription model for starting your car.
I replaced my deck last summer. Had to do a lot of contractor
interviewing. I didn't choose one who said "I can do it" and showed me
photos of work he had done. I chose one who said "I can do it" and looked
around and said "You know, won't be able to tell until I get the old one
removed but I think that there some things that need fixing underneath."
Another example, because I'm also a hardware engineer. Many digital
circuit designers think that digital is an isolated domain. There was
a time a few decades ago when an analog engineer couldn't get a job.
But then there was an awakening when folks realized that everything was
analog at its core and all of a sudden "full stack hardware engineers"
were writing their own tickets. Sure, many digital designers said
"Why do I need to know this stuff? Nobody uses Rubylith anymore and
the DRC (design rule checker) software takes care of stuff for me.
Analog designers bail those people out when things don't work.
To me, a big problem with what I'll call domain-specific programmers is
that they get involved in standards and specifications and aren't trained
in how to abstract. So standards are produced that result in enlarged,
more complex domains. One of the best examples is CSS, a standard that is
too complex to be documented. I have no clue as to how many CSS properties
exist anymore. It's not cleanly designed, and of course with the addition
of each new property the interaction matrix grows exponentially. And the
increasing number of mode-switching properties is growing the number
of interaction matrices. There are literally thousands of things a CSS
"programmer" needs to know, yet people still ask question like "How do
I vertically center something" because it's still hard to do. Even the
worst programming language is orders of magnitude simpler than CSS.
But hey, CSS isn't "programming" so of course it's better.
Bottom line to me is that people with serious expertise are always going
to be needed. Someone has to design the hardware, someone has to make the
tools used to design the hardware, someone has to implement programming
languages and operating systems and all that. But that's a different
domain than what the majority of the world wants today.
next prev parent reply other threads:[~2022-02-06 18:37 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-31 20:46 [TUHS] ratfor vibe Will Senn
2022-02-01 15:37 ` arnold
2022-02-01 15:52 ` Ralph Corderoy
2022-02-01 16:58 ` Clem Cole
2022-02-01 17:02 ` silas poulson
2022-02-02 7:47 ` arnold
2022-02-03 5:47 ` [TUHS] more about Brian Rich Morin
2022-02-03 7:44 ` markus schnalke
2022-02-03 8:18 ` Rich Morin
2022-02-04 2:23 ` Adam Thornton
2022-02-04 2:34 ` [TUHS] more about Brian... [really Rust] Jon Steinhart
2022-02-04 13:07 ` Thomas Paulsen
2022-02-04 23:18 ` Dan Cross
2022-02-04 3:28 ` [TUHS] more about Brian Dan Stromberg
2022-02-04 5:11 ` Rich Morin
2022-02-04 21:22 ` [TUHS] Go vs. Rust, and etc. (was: more about Brian...) Greg A. Woods
2022-02-04 21:37 ` Richard Salz
2022-02-04 22:32 ` Steffen Nurpmeso
2022-02-04 23:05 ` Thomas Paulsen
2022-02-04 23:15 ` Seth J. Morabito
2022-02-05 1:41 ` Adam Thornton
2022-02-04 7:38 ` [TUHS] more about Brian Andy Kosela
2022-02-04 8:10 ` Steve Nickolas
2022-02-04 8:44 ` markus schnalke
2022-02-04 9:16 ` Steve Nickolas
2022-02-04 18:54 ` John Cowan
2022-02-04 19:45 ` Thomas Paulsen
2022-02-04 20:28 ` Hellwig Geisse
2022-02-04 21:03 ` Jim Capp
2022-02-04 22:30 ` Steffen Nurpmeso
2022-02-04 22:25 ` Steffen Nurpmeso
2022-02-06 0:56 ` Larry McVoy
2022-02-06 1:10 ` Will Senn
2022-02-06 4:52 ` Rob Pike
2022-02-06 4:58 ` Dan Halbert
2022-02-06 5:06 ` Will Senn
2022-02-06 6:19 ` Ed Carp
2022-02-06 6:27 ` Rob Pike
2022-02-06 6:40 ` Stuart Remphrey
2022-02-06 6:44 ` Bakul Shah
2022-02-06 19:08 ` Steffen Nurpmeso
2022-02-06 12:52 ` Ralph Corderoy
2022-02-06 13:14 ` Ed Carp
2022-02-06 14:13 ` Dan Cross
2022-02-06 14:15 ` Larry McVoy
2022-02-06 16:31 ` Warner Losh
2022-02-06 18:36 ` Jon Steinhart [this message]
2022-02-06 19:27 ` [TUHS] more about Brian... [ really GC vs malloc/free languages ] Jon Steinhart
2022-02-06 19:33 ` Warner Losh
2022-02-06 19:37 ` Jon Steinhart
2022-02-06 20:21 ` [TUHS] COFF is over there Ralph Corderoy
2022-02-06 16:16 ` [TUHS] more about Brian Brad Spencer
2022-02-08 5:22 ` Ed Carp
2022-02-03 18:57 ` [TUHS] ratfor vibe silas poulson
2022-02-04 8:26 ` arnold
2022-02-04 19:41 ` John Cowan
2022-02-10 15:18 ` Ralph Corderoy
2022-02-03 4:00 ` Will Senn
2022-02-03 4:31 ` Al Kossow
2022-02-03 5:16 ` Warner Losh
2022-02-03 20:00 ` Adam Thornton
2022-02-04 6:06 ` Ori Idan
2022-02-04 17:35 ` Adam Thornton
2022-02-04 17:44 ` Will Senn
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).