dead programming languages

Or maybe Ada, but definitely not C++.

John

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

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.

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

Sylvia.

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

CH

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

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.

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.

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.

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.

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

Extra hardware cost???

Today CPU time is cheap and most embedded controllers are way faster than they need to be to do the job (this was not always true).

Checks and asserts can help in debugging code but if any of them have side effects then it can make for unwelcome interesting behaviour when the final optimised version is created.

The standard trick is to develop it with all the range checking on and some form of postmortem call stack dump if it ever crashes and then disable all the checking in production code but leave the post mortem stack traceback and keep a copy of the map file and production code.

That way with a bit of luck you can identify and eliminate any in field failures reliably. This presupposes you have a way to communicate with the embedded firmware and do a soft reset to regain control.

Unlike hardware which wears out with time software should become more reliable with accumulated runtime in different environments.

For embedded programming? What choice do you have? Unless you're planning to write your own compiler, you use the available compilers for the IC and you learn the embedded IC's dialect for that language.

Faster processor, more memory.

Sylvia.

It is not just about the cost of hardware. It more about doing

*the same* thing done before - with bloated resources. Which is sort of forgivable, however if it were not the bloat so much more can be done using today's CPU/memory resources than virtually everyone (well, except me :) does. Talk about *gigabytes* of RAM and getting a video player complain about having insufficient memory... (yes, I had that not long ago, on windows 10 with 8G RAM playing a 2G mkv file....). And if it were only that, this is just the tip of the iceberg. Everyone is hasty to just sell something, as long as people can't see to what extent is is not even half baked they just go ahead.

------------------------------------------------------ Dimiter Popoff, TGI

0.01% faster... 10 bytes more memory. WTF???

Anytime someone talks about "bloat" in software, I realize they don't program.

It's like electric cars. The only people who complain about them are the people who don't drive them.

LOL, you should work on your realization abilities. You have never communicated with a person who has programmed more than I have. Checking who you are conversing with is also a good idea before saying something stupid again.

Yikes. Most of the embedded products that I coded were in assembly.

Most type conversions took zero nanoseconds.