Posts by fg_swe 1478 publicly visible posts • joined 20 Nov 2021
Please also look at
WIRTH
HOARE
BAUER
and all the other Algol men. They knew about the need for memory and type safety for decades, if you listen to their speeches. Apparently they were not too much interested in drumming for their ideas, so applied computer science degraded into "free" Unix, instead of the much more robust Algol world.
Not biologically, but certainly from an engineering point of view:
https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/
Tony says that index checking should be done at runtime and that it is a very real problem in the world of real FORTRAN programs. What I infer from this is that software engineers in general are not perfect. Humans they are, not gods.
Also, Algol was already much better than C is to the present day. Cheap won out over proper engineering.
C and C++ should be phased out of any software engineering project which is exposed to external input and/or security-critical.
In other words C and C++ are shoddy engineering, we already had it better in the Algol Mainframes.
Here are the details: http://sappeur.ddnss.de/Sappeur_Cyber_Security.pdf
..nuclear power has the lowest rate of victims per TWh of energy generated.
You can see why this is the case:
1.) Add up all the victims of Harrisburg, Chernobyl, Fukushima, Windscale,...
2.) Add up all the people burned to death in oil platform explosions, killed in coal mines, got cancer from the billions of tons of ash blown out by coal power plants.
3.) Add up all the people who died of the toxic fumes from solar cell production. Add the folks who died from the coal plants which provided the energy to create the solar cells.
Due to the extensive safety precautions, nuclear power is ALREADY the safest energy source.
https://www.zmescience.com/other/feature-post/safest-forms-of-energy-05022022/
https://de.wikipedia.org/wiki/Braunkohle (we have enough to power all of our needs for the next 100 years)
https://de.wikipedia.org/wiki/Synthesegas
https://de.wikipedia.org/wiki/Brutreaktor (burn the U238, which is 100x more abundant)
https://de.wikipedia.org/wiki/Fischer-Tropsch-Synthese
https://de.wikipedia.org/wiki/Kernkraftwerk_THTR-300
https://en.wikipedia.org/wiki/Underground_coal_gasification ( lots of coal beneath the north sea)
If only we used more than two brain cells, we could show the middle one to the commies and Mohammedic Oil Tyrants. I guess this is what happens when you betray your king.
https://de.wikipedia.org/wiki/Wilhelm_II._(Deutsches_Reich)
"Coal is evil"
"Uranium is evil"
"glue yourself to the autobahn to protest coal"
Meanwhile the COMINTERN power centers Moscow and Beijing build out their coal and uranium power generation. In parallel, they have accumulated the best part of the world's manufacturing capability. Manufacturing needs cheap energy. Also, the NATO banksters have enabled the selling of virtually ANY high tech the communists need.
Germany is especially stupid, KGB Colonel PUTIN has us at the balls after the MethanWende (sold as "EnergieWende" by our GREENIES).
Well done KGB, you are true masters of messing with other people's minds. May your wickedness one day be your downfall.
According to my understanding, yes.
Their customers can save manpower on setting up and running database servers.
The real challenge of designing schemas and optimizing queries will be left to the customer, I assume. Maybe they will provide a modicum of help with EXPLAIN PLAN...
Its all part of the Cloud Hype, where you hand over your data to people you have never personally met. What could possibly go wrong ?
"Even Russia has their own homegrown architecture, but probably are suffering such a brain drain from Putin's stupidity lately that effort will never advance any further."
If you knew a bit about ELBRUS, you would figure the opposite.
First, it is used mostly in olive green applications and secondly they are now forced to substitute American CPUs. Olive green gets more funding due to obvious and the second might be even more important to do.
Even though their elite has made very serious mistakes, they have figured that AI controlled technology is of strategic importance. In addition to the strategically important tech they build since U2s invaded their airspace.
Maybe it is of little use to compete in the traditional applications. But now imagine a very low power processor that will be powered by a small solar cell on the same chip. A device that costs 3cent/piece and can be attached to each tree in a forest, monitoring its vital parameters. It would run at very low speed and consume very little power.
Maybe this is a contrived example, but you get the idea.
There might be unheard-of niches were even tiny license costs are too much. In this space RISC V might be the right solution.
It is not really clear which markets they want to address. Auto/Aerospace/Rail is very much different from computing or networking. The bread-and-butter control unit has integrated SRAM in the range of a few Mbytes; while computing uses thousands of times more external DRAM. Control units need very specialized A/D, D/A, pwm, watchdog, crypto peripery. Must all be on a single chip or it will be too big and too expensive.
Then you need support from Lauterbach (debugger) and Vector Informatik (AUTOSAR operating system) to be viable in automotive.
I suspect STM, NXP, Infineon, TI, Japan are so much entrenched in control units that MIPS does not stand a chance as a newcomer.
Computing and automotive are very much different, even though they sometimes use the same CPU cores (ARM and PowerPC, VAX come to mind).
Time and again, a lack of memory safety creates plenty of exploitable bugs.
Here is a systematic fix, as opposed to band-aids: http://sappeur.ddnss.de/Sappeur_Cyber_Security.pdf
And no, there are NO perfect programmers/software engineers who will write bugfree code.
Millions of LOC are almost impossible to secure. seL4 is like a frigate with 20 compartments - a single torpedo can only take out one compartment, but the ship stays afloat.
For example, a bug in the TCP stack of an seL4 system does not pwn the entire system. Your data stays secure, as it is decrypted in a different compartment. With Linux, it is Game Over.
Windows is even worse, as they run a c**pload of stuff in the Kernel, including font parsing+rendering, graphics rendering, several network stacks, a network file system and whatnot.
Likewise, Memory Safe Languages will contain the effects of programming errors in about 70% of cases. With C or C++, a single programming error typically hands the kingdom to the intruder. See http://sappeur.ddnss.de/Sappeur_Cyber_Security.pdf
In the past I have created a moderately complex program which performs statistics on CSV files.
Program A uses Java Standard Library, does lots of "new String()"
Program B uses Sappeur strings, ("new String_16()"). They are refcounted and will be reclaimed in (pseudo) realtime.
The findings were:
F1) If the Java program should be competitive in speed with B, it needs 2x the RAM of B.
F2) If the Java program is only allowed to use 1.2x the RAM of B, it will become very slow (as compared to B), due to lots of GC runs.
That test was done on Solaris in 2011 with the then current Java version.
I should redo the experiment to see whether the Java GC has become better.
Regarding your argument "it will only create virtual memory load" - that is still serious system load, as the memory must be swapped to disk even if unused. Whether it can actually be swapped out depends highly on the allocation patterns. A single active object per page can thwart the paging to disk.
If your application cannot kill anybody and does not store anything of much value(say Facebook), then maybe it is justified to use a dynamically typed language.
In automotive, aerospace, trains and medical machinery you better use as much type safety you can get.
https://www.adacore.com/uploads/customers/CaseStudy_Eurofighter.pdf
Apparently, many FORTRAN programs have issues with index errors, according to Sir Tony Hoare. Index errors are considered a typing problem, too.
Just looked at the paper you reference. They claim PASCAL would be unsuitable for numerical processing, process control and operating systems.
I once wrote a planetary simulation in Turbo Pascal and found it perfectly fine for this purpose. The compiler was lightning fast on a 16Mhz 80286 (three seconds for a project of 1000 LOC).
HP wrote the MPE OS kernel in a Pascal dialect and the result "mini mainframe" went on to be highly successful in business settings such as corporate email, manufacturing management, inventory mgmt etc.
Currently I write auto control unit code in C and I see no reason why we could not use Pascal or Ada as a replacement for C. Pascal would be an improvement, because one can specify value domains for variables. This has to be grafted on top of C (using special comments), if you want to use static checkers for variable domains.
Arianespace, Leonardo and many others use Ada for aerospace control units and the issues they had were related to project execution (not doing a HIL Test for the Airanve V first flight, for example). Never heard they had issues with the language.
The lack of index checking in C is also a very real problem in real-world auto control units. Can be fixed to some degree using PC-Lint and PolySpace. Is also "fixed" by memory protection units. At least you can contain the cancer...
Conceptually, Sappeur is very similar to C++, except for the unsafe stuff such as unsafe casts, pointer arithmetic and so on. The good things such as stack allocation, RAII, destructors, ARC smart pointers, complex aggregate data structures are preserved.
Transforming Sappeur code to C++ is straightforward.
Please see page 7 of the following for an example:
http://sappeur.ddnss.de/SAPPEUR.pdf
Real-world programs are full of memory management errors and you should better have a type system plus runtime checking, which will find these errors for the developer.
valgrind and purify are only partial fixes, as they cannot find the problems which come from "creative input", as long as such input is not generated by an intelligent and well-resourced test engineer.
Also, valgrind will slow down by a factor of 100 and therefore does not expose multithreading issues under high load.
Many software developers are of the myopic opinion that C and Unix are the pinnacle of practical computer science. Because that is what they heard in a slogan.
These folks are too lazy to do some research into the history of computers and software. They would find interesting systems such as the Algol Mainframes, HP MPE, S/360 and successors, Modula/2, Oberon, LISP workstations, Smalltalk.
S/360-derived computers are still a mainstay of financial and business transaction processing. The Algol mainframes had some sort of type safety in their instruction set. MPE was a very successful "small mainframe" written in a Pascal variant. Oberon has many great ideas and is very elegant.
Knowing history is important for software engineers, too.
Sappeur is adding value by making your C++ code memory safe. Including multi-threaded code !
And it is indeed a compiler which performs type checking and has a very special type system. It just does not have an optimizer and a machine code generator of its own.
Compared to Java, Sappeur programs are lean and efficient. For example, you can write small Unix command line utilities with Sappeur. You cannot do this in Java, because of the excessive startup time of Java programs.
Some people say you need a dedicated generics mechanism, similar to C++ templates.
This is not true. A proper macro processor such as m4 can (for all practical purposes) do the same. Debugging is much easier, as the "instantiated" code can/will exist in a file to be inspected with a standard editor. No insane, cryptic C++ template error messages.
Not my invention, saw it when I worked for D'Assault on CATIA.
As with every nontrivial technical endeavor, one should apply the KISS principle. Demonstrate your innovative idea in a way that is as straightforward as possible. You can always perfect it later.
What does this mean ?
Don't use the gcc infrastructure, instead generate C or C++ code and let existing compilers do the optimization and architecture-specific work. Debugging a compiler that emits C++ is way much easier than debugging ASTs and machine code. As an added benefit, your compiler will be able to run on almost any CPU, because almost any CPU has a C++ compiler.
This is what I did here
http://sappeur.ddnss.de/
The innovative aspect is that this language is a memory safe C++ variant. All the goodies of C++ plus single- and multi-threaded memory safety, due to a type system which "knows" of single- and multi-threaded sections of the program.
There exist Eiffel compilers which use a similar concept of emitting memory-safe C.
First, the computer is a machine. To work correctly, it must be precisely controlled. You *could* instead "train an AI", only to find out the AI has some very funny behaviour in edge cases.
For example, you can train an AI to drive a car and it will work on 364 days of the year. On day 365 it will experience an untrained scene and make a spectacular crash.
Regarding loops, branches, instructions and function calls - they are the essence of imperative programming. Like a certain sweetness and acidity (and more) we know as apples.
Then there are other fruits such as functional programming with much more mathematical expressiveness. Think of the sweetness and acidity (and more) of an orange.
Some programming problems call for imperative, while others are best solved using functional languages. One day you want to eat an apple, the next day you prefer an orange. That does not mean oranges are categorically better than apples.
Also, there are many more fruits such as logic programming. They have their niches, too.
MPE was a very successful business (as opposed to scientific and technical) computer operating system.
https://en.wikipedia.org/wiki/HP_Multi-Programming_Executive
http://www.robelle.com/smugbook/classic.html
MPE had a rough start, but after a couple of years it developed into a rock-solid OS, loved by loyal customers of the corporate world.
It was in fact a kind of economic mini-mainframe which could connect thousands of end user terminals for transaction processing, email, order processing, manufacturing management and the like.
It was implemented in a kind of Pascal.
MPE would still be in use if customers had to make the call, because it was so reliable and secure.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
