Replies

I wrote a proprietary 4GL based on C for multiple platforms for 20 years when there were few standards.

I'm impressed.

It’s doable and maintainable, especially with the standards that exist in the industry today.

Maintainable? Can you pull out your C compiler and compile the source w/o modification today? How about using another C-compiler?

The problem, IMHO, is that today’s application programmers - as opposed to systems programmers who write the OS, kernels, device drivers, etc. - are incapable of handling the stack. They code in languages that handle everything for them. It makes for great, object-oriented, reusable code, but it means they’re totally unaware of what’s under the hood. They also have no idea how to open a socket or listen to a port.

I generally agree here -- though let's not kid ourselves: Object Oriented isn't always the best choice.
I think really what we're seeing is a failure in the CS-education system; it is surprising how many languages don't have something like Ada's subtype -- and how many CS graduates don't grasp how useful it is to be able to exclude values. {IE in Ada Positive is a subtype (of Integer) that has the additional constraint of only having values greater than zero.} Any CS battery of coursework ought to include enough Math to make the advantages thereof obvious.

Maintainable? Can you pull out your C compiler and compile the source w/o modification today? How about using another C-compiler?

That proprietary 4GL is still running today, still being modified and enhanced, still compiled on multiple platforms, and still distributed via binary to multitudes of companies. So, yes.

I think really what we're seeing is a failure in the CS-education system;

That's the truth of it right there. And I agree that OO isn't always the best fit. Therein lies the crux of the issue. They're not taught to solve the actual problem with the best tools. They're taught to write software to work around their own lack of knowledge. They don't know how to analyze a specific problem or requirement and then develop an efficient and effective solution. They write inefficient code because "hardware is cheap." They don't know enough to respect memory and bandwidth as the precious resources they still are.

Much of assembly coding for a real time system consisted of verifying actual input and output ranges, sub-calculation significant figure maintenance design, error checking during calculations, and processor calculation time allocation/optimization.

There's nothing like living under the hood (at least for a fixed task list).