Its a typical C/C++ project using Windows, a graphical patient data front end for a medical company. The programmers are sharp, and most of their code works with a little debugging help. But today, one of the programmers found the patient data records were getting corrupted, seemingly at random. The code has been analyzed over and over again, and its looking like a bad pointer problem. Its going to get fixed, but it might take all day, or perhaps into tomorrow.
Adding the new look to the patient data entry window is going to have to wait. Management might ordinarily be annoyed with this delay, but they've been told: "its a wild pointer bug". Everyone knows that's serious, everyone knows it has to be corrected at all costs. The time the last data corruption error made it out to the customers, there was hell to pay.
Why do we have such problems ? Is it just a cost of doing business ?
Modern Virtual Memory operating systems have greatly lessened the impact of such bugs. Now, the program no longer takes the entire computer down with it. The most common result of pointer and array dereferencing, problems is a "program invalid access" error, because the program tried to access an area outside the programs working page set, or tried to write to pages marked read only, or tried to execute from data memory, etc. However, that still leaves the occasional bug where an invalid access corrupts valid data within the program. These are the bugs that take weeks or months to wring out of a final product, indeed if they are ever really completely removed.
We need to improve the quality of computer code, especially real time embedded code. Coding errors have killed an entire Mars landing effort, caused massive telephone outtages, and caused outtages in other critical equipment. Today software has earned a reputation as being unreliable, when computer crashes are frequent, and even some household appliances such as DVD players are prone to lockups that only powering off, and then back on will clear.
Programmers know there are other languages that are "constrained" so as not to be prone to such errors, including Java, Fortran, Basic, and yes, Pascal. There are reasons they are not mainstream candidates for new projects. Too old, too slow, too non-standard. Where speed is not a concern, languages like Java and even script languages like TCL, or Python are used. The rewards are clearly shorter programmer development time and less time spent debugging low level machine problems. Fortran both runs fast and is constrained, but its not a modern language. Pascal ? It does not "let you do anything", and besides its "obsolete".
We need to rediscover protected languages. Your language should work for you, not against you, or as a passive observer. Language protections can act as a "protection of last resort" against programmer errors. For time and speed sensitive applications, the protection can always be removed by compile time option.
Pascal is one in a series of "Wirthian" languages, after Nicklaus Wirth, a retired computer professor with a long history of language design. Wirth designed several languages, both before and after Pascal. Wirths last achievement before retirement was the Oberon series of languages, which incorporated objects, and also many of the improvements in language design that Wirth came up with over the years.
The Wirth languages featured clean, well thought out constructs that were easy to implement on currently available hardware. To keep the language Pascal simple, Wirth left out many of the practical details needed to perform industrial programming applications. Wirth meant the language to be an example and a minimum base for a larger, more application oriented language.
Wirth had the luxury of being able to move from one language design to a new, cleaner/and or more capable design. However, as real world programmers we rarely have that freedom. The best of all worlds is a clean Wirthian language that has been extended in a logical way to handle modern requirements. Oberon is certainly such a worthy language. Pascal is another. Pascal has several very important characteristics for our use:
The IP Pascal implementation started as a ISO 7185 compliant compiler in 1980. In the early 1990s, I embarked on a program to update both the compiler and the language it compiles for more modern projects. I wanted IP Pascal to be more than just another runaway train wreck of a language that used Pascal as the base language. Too many Pascals out there are an amalgamation of Pascal, Basic and C/C++. What I wanted was a Pascal as Wirth would have designed it, if he had wanted to extend Pascal. For my guide, I have used the Oberon language extensively. IP Pascal is literally what Oberon might have been if it had been made compatible with Pascal.
However, IP Pascal is more than that. IP Pascal is a complete system, in much the same way as Java presents a complete runtime environment. What IP Pascal is NOT is a C or Basic lookalike. There are no type casts. There is no ability to take the address of program objects arbitrarily. There are no built in string operators. There are no embedded assembly language statements. Instead of loosening Pascal type safety, IP Pascal maintains and extends it.
What IP Pascal does have is runtime efficiency. There should not have to be a choice between runtime efficiency and type security. You CAN have both !