mjncad, Most all high level languages with decent support have had pretty good optimizing compilers for a decade or two. The result is that the emphasis is on writing easy to read code that is easy to understand and maintain not worying about using another machine cyle to make another fetch or write to mem.
Once you have relieved the programer from the neccessity to worry about efficiency and execution speed and concentrate on what it is the code is supposed to achieve not how it is to achieve it then you get more productivity as well as easy to read and understand programs that can be maintained by folks who didn't originally write it.
Now then, about the efficiency and about hard real time requirements and the execution speed and all that sort of thing... A good optimizing compiler actually emits code that executes as fast or faster than most bit fidlers can put together manually and it is much easier to maintain at the high level source level instead of machine instruction level.
I have met a lot of bitheads who just would not believe that someone could write so verbose and English (Natural Language) like statements to express the required logic and actions so clearly and not be way slower than their own clever hand coded "tricks" but in heads up competition they have been stomped by much less skilled programers using a good optimizing compiler.
If you put enough SMART GUYS to work long enough you can build a compiler that will spit out the tightest code imaginable starting with the easiest to read and under stand high level language statements. Once you have captured the "intelligence" in the compiler then the requirement to be a super bit head to write a decent real time program is removed and just regular people who understand the problem domain can write programs that execute efficiently and git 'er done.
As you can imagine there has been a lot of weeping and wailing on the part of the bitheads whose job security was threatened by a bunch of whipper snappers who didn't really understand "TIGHT CODE." Programing has moved from an arcane art to an engineering endeavor, not unlikie engineering electronic hardware or bridges or ... I forget who sid this but it is so true... If architects and engineers built buildings the way programers make programs then civilization as we know it would be destroyed by the first woodpecker.
About 10 years or so ago I had some ideas about automating the programing process by coupling it to anallysis. Why not use structured methodologies (perhaps mechanized through CASE tools) to analyze and define the relationship between the problem space and solution space? It turned out I was working in a vacuum and several folkks were way ahead of me in trying to do that. Project Technology in Berkely, California (Sally Schlaer and Steve Mellor) had some real smart guys working on that.
They had developed an object oriented analytical methodology that allowed you to define the problem and once you had the definition captured in the CASE tool the tool would feed code to a compiler and you got a runable program that was the solution to the problem. This was in its infancy when I first started takiing classes they offered but was able to handle some pretty demanding realtime multi-tasking problems as of 8-10 years ago. I haven't kept up with their development but it should be pretty polished stuff by now.
Pretty neat concept huh? Define and model the problem and the computer tools write the program for you essentially. Takes programinig up a notch or order of magnitude in abstraction. Now a scientist or engineeer trained in the use of these analytical methodologies can descripe a realtime system with this formalism and get a runable program. Gee Mr. Programer, feel threatened?
Oh, and how does this stuff relate to HYDROGEN? This stuff is a real gas and so is hydrogen!
Pat
>
