Re: OT: Programming Languages

On 11/2/2024 9:54 AM, Joe Gwinn wrote:

On Fri, 1 Nov 2024 17:20:39 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:
 

On 11/1/2024 5:05 PM, Joe Gwinn wrote:

C++ is an order of magnitude more complex than C.  Even a
casual C programmer can imagine what his code will look
like after compilation.  I.e., can imagine exactly what the
CPU will be doing (ignoring the fact that the compiler will
often out-think the coder in terms of time/space efficiency).

>
I think that the complexity ratio between C and C++ well exceeds ten.

>
Possibly.  But, the cognitive load is roughly an order of magnitude.
If the developer can't "grok" (in the most literal sense of the word)
what's going on, what hope has he?

 Most certainly.  I first measured the complexity of computer languages
in the says when Ada83 first emerged in the mid 1980s, long before the
object-oriented stuff emerged.  The competition was K&R C.
 People knew that Ada was far more complicated than C, but exactly how
can one quantify such a slippery thing as "complexity" (whatever that
means)?
 In those days, we used DEC VAX/VMS computers, and DEC had
well-regarded compilers for both C and Ada83, so I measured the total
file footprint in bytes on the disk of the two compilers (and their
libraries), and Ada83 was ten times the size of the C compiler.
 Now this Ada83 compiler was unable to do anything except pass the
formal acceptance test for Ada83 compilers, while the C compiler was
in wide use, so the true ratio had to exceed ten when the Ada compiler
matured.
 C++ was emerging around then, and the Ada community was forced to
respond - their answer was Ada95.  One assumes that it is a factor
larger and more complex than Ada83, and that it too grew as it
matured.
 You are probably able to weigh the various compilers, allowing us to
quantify the offerings of today.

I'm not worried about the complexity of the compiler.  Presumably,
"qualified" developers can throw resources at that ONE product,
allowing it to evolve in correctness and efficiency.
My attention is always on the developer.  How "hard" is it for him
to wrap his head around the ideas that the language embraces?
E.g., object-based is a different mindset than procedural... but,
the mental step is a small one; you just think of nouns and verbs
instead of a sequential "actor's narrative".
[Object-oriented, OTOH, drags in many more issues -- polymorphism,
inheritance, etc.]
Ignoring *how* the compiler implements all of these things, it's
not a huge stretch to understand them conceptually.  Constructors,
destructors, member functions, private data, etc. aren't really
that hard to understand.
LISP's lists are even simpler -- yet the step to embracing them
seems to be a lot bigger for most folks.

It took a while for compilers to handle mutual-exclusion
functions/commands correctly - in most architectures, one must block
interrupts for this to work correctly.  It's a long story, and is a
good reason to work in assembly for that.

>
With modern processors, there are considerably more pitfalls than that.
Most "programmers" haven't a clue as to what a "barrier" is nor when
(or why!) to use them.

 These programmers would likely hurt themselves if allowed to use a hex
calculator without close supervision.  So better find better
programmers.

The hardware's evolution is making things like the single-threaded
vs. multi-threaded mindset adjustment look trivial.  You'll see
more folks relying on black box products from third parties on
which to develop their products -- good luck getting THOSE
defined and debugged!  Like having one big hardware component
in the middle of your design with lots of pins, a many thousand
page datasheet -- but lots of missing or simply "typ" specifications
in the parameterization.

And, as hardware has become more featureful, the needs for talking
to the iron UNAMBIGUOUSLY are increasing, constantly.  Open door
for obscure, intermittent bugs...

 Sounds like a good argument for running machine code right on the iron
- no annoying obscuring layers.

Ah, but the iron is NOW the problem!  Out-of-order execution, speculative
execution, i&d caches, multiple cores, *real* MMUs, TLBs, etc.  The days
when you could hack together a "simple" RTOS in a few weekends are past
(for all but the simpler machines) and predict performance "on paper".
Now, there is considerably more machine state in play that affects
that calculus:  is the cache warm?  cold?  How many lines do
you evict before opting to flush the whole thing?  When for a TLB
shootdown vs. expecting the other core(s) to purge theirs?  How
*long* will my core have to wait for the other cores to get back
into sync?  (how do I know *what* they have cached while I've
been busy?)
You will be forced to *rely* on "abstraction layers" because
you won't be stuck with "mere mortals" developing your code!