[TUHS] more about Brian... [ really GC vs malloc/free languages ]

[Jon Steinhart]

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
> management.
>
> 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
about computers."

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.

Jon