dead programming languages...

[John Larkin]

https://en.wikipedia.org/wiki/Timeline_of_programming_languages


Now I\'m told that we should be coding hard embedded products in C++ or
Rust.

 

[John Walliker]

On Wednesday, 22 February 2023 at 19:05:37 UTC, John Larkin wrote:

https://en.wikipedia.org/wiki/Timeline_of_programming_languages


Now I\'m told that we should be coding hard embedded products in C++ or
Rust.

Or maybe Ada, but definitely not C++.

John

 

[Don Y]

On 2/22/2023 4:00 PM, John Walliker wrote:
> Or maybe Ada, but definitely not C++.

Ada will sorely limit the talent you can draw. Who cares
about the language\'s features if you can never get a
finished product from it!

[Ditto the many \"fad\" languages that may be \"gone\"
before the product\'s completely implemented!]

I use a C++ like syntax for code written entirely in C
(some syntax enhancements to increase comprehension
that are strictly NOT portable!) as it helps others
relate to what the code is trying to express.

ANYONE can learn practically ANY programming language.
And, in most projects, you\'ll likely have to know \"a few\"
to completely implement the product (unless it\'s a
relatively limited application) because different languages
express different concepts better or worse than others.

The important thing is getting a broad-based understanding
in algorithms and their consequences. And, realizing that,
for most problems, there are cleverer ways of implementing
them than you\'ve considered or will likely consider! Not
because of \"language tricks\" but, rather, because of the
inherent nature of the problem that you\'ll often miss. If
you\'ve not thought along those lines, you\'re likely
Just Another Coder (JAC? should I coin the term? :> )

Having a good understanding of the architecture of the (likely)
hosting processor also separates the men from the boys.

Knuth\'s tAoCP (et al.) don\'t use any \"modern\" language that sees
use outside of his texts. Yet, damn near every professional
has \"learned\" it -- if only to understand the algorithms
therein described. Clearly. (Note how the language of
choice that writers have used, over the years, is largely
irrelevant in the quality of the material they present)

 

[Phil Hobbs]

On 2023-02-22 19:06, Don Y wrote:

On 2/22/2023 4:00 PM, John Walliker wrote:
Or maybe Ada, but definitely not C++.

Ada will sorely limit the talent you can draw.  Who cares
about the language\'s features if you can never get a
finished product from it!

[Ditto the many \"fad\" languages that may be \"gone\"
before the product\'s completely implemented!]

I use a C++ like syntax for code written entirely in C
(some syntax enhancements to increase comprehension
that are strictly NOT portable!) as it helps others
relate to what the code is trying to express.

ANYONE can learn practically ANY programming language.
And, in most projects, you\'ll likely have to know \"a few\"
to completely implement the product (unless it\'s a
relatively limited application) because different languages
express different concepts better or worse than others.

The important thing is getting a broad-based understanding
in algorithms and their consequences.  And, realizing that,
for most problems, there are cleverer ways of implementing
them than you\'ve considered or will likely consider!  Not
because of \"language tricks\" but, rather, because of the
inherent nature of the problem that you\'ll often miss. If
you\'ve not thought along those lines, you\'re likely
Just Another Coder (JAC?  should I coin the term?  :> )

Having a good understanding of the architecture of the (likely)
hosting processor also separates the men from the boys.

Knuth\'s tAoCP (et al.) don\'t use any \"modern\" language that sees
use outside of his texts.

So you program everything in TeX and MIX assembler?

(Don L used to code a whole lot of stuff directly in Postscript, iirc.)

Cheers

Phil Hobbs


--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

 

[bitrex]

On 2/22/2023 2:05 PM, John Larkin wrote:

https://en.wikipedia.org/wiki/Timeline_of_programming_languages


Now I\'m told that we should be coding hard embedded products in C++ or
Rust.

User-defined strong types that enforce their own usage are probably
worth the price of admission alone; e.g. quantities in newton/meters
should be of type NewtonMeters and foot/pounds should be FootPounds, and
casually performing operations with the two causes a compile error.

 

[Sylvia Else]

On 23-Feb-23 6:05 am, John Larkin wrote:

https://en.wikipedia.org/wiki/Timeline_of_programming_languages


Now I\'m told that we should be coding hard embedded products in C++ or
Rust.

But can you afford the memory and time overheads inherent in run-time
range checks of things like array accesses?

Sylvia.

 

[Don Y]

On 2/22/2023 7:47 PM, Phil Hobbs wrote:

Knuth\'s tAoCP (et al.) don\'t use any \"modern\" language that sees
use outside of his texts.

So you program everything in TeX and MIX assembler?

Did you miss \"don\'t use any \'modern\' languages that sees use
outside of his texts\"?

> (Don L used to code a whole lot of stuff directly in Postscript, iirc.)

IIRC, it\'s Turing complete. Just impractical for most \"normal\" uses.

[And, in an embedded context, would be difficult to verify whether
or not the code wouldn;\'t run out of resources in some situations]

 

[Don Y]

On 2/22/2023 8:02 PM, bitrex wrote:

User-defined strong types that enforce their own usage are probably worth the
price of admission alone; e.g. quantities in newton/meters should be of type
NewtonMeters and foot/pounds should be FootPounds, and casually performing
operations with the two causes a compile error.

Unless you\'d overloaded a cast operator to do that for you.

[I tried building a \"units\" library that allowed arbitrary
combinations of units (types) via overloaded operators.
It was wholly impractical.]

 

[Don Y]

On 2/22/2023 8:15 PM, Sylvia Else wrote:

But can you afford the memory and time overheads inherent in run-time range
checks of things like array accesses?

That;s a small cost. Modern tools can often make (some) of those
tests at compile time.

The bigger problem with many newer languages is that they rely heavily
on dynamic memory allocation, garbage collection, etc.

And, most of the folks I\'ve met can\'t look at a line of arbitrary
code and tell you -- with *confidence* -- that they know what it
costs to execute, regardless of how comfortable they are with
the language in question.

Even C is becoming difficult, in some cases, to \'second guess\'.
And, ASM isn\'t immune as the hardware is evolving to provide
performance enhancing features that can\'t often be quantified,
at design/compile time.

E.g., I rely on RPCs extensively in my current design. But, what
will it cost to marshall a given set of arguments, schedule the
packet for delivery, accept it at the service end, run the stub,
pack up results -- and ship them back to the caller/client?
How will this change as the workload seen by a service increases?
Or, the number of clients -- of potentially different services -- on
a particular node increases?

And, while the interface looks like a traditional function call,
the developer now has to consider the possibility that the
service may be unavailable -- even if it WAS available on the
previous line of code! (developers have a tough time thinking
in pseudo-parallel, let alone *true* parallelism)

So, the language becomes less of an issue but the system design
and OS features/mechanisms (the days of toy RTOSs are rapidly coming
to an end)

 

[bitrex]

On 2/23/2023 11:33 AM, John Larkin wrote:

On Thu, 23 Feb 2023 14:15:28 +1100, Sylvia Else <sylvia@email.invalid
wrote:

On 23-Feb-23 6:05 am, John Larkin wrote:
https://en.wikipedia.org/wiki/Timeline_of_programming_languages


Now I\'m told that we should be coding hard embedded products in C++ or
Rust.


But can you afford the memory and time overheads inherent in run-time
range checks of things like array accesses?

Sylvia.

On a Raspberry Pi Pico? I think not.

In a hard embedded product, what do you do when a range check fails?

I feel like once a \"hard embedded\" product has enough degrees of freedom
in its inputs to make range check failures a likely occurrence, one
isn\'t really designing a \"hard embedded\" thing anymore.

I\'m curious what kind of designs these are where people have to do so
many range checks, like I\'ve rarely been concerned a 10 bit i2c ADC is
ever going to accidentally return a value of 1024 or something and then
need to accommodate that possibility in my code.

 

[Don Y]

On 2/22/2023 8:25 PM, Don Y wrote:

On 2/22/2023 8:02 PM, bitrex wrote:
User-defined strong types that enforce their own usage are probably worth the
price of admission alone; e.g. quantities in newton/meters should be of type
NewtonMeters and foot/pounds should be FootPounds, and casually performing
operations with the two causes a compile error.

Unless you\'d overloaded a cast operator to do that for you.

[I tried building a \"units\" library that allowed arbitrary
combinations of units (types) via overloaded operators.
It was wholly impractical.]

Note that my \"Calculation\" (utility) does this -- but with explicit
code to examine the types of each argument in each calculation,
accumulating a string of units (numerator, denominator) for the
results:
5 feet x 14 inches = XXX area (length*length)
XXX area x 3 yards = YYY volume (length*length*length)
YYY volume / 99 seconds = ZZZ flow rate (length*length*length/time)
etc.

The advantage this has is that you can mix units that aren\'t
strictly related.

 

[Clifford Heath]

On 23/02/23 14:02, bitrex wrote:

On 2/22/2023 2:05 PM, John Larkin wrote:
https://en.wikipedia.org/wiki/Timeline_of_programming_languages

Now I\'m told that we should be coding hard embedded products in C++ or
Rust.

User-defined strong types that enforce their own usage are probably
worth the price of admission alone; e.g. quantities in newton/meters
should be of type NewtonMeters and foot/pounds should be FootPounds, and
casually performing operations with the two causes a compile error.

On the contrary, the language should automatically provide the
appropriate conversions.

CH

 

[Don Y]

On 2/22/2023 9:00 PM, Clifford Heath wrote:

On 23/02/23 14:02, bitrex wrote:
On 2/22/2023 2:05 PM, John Larkin wrote:
https://en.wikipedia.org/wiki/Timeline_of_programming_languages

Now I\'m told that we should be coding hard embedded products in C++ or
Rust.

User-defined strong types that enforce their own usage are probably worth the
price of admission alone; e.g. quantities in newton/meters should be of type
NewtonMeters and foot/pounds should be FootPounds, and casually performing
operations with the two causes a compile error.

On the contrary, the language should automatically provide the appropriate
conversions.

I disagree, esp for anything beyond simple types. (i.e., promote a
char to an int and hope the developer truly understands how signedness
is handled, etc.)

Pascal?

Requiring an explicit cast reassure me (the NEXT guy looking at
the code) that the developer actually intended to do what
he\'s doing in the way he\'s doing it -- even if it \"makes sense\".
This is what I liked most about C++ (overloading operators
so the *syntax* was clearer by hiding the machinery -- but not
eliminating it!)

How many times do you see an int being used as a pointer?
Is it *really* intended to be a pointer in THIS context?
I get tired of having to chase down compiler warnings
of this sort of thing in inherited code: \"If you WANT
it to be a pointer, then explicitly cast it as such!
Don\'t just count on the compiler to *use* it as one!\"

 

[Ricky]

On Wednesday, February 22, 2023 at 2:05:37 PM UTC-5, John Larkin wrote:

https://en.wikipedia.org/wiki/Timeline_of_programming_languages


Now I\'m told that we should be coding hard embedded products in C++ or
Rust.

I don\'t know about calling languages dead, but maybe morbidly obese?

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

 

[Ricky]

On Wednesday, February 22, 2023 at 7:06:53 PM UTC-5, Don Y wrote:

On 2/22/2023 4:00 PM, John Walliker wrote:
Or maybe Ada, but definitely not C++.
Ada will sorely limit the talent you can draw. Who cares
about the language\'s features if you can never get a
finished product from it!

[Ditto the many \"fad\" languages that may be \"gone\"
before the product\'s completely implemented!]

I don\'t know about Ada, but VHDL is based on Ada and is a very productive language.

At the other extreme, I use Forth, which is not remotely popular, but is very effective.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

 

[Ricky]

On Wednesday, February 22, 2023 at 10:15:36 PM UTC-5, Sylvia Else wrote:

On 23-Feb-23 6:05 am, John Larkin wrote:
https://en.wikipedia.org/wiki/Timeline_of_programming_languages


Now I\'m told that we should be coding hard embedded products in C++ or
Rust.

But can you afford the memory and time overheads inherent in run-time
range checks of things like array accesses?

You mean as opposed to programs randomly failing in the field?

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

 

[Jan Panteltje]

On a sunny day (Wed, 22 Feb 2023 11:05:30 -0800) it happened John Larkin
<jlarkin@highlandSNIPMEtechnology.com> wrote in
<3opcvh111k7igirlsm6anc8eekalofvtcj@4ax.com>:

https://en.wikipedia.org/wiki/Timeline_of_programming_languages


Now I\'m told that we should be coding hard embedded products in C++ or
Rust.

Cplushplush is a crime against humanity
C will do better
But asm is the thing, it will always be there
and gives you full control.
It is not that hard to write an integer math library in asm..
And even 32 bit integer will take care of most things here on earth.

The problem is that many so called \'coders\' know shit about hardware
so need bloat as a cover up so to speak.
The sickening idea of operator overloading in C plushplush.... comes to mind.
I use linked lists in C in many of my programs, takes care of all \'object oriented\' stuff.
Nothing I have not been able to do.

Where the madness will go? Look at Microsoft Outlook email
If you lose 15 minutes a day using that stuff (as opposed to 1 second with pop email)
advanced math says it cost you 365 * 15 = 5475 minutes a year, or 81.25 hours a year,
or 10 working days!!!!

An other failure of the US capitalist system, controlled by companies that suck you
for time and money with ever worse products, selling snake oil.
There is an opening there for competition... But the fake over valued US dollar and its Mafia like control
\'protection\' in this world is used to kill that competition.
Else just blow up the oil pipeline like North-stream right?
Creeps!!!
I remember (and do have) a very old eeePC 701, it was a new thing, came with Linux pre-installed,
Its still working! but the next model came with MS windows...
Market control, where are they now...

The nukes will fall, its nature.
One ant heap against the other, may the best one win, its EVOLUTION.
Could be the ants that win though, so be prepared.

https://rageagainstwar.com/#Coalition
will it go the way it did during the Vietnam war?
Youth revolting?

I remember that evening in those day: I was outside and saw a falling star
You are supposed to do a wish, so I wished for an end to that war.
A few days later it was over...
cause and effect or do we know the future?
Had more experiences like that
There are many explanations...

 

[Sylvia Else]

On 23-Feb-23 4:01 pm, Ricky wrote:

On Wednesday, February 22, 2023 at 10:15:36 PM UTC-5, Sylvia Else wrote:
On 23-Feb-23 6:05 am, John Larkin wrote:
https://en.wikipedia.org/wiki/Timeline_of_programming_languages


Now I\'m told that we should be coding hard embedded products in C++ or
Rust.

But can you afford the memory and time overheads inherent in run-time
range checks of things like array accesses?

You mean as opposed to programs randomly failing in the field?

It\'s not as if the checks make a program work properly, they only make
the failure mode clearer. If an improper access occurs frequently, then
this would likely show up during development/testing. If it occurs
rarely, then you\'ll still see what look like random failures in the field.

Whether it\'s worth the extra cost of hardware will depend on how many
incarnations there are going to be.

Sylvia.

 

[Martin Brown]

On 23/02/2023 03:02, bitrex wrote:

On 2/22/2023 2:05 PM, John Larkin wrote:
https://en.wikipedia.org/wiki/Timeline_of_programming_languages


Now I\'m told that we should be coding hard embedded products in C++ or
Rust.

Maybe C++ provided that you only use a restricted subset of the language
much like the Spark dialect of High Integrity Ada. Modula2 came close to
being ideal (particularly back in its brief heyday) but never took off.
Close enough to bare metal to do device drivers but with strong typing.

The one that used to drive me crazy was hardware engineers who mapped
DACs and ADCs onto the least significant bits of a register - requiring
significant code changes when a new DAC/ADC with more bits came along.

User-defined strong types that enforce their own usage are probably
worth the price of admission alone; e.g. quantities in newton/meters
should be of type NewtonMeters and foot/pounds should be FootPounds, and
casually performing operations with the two causes a compile error.

Unfortunately average to bad programmers will get around such strong
typing restrictions by the random application of casts
(until it compiles)

Programs should where possible use one consistent set of units
throughout unless their task is converting between different units.

I recall someone once ordered a gross of grosses due to their odd
misunderstanding of the ordering system and their mistake only became
apparent when a 40T trailer arrived instead of the usual van.

--
Martin Brown

 

[Ricky]

On Thursday, February 23, 2023 at 3:51:26 AM UTC-5, Sylvia Else wrote:

On 23-Feb-23 4:01 pm, Ricky wrote:
On Wednesday, February 22, 2023 at 10:15:36 PM UTC-5, Sylvia Else wrote:
On 23-Feb-23 6:05 am, John Larkin wrote:
https://en.wikipedia.org/wiki/Timeline_of_programming_languages


Now I\'m told that we should be coding hard embedded products in C++ or
Rust.

But can you afford the memory and time overheads inherent in run-time
range checks of things like array accesses?

You mean as opposed to programs randomly failing in the field?

It\'s not as if the checks make a program work properly, they only make
the failure mode clearer. If an improper access occurs frequently, then
this would likely show up during development/testing. If it occurs
rarely, then you\'ll still see what look like random failures in the field..

If you have checks in place, you will know something about what failed and where to look in the code.

Whether it\'s worth the extra cost of hardware will depend on how many
incarnations there are going to be.

Extra hardware cost???

--

Rick C.

-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209