All:
I humbly offer - as a meditation of sorts - an excerpt from the
esr.ibiblio.org blog authored by Eric Raymond, on 2017-1113, in a series
discussing possible paths for transitioning out of C++. No point to
push, here: perspective, is all.
"...
"Ever since the very earliest computer languages it’s been
understood that every language design embodies an assertion about the
relative value of programmer time vs. machine resources. At one end of
that spectrum you have languages like assembler and (later) C that are
designed to extract maximum performance at the cost of also pessimizing
developer time and costs; at the other, languages like Lisp and (later)
Python that try to automate away as much housekeeping detail as
possible, at the cost of pessimizing machine performance.
In broadest terms, the most important discriminator between the ends
of this spectrum is the presence or absence of automatic memory
management. This corresponds exactly to the empirical observation that
memory-management bugs are by far the most common class of defects in
machine-centric languages that require programmers to manage that
resource by hand.
A language becomes economically viable where and when its
relative-value assertion matches the actual cost drivers of some
particular area of software development. Language designers respond to
the conditions around them by inventing languages that are a better fit
for present or near-future conditions than the languages they have
available to use.
Over time, there’s been a gradual shift from languages that require
manual memory management to languages with automatic memory management
and garbage collection (GC). This shift corresponds to the Moore’s Law
effect of decreasing hardware costs making programmer time relatively
more expensive. But there are at least two other relevant dimensions.
One is distance from the bare metal. Inefficiency low in the
software stack (kernels and service code) ripples multiplicatively up
the stack. This, we see machine-centric languages down low and
programmer-centric languages higher up, most often in user-facing
software that only has to respond at human speed (time scale 0.1 sec).
Another is project scale. Every language also has an expected rate
of induced defects per thousand lines of code due to programmers
tripping over leaks and flaws in its abstractions. This rate runs higher
in machine-centric languages, much lower in programmer-centric ones with
GC. As project scale goes up, therefore, languages with GC become more
and more important as a strategy against unacceptable defect rates.
... "
--
For group guidelines, visit
http://www.rbase.com/support/usersgroup_guidelines.php
---
You received this message because you are subscribed to the Google Groups "RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
