Sujet : Re: OT: Linix goes politics
De : joegwinn (at) *nospam* comcast.net (Joe Gwinn)
Groupes : sci.electronics.designDate : 27. Oct 2024, 22:52:46
Autres entêtes
Message-ID : <dtcthjta199gkv0rvff4tbaip2qgaj0k2q@4ax.com>
References : 1 2 3 4 5 6
User-Agent : ForteAgent/8.00.32.1272
On Sat, 26 Oct 2024 14:45:07 -0700, Don Y
<
blockedofcourse@foo.invalid> wrote:
On 10/26/2024 2:19 PM, Joe Gwinn wrote:
It's 9000 languages. This was discussed on SED in February 2023. My
posting on the subject is "Re: dead programming languages" posted on
23 February 2023. This is the posting that went into ecosystems and
other practicalities.
>
Most languages just change the syntax of operations.
>
OTOH, many introduce (or, promote to first-class notions)
techniques and mechanisms that are tedious to implement
in other languages.
In evolution, all's fair, even if it isn't squishy critters that are
evolving.
E.g., support for concurrency has to be added to most
languages; there are no notions of having other processes
running alongside "yours"; thus, no mechanisms for exchanging
information with them, no mechanisms to ensure competing
accesses to data are atomic, etc.
Concurrency is far older than any computer language save assembly.
Hardware did concurrency before that.
In the old days, we did multiprocessing, with multiple processors
sharing a backplane with multiple processors.
In advanced cases, there would also be a memory board on one of the
backplane slots, where data used by all could be retained - the
blackboard model was common.
Later, threads were invented, this being concurrent threads of control
within the same process and thus address space. Etc.
And realtime operating systems were basically clouds of independent
but interacting finite state machines. As was the hardware being
controlled. The mapping between hardware and software FSMs needed to
be clean, or things got pretty awkward.
In none of these cases were the computer languages expected to have
any critical role in handling and implementing concurrency.
Which is good because they were not very good at concurrency.
To summarize, the software folk had no idea how hardware actually
worked, and the hardware folk didn't speak software.
Imagine using C (or any other programming language) to
*interact* with a relational database... how many errors
would a user likely make by failing to address the issues
that SQL hides?
Databases are a swamp of their own, and are far too slow and
unreliable for embedded realtime. It's very common to use
N-dimensional hash tables for storage and access of random data. Hash
table lookup is a O[1] (constant-time ) operation that does not
degrade as data accumulates.
Joe Gwinn