Re: Systematic Fix: Type Safe Programming Language
@Frank Gerlach #2:
You make good points, particularly when you say '"stop using plain C++ arrays, pointers and quite a few nasty C/C++ "tricks"/.
Re: "I wonder how you would make Array Access typesafe in C"
It can be done. Don't use naked pointers where it could be an issue. Make an array type with info as to length, etc of structures. One of the big issues with C, from my point of view is that its maintainers are content to have a souped up assembly language rather than just a real modern language. I have been looking into how one might fix that myself. I think it is possible.
Re: "properly optimizing compilers can safely remove lots of bounds checking, as overruns are very often known at the beginning of a loop"
I emphatically agree with this, even in a broader sense. A programming language like Modula or Oberon (or Ada) that gives the compiler lots of information allows the compiler to do all sorts of compile time optimizations. In theory, a language that gives the right type of information to a compiler with sophisticated optimization should be able to beat a human at optimizing the overall code. I have, for many years now, adopted the stance that the compiler gets the first crack at optimization and only if it fails and the optimization is needed do I step in to hand-code.
Re: "do we need to use a portable assembly language for anything "efficient", just because we need it for a very small part of the operating system ?"
No. However, it seems to me that C is tantalizingly close to a good general purpose replacement for everything including Assemblers and Scripting. C, on its own, is perfectly capable of supporting very elaborate abstractions. To fix its few problems, it seems to me that it just needs a few tiny nudges to better rationalize and integrate the pre-processor, provide support for Objects, bring functions up to first class objects, some refinement of syntax to allow nesting of functions and a bunch of ancient assumptions ripped out such as the special treatment of source code in disk files. The compiler should worry about finding and integrating called function and the default language run-time should default to values that would allow simple scripts to be written directly. Here is what the famous 'Hello World' program should look like in its entirety:
"hello, world"
The proof of utility of the C-language family (including C++, C#, Java, ECMAScript, Objective C, golang, etc) is its ubiquity. The proof that it requires refinement is evident in the proliferation of the C-like languages. Each aims to correct perceived deficiencies in C. I think that a good re-think of the language could allow us to toss C++, C#, Java, Objective C, golang, etc. I have a hunch that done right it would actually decrease the size of the base language.
Re: "Even the vast majority of kernel code does not need to be type-unsafe. Both MPE and Oberon prove this."
Don't get me wrong, I am a big believer in the utility of type safety and other facilities that protect programmer's from themselves. Most programmers do not belong in charge of a C compiler. I gave up on Oberon for various reasons, but was a Pascal and Modula 2 programmer in the early 1980s even before I learned C. I preferred Modula to C for many reasons. However, at the end of the day, for a programmer that can handle a C compiler, Pascal and Modula (and from the looks of it Oberon) are like programming with mittens on. Part of its strength in abstracting the machine is also a part of its weakness.
Good teams can make a pretty good go at modest programs using nearly any language. Bad teams can make a mess of modest programs using nearly any language. We have a lot of extremely well trained and practiced people out there including project managers, build specialists, designers, analysts and coders. We could accomplish a great deal just by funding the good ones and getting the bad ones out of their way. Unfortunately, the people deciding on which teams get assembled are generally pretty hopeless.
We do not reward technical success very well. One of the very best projects I worked on was with Sybase to produce a replacement billing system for a large leasing company. It was a team of maybe a hundred or so people and virtually every one was a seasoned professional near the top of their game. The project was delivered beyond spec, below budget and slightly ahead of time. That team was eventually disbanded because even though they got better results for (much) less money, the sales process above them could not compete with the bigger more ruthless players.
For projects like the above, there is not a lot of repeat business if you do your job well. The job is done and systems like that stay in place under low maintenance for many years.
Love it or hate it, C continues to exert influence because it gets the job done. Warts and all, it is often better than the alternatives. I honestly think that C can be cured of some of its ills, but things like C++, Java or C# are not that cure.