Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: sci.electronics.design
Subject: Re: OT: Linix goes politics
Date: Sun, 27 Oct 2024 15:12:33 -0700
Organization: A noiseless patient Spider
Lines: 114
Message-ID: <vfmdsj$jh1o$2@dont-email.me>
References: <vff5rp$1c1v6$1@solani.org>
 <d3gnhj1v9pt3aea029c1q1lotbm7pemrv2@4ax.com> <vfi09d$23gs$1@solani.org>
 <04jqhjdoje7mjhueqi3iusubfg3vs7plql@4ax.com>
 <i9mqhjdqclnurb4r2t7u0pin28hlt372i4@4ax.com> <vfjnte$3sq4f$1@dont-email.me>
 <dtcthjta199gkv0rvff4tbaip2qgaj0k2q@4ax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 27 Oct 2024 23:12:36 +0100 (CET)
Injection-Info: dont-email.me; posting-host="5b998538948c688c7483e57c5a315b85";
	logging-data="640056"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/WaydMkVht+YMJRritRdRF"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:OQXgruenLfjx4EcV5d+vLemb5HA=
In-Reply-To: <dtcthjta199gkv0rvff4tbaip2qgaj0k2q@4ax.com>
Content-Language: en-US
Bytes: 6017

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