Ada is a multi-paradigm language (i.e. procedural or OO) that has threads ("tasks") built it. The experiences of Ada83 tasking wasn't brilliant - the OS/hardward available at the time just weren't up to the job and hopelessly expensive. This left a nasty taste for some which in turn led to FUD about the language as a whole - you wouldn't believe the rubbish I've heard over the years about what Ada is or is supposed to do!
Ada95 (and in particular the $0, Open Source GNAT compiler) changed that, making an affordable-for-the-masses,, fast Ada environment available on GNU/Linux and Windows platforms. It now comes with an Eclipse plug-in too.
Now, Ada2005 has arrived which even extends OO into the domain of active objects (i.e. extensible, polymorphic tasks).
I hope they have enough flight data to re-create (virtually) what happened in the lab. I'd be very interested to find out if this was a software error... and if so, what could have prevented it - different language (Ada95?), better test tools (www.polyspace.com?)...
I'm no "tree hugger" but......I listen to Jonathon Porrit on the radio yesterday, and he is actually in favour of keeping the existing nuclear power plants OPEN.
Read the report before judging...
http://www.codesandciphers.org.uk/lorenz/rebuild.h tm/
The Colossus celebrates its 62nd birthday this year. Another case of Yankees trying to re-write history! It's bad enough when Hollywood get away with it for 'artistic reasons' but/. and CNet should know better...:-)
But for any reasonable size program the combinations are just so high you can't sit and write unit tests to cover and execute each and every posibility. Either physically or financially.
What you can do, is use tools like PolySpace (www.polyspace.com) to ensure you won't have any array overruns, out of range errors, access through dangling pointers, etc. You can then run unit tests on the 'working' code in working scenarios to ensure it does what it should.
You can't prove the absense of bugs by testing - only their persense. If you want to _prove_ absense of run-time exceptions then you have to start using tools like those from www.sofcheck.com, www.polyspace.com or www.praxis-his.com
One could generalize further in that, IMHO, there are a lot more bad programmers than there are good programmers.
Given a good education in what consitues 'good programming practice', a good programmer will be a good programmer in most any language.
The arguement then is "how can we improve the performance of those below 'good'?".
Using the best tool during each phase of development seems like an obvious statement - but then why do people insist on sticking with C/C++? Language choise can have a severe impact on performance - see http://www.stsc.hill.af.mil/crosstalk/2000/08/mcco rmick.html
"All coders, great or small, have run time errors at some point. Its a fact of life."
Sorry, no - that simply isn't the full story anymore. There is no need for your code to ever be delivered with a run-time error (and by that I assume we're talking about/exceptions/ here, not something that doesn't meet a requirement) anymore.
There are tools from companies like SofCheck for Java, SPARK for Ada or PolySpace for C/C++/Ada that can identify these before they are ever run.
Got a good point there! I started on SML/NJ and have toyed with O'Caml on and off (currently 'off':-)
If you want something similar to the speed of C and with the same 'if it compiles, it work' mentality then check out Ada95 too - a much malign language but only by those who either haven't used it ever, or those that haven't used it in the last 5-6 years.
Probably true - but then being popular doesn't make something 'good' or 'worthwhile'.
Ada83 certainly had a lot going/against/ it - lousey and very expensive compilers for one. This is simply not true of Ada95 compilers as a) the language was improved; and b) the compilers got a lot better and a lot cheaper (including free).
In aerospace, there is rarely any need for dynamic memory management (post "initialisation") - you know how many of any kind of object you are going to be dealing with at compilation time.
In Ada you just don't need to resort to pointers 99 times out of 100 as the compiler will hid all that for you.
WRT: SPARK check out this report:
http://www.cyberpartnership.org/SDLCFULL.pdf
The report's task force was co-chaired by Microsoft and Computer Associates people and is being submitted to the DHS.
It explicitly recommends SPARK as one method of increasing reliability/security.
It also states "A programming language with significantly fewer possibilities for mistakes than C or C++ should be used where possible."
Slashdot Mirror
You could try Ada.
Ada is a multi-paradigm language (i.e. procedural or OO) that has threads ("tasks") built it. The experiences of Ada83 tasking wasn't brilliant - the OS/hardward available at the time just weren't up to the job and hopelessly expensive. This left a nasty taste for some which in turn led to FUD about the language as a whole - you wouldn't believe the rubbish I've heard over the years about what Ada is or is supposed to do!
Ada95 (and in particular the $0, Open Source GNAT compiler) changed that, making an affordable-for-the-masses,, fast Ada environment available on GNU/Linux and Windows platforms. It now comes with an Eclipse plug-in too.
Now, Ada2005 has arrived which even extends OO into the domain of active objects (i.e. extensible, polymorphic tasks).
Something similar to what "The Master" did when he ran out...
FUD alert!!!
o rmick.html
C# might be appropriate for your domain but it certainly isn't in Ada's - safety critical or mission critical systems.
It's also easy to learn as can be seen here http://www.stsc.hill.af.mil/crosstalk/2000/08/mcc
- ever
made me laugh out loud!I hope they have enough flight data to re-create (virtually) what happened in the lab. I'd be very interested to find out if this was a software error... and if so, what could have prevented it - different language (Ada95?), better test tools (www.polyspace.com?)...
You could argue that "the earth was without form" is a "flat earth".
i s%201%20;&version=9;
http://www.biblegateway.com/passage/?search=Genes
I'm no "tree hugger" but... ...I listen to Jonathon Porrit on the radio yesterday, and he is actually in favour of keeping the existing nuclear power plants OPEN.
Read the report before judging...
Sorry hit 'submit' not 'preview'! The link is http://www.codesandciphers.org.uk/lorenz/rebuild.h tm
http://www.codesandciphers.org.uk/lorenz/rebuild.h tm/
The Colossus celebrates its 62nd birthday this year. Another case of Yankees trying to re-write history! It's bad enough when Hollywood get away with it for 'artistic reasons' but /. and CNet should know better... :-)
Looks like the CIA have screwed up again then! :-)
Check this:
http://www.cia.gov/cia/publications/factbook/geos/ us.html
"I'd love to hear from anyone who can recommend test coverage tools for C..."
See http://www.polyspace.com/
But for any reasonable size program the combinations are just so high you can't sit and write unit tests to cover and execute each and every posibility. Either physically or financially.
What you can do, is use tools like PolySpace (www.polyspace.com) to ensure you won't have any array overruns, out of range errors, access through dangling pointers, etc. You can then run unit tests on the 'working' code in working scenarios to ensure it does what it should.
Told by whom? Certainly not the Met. Office! "Seaweed readers" I'd bet! ;-)
Well, there you go - I didn't have a spell-checker tool available to spot that bug! :-)
You can't prove the absense of bugs by testing - only their persense. If you want to _prove_ absense of run-time exceptions then you have to start using tools like those from www.sofcheck.com, www.polyspace.com or www.praxis-his.com
One could generalize further in that, IMHO, there are a lot more bad programmers than there are good programmers. Given a good education in what consitues 'good programming practice', a good programmer will be a good programmer in most any language. The arguement then is "how can we improve the performance of those below 'good'?". Using the best tool during each phase of development seems like an obvious statement - but then why do people insist on sticking with C/C++? Language choise can have a severe impact on performance - see http://www.stsc.hill.af.mil/crosstalk/2000/08/mcco rmick.html
"All coders, great or small, have run time errors at some point. Its a fact of life."
/exceptions/ here, not something that doesn't meet a requirement) anymore.
:-)
Sorry, no - that simply isn't the full story anymore. There is no need for your code to ever be delivered with a run-time error (and by that I assume we're talking about
There are tools from companies like SofCheck for Java, SPARK for Ada or PolySpace for C/C++/Ada that can identify these before they are ever run.
To me the glass is half full...
Got a good point there! I started on SML/NJ and have toyed with O'Caml on and off (currently 'off' :-)
If you want something similar to the speed of C and with the same 'if it compiles, it work' mentality then check out Ada95 too - a much malign language but only by those who either haven't used it ever, or those that haven't used it in the last 5-6 years.
Probably true - but then being popular doesn't make something 'good' or 'worthwhile'. Ada83 certainly had a lot going /against/ it - lousey and very expensive compilers for one. This is simply not true of Ada95 compilers as a) the language was improved; and b) the compilers got a lot better and a lot cheaper (including free).
Actually, that's exactly what I do and have done for the last 16 years - all in aerospace.
In aerospace, there is rarely any need for dynamic memory management (post "initialisation") - you know how many of any kind of object you are going to be dealing with at compilation time. In Ada you just don't need to resort to pointers 99 times out of 100 as the compiler will hid all that for you.
They're only buzz words if you don't understand what they mean... ...and since when did "Baysian Probability" become a 'buzz' word!! :-O
Yeah, now what you mean... But the low salary is "Programming Language Independent"! :-(
Bet you get to turn out any old sh*t too!
Now you know that we have 1000*the man power requirements but only ever get 0.5*the men! ;-)
WRT: SPARK check out this report: http://www.cyberpartnership.org/SDLCFULL.pdf The report's task force was co-chaired by Microsoft and Computer Associates people and is being submitted to the DHS. It explicitly recommends SPARK as one method of increasing reliability/security. It also states "A programming language with significantly fewer possibilities for mistakes than C or C++ should be used where possible."