Re:shhh! don't go blabbing this all over the place
on
The Return of Ada
·
· Score: 1
Finally, apart from inheritance, even Ada83 supported all the other features of OO to some extent. That's like saying C is OOP because it has structures and linkable modules. Err - no - it isn't!
Ada 83 didn't bring anything to the OOP party besides abstraction/data hiding, and even then it didn't do it very well. What makes you say that? What problem do you have with Ada83's abstraction/data hiding that hasn't been improved in Ada95/05?
I pray for the sake of all remaining Ada programmers that '95 fixed all the problems I found, but Ada '83 was a bucket of crap. So you're basing your opinion of a current language version on one that is 24 years old? Have you tried the first version of C?
BTW, the project in the OP succeeded, but I can point to a few high-profile failures using Ada here in Australia. The combat system for locally made submarines and a system for the Queensland betting agency. They were all pre-95 so maybe they should have waited for the technology to mature before jumping in. I certainly wish we had. Was their failure proven to be as a result of the choice of language? Or was it that the original requirement was poorly specified, analysed and understood?
Re:shhh! don't go blabbing this all over the place
on
The Return of Ada
·
· Score: 1
That says more about the standardisation process than it does about OOP. Actually, it's more about language maturity.
That was only part of the point. The other point was related to how Ada, with its strong typing, encapsulation (over that of other languages), and library system allows compiler vendors to carry out certain optimizations that could be difficult or unreliable in other languages, hence improving performance.
To be honest I can't remember the details of this as it was a while back I read or heard about this - it's possible it was at a Tartan seminar, but it made sense at the time.
What happened? Ada, as usual, assumed the programmer was an idiot. We were using packed types (a necessity of the hardware), and instead of just outputting the entire record like it was told, Ada picked-apart the record into individual pieces. Every piece that was smaller than 1 byte, Ada increased the size of the data to 1 byte, and output it to the destination file. That is the correct behaviour of the default 'Write (to stream) attribute of a type as defined in:
http://www.adaic.org/standards/05rm/html/RM-13-13-2.html for Ada 05, http://www.adaic.org/standards/95lrm/html/RM-13-13-2.html for Ada 95
Thanks Ada. Now, instead of nicely compressed bitfields, I have each flag taking up an entire byte of memory, and non-aligned packed types are all increased to a byte in size. The only solution was to do an unchecked conversion to a generic array of bytes, and output that using Stream_IO (the wrong way). Yes, you're right - that was the wrong way (to some extent). You should have overridden the 'Write and 'Read attributes for the types you were trying to output as shown in Cohen, N. "Ada As A Second Language" (Second Edition) section 16.7.1.
Also, I would not write hardware simulation in Ada if i want performance, you are chasing constants in that case, and then C is the only way (and I have worked with implementing dynamically recompiling CPU-simulators, so I have a certain perspective on that). Interesting. If you have not already done so, it may be worth taking a look at: http://www.sigada.org/wg/eduwg/pages/lawlis.html.
This is very old, probably from the days when Ada compilers weren't particularly efficient at generating code compared to how they are now, and it specific in this case to DSPs, but it certainly gives something to ponder over.
Before continuing down the path of an argument on "Ada sucks for embedded systems", I would suggest reading the following thread that I started around 12 years ago.
As a result of all the replies I got (well, most of them, apart from a number of Robert Dewar's offensive comments:-) my view on Ada totally changed. I had been writing C for the 2-3 years before that, as well as Occam, and had been using PASCAL a lot before that. Funnily enough, at the time, I was working on the control system for an instrument to be installed on a satellite.
As far as typing is concerned, if you are spending that amount of time looking up definitions, then I would suggest you have an excessive number of types, or a design problem; it may be, for example, that your system is not partitioned properly!
From what you say about unit testing, do you use AUnit?
I thought unit testing was pretty simple in Ada, it certainly was when I was using it, especially as (as far as I remember) you could do things with child packages and stuff like that.
3) Exporting a C interface isn't equivalent to good support of C++. Try interfacing Qt to Ada. (It's probably been done, but I mean try doing it yourself...this is about the general problem of C++ libraries.) http://www.qtada.com/en/index.html
Re:shhh! don't go blabbing this all over the place
on
The Return of Ada
·
· Score: 1
"but OO it really aint"
Actually, it is! It supports all the concepts of OO - polymorphism, inheritance, encapsulation and abstraction. Just because it didn't use object.method syntax doesn't mean it isn't Object Oriented. in fact the object-oriented aspects of Ada 95 are very interesting. In Ada 2005 the object.method syntax is supported, but in Ada 95 you had to use a "controlling parameter" in your function/procedure calls. However, as I remember it, there was more capability available as a result of that controlling parameter than there is with either C++ or Java.
Finally, apart from inheritance, even Ada83 supported all the other features of OO to some extent.
Re:shhh! don't go blabbing this all over the place
on
The Return of Ada
·
· Score: 1
The comment was that Ada was the first _standardised_ OO Language which, in fact, it (Ada 95) was.
It's not very difficult in Ada, you can use Unchecked_Conversion (http://en.wikibooks.org/wiki/Ada_Programming/Types#Unchecked_Conversion) if you're desparate. However the point here is that, if you've got into that sort of hole, you've probably done something wrong earlier on!
Re:Not just a girl...a rather messed up girl
on
Why Not Ada?
·
· Score: 1
"Actually, I'm an Electrical and Computer Engineering major (hardware, not software),"
Interesting. You may find at some point that you will be designing ASICs and FPGAs. If you do, there is a chance that you will be doing this with VHDL. (There's quite a lot of money in this kind of thing in the UK). Should you ever be in this position, you will find that knowing Ada is a huge benefit as VHDL is heavily based on Ada.
Although I hope this makes you look at Ada in a new light, I won't be holding my breath, but I would suggest you investigate VHDL before writing off Ada.
Re:Not just a girl...a rather messed up girl
on
Why Not Ada?
·
· Score: 1
"but I'm being force-fed Ada95 and have been waiting for an opportunity to vent in a public forum"
"Force-fed" huh? I guess you would rather be learning how to make megabucks writing flaky code in a flaky language (like C++ or Java) than being provided with a solid grounding in Software Engineering.
It sounds like you have the wrong attitude. All you need to remember is that any good programmer can write in any language, but very few languages force you to think about what you're trying to do - especially C/C++. They just let you do what you want and then expect you to sort out the mess afterwards - with Ada, you're expected to not get into that mess in the first place.
"The reason people don't use Ada is because its blocks are delmited by indentation"
That's an interesting one - I've been programming in Ada for nearly 10 years and never knew that before! I'd be interested in knowing whether you can provide a reference to where this is defined.
Funnily enough, before I started using Ada I'd been using C and OCCAM for a couple of years, and OCCAM did use indentation as part of the syntax.
Re:Why Ada is unpopular
on
Why Not Ada?
·
· Score: 1
"Ada was designed to work with a 48-character set."
I have no idea where you got this idea from. Ada was designed to work with the ASCII character set originally, now (Ada 95) the default is ANSI Latin-1.
"So it doesn't use many special characters, or even lower case letters."
False.
"This leads to ALL UPPER CASE PROGRAMMING, which is today considered ugly"
Most Ada code I've seen follows the conventions first used in the reference manual. For Ada 83, keywords were in lower case with identifiers in upper case, so you could end up with e.g:
if THE_LENGTH_OF_A_PIECE_OF_STRING = 12 then ... Personally I found this convention to be appalling and ugly and didn't use it anyway, but it was only a convention - it was not dictated by the language which is, and always has been, case-insensitive! In Ada 95 the convention is much better. Keywords are still lower case, but identifiers are capitalised e.g.:
if The_Length_Of_A_Piece_Of_String = 12 then ... One of the good things about Ada is that all the important documentation, e.g the ISO Standard, the Annotated ISO Standard and the Quality & Style guides are all freely available. So you can get a compiler (GNAT) and a Language Reference Manual just to try it out without spending any money whatsoever! Go on - try it!
"One feature that I would like to see in new compilers is better run-time diagnostics"
GNAT is quite good at this. Also if you use exception handlers, Ada.Exceptions.Exception_Message on GNAT will provide you with exactly where the exception was raised, and Ada.Exceptions.Exception_Name the name of the exception.
If you haven't even seen Ada, here is a link to the GNAT compiler sources. Just download it, unzip and untar it and look at the code. Then let us hear what you think of it.
"I don't know about GNAT, but the Ada compiler that used Ada syntax in its command language sucked hard. "
AdaWorld?
"Anyway, the only programming projects I really enjoyed were the C ones in the third year"
Why? Was it because you enjoyed the challenge of discovering bugs and fixing them in C more than just writing the code in Ada and having it work first time?
"According to my prof. ADA is used in military tasks involving 100% reliablity (submarine radar traking systems, air traffic control systems, stuff like that). "
Are air traffic control systems a purely military thing? Ada is used most often when high reliability is required, not because it is a "complex" language, but because it is a safe language.
As people have mentioned, it is heavily used in Air Traffic Control, Aircraft, Railway Systems and so on, both military and commercial. Pretty much anywhere where peoples' lives are at stake in the event of failure. For a more complete list check out: http://www.seas.gwu.edu/~ mfeldman/ada-project-summary.html.
"You speak formally when you are trying to prove something, or be academic, but to get work done, you don't wish to be bothered with the formallities."
Much of the formality within Ada is geared towards:
1) Non-ambiguous semantics resulting in less chance of programmer induced errors.
2) "Programming in the large" - essentially programming large systems using large teams where interfaces are defined by one sub-team and used by another.
3) Ease of maintenance.
I have to assume from your comment that the "work" you do is not as part of a team, that your debugging effort is vastly more than the design effort, and that your code is never maintained, except possibly by yourself.
Not even slightly true. Ada was developed effectively as a panacea to reduce the massive costs involved in maintaining and supporting all the different languages and specialised compilers in use in the DoD at the time. So basically the intention was to make a language that would satisfy pretty much everyone. Specialised it certainly was not.
Slashdot Mirror
That was only part of the point. The other point was related to how Ada, with its strong typing, encapsulation (over that of other languages), and library system allows compiler vendors to carry out certain optimizations that could be difficult or unreliable in other languages, hence improving performance.
To be honest I can't remember the details of this as it was a while back I read or heard about this - it's possible it was at a Tartan seminar, but it made sense at the time.
Interestingly there have been a number of examples of where Ada has outperformed C. Check out http://www.adahome.com/Ammo/Stories/Tartan-Realtime.html (although adahome.com appears to be unmaintained).
http://www.adaic.org/standards/05rm/html/RM-13-13-2.html for Ada 05,
http://www.adaic.org/standards/95lrm/html/RM-13-13-2.html for Ada 95 Thanks Ada. Now, instead of nicely compressed bitfields, I have each flag taking up an entire byte of memory, and non-aligned packed types are all increased to a byte in size. The only solution was to do an unchecked conversion to a generic array of bytes, and output that using Stream_IO (the wrong way). Yes, you're right - that was the wrong way (to some extent). You should have overridden the 'Write and 'Read attributes for the types you were trying to output as shown in Cohen, N. "Ada As A Second Language" (Second Edition) section 16.7.1.
... and also was commenting on a version of Ada that he was aware of around 3 years before standardisation. See some comments on http://www.adapower.com/index.php?Command=Class&ClassID=Advocacy&CID=39.
http://www.sigada.org/wg/eduwg/pages/lawlis.html.
This is very old, probably from the days when Ada compilers weren't particularly efficient at generating code compared to how they are now, and it specific in this case to DSPs, but it certainly gives something to ponder over.
John
Before continuing down the path of an argument on "Ada sucks for embedded systems", I would suggest reading the following thread that I started around 12 years ago.
:-) my view on Ada totally changed. I had been writing C for the 2-3 years before that, as well as Occam, and had been using PASCAL a lot before that. Funnily enough, at the time, I was working on the control system for an instrument to be installed on a satellite.
http://groups.google.co.uk/group/comp.lang.ada/browse_frm/thread/751584f55705ddb7/8d598713f676abe9?hl=en&lnk=st&q=ada+useless+embedded#8d598713f676abe9
As a result of all the replies I got (well, most of them, apart from a number of Robert Dewar's offensive comments
As far as typing is concerned, if you are spending that amount of time looking up definitions, then I would suggest you have an excessive number of types, or a design problem; it may be, for example, that your system is not partitioned properly!
From what you say about unit testing, do you use AUnit?
I thought unit testing was pretty simple in Ada, it certainly was when I was using it, especially as (as far as I remember) you could do things with child packages and stuff like that.
"but OO it really aint"
Actually, it is! It supports all the concepts of OO - polymorphism, inheritance, encapsulation and abstraction. Just because it didn't use object.method syntax doesn't mean it isn't Object Oriented. in fact the object-oriented aspects of Ada 95 are very interesting. In Ada 2005 the object.method syntax is supported, but in Ada 95 you had to use a "controlling parameter" in your function/procedure calls. However, as I remember it, there was more capability available as a result of that controlling parameter than there is with either C++ or Java.
Finally, apart from inheritance, even Ada83 supported all the other features of OO to some extent.
The comment was that Ada was the first _standardised_ OO Language which, in fact, it (Ada 95) was.
It's not very difficult in Ada, you can use Unchecked_Conversion (http://en.wikibooks.org/wiki/Ada_Programming/Types#Unchecked_Conversion) if you're desparate. However the point here is that, if you've got into that sort of hole, you've probably done something wrong earlier on!
"Actually, I'm an Electrical and Computer Engineering major (hardware, not software),"
Interesting. You may find at some point that you will be designing ASICs and FPGAs. If you do, there is a chance that you will be doing this with VHDL. (There's quite a lot of money in this kind of thing in the UK). Should you ever be in this position, you will find that knowing Ada is a huge benefit as VHDL is heavily based on Ada.
Although I hope this makes you look at Ada in a new light, I won't be holding my breath, but I would suggest you investigate VHDL before writing off Ada.
"but I'm being force-fed Ada95 and have been waiting for an opportunity to vent in a public forum"
"Force-fed" huh? I guess you would rather be learning how to make megabucks writing flaky code in a flaky language (like C++ or Java) than being provided with a solid grounding in Software Engineering.
It sounds like you have the wrong attitude. All you need to remember is that any good programmer can write in any language, but very few languages force you to think about what you're trying to do - especially C/C++. They just let you do what you want and then expect you to sort out the mess afterwards - with Ada, you're expected to not get into that mess in the first place.
"The reason people don't use Ada is because its blocks are delmited by indentation"
That's an interesting one - I've been programming in Ada for nearly 10 years and never knew that before! I'd be interested in knowing whether you can provide a reference to where this is defined.
Funnily enough, before I started using Ada I'd been using C and OCCAM for a couple of years, and OCCAM did use indentation as part of the syntax.
"Ada was designed to work with a 48-character set."
...
...
I have no idea where you got this idea from. Ada was designed to work with the ASCII character set originally, now (Ada 95) the default is ANSI Latin-1.
"So it doesn't use many special characters, or even lower case letters."
False.
"This leads to ALL UPPER CASE PROGRAMMING, which is today considered ugly"
Most Ada code I've seen follows the conventions first used in the reference manual. For Ada 83, keywords were in lower case with identifiers in upper case, so you could end up with e.g:
if THE_LENGTH_OF_A_PIECE_OF_STRING = 12 then
Personally I found this convention to be appalling and ugly and didn't use it anyway, but it was only a convention - it was not dictated by the language which is, and always has been, case-insensitive!
In Ada 95 the convention is much better. Keywords are still lower case, but identifiers are capitalised e.g.:
if The_Length_Of_A_Piece_Of_String = 12 then
One of the good things about Ada is that all the important documentation, e.g the ISO Standard, the Annotated ISO Standard and the Quality & Style guides are all freely available. So you can get a compiler (GNAT) and a Language Reference Manual just to try it out without spending any money whatsoever! Go on - try it!
"One feature that I would like to see in new compilers is better run-time diagnostics"
GNAT is quite good at this. Also if you use exception handlers, Ada.Exceptions.Exception_Message on GNAT will provide you with exactly where the exception was raised, and Ada.Exceptions.Exception_Name the name of the exception.
"Exception handling is Bad Programming"
:-}
I guess that must be why they didn't implement exception handling in:
1) C++
2) Jave
3) Eiffel
If you haven't even seen Ada, here is a link to the GNAT compiler sources. Just download it, unzip and untar it and look at the code. Then let us hear what you think of it.
ftp://cs.nyu.edu/pub/gnat/gnat-3.12p- src.tar.gz
"I don't know about GNAT, but the Ada compiler that used Ada syntax in its command language sucked hard. "
AdaWorld?
"Anyway, the only programming projects I really enjoyed were the C ones in the third year"
Why? Was it because you enjoyed the challenge of discovering bugs and fixing them in C more than just writing the code in Ada and having it work first time?
"According to my prof. ADA is used in military tasks involving 100% reliablity (submarine radar traking systems, air traffic control systems, stuff like that). "
Are air traffic control systems a purely military thing? Ada is used most often when high reliability is required, not because it is a "complex" language, but because it is a safe language.
As people have mentioned, it is heavily used in Air Traffic Control, Aircraft, Railway Systems and so on, both military and commercial. Pretty much anywhere where peoples' lives are at stake in the event of failure.
For a more complete list check out:
http://www.seas.gwu.edu/~ mfeldman/ada-project-summary.html.
"You speak formally when you are trying to prove something, or be academic, but to get work done, you don't wish to be bothered with the formallities."
Much of the formality within Ada is geared towards:
1) Non-ambiguous semantics resulting in less chance of programmer induced errors.
2) "Programming in the large" - essentially programming large systems using large teams where interfaces are defined by one sub-team and used by another.
3) Ease of maintenance.
I have to assume from your comment that the "work" you do is not as part of a team, that your debugging effort is vastly more than the design effort, and that your code is never maintained, except possibly by yourself.
Not even slightly true. Ada was developed effectively as a panacea to reduce the massive costs involved in maintaining and supporting all the different languages and specialised compilers in use in the DoD at the time. So basically the intention was to make a language that would satisfy pretty much everyone. Specialised it certainly was not.