[email protected] (Tomasz Rola) writes: > So, now the 5-6 years old anecdote about one contractor stating that > "Ada is obsolete" makes much more sense, even though at the time I > read it, it sounded rude and immoral. It doesn't really matter anymore > what language will be choosen for a project - well, it may still be a > problem if one prefers to write Lisp (MHO: concise, elegant) over > writing Java (MHO: overly talkative and relying too much on external > tools and cargo cult procedures like refactoring - I guess almost > nobody writes Java in Emacs nowadays). But the source code is going to > be verified in theorem proover, automatically. And even the compiler > does not need to be trusted anymore, because one can compare exec file > with source and prove that one matches another.
ADA tends to still be used for "human rated" applications ... aka human lives at risk ... like commercial airplane control systems. http://en.wikipedia.org/wiki/Ada_%28programming_language%29 from above: Ada also supports run-time checks to protect against access to unallocated memory, buffer overflow errors, range violations, off-by-one errors, array access errors, and other detectable bugs. These checks can be disabled in the interest of runtime efficiency, but can often be compiled efficiently. It also includes facilities to help program verification. For these reasons, Ada is widely used in critical systems, where any anomaly might lead to very serious consequences, e.g., accidental death, injury or severe financial loss. Examples of systems where Ada is used include avionics, railways, banking, military and space technology.[6][7] ... snip ... List of ADA uses http://www.seas.gwu.edu/~mfeldman/ada-project-summary.html in the 90s, bugs related to c-language pointer use accounted for the majority of internet exploits. this started to shift some in the late 90s with increasing number of virus&trojan based exploits I've frequently pontificated that the original mainframe tcp/ip product was done in vs/pascal and had *NONE* of the pointer-related exploits common in c-language implementations. some past posts http://www.garlic.com/~lynn/subintegrity.html#buffer part of the problem is c-language pointer values can be ambiquous which is not easily identifiable by source code analysis (there is currently thread in comp.arch about difficulties with language features that are abiquous or not stictly defined) -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
