Re: OT: Linix goes politics

On 10/27/2024 2:52 PM, Joe Gwinn wrote:

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.

I object to the novel-for-the-sake-of-novelty approach that seems
to be so common.
OTOH, object-based languages, list processing, *string* processing,
etc. all have suitable application domains where they excel over
other approaches (of course, any language that is Turing complete
can be used to solve any problem expressible in another such
language).

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.

But HLLs have not embraced it, relying on "libraries", helper
routines and other mechanisms to provide it to the developer.

Hardware did concurrency before that.
 In the old days, we did multiprocessing, with multiple processors
sharing a backplane with multiple processors.

It was not uncommon to have two processors sharing a store.
Some of the old MCUs were very easy to do SMP -- but, we
didn't call it that, back then.

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.

The flaw, there, is that it doesn't allow for selective access
to specific data.  Its akin to a monolithic binary that makes
everything available to everything else.  Fine for DESIRED
sharing; abysmal in preventing UNDESIRED sharing!

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.

But, now hardware *presents* multiple execution engines (cores,
hardware contexts) so languages that don't address this environment
force the developer to adopt piece-meal approaches to solutions.

To summarize, the software folk had no idea how hardware actually
worked, and the hardware folk didn't speak software.

But, that's because most EE programs were hardware and most CS
programs were software.  Few folks had a foot in each camp.
(my degree was exactly thus)

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.

That, again, depends on the timescales involved.  Real-time need
not be "real fast".

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.

But, you can wrap that in a DBMS context so the developer thinks
he is just dealing with yet-another-database.
I use an RDBMS in my (real-time) system but acknowledge the
variance in query (and other operator) outcomes.  So, ask for
the data *before* needing it.  Or, ask *when* needed if you
are sure the result will be available before your deadline.
[A database makes it SO much easier to deal with "data" as it
forces structure onto the data; no parsing of text/binary
files... let the DBMS ensure the integrity of its contents
so the fact that the data CAME from the DBMS vouches for its
integrity:  "Is this datum that I fetched a valid *date*?
Let me write a routine to check..."]

Joe Gwinn