The Return of Ada

Pickens writes "Today when most people refer to Ada it's usually as a cautionary tale. The Defense Department commissioned the programming language in the late 1970s but few programmers used Ada, claiming it was difficult to use. Nonetheless many observers believe the basics of Ada are in place for wider use. Ada's stringency causes more work for programmers, but it will also make the code more secure, Ada enthusiasts say. Last fall, contractor Lockheed Martin delivered an update to ERAM, the Federal Aviation Administration's next-generation flight data air traffic control system — ahead of schedule and under budget, which is something you don't often hear about in government circles. Jeff O'Leary, an FAA software development and acquisition manager who oversaw ERAM, attributed at least part of it to the use of the Ada, used for about half the code in the system."

Comments

I used ada....

[aldousd666]

In school. It wasn't actually any different from very many other languages that have huge class libraries, it's just that they were all 'included' in the langauge instead of linked in separately. It's more verbose and stuff, but I didn't see any completely foreign concepts in Ada that aren't around in most other langauges. Just more typing, from what I remember.

Re:I used ada....

[Xipher]

I had to use Ada in my Data Structures class with John McCormick at UNI http://www.cs.uni.edu/~mccormic/ This guy teaches a tough class but you end up learning a lot, and he is very big on Ada. While I haven't used it much since I did like a lot of features in the language.

Re:I used ada....

[iamhigh]

Me too... even graduated first in my little AF programming class (Keesler AFB). And I can't code for shit.

Re:I used ada....

[Red Weasel]

The great part about being a programmer for the Air Force is how easy it was to get a waiver to use a more appropriate language. ADA was used in tech school and that was about it.

Now that I've left I STILL find ADA code running from the 70s. Upgrading it is a major bitch but If you are going to sling code for the government it would be good to know the basics.

The ability to import java and c into ADA are a real boon.

Re:I used ada....

[aldousd666]

They used it in real school too, I never had a java course, and I get along just fine today in 'the real world.' Admittedly I don't use Ada either, but it worked well enough for Data Structures and Algorithms classes.

Re:I used ada....

[Teese]

yea, but mccormick was the only one who taught using Ada, practically every other class was c++ (well, except for Wallingford). Of course I was there 10 years ago, I guess I have no idea what goes on there now.

Re:I used ada....

[TargetBoy]

Likewise, I also used Ada in college.

I found it very easy to work with and is only slightly more verbose than VB or PowerBuilder.

Frankly a language that forces programmers to do the right thing up front might just be the thing to do. It's always faster to re-type something than to try to find the bug in your code after it is running.

Re:I used ada....

[Chris Mattern]

Ever try reading in and storing an arbitrary length string? I'm fairly convinced it's not possible in Ada.

It's not possible anywhere, unless you have access to an arbitrary size memory. Ada simply makes you aware of that fact before you put the code into production.

Re:I used ada....

[harmonica]

It's more verbose and stuff, but I didn't see any completely foreign concepts in Ada that aren't around in most other langauges. However, Ada had a lot of those concepts working reliably in 1983 and 1995 (the years the first two major versions were released if I remember correctly), when most other people were using not-so-sophisticated languages, to put it mildly.

Getting into Ada is rather complicated and time-consuming, though, so it's not surprising that it never took off in a big way.

Re:I used ada....

[wfstanle]

That's the root cause of buffer overflows. If you can't do such "crimes" then security is advanced.

Re:I used ada....

[dpilot]

Sounds like an incipient buffer overflow, to me.

Re:I used ada....

[Anonymous Coward]

Sounds like an incipient buffer overflow, to me.

No, the program would just quit reading into the string at the predetermined cutoff. Your program might operate incorrectly if the input is incorrect, but it wouldn't overflow the buffer.

Re:I used ada....

[SL Baur]

Now that I've left I STILL find ADA code running from the 70s. Ada didn't become Ada until 1983. Commercial compilers were still stabilizing five years later. So, if you had working Ada code you had a time machine and you also had a compiler from the future. See (all of the criticisms of Ada were true at the time I wrote it) http://homes.cerias.purdue.edu/~spaf/Yucks/V1/msg00096.html

Now that I'm not forced to work with it, I feel nostalgia sometimes. I built a GNAT RPM for Turbolinux, but I don't they ever distributed it. How is GNAT nowadays?

Re:I used ada....

[naasking]

Well, that and Ada's I/O is pretty terrible. Ever try reading in and storing an arbitrary length string? I'm fairly convinced it's not possible in Ada.

Show me some hardware that can do that, and it'll be a valid criticism. I believe the criticism you meant to level, was a dynamically sized string. This indeed was more difficult, but not at all impossible. I learned Ada95, and you could do it at least with the libraries available in that revision. Ada 2005 also fixed many such shortcomings in the standard library. Ada even has closures now!

Re:I used ada....

[SL Baur]

Yeah. The typed I/O stuff was really the pits. It was even more difficult to send arbitrary data across the wire in networked applications (which of course, they all are in C3I - one of Ada's first application domains). Difficult, but not impossible.

Perhaps the best job I ever had was when I was the 900 pound gorilla who vetted commercial Ada compilers. Every so often the boss would come in to my office, drop a package or tape of a commercial Ada compiler on my desk and say, "tell me what you think about this".

I got so frustrated with Verdix Ada at one point because they had potentially the best system, but ignored our (valid) bug reports. After perhaps one beer too many and seeing a remark about VADS on comp.lang.ada, I flamed them. The next day, I got email and a telephone call from a guy at Verdix. After some discussion, I agreed to become a beta tester and if my concerns were addressed to issue a formal public apology on the newsgroup. I did, they did and I did. Unfortunately, the fix was in, the official Unix Ada compiler for the DoD was declared to be Alsys (Ichbiah (Green), Brosgol (Red), duh).

I never met Ichbiah, but I did get to meet Benjamin Brosgol. He participated in Ada training (reeducation sessions) for Software Engineers at the company I worked for. A nice man, but I don't particularly care for the design decisions he makes in language design (and being me, I let him have both barrels - he's remarkably even tempered too).

Alsys was barely usable - the code it produced worked, but even small systems (30k SLOC) took hours to recompile. At one point I was setting up a network test and noticed that one of my embedded message strings was wrong. Rather than doing a painful recompile of the world, I fixed it by editing the binary in Emacs. A couple weeks later, the test was still chugging along (remarkable for Ada stability at the time) and when it was time to give a demo to the highest ranking General in the US Army, the boss lady told me to just leave it running, so I did.

So whatever anyone says about Ada in the 1980s, the view from the trenches was somewhat different. I also have no doubt that the technology probably got quite good in the 1990s. Early adopters always get the rough end of the stick.

Re:I used ada....

[Not The Real Me]

"Likewise, I also used Ada in college."

I too used Ada in college. Ada is a superset of Pascal. It's very similar to Borland's Delphi and Oracle's PL/SQL, which are basically their versions of Object Pascal.

The FAA should've used Java. Then the project would've taken 3x longer and had cost overruns of 400% and/or would've gotten cancelled, like most government projects.

Re:I used ada....

[Orion Blastar]

Ada is very much like Pascal, but with a black box strategy.

Sure class libraries are not included with Ada as they are in Pascal, C++, Java, et all. But the advantage of Ada is that each team developing a part of the program can write their own piece of it and only release the APIs needed to interface with that piece of the program without seeing the source code. For example you can write functions and procedures into a class library and keep it secret so only members on your team can see the source code, but another contracting agency on another team cannot steal your IP because they only have access to your library but not your source code. They know the variables they have to send to your functions and procedures in order to use them and what they pass back, but it is a black box process in that they cannot see how the black box works only what goes in and out of it.

Ada meets the DOD standards for a secure language because of the black box concept. That way a program written for the military by several different contracting teams is more secure because if an enemy agent gets a copy of one of the source code copy to one of the libraries they won't have access to the other five or six libraries that it interfaces into in order to work.

Of course this means Ada isn't the best language to use for an open source project, or for when several teams need access to the source code of the other teams as well. Ada should only be used when the IP or security needs to be secret and on a need to know basis that can control who can see the source code and who cannot.

Re:I used ada....

[MichaelSmith]

Now that I've left I STILL find ADA code running from the 70s. How is GNAT nowadays?

Pretty much all there is for Ada development these days. But now there is this "press a button and hey presto" ada to java converter going around...

Re:I used ada....

[MichaelSmith]

Ada even has closures now! And BASIC has exceptions!

Re:I used ada....

[Anonymous Coward]

I was a victim of Ada '83 in the late 80s. It all sounded like a good idea at the beginning but as I had to wrestle with the crapfest I grew to hate it like no other language. At that point I was willing to pick up any language and try it: Forth, Modula, etc., so I jumped in.

All the propaganda (even hard technical documentation was full of it) compared Ada favourably with Cobol and Fortran instead of real-world choices in the 80s which all left it for dead. What a grab-bag of incompatible concepts. God forbid you used a limited private type anywhere that found its way into a structure. You'd spend your days writing Set() functions for each of those structures.

Then there's Section 13, which embedded systems spend a lot of time involved with. The interrupt handling was a joke. It varied wildly from compiler to compiler, even between compilers from the same vendor (you paid separately for a 286 and 386 compiler - A$15k in 1990!). So there went your portability.

And the compilers! What a gigantic fraud. We paid A$4k for a compiler that allocated all automatic arrays on the heap at the top of a function, but decided deallocating them wasn't worth doing at the bottom.

Ada '95 might have fixed some or all these issues, but I don't care. I wouldn't work in it again if you doubled my salary. I'm still a fan of strong typing, but living in C for fifteen years I've implemented my own disciplines to 99% replace that.

As far as I'm concerned Jean Ichbiah is the greatest con-artist in software history.

Re:I used ada....

[cibyr]

I'm currently doing a course with VHDL which I'm told borrows most of its syntax from Ada, and I can't stand it.

It's not the whole "you're designing hardware, everything happens at once, concurrency-gone-mad" aspect, I got my head properly around that in the first couple of weeks. It's just the utterly horrible syntax and the ridiculous hoops it forces you to jump through.

Want to declare an array of bits? Sure, that's one line. Want an array of arrays of bits? Now you have to declare a new type first.

Adding two numbers, and want to know if there's an overflow? You have to pad out the numbers to include the extra bit.

There's absolutely no consistency in when you need brackets, semicolons, commas or something else.

You have to do *two* casts if you want to use a string of bits as an index to an array. (There's heaps of really stupid type incompatibility stuff).

One thing that's specific to VHDL: Ok, you've given us the ability to create arrays which are indexed backwards - why on FSM's good Earth can't we slice an array backwards?

Re:I used ada....

[Mad Merlin]

Ever try reading in and storing an arbitrary length string? I'm fairly convinced it's not possible in Ada.

It's not possible anywhere, unless you have access to an arbitrary size memory. Ada simply makes you aware of that fact before you put the code into production.

I'm not saying it has to be in a single step, indeed to do it safely will often require multiple steps. However, Ada doesn't seem capable of either.

The icing on the case was that if you do a get(foo), where foo is a fixed length string, it will read exactly the length of the string, hanging if there's not enough input and stopping part of the way through the input if there's too much. It might be possible to work around that by reading a single character at a time into a character and then repeatedly appending the character to a string which you could theoretically resize. However, IIRC, resizing the string, casting a character to a string, and appending to a string are all extremely painful or impossible.

Re:I used ada....

[Mad Merlin]

That's the root cause of buffer overflows. If you can't do such "crimes" then security is advanced.

In the same way that a turned off and unplugged computer is very secure from network attacks.

Re:I used ada....

[jonadab]

> > Ever try reading in and storing an arbitrary length string? I'm fairly convinced it's not possible in Ada.
> It's not possible anywhere, unless you have access to an arbitrary size memory.

And yet, a language without the capability to attempt that (and only fail if the string actually gets too long for memory, which in practice doesn't happen very often) is pretty much useless for writing real-world programs like, say, an XML parser, or an email proxy, or, you know, anything much beyond classroom-example programs.

Re:I used ada....

[PresidentEnder]

Java's compiler screams if you try a narrowing conversion (in which you could lose precision) without an explicit cast.

Re:I used ada....

[LoofWaffle]

You're right. An XML parser is infinitely more useful than say an early warning radar, which are largely coded in Ada.

Re:I used ada....

[AdamHaun]

Can you elaborate on this? I'm curious what makes Ada binary libraries more secure than any other language's binary libraries.

Re:I used ada....

[HeroreV]

I don't think many applications are going to find much use for early warning radar.

Re:I used ada....

[kafka.fr]

Ever try reading in and storing an arbitrary length string? I'm fairly convinced it's not possible in Ada.

Have a look at http://www.adaic.org/standards/05rm/html/RM-A-4-5.html and http://www.adaic.org/standards/05rm/html/RM-A-10-12.html

For the lazy: yes it is possible, just as it is in C++ (for example).

Re:I used ada....

[kafka.fr]

[...] anything much beyond classroom-example programs. Oh yes. Check this classroom example :
https://libre.adacore.com/aws/main.html

"AWS: a complete Web development framework"

As a reminder, the GNAT compiler is written (mostly) in Ada. But maybe it's not much beyond a classroom example either.

Re:I used ada....

[shutdown -p now]

What you describe is modularity. It is a very old concept. C had it essentially from the very beginning - you can have an .h file describing the interface to the library, but no source code for it. A bit later, Modula-2 had it all nicely integrated into the language itself. I'm sure there was some earlier stuff, too.

Re:I used ada....

[petermgreen]

It wouldn't have happened in Ada, since the US system would be using SpeedMPH and the metric system would be using SpeedKMPH, both derived types from whatever precision decimal is required, and attempting to use a SpeedMPH decimal as a SpeedKMPH would be a compile time error and would be caught.
Does anyone actually bother to do that though? or do people just use a generic floating point type for everything?

BTW you should be create such types in C++ fairly easilly.

Re:I used ada....

[Jamie Lokier]

BTW you should be create such types in C++ fairly easilly.

And I have. The classes and all the overloaded functions were C++ generated by Emacs-Lisp. The code optimised pretty well to the equivalent raw floating point - we used it in a computationally intensive video game.

-- Jamie

Re:I used ada....

[LoofWaffle]

Applications require people to write them, people require some sense of security (per Maslow) before they can achieve the sort of self-actualization necessary to be creative and productive, early warning radar systems provide some of that security.
If you live in the US, this logic is obviously a bit of a stretch; However, if you live some place like the Gaza Strip then this argument has a bit more merit.

In any case, my points were that Ada is far from useless. In fact, it is used in more mission critical applications than we realize. It is also not limited to merely introducing students to procedural programming, which it is very good for.

Re:I used ada....

[Bush Pig]

When I was at uni from 1992-6 ADA was the teaching language (must have stabilised since you used it). I loved it. It forces good habits, and if you get a clean compile, it is GUARANTEED to do something sensible (although not necessarily what you wanted). Also Oracle's PL/SQL is a subset of ADA with database extensions, and it's as tight as a nun's cunt. I love it.

Re:I used ada....

[Bush Pig]

I call bullshit. I forget how you do it, but I'm pretty sure you can declare an arbitrary length buffer, with protection for overflow, in ADA. (If I could be bothered, I'd look it up.)

Re:I used ada....

[Orion Blastar]

It would have to be the Ada runtime checks to make sure that access to unallocated memory, buffer overflow errors, off by one errors, array access errors, and other errors don't exploit the code in the libraries. I mean that is why the DOD uses Ada in avionics and missile controls. They don't want someone exploiting a bug or getting access to the source code so they can control or damage plans or missiles.

Re:I used ada....

[Orion Blastar]

True but Ada has runtime controls that prevent access to unallocated memory, buffer overflow errors, off by one errors, array access errors, etc for the modular code. That makes Ada more secure than C or Modula-2.

Re:I used ada....

[HeroreV]

I see what you're saying. The poster you replied to said Ada "is pretty much useless for writing real-world programs", but I only feel it is probably not a very good choice for most applications.

Re:I used ada....

[shutdown -p now]

True but Ada has runtime controls that prevent access to unallocated memory, buffer overflow errors, off by one errors, array access errors, etc for the modular code.

What does all you've listed has to do with modularity? It's just runtime checks. You can perfectly well make a C implementation (conforming, no less) that would do all of the above. Furthermore, I'm not sure about Modula-2, but quite a few Pascal compilers did bound checking by default.

Skill and not language used?

[thedak]

I may just be a whippersnapper, get off my lawn and whatnot; as a Java, C, C++ coder, but the project being completed under-budget and pre-deadline and having that attributed to Ada itself seems rather misguided to me.

As far as I'm concerned, if a competent team is hired; skilled programmers and developers, then anyone could get it done under-budget and pre-deadline. (yes, yes, military intelligence, oxymoron, but it seems to have worked out with this project)

I think the headline could later read, "the return of C", or any other language in the future if a team manages to finish a project efficiently due to the use of skilled developers.

Not necessarily a praise of language used is necessary, and a congratulatory beer for the team may be advised.

Re:Skill and not language used?

[CogDissident]

Oddly, they're saying a language which is slower for people to write, and considerably more obscure than most languages, is the reason something is done under-budget and quickly? It seems like those traits would make it more secure, but take much longer to make...

Re:Skill and not language used?

[Digi-John]

Perhaps a language which is slower and a bit more difficult to write prevents programmers from dumping so many lines of semi-working crap, requiring them to put a little more thought into the code?

Re:Skill and not language used?

[Anonymous Coward]

Ada is a strong programming language and it is harder to make some of the more common stupid mistakes in Ada. But I think you are right and especially so with Ada. I haven't seen a junior Ada programmer in a LONG time. Projects using Ada tend to have senior people who understand their domain and don't make newbie mistakes.

When you combine a language that encourages errors at compile time rather than run-time with experienced people, you are going to get good results.

Re:Skill and not language used?

[larry bagina]

Aside from writing code, you also have to test it. That extra security/straightjacket can mean it works right the first time.

Re:Skill and not language used?

[everphilski]

Oddly, they're saying a language which is slower for people to write, and considerably more obscure than most languages, is the reason something is done under-budget and quickly? It seems like those traits would make it more secure, but take much longer to make...

You need to make a distinction: they weren't writing new code, they were updating existing code. This is a very important distinction. We are all aware of "code rot", etc. and how over time documentation gets lost, people have to re-learn a piece of code based purely on the source, etc. However they took an older piece of code and revamped it, right on time and under budget. This is notable, and may be attributable to some of the properties of Ada.

Maybe, maybe not, but there's a good chance it had something to do with Ada.

Re:Skill and not language used?

[afidel]

Not necessarily, if you only get the top 10% programmers because of the job requirements then it's easy to see where a difficult to learn language could lead to better, more consistent code. I know my coding skills suck which is why I went into sysadmining instead of programming, but I would technically qualify for many programming jobs and could even stumble through making code that would pass general inspection. There really is a TON of difference between a great coder and an average or mediocre coder.

Re:Skill and not language used?

[Detritus]

One of the advantages of a language like Ada is that more problems can be detected at compile time and corrected at low cost, as opposed to languages like C that assume that you know what you're doing and are optimized for speed. Ada also has run-time checks that can catch many problems. It's usually more efficient for the project to do the work up-front, rather than to hack together something and debug it.

Re:Skill and not language used?

[plague3106]

I agree, given that only half of the code was Ada code. Maybe it was all the non-Ada code that saved the project from Ada.

Re:Skill and not language used?

[samkass]

Not at all. Most of the time spent between project kickoff and software delivery is NOT spent actually typing the code. If you program in a language that makes it harder to write bugs, easier to find bugs, easier to express algorithms, easier to read other people's code, and easier to do automated testing and verification you'll save huge amounts of time even if coding takes several times as long.

Interestingly, that's one of the arguments in support of Java. Hardcore C or C++ hackers find it cumbersomely verbose, but it's pretty easy to read any Java coder's source code from anywhere in the world and debug it with relatively little time spent in the code archeology phase. That is, for those bugs that make it past the relatively extensive automated checks that are possible because of the straightforward syntax.

Re:Skill and not language used?

[Jason King]

Yes, 10 uber-coders can finish a project ahead of 10 clueless coders every time. What Ada does is it makes it harder for the clueless coder to hose the whole system. Because its persnickety you don't find buffer overruns (for example) in the wild. You always get them in test or sometimes they even generate compiler errors. The earlier in the cycle you get your errors the easier they are to fix.

Re:Skill and not language used?

[Anonymous Coward]

but it's pretty easy to read any Java coder's source code from anywhere in the world

Only if India's on the moon.

Re:Skill and not language used?

[hey!]

I think there is something to be said for this idea. Not too much, mind you, but something.

Let's imagine a language so obscure and difficult, that 90% of working programmers cannot gain sufficient mastery of it to understand what it is saying at first glance. This sounds terrible, until you realize that every programmer at some time in his life has written code in "friendly" languages that 0% of programmers (including his future self) can understand. And maybe selecting a language that only the top 1% of programmers is capable of using might be a good thing for some projects.

Unfortunately, I don't think you can mandate thinking via language restrictions.

If you really, really wanted to improve the quality of thought in code, wouldn't mandate languages, you'd mandate editors that don't support cut and paste. Then instead of taking a piece of code that works more or less for one purpose, then hammering into the approximate shape you'd need for something else, sooner or later you'd be forced to abstract what was useful about it rather than banging it out over and over again.

Re:Skill and not language used?

[conspirator57]

two words: type safety

this one feature prevents much debugging and allows better, more automated test coverage.

they coded slower, but took less time in QA.

Re:Skill and not language used?

[wfstanle]

You are forgetting something... Actually writing the original code takes up a small part of the total time spent on a program in its life cycle. There is debugging, testing and updating that have to be considered. I have updated programs written in Ada and in other programming languages. Have you actually had to read code the code written by others? Reading a C or C++ program is not easy. Some say that C (and all of its derivatives) are "Write only languages". At least in Ada, it is easier to make sense of the code that others write.

Re:Skill and not language used?

[somersault]

That's what I was thinking too. Testing should be a major part of any project - and especially one where large pieces of metal hurtling through the air are involved :p

Re:Skill and not language used?

[hitmark]

and debug, debug, debug, reimplement, debug, debug, debug, reimplement, debug, debug, debug, discard/emulate on top of new hacked together system, and the pattern goes on...

Re:Skill and not language used?

[aldousd666]

haha in refernce to your java being easy to read by default, you're forgetting about people like this.

Re:Skill and not language used?

[Ephemeriis]

You need to make a distinction: they weren't writing new code, they were updating existing code. This is a very important distinction. We are all aware of "code rot", etc. and how over time documentation gets lost, people have to re-learn a piece of code based purely on the source, etc. However they took an older piece of code and revamped it, right on time and under budget. This is notable, and may be attributable to some of the properties of Ada.

  Maybe, maybe not, but there's a good chance it had something to do with Ada. Ada is almost self-documenting. The syntax is all very verbose and human readable.

If you have to walk in blind and maintain someone else's code, Ada is the language to do it in.

Re:Skill and not language used?

[afidel]

No, I'm saying most of the bottom 90% have no idea what Ada is =)

Re:Skill and not language used?

[hey!]

Not necessarily.

C is a good language if you (a) need a portable language but don't have another portable language to implement it with and (b) you need the language to be well designed enough for a team of competent programmers to tackle nearly any problem.

You can give a language more features that makes it easier to tackle certain problems, but it tends to undermine the portability goal. C is something like a portable assembler, only with the most critical abstractions for day to day programming provided. Once you get into more, you start to run into assumptions. Static or dynamic typing? It depends on your software engineering methodologies, particularly testing.

What C is emphatically not is idiot proof. Even worse, it is spectacularly not clever person proof. I dunno. I've never worked in Ada myself, but I suspect this might be some of its, er, attraction. It looks like a language in which it is not fun to be cleverer than you need to be.

Re:Skill and not language used?

[Abcd1234]

Nah. "Hack it 'til it compiles" still works in a strict language. It just takes a little longer.

The reality is, bad programmers will inevitably generate bad code. Skilled programmers, however, can always write quality code, regardless of the language, however they will also be able to utilize available language features (such as DBC, etc) to improve their work. At least, IME.

Re:Skill and not language used?

[umghhh]

I suppose this may be part of the story but I think GP was onto something only I think supercoders do not finish projects on time and with good quality, well managed teams do if requirements are clear and not changing every minute.
As QA expert I see my job secure because of so many genius coders out there - keep up your smart ways guys!!!

Re:Skill and not language used?

[iamacat]

That is, for those bugs that make it past the relatively extensive automated checks that are possible because of the straightforward syntax.

Are we talking about the same old Java that doesn't support typedefs and uses Object for all standard data structures? Generics add a bit of syntactic sugar, but do little to ensure safety. You can cast a HashMap to HashMap without any way to check if it is valid at compile OR run time. Compared to that, C++ can be used for safer programming by encapsulating all pointers into template classes and relying on local destructors for reliable memory management.

Re:Skill and not language used?

[naasking]

Let's imagine a language so obscure and difficult, that 90% of working programmers cannot gain sufficient mastery of it to understand what it is saying at first glance.

Wouldn't work. C++ is just such a language for example, but this provides no such barrier to poor programmers and poor code! ;-)

Re:Skill and not language used?

[DrWho520]

The earlier you find a bug in the development cycle, the less it costs to fix. If software engineers find issues in code at the coding stage, they can fix those errors with relative ease whether they find the error when they compile or run their unit test. When Software Integration begins, you go up an order of magnitude in cost and difficulty. Make it to System Integration without finding the bug and you have system engineers writing software error reports for software written by engineers who rolled off the program 3 months ago. I will let you imagine how easy it is to fix a bug at that level. Though most problems at that level result from poor requirements analysis.

Re:Skill and not language used?

[darkwing_bmf]

You could say it's slower to write, but it's not that slow.
Ada:
IF a AND b THEN
  c;
  d;
  e;
END IF;

C:
if (a && b) {
  c;
  d;
  e;
}

Ada tends to use words instead of symbols. Does it take longer to type? Yeah, a little. But this doesn't make it hard or obscure. In fact, it makes it much easier for non-programmers (and new programmers) to read and understand the code.

Why would you care about non-programmers? Because in the real world, programs are written to offer real world solutions. It helps if these programs can be reviewed by engineers, scientists, accountants, etc... who may not know every language, but can figure out the basic logic if it uses words instead of symbols. Also, the improved readability makes future changes less painful.

What happens if a coworker used & instead of && in the C version? It's a lot harder to make those kinds of mistakes in Ada.

Re:Skill and not language used?

[cmeans]

Or it could simply mean that they way over budgeted for the work that was actually needed to be performed, and poorly spec'd the time it would take to do it. Normally, companies are more conservative with how long it'll take to do something (this helps bring the cost down and increases the likely hood that they'll get the work), thus, the reality tends to extend the deadline. In this case, they might have just been overly generous in their time allotment, and simply fortunate that the client was willing to pay for it.

Re:Skill and not language used?

[Kartoffel]

Mod parent up. Bondage and discipline prevents sloppy hack jobs, yet hinders quick hackish projects. For small projects, rapid hacks are ok. For large projects, you want thoughtful organization and testing along the way.

Re:Skill and not language used?

[Tired and Emotional]

Actually the real difference between Ada and many other langauges is that it is possible to code in a way that often guarantees that subsequent changes will either be correct or else will fail to compile. In other words, it makes modification easier. The idea is that local changes cannot have global effects. This was a design goal of the language (look up "beaujolais effect" for some history)

For example, suppose you want to add a new value to an enumeration. As long as you adopt certain style conventions (avoiding default clauses) if you miss any places where you need to deal with it, you will get an error at compile time.

The overloading rules work well too because the result type is also involved in overload resolution. So you can have i := foo(); and a := foo(); call different foo's if i and a are different types. If i and a start out the same type and later one of them has to change, you just change it and you will get an error message on the call to foo that you need to fix until you provide the missing implementation.

Plus the fact that you have modules and a good system (in Ada 95) for hiding implementations, and a much better controlled system of generics than in C++ means you have better control over your system. You are never going to have your executable blow up from 10 M to 200M overnight because you added a template declaration.

As for verbosity, it really isn't. More perhaps than C/C++ but nothing like COBOL. However it does pay to use a slightly more verbose style than is absolutely essential by always fully qualifying names, but the same is true in C++.

The one weirdness that catches out beginners is that arrays passed as parameters retain their lower bound. So when dealing with substrings, for example, you have to be prepared for non-zero (or 1) lower bounds. But its easy to do.

Re:Skill and not language used?

[Darinbob]

"Return of C"? Has it ever gone away? I use it all the time in places where C++ is too bloated and assembler isn't required.

I think C is the languages that killed Ada. Ada was about code safety and correctness, and C was about being able to break the rules. Early Ada also did not give sufficient access to the underlying machine, which made it suitable for applications but not so much for systems work where C excelled. By the time Ada evolved, C was already entrenched as the system language and C++ was starting to dominate applications.

As a language, Ada is great. Maybe a few nits I'd change, but very well grounded and building on the solid base of Pascal and Modula-II.

Re:Skill and not language used?

[Darinbob]

The problem with software taking too long to write and ending up over budget has little to do with how easy it is to write a line of code. Obscurity should have zero impact on a quality team of programmers (who should all be able to switch languages at a drop of a hat). Writing slowly should have little impact as well, since most programming should rarely involve having to type as fast as you can all day.

So why does a difference in language make an impact? If a language emphasizes good programming practices, the users of that language tend to follow along. A language that is sloppy with types or has malleable interfaces can encourage sloppier code. You can write great code in any language, and yet great code still remains relatively uncommon.

Another factor is with project management itself. The project under consideration isn't about writing a new version of quicksort quickly and under budget, it's about a huge piece of work with maybe dozens of people working together. Programming such a project is not about writing a new function, but about how to fix or change existing functions without breaking something else, and how to get different people's work to fit together as planned.

Re:Skill and not language used?

[aethogamous]

This reminds me of the old saying:

any idiot can design something to be idiot proof, but it takes a truly clever person to design something to be clever person proof...

Re:Skill and not language used?

[jgrahn]

Oddly, they're saying a language which is slower for people to write, and considerably more obscure than most languages, is the reason something is done under-budget and quickly? It seems like those traits would make it more secure, but take much longer to make...

How does slow to write and obscure translate to "more secure"? It doesn't.

To me, "slow to write" translates to "programmer gets bored and sloppy". And if you are bored, it's not hard to write crappy, uninspired code even in a bondage & discipline language.

Re:Skill and not language used?

[bnenning]

That extra security/straightjacket can mean it works right the first time.

Or not. I'm not quite sure why, but my Python code has a significantly higher frequency of working right the first time than my Java code, and that's after developing in Java for 10 years and Python for less than 2. My theory is that it Java's static typing and verbosity consumes a portion of my mental energy that makes it harder to focus on the actual algorithm.

Re:Skill and not language used?

[gbjbaanb]

It's usually more efficient for the project to do the work up-front, rather than to hack together something and debug it.

I think that applies a thousandfold in mission-critical software that stops airplanes from "sharing the same airspace".

Re:Skill and not language used?

[gbjbaanb]

Actually, I think its the reason you get uber-coders in the first place.

If you want cowboy coders, then choose the latest, coolest anguage there is. You'll soon see the muppets who couldn't hack it with an established language who had to do real work with real systems using it. By saying they work with the latest, they get to blame the language "its a learning process", or just by following where the money is.

Coders who insist on the latest stuff are always worse than the people who are content to work in the old stuff. They are the people who are more interested in getting the system implemented well, and not playing with the new toys.

So, choose ADA. If you can find them, experienced ADA devs will be far better for your business than some C# kids.

Re:Skill and not language used?

[EdF]

It's really not any slower to write once you know it. And if anything, it's much less obscure (meaning that the meaning of what you write is relatively unambiguous) compared to various C family languages. The "slowness" people complain about has to do with specifically stating your intent in the application, so that the compiler can check code all over the system for consistency of intent. Not too much different in essence from Design by Contract or Test-First development. As the author of AUnit (the Ada version of JUnit and CPPUnit), I can say that there is really not much conflict between the use of Ada and agile methods. Except that the Ada compiler will catch a lot of things that you won't have to write either assertions or unit tests for. The whippersnapper above is naive.

Re:Skill and not language used?

[Jason King]

Its going to sound like I'm talking out both sides of my mouth, but there are good and bad developers in lots of different tools. I've seen geniuses doing Ruby on Rails and 'tards doing COBOL (and vice versa) so maturity of environment and ability of coders are separate items.

Re:Skill and not language used?

[SpinyNorman]

Skill is obviously imporant, but all languages are not created equal...

Some languages are better suited to certain tasks than others
Some languages are more productive than others
Some languages prevent certain types of bug better than others
etc, etc

C++ is a great language in the hands of experts, but not all (or even many) programming teams are comprised of all experts. Given that it's better to have quality depend on process rather than people, depending on skilled (and unerring) programmers for quality is an iffy proposal. A language like Ada that forces things like rigorous module definition, type definition & usage, bounds checking, etc, should not be discounted as an aid towards less buggy code.

Re:Skill and not language used?

[SL Baur]

Oddly, they're saying a language which is slower for people to write, and considerably more obscure than most languages, is the reason something is done under-budget and quickly? Developmental time is practically irrelevant in the complete software life cycle.

I don't particularly care for static typing (I'm a functional language fanboy), but it is definitely a property of statically typed languages that once you get something to compile, it's much more likely to do something, as opposed to a language like C where you still have a lot of debugging ahead of you when it (probably) doesn't work quite right. Static typing also means you get a lot of correctness checking for free. It's no mistake that in large C language projects like the Linux kernel, the developers are moving towards as much static typing as the C language permits (and developing tools like sparse where it does not).

The point remains, developmental time is irrelevant over the lifetime of a software project. Correctness checking (debugging) and maintenance dominate time costs.

Re:Skill and not language used?

[G-funk]

Typedefs are not something I miss at all, but I'm at the front of the line hoping for reified generics in J7, although it seems like we might not be getting them :(

In an ideal world:

ArrayList.getClass() != ArrayList.getClass()

Re:Skill and not language used?

[ucblockhead]

This idea of making programs readable for "normal people" has been around since Cobol. In practice, it has never worked very well because the difficult part about programming, and understanding code, has little to do with the syntax and everything to do with concepts. Saying '&' or '&&' in a more human readable fashion is useless if the person reading doesn't understand the difference between logical and bitwise operations.

Re:Skill and not language used?

[Samah]

I don't understand why people love dynamic typing so much. I'd much rather the compiler tell me off for misusing a variable than at runtime where it might not crop up until the code is in production. I'm not saying dynamic typing is BAD (I love Lua), just that I don't get why so many people can possibly hate static typing.
Also I don't think you can really label Java as "verbose" when it shares mostly the same the syntax as C++ and C# (unless you assume those to be verbose too).
Having said that, it's not exactly terse, either. :)

Re:Skill and not language used?

[darkwing_bmf]

As a programmer, *I* find it more readable as well. This doesn't matter when writing your own small program from scratch, but it's damn convenient when you've got to maintain someone else's code. You can do fewer "clever" things in Ada.

Suppose we want to assign b to a, then execute c if b is non-zero:

In C:

if (a=b) c;

It is clever. But can easily be misread as a comparison between a and b instead of an assignment. Obviously (or maybe not) good programmers won't write this way, but C allows it and you don't always get to choose who wrote the code you're currently working with. And this is just a trivial example. It can get far more complex and clever than I'm willing to attempt.

Ada doesn't let you be that clever. You're forced to write it out:

a := b;
IF b /= 0 THEN
  c;
END IF;

Now pretend someone else wrote this and you don't know the original goal of the code segment. You're not even sure if the code is 100% correct or not. Which one would you rather maintain?

Re:Skill and not language used?

[Tablizer]

a language so obscure and difficult, that 90% of working programmers cannot gain sufficient mastery of it to understand what it is saying at first glance.

Wouldn't work. C++ is just such a language for example, but this provides no such barrier to poor programmers and poor code! ;-)

But C++ is not comparable because if you get yourself into a type knot, you can easily just force-feed bytes into bytes as a last resort. You can pound square pegs into round holes, while in Ada that's difficult.

Re:Skill and not language used?

[bnenning]

Also I don't think you can really label Java as "verbose" when it shares mostly the same the syntax as C++ and C# (unless you assume those to be verbose too).

I do. Simple example: given a list of employees, find the ones with salary above a given limit.
Python:
emps = [e for e in employees if e.salary>limit]

Java:
List emps = new ArrayList();
for(Employee e : employees) {
        if (e.salary()>limit) {
                emps.add(e);
        }
}
And that's assuming that employees has the right template declaration, otherwise I have to cast. Yes, it's only a couple of lines difference, but that can be multiplied by hundreds over the course of a program. More importantly, having to wade through the Java boilerplate can easily disrupt my flow. The Python very closely matches my internal thought process..."ok, I need the employees with salary above the limit...e in employees if e.salary>limit...done, what next". Java forces me to go down a level and manually create and populate the list. (And the pre-1.5 version is even worse, since you have to create and manage an irrelevant Iterator). By the time I'm done with that the real problem I'm trying to solve may have gotten swapped out of my brain's working set. I find myself substantially more productive in Python, and I've had few cases of nontrivial typing bugs due to dynamic typing. Most typing bugs are trivial; they fail immediately upon running and it's easy to see where.

I'd be interested to see a breakdown of static vs dynamic advocates and Myers-Briggs personality types. I suspect Ps like me go for dynamic, and Js for static.

Re:Skill and not language used?

[Eccles]

Another nice advantage of the Python syntax is that it would probably be multi-threaded more easily (assuming an example where determining whether an element is part of the subset is computationally expensive.)

Re:Skill and not language used?

[aldwin]

That's because you're too sober when you're coding. You need to be drunk to code in Java effectively.

Re:Skill and not language used?

[Samah]

What you've provided is essentially a combination of subsets and closures, which Java does not support (yet... maybe JDK7 *fingers crossed*).
Also, salary does not need to be a method--it could just as well be a field. Although encapsulation then says you should access it with getSalary().
I see your point about "matching internal thought process", but since I work with Java eight hours a day, I can read it about as easily as your Python. ;)
Back to the point of dynamic vs static, just to make it even uglier (but typesafe!), you should have parameterised that with <Employee> too. :)

Re:Skill and not language used?

[chgros]

Note that the verbosity is not due to static typing. For instance, what you do in Python can also be done with most ML family languages (e.g. OCaml), which are statically typed.

For instance in OCaml you'd write:
let emps = List.filter (fun e -> e.salary>limit) employees

Re:Skill and not language used?

[smellotron]

You can cast a HashMap to HashMap without any way to check if it is valid at compile OR run time. Compared to that, C++ can be used for safer programming by encapsulating all pointers into template classes and relying on local destructors for reliable memory management.

Don't get me wrong, I definitely prefer C++ over Java, but you're missing something huge.

C++ compilation is Turing-complete because of templates, making it balls-hard to write effective tools for. Java source can be fed into static analysis tools that will guarantee that your HashMap will only contain Doubles, and never any other type of Object. The same can generally not be said for C++ code with templates, because no one wants to write the tools to do so. Just look at the relative power for refactoring that Eclipse has with Java when compared to Visual C++ and any of the best C++ refactoring tools currently in existence. Eclipse wins, hands down.

Re:Skill and not language used?

[shutdown -p now]

This has nothing to do with static/dynamic typing. Here's the same example in C# 3.0, which is a statically typed language:

var emps = from e in employees where e.Salary > limit select e;

Or the same by direct function calls, without the fancy LINQ syntax:

var emps = employees.Where(e => e.Salary > limit);

Note that var is not a variant, the type for the variable is inferred here, but at no moment duck typing is introduced. Similarly for e in LINQ expression and the lambda - it's also strongly typed.

Re:Skill and not language used?

[shutdown -p now]

Compared to that, C++ can be used for safer programming by encapsulating all pointers into template classes and relying on local destructors for reliable memory management.

Right. Just don't forget what an implicitly-generated copy constructor and assignment operator for a class containing std::auto_ptr will do...

Re:Skill and not language used?

[JasterBobaMereel]

...Or maybe your Python code does not work right but you just haven't seen it fail ... yet ...

a B&D language won't let you make some of the hard to find obscure errors that languages like Python and C/C++ etc let you (not that they are any where near perfect ....)

Re:Skill and not language used?

[zsau]

Learn a language with type inference (e.g. Haskell). Love it. All the advantages of static typing (speed, compiler finds the errors), along with all the advantages of dynamic typing (not having to write them, more type flexibility).

(The latest C# has a primitive form of type inference. I don't know whether its limitations are caused by lack of imagination on the part of the developers (unlikely), not crediting users with the intelligence to understand it, problems of syntax, or because an imperetive language is necessarily hamstrung. But if C#'s the only time inference you've seen, look further afield.)

Re:Skill and not language used?

[david.emery]

What happens with experience in Ada is that you learn how to code to let hte computer do a lot of these kinds of checks. You concentrate on what the compiler canNOT check. Then when you think you're done with your work, you start running code through the compiler, working off the errors that the compiler catches.

When both you and the compiler agree the code is correct, it -usually is-, because you let the compiler take care of some stuff so you don't have to.

dave

Re:Skill and not language used?

[jmccabe]

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:Skill and not language used?

[Bush Pig]

It's not particularly slow to write (try COBOL, if that floats your boat) or obscure (assembler, anyone?) as it happens. It's actually quite sensible, particularly if you already know Pascal. The best thing about it is that it just won't let you do anything stupid. Hence the under-budget, under-time thing.

Re:Skill and not language used?

[CogDissident]

Anyone notice that I have 16 replies, and haven't been moderated either way. Is my comment really "that" neutral?

Re:Skill and not language used?

[jguthrie]

"Bondage and discipline" languages do absolutely nothing to prevent "sloppy hack jobs". The best they can do is make those sloppy hack jobs somewhat more verbose, which is hardly the same as preventing them. To see this, you need look no farther than various comments in this discussion by skilled Ada people talking about how less skilled people had to write huge amounts of code because they did things the wrong way. That wrong way was a sloppy hack job and it clearly wasn't prevented.

A computer program language has very little effect on the likelihood that a given program written in that language will be written on time and under budget. When I look back on the errors that I spend my time wrestling with (mostly in C and C++, although I've written in everything from assembly language to Modula-[23] and Lisp) I find that a relatively small number of those errors were due to what are traditionally considered to be the "source of common errors", like pointers and unenforced array constraints, that language books spend all their time berating C programmers for using, and a vanishingly small number of the errors that I found difficult to find were due to those "common" sources of errors. As I've said before, if a programming language could flag an error when I reversed a branch, I'd marry it. The errors that are hardest to find are "cognitive errors" where you somehow know that that statement is right, so you don't bother checking it closely. Don't say that you don't do that. You're human, so you do it.

A lot of noise has been made about Ada's type checking system, and how the system is so picky that once you simply get the program to compile that you can be fairly confident that it works. When I first read that, I had a good belly laugh. Since then, that assertion has been repeated over and over and, well, I am aghast that there are so many people repeating that untruth because it is simply wrong. When you get the program to compile, you still have to do all the testing. In fact, a rigid type system is just a sort of a test and you'll find all the type errors in dynamically typed languages as soon as you exercise all of the paths through the code, which is an essential process if you want your program to be considered "tested."

On the other hand, the main reason why Ada was never very popular has nothing to do with its verbosity or its type enforcement. Rather, it's because there were no inexpensive compilers for it back when it had a chance to achieve a critical mass of users. I know that's why I never tried to learn it back in the 80's. The irony of the situation, for me at least, is that this article came out now, and I happen to be reading Grady Booch's book on Ada. I bought it for $1 off the clearance rack at Half Price Books.

Re:Skill and not language used?

[Nelson]

I challenge comparisons like these. I've heard these arguments over and over, saying you're more productive doesn't really mean much. There isn't a metric that measures it and what it really means is you know python better than you know java (or whatever) and the parts of the program you don't understand that cause the typing errors are usually easy to fix.

The differences between the Python code and Java code sample are really pretty small, tooling will fix most of it, in Idea or Eclipse it will auto populate most of those key strokes for you and aside from keystrokes or lines what is your metric for this? At then end of it all, what really matters is which is easier to read at a glance and personally I can't find a difference. One is one line and one is 3 or 4 lines, I find myself doing the same mental parsing regardless of the line count. Does the code "verbosity" really matter here? Where it seems to matter if you ask me is in C and C++ where there are pages and pages of definitions included and boiler plate included just to use libraries, compare a C GTK+ pop-up dialog to a Java swing popup dialog and there is a verbosity argument.

There is also the logical hole that line counts affect readability and maintainability of program to begin with, there is a definite argument that a really compact and concise piece of code is at times even more difficult to maintain than a more verbose piece of code, just about any assembly language program is an example. With your code, it starts to look a little bit more crummy in python as soon as you start to add other criteria.

Re:Skill and not language used?

[Nelson]

What's funny is that people will argue that there is a cost, I don't think there is a measurable one, not with the keystroke typing. I also suggest that with modern tooling, it'll more than eat that cost up by itself, if that cost actually exists. Eclipse ADT will auto populate the "END IF;" and "THEN" when you type in "IF" if you desire.

I think there is often a radical difference in cost when it comes to reading and maintaining the code though, those simple mistakes can be costly. Ada has proven itself over and over, if you care about correctness and reliability as well as performance, it should be in the conversation and there are wonderful free tools available, next time you're writing a C or C++ program from scratch, you should consider Ada, there are whole classes of problem that large C and C++ apps tend to develop that aren't there in Ada. A more notable issue might be that developers still approach software as a disposable commodity, they simply aren't used to maintaining code or producing it for the next guy to maintain.

Re:Skill and not language used?

[phlinn]

What safewords do you use with bondage and discipline languages?

Sorry, that was horrible.

Re:Skill and not language used?

[default luser]

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!

Or, sometimes you're just forced to pound square pegs into a round hole.

IAAAP (I Am An Ada Programmer)

As you can imagine, we use it on embedded airborne systems, a place that has always been a hotspot for Ada. I could tell you so many instances where Ada has forced me to pound a square peg into am round hole, but this is by-far my favorite:

When I designed the data extraction package for our system, I designed it correctly using Access types to avoid redundant copies, and Ada Stream_IO to output binary data directly into a file. This is how I would have done it in C++, and it should have worked fine on Ada.

Cut to testing of my system, where I was writing data to the files, and discovering that there was far too much data in the output (and the format was wrong).

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.

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).

Re:Skill and not language used?

[jmccabe]

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.

Re:Skill and not language used?

[default luser]

That is the correct behaviour of the default 'Write (to stream) attribute of a type as defined in:

Oh, sure, it's there. But it's not in a language that somebody still learning Ada can understand. I made this mistake while I was still learning Ada. And, as you can imagine, there's not a lot of people out there who know the inner workings of Ada these days, so I was forced to experiment and learn.

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.

Sure, you can do that for general file output.

For this particular project, that would have made the code too specific; the goal was to make this easily expandable, so programmers could add output files easily as they found they needed more data. With the implementation I came up with, all you had to do to add a new output buffer was make a copy of the package, then add the appropriate type. The rest took care of itself.

And yeah, I did consider using a true generic when designing this, but the annoyance is that Ada forces all generic instances to share local memory (anything not defined by the input parameters to the generic). If you want independence between generics instances, this means you have to have huge declaration blocks for your generics (not pretty or maintainable), or you have to design around the limitations (not possible in my case). Unfortunately, the capability to make local memory independent in Ada generics is an optional feature for compilers.

Re:Skill and not language used?

[jesup]

I worked on a large, early Ada project at GE Corporate Research. This was the back-end for a compiler for an early RISC processor, the RPM-40. Assembly-language reordering for RISC pipeline (Gross' algorithm with heuristics), NOP insertion, assembling, linking. We were working for a manager who had been on the 'green book' Ada spec team, and using the early Vax VMS Ada compiler. It was one of the few of the era that could handle our code, which had I think 8 levels of inheritance, including something like 6 levels of generics (starting with things like tuples and lists, up through DAGs of instruction nodes for input to reordering algorithms).

One amusing thing that bit us was we kept getting inconsistent results. We finally tracked it down to the fact that every one of us had assumed that local variables with built-in types (integers, etc) would be initialized (integers to 0, etc). In fact they were unknown stack-garbage - we all went to the green book, looked and looked, and finally realized that only derived types have default initializers that will be invoked for local vars. We were amazed this was allowed (given the goal of "correctness"), and even more so that the compiler didn't flag it as a possible problem (at the time, my Amiga Lattice C compiler would warn you of possible uninitialized values).

It did all finally work, and had a very nice overall design. The separation of API from implementation did help. C++ templates produced some of the benefits that Ada generics had, though not all of them, and the syntax (due to the origins of C++) was a little awkward.

Re:Skill and not language used?

[ucblockhead]

But that's hardly unique to Ada...C and C++ are the only languages that let you do the above. Every other language that I am aware of forces you to put the assignment and comparison in different statements.

Re:Skill and not language used?

[Kartoffel]

Top coders prefer using assertions.
The rest run unit tests before submitting.

Re:Skill and not language used?

[bnenning]

I've heard these arguments over and over, saying you're more productive doesn't really mean much.

It means quite a bit to me, although I'll grant it's difficult to put an objective number on.

what it really means is you know python better than you know java

Well, as I said I've been writing Java for more than 10 years and Python less than 2. I used to be in the static typing camp, figuring that mass chaos would ensue if you didn't religiously inform the compiler of the type of every variable. In practice, I've found there are many benefits and few costs.

The differences between the Python code and Java code sample are really pretty small, tooling will fix most of it, in Idea or Eclipse it will auto populate most of those key strokes for you

The problem isn't the keystrokes when first typing it. The problem is the mental shift between levels of abstraction, which happens both when you initially write it and when you subsequently read it. It lumps together code that describes the essential purpose of the algorithm with code that only exists because the language isn't sufficiently expressive.

Where it seems to matter if you ask me is in C and C++ where there are pages and pages of definitions included and boiler plate included just to use libraries, compare a C GTK+ pop-up dialog to a Java swing popup dialog and there is a verbosity argument.

Right, we're just drawing the line in different places. Personally I don't like loops in general; I find most of the time they're a low-level distraction from what I really want to do, and a frequent source of silly bugs (off by 1 in the indices, using the wrong local variable inside the loop, etc). I'm even slightly annoyed by the "for e in employees" implicit loop in the Python list comprehension. I'd prefer something like a "select" method like the C# code above. (Although that would require improving Python's lambda syntax, which Guido doesn't want to do. But I digress).

Re:Skill and not language used?

[Nelson]

I've heard these arguments over and over, saying you're more productive doesn't really mean much.

It means quite a bit to me, although I'll grant it's difficult to put an objective number on. I can agree with that. There is something to comfort. It'd be nice to measure the productivity and correctness though, otherwise it's just kind of a talking point that sounds good.

what it really means is you know python better than you know java

Well, as I said I've been writing Java for more than 10 years and Python less than 2. I used to be in the static typing camp, figuring that mass chaos would ensue if you didn't religiously inform the compiler of the type of every variable. In practice, I've found there are many benefits and few costs. I apologize if what I said was at all offensive, as I read it again I probably should have waited on the coffee to kick in. I was meaning "comfort."

The differences between the Python code and Java code sample are really pretty small, tooling will fix most of it, in Idea or Eclipse it will auto populate most of those key strokes for you

The problem isn't the keystrokes when first typing it. The problem is the mental shift between levels of abstraction, which happens both when you initially write it and when you subsequently read it. It lumps together code that describes the essential purpose of the algorithm with code that only exists because the language isn't sufficiently expressive. Like declaring the output variable? I really don't see much difference in this case. I'm not discounting it, I guess I sort of ignore that part and just see code iterating through a list and creating a new list with the matching criteria. I've been using both python and java for a long time and I almost can't see a difference between the two examples, my brain kind of keys off of a couple parts and they both read just about the same.

Where it seems to matter if you ask me is in C and C++ where there are pages and pages of definitions included and boiler plate included just to use libraries, compare a C GTK+ pop-up dialog to a Java swing popup dialog and there is a verbosity argument.

Right, we're just drawing the line in different places. Personally I don't like loops in general; I find most of the time they're a low-level distraction from what I really want to do, and a frequent source of silly bugs (off by 1 in the indices, using the wrong local variable inside the loop, etc). I'm even slightly annoyed by the "for e in employees" implicit loop in the Python list comprehension. I'd prefer something like a "select" method like the C# code above. (Although that would require improving Python's lambda syntax, which Guido doesn't want to do. But I digress). Maybe there is something in this. I understand the different types of defects in static vs. dynamic systems and the costs associated with fixing them; in particular you might have trouble just making the program compile to see it fail where as seeing it fail and then seeing that you're treating a "student" object like a "teacher" object (or something of that nature) is usually a fairly simple fix. It seems like a difference in terms of explicitness, there are engineers that like things very well defined and spelled out and those that like it vague, just as a matter of taste.

Re:Skill and not language used?

[iamacat]

I don't like STL for this reason, among many others. It's trivial to defined classes that disallow default copy constructor/assignment, or do reference counting.

Re:Skill and not language used?

[iamacat]

Java source can be fed into static analysis tools that will guarantee that your HashMap will only contain Doubles, and never any other type of Object. You are either trolling or are dangerously misinformed about Java.

Re:Skill and not language used?

[shutdown -p now]

Reference counting in C++ has other issues - stuff like std::tr1::enable_shared_from_this also exists for a reason. You can, of course, use intrusive counters for your own classes, but not for many third-party libraries (especially those that insist on always heap-allocating instances of their classes).

I would agree, though, that most of the type safety that Ada packages in the language itself can be done in C++ on library level, and indeed even more impressive things are being done - boost::units, for example. C++ templates are rather brittle by themselves though, with all the duck typing for template parameters. C++0x concepts should fix this, and hopefully, this time it won't take implementations 5+ years to catch up with the standard (g++ is implementing C++0x features steadily, and there are hints on MSVC developers' blogs that they are also tracking the draft); still, it's not here just yet.

Re:Skill and not language used?

[Weedlekin]

"it is definitely a property of statically typed languages that once you get something to compile, it's much more likely to do something, as opposed to a language like C"

I think you mean strongly typed rather than statically typed, because C is a statically typed language.

Re:Skill and not language used?

[cduffy]

You confuse "cowboy" with "genius".

The second best "genius coder" I know has an excellent sense of design (his job title usually has "architect" in it somewhere) and does test-first development for every piece of code he writes, every time, no exceptions. His code is as solid as one would expect.

The best "genius coder" I know is one of Linus's lieutenants. If his code wasn't solid, he'd lose his standing in the community -- and it is solid, tremendously so, even though his workflow is of the cowboy variety (and his productivity is easily on the scale of 30x that of a more conventional developer -- I've seen him write working video drivers for embedded chipsets from nothing more than a white paper in less than a day). That's genius. Your average cowboy may think they're good, but there are folks out there whose skillset defies conventional thinking... just not many of them.

Re:Skill and not language used?

[cduffy]

Familiar with Boo? I love it -- it has much of Python's easy-on-the-eyes (and fingers) goodness but with compile-time type inference (capable of Python-style duck typing, but only when explicitly requested).

Stringency==Secure

[Zordak]

Ada's stringency causes more work for programmers, but it will also make the code more secure, Ada enthusiasts say.

So... you're saying I should ideally program my firewall in INTERCAL?

Re:Stringency==Secure

[somersault]

He said stringency, not lunacy..

Re:Stringency==Secure

[Nimey]

DO ,1 <- #13
PLEASE DO ,1 SUB #1 <- #234
DO ,1 SUB #2 <- #112
DO ,1 SUB #3 <- #112
DO ,1 SUB #4 <- #0
DO ,1 SUB #5 <- #64
DO ,1 SUB #6 <- #194
DO ,1 SUB #7 <- #48
PLEASE DO ,1 SUB #8 <- #22
DO ,1 SUB #9 <- #248
DO ,1 SUB #10 <- #168
DO ,1 SUB #11 <- #24
DO ,1 SUB #12 <- #16
DO ,1 SUB #13 <- #214
PLEASE READ OUT ,1
PLEASE GIVE UP

Re:Stringency==Secure

[dysfunct]

PLEASE FORGET doing that.

Ada

[nwf]

I took a class in Ada for a previous employer. I found it a lot like Pascal and not all that difficult. The main issue was the cost of compilers which had to go through an expensive certification process. I did find the language a but verbose for many things, e.g. here

The real issue isn't that it's hard to learn, it's that it's a little cumbersome, but more importantly, not many people know it and they typical clueless manager wants to see 10+ years of Ada experience on the resume/cv before hiring someone. Those people are few and far between, but and competent software developer can learn it.

Re:Ada

[Maaras]

You hit the nail on the head. I wrote Ada on a defense project for about 4 years. From a purely technical standpoint, it is the best programming language that I have ever used. However, in the real world, other concerns tend to dominate. Concerns such as IDE's (AdaCore's IDE was exceptionally slow and hard to use, on Solaris, at least.) and finding developers who know Ada (or are willing to REALLY learn it) counter-balance a lot of Ada's strengths. What good is the best language on Earth if you can't get developers to use it?

Re:Ada

[Asuranceturix]

Its syntax is fairly easy, and it provides means to avoid common mistakes in other languages such as the ability of deriving new types from primitive types and strong typing even with numeric types. Thus, I could define types *and* operators which are really significant for the problem at hand, no matter which machine it runs on:

type Distance is digits 4 range 0.0 .. 100000.0;
type Time is digits 4 range 0.0 .. 1000.0;
type Speed is digits 4 range 0.0 .. 200.0; -- Based on physical constraints, for instance

function "/"(Left : Distance; Right : Speed) return Speed is begin (code here) end;

This way, there is no way I can mangle arguments, a Time/Distance operation is undefined, for example, and will raise a compilation error. Besides, I don't have to care which size those variables take, I just specify what I really need and the compiler and runtime will take care of the details.

On the other hand, advantages such as this one only work if the programmer adapts herself to this way of thinking, instead of using predefined types as she would have done in C.

For a quick review of interesting characteristics of the language which make it useful to avoid mistakes (and, for the purpose of the article, cut debugging time), you can refer to this set of slides (PDF).

Re:Ada

[Anonymous Coward]

It's not expensive any more. Ada is included with GCC. It's also known as GNAT.

Re:Ada

[Dog-Cow]

I've never seen Ada code before, but for a post extolling the virtues of the static type checking, your example does a really poor job. Unless it's supposed to be so obviously incorrect.

1) You define Distance as 4 digits, but give it a range containing 6.

2) You define speed as distance/speed, which is recursive and wrong.

Re:Ada

[Asuranceturix]

As for 1, the number of digits indicates the precision, it's floating point we're talking about. As for 2, you're absolutely right, I made indeed a mistake! It should have been: function "/"(Left : Distance; Right : Time) return Speed is begin (code here) end; Anyway, if I had tried to use the correct operands, the compiler would have called me idiot at once and I would have caught the definition error at once, which was exactly the point!

Re:Ada

[xZgf6xHx2uhoAj9D]

Further, the code given does nothing (that I can see) to handle divide-by-zero errors at compile time, which I would think would be the most common error needed to be caught at compile time.

Re:Ada

[MichaelSmith]

Yes. AdaCore now provide a closed source Eclipse plugin.

Re:Ada

[FBSoftware]

Yes, there are currently two Eclipse plug-ins for Ada: Hibachi (http://www.eclipse.org/hibachi/), based on the Aonix ADT and GPL'd GNATbench (https://libre.adacore.com/) from AdaCore. GNATbench is better if you are using the GNAT compiler.

Have Apple or Google do the work

[backpackcomputing]

Here's a crazy idea: DoD should consider contracting out the work to Apple or Google! http://backpackcomputing.com/

Language Magic Bullets

[msgmonkey]

Most projects do not meet their goals and/or timeframes from bad project management. Whilst the choice of language is obviously important, I have never heard of choice of language being a major factor when reporting on contracts that are over due/over budget or plain just dont work.

I'm just worried that some PHB will read this and go, "Hmm, Ada, we must use that!"

Btw Ada is n't that bad a language, but does n't guarentee success. I remember being told that an Ariene rocket that exploded mid flight was written in Ada, the cause was a overflowing integer.

Re:Language Magic Bullets

[Maaras]

I remember being told that an Ariene rocket that exploded mid flight was written in Ada, the cause was a overflowing integer.

Can you provide a citation for this? I've used Ada before and would be curious to read about how such a thing could have happened.

Re:Language Magic Bullets

[Ford Prefect]

Btw Ada is n't that bad a language, but does n't guarentee success. I remember being told that an Ariene rocket that exploded mid flight was written in Ada, the cause was a overflowing integer.

I was wondering if anyone would mention that - the first non-flight of the Ariane 5 booster.

It's possible to program bugs in any real programming language...

Re:Language Magic Bullets

[Detritus]

It was the first Ariane V launch. They had reused software from an earlier model of the Ariane without properly testing it in its new environment. Think of it this way, you take the speedometer module from your Trabant and install it in a Ferrari. The first time that you exceed 100 km/h, the speedometer module fails with an overflow error because the type for speed was defined as 0..100. The problem was that Ariane's management was cutting corners on requirements analysis and testing. The software performed as designed, it just wasn't designed for the Ariane V.

Re:Language Magic Bullets

[rtaylor]

I don't know any of the specifics but an integer overflow is still very plausible.

A remote device might have settings 1 through 10. Send it an 11 and it has problems. ADA is still perfectly capable of overflowing a remote device by a programmer not adhearing to a communication protocol even if the local machine sending commands isn't susceptible to overflows.

Re:Language Magic Bullets

[bunratty]

Wikipedia has an article on the Ariane crash. If you think something in the article is inaccurate, you can always check the sources.

Re:Language Magic Bullets

[mihalis]

Bug? Phooey - The software in question performed exacly as per spec... the spec for the Ariane 4 rocket, that is.

Re:Language Magic Bullets

[Chatterton]

Especially when you deactivate checks.

Re:Language Magic Bullets

[Maaras]

Oh, I never would have argued that what he said wasn't true, I was merely asking out of curiosity. Thanks for the link :)

Re:Language Magic Bullets

[Nicolas Roard]

It's very well known. When I was a freshman in CS (in 96!), most of the teaching was done in Ada (some of the profs were really big on it), and they described the problem. As far as I remember, this is what happened:
- they chose to reuse a previous components made for Ariane 4 (ok...)
- they chose to NOT test it as it was working fine on Ariane 4 after all... in order to "cut costs"
- the flight parameters were quite different between Ariane 4 and 5, and notably, some were out of the range experienced with Ariane 4
- an exception was thus triggered in the component (which had something to do with navigation system), but there was no code to handle it (iirc there was code, but it had been disabled when compiling the component)
- the default exception mechanism was executed, and decided to reset the full navigation system
- the rocket then changed behaviour (duh!) and started to veer off from the planned flight path, and at that point a ground engineer decided to blow it up.

To sum it up: by deciding to "cut" cost by not testing a component they lost millions of euros. Nothing the language could have done, really.

I never had to program in Ada after my BS, but I did like the language. It really felt like an engineering language you could rely on -- we joked at the time that if you could compile your code, your program was probably right. On the other hand it was quite verbose and the compilator was really strict (but with wonderful error messages, never found something as good since).

Funnily I'm myself very keen on dynamic languages (ObjC/Smalltalk...) and usually don't like static languages. Still, kinda like Ada.

Re:Language Magic Bullets

[Mikkeles]

'...Ariene rocket that exploded mid flight...'

That was the first Ariene V flight. Wikipedia has an article and the accident report is here.

Basically, the error was an integer overflow in code reused from the Ariene IV for which the range check had been deliberately eliminated as a performance measure since (in the Ariene IV) it could not overflow. That assumption is not valid for the Ariene V.

To add insult to injury, the functionality provided by the component is not needed at or after liftoff, so could safely have been disabled at that time. Further, the original reason for the function was to allow, in older Ariene models, for the ability to suspend the launch sequence at or after -9 seconds and resume without having to redo some steps.

The lesson is that code cannot save one from a wrong design (although bad code can ruin a good design).

Re:Language Magic Bullets

[TheRaven64]

Actually, it's slightly more depressing than that. The component in question was a gyroscope used for immediately post-launch corrections on IV. It wasn't required at all in V due to improvements in other areas, but it was kept in for extra reliability.

The old 16-bit gyroscope controller was replaced with a 32-bit one but the software was kept the same. The software got an invalid input, diagnosed it as a fault and shut itself down. The backup was brought online, got an invalid input, and shut itself down. At this point, the system determined that the rocket was unsafe and caused it to self destruct. By this point, it was already at a higher altitude than the gyroscope was intended to operate (the V accelerated faster and so got above this threshold much faster than the IV).

Re:Language Magic Bullets

[HiThere]

Ariane V http://www.adapower.com/index.php?Command=Class&ClassID=FAQ&CID=328

OTOH, remember the link is to a site promoting Ada. They're telling the truth as they know it, but they're biased.

Re:Language Magic Bullets

[dpilot]

They may be biased, but they're also informed. Would you prefer a summary from a C coder who knew nothing whatsoever about Ada? A knowledgeable person can make efforts to set aside bias. An ignorant person can't set aside ignorance, because by doing so he becomes knowledgeable.

Re:Language Magic Bullets

[dumael]

Unfortunately Ada doesn't prevent bad software management. Especially when you deactivate conversion checks, don't test with data that simulates what your hardware's going to do, and recycle code from a previous platform that has quite different operating charateristics.

http://en.wikipedia.org/wiki/Ariane_5_Flight_501

Re:Language Magic Bullets

[Cochonou]

This is this kind of code which caused the crash of the SRI (internal reference systems). Pay attention to the PRAGMA SUPPRESS statement.

-- ...
declare
vertical_veloc_sensor: float;
horizontal_veloc_sensor: float;
vertical_veloc_bias: integer;
horizontal_veloc_bias: integer;
-- ...
begin
declare
pragma suppress(numeric_error, horizontal_veloc_bias);
begin
sensor_get(vertical_veloc_sensor);
sensor_get(horizontal_veloc_sensor);
vertical_veloc_bias := integer(vertical_veloc_sensor);
horizontal_veloc_bias := integer(horizontal_veloc_sensor);
-- ...
exception
when numeric_error => calculate_vertical_veloc();
when others => use_irs1();
end;
end irs2;
Of course, as others pointed out, the "real" cause of the crash was bad design and software validation choices of the management.

Re:Language Magic Bullets

[AJWM]

Not only that, but the part in question (a component of the guidance system) was intended to update the rocket's position while on the pad, not after launch. The flight trajectory on the earlier model Arianes were such that it didn't matter, it wouldn't overflow anyway. Not so on the Ariane V.

It was really a matter of the spec or procedures being wrong, not the code.

Unlike, say, the first Mariner Venus mission where the Fortran guidance code had a line in it something like

DO 20 I = 1.10

instead of

DO 20 I = 1,10

The latter iterates I from 1 to 10, with label 20 marking the end of the loop. The former assigns the value 1.10 to the real variable DO20I -- in those days Fortran didn't care about whitespace, and implicit declarations were ok, type being indicated by the first letter of the variable name.

Re:Language Magic Bullets

[DavidHumus]

All of which should highlight the fact that emphasizing the "safeness" of the programming language is fixing the wrong problem.

Re:Language Magic Bullets

[MichaelSmith]

Not only that, but the part in question (a component of the guidance system) was intended to update the rocket's position while on the pad, not after launch. The flight trajectory on the earlier model Arianes were such that it didn't matter, it wouldn't overflow anyway. Not so on the Ariane V. The stupid bit was that the component which caused the problem wrote an exception trace to the same stream which its numeric output normally went to. A c program in the same situation might have written a bit of crap to the stream or segfaulted. It was the massive exception trace which crashed the spacecraft.

Re:Language Magic Bullets

[HiThere]

I chose that site because it was the best source I knew. I also seem to remember that they glossed over features of the story that would have made Ada a bit less innocent. I don't remember what they were, it being decades ago, and the story as reported is substantially as I remember it being reported at the time. But I seem to remember something (not anything I can put my finger on) which is glossed over in this version. Possibly something like a company touting Ada's unquestionable security causing sufficient care not to be taken, or something like that. (Think of Oracle's "Unbreakable Linux".)

Re:Language Magic Bullets

[TheLink]

"The lesson is that code cannot save one from a wrong design"

Which is why I prefer using languages which are faster and easier to code in, so that I can spend more time in design (or slashdot ;) ).

Most programming is actually design, coding is closer to the act of drawing the blueprint[1].

So I prefer using something which allows me to "draw faster". If the drawing is wrong at the start, I can throw it away and start again.

If the drawing tool has decent defaults/templates and syntactic sugar which make drawing faster, then all the better.

[1] Whereas building the executable (compiling etc) is analogous to the actual construction of what's in the blueprint. Which is why Software Engineering is so different from Civil Engineering.

Re:Language Magic Bullets

[Robb]

The Ariane rocket failure was a management mistake, taking existing code and deciding to use it without further testing with different hardware having different flight parameters. Had the programmers been allowed to do their job it seems very likely the problem would have been avoided. Bertrand Meyer was the person I remember making the biggest fuss about the whole issue. He had some good points about writing reliable software but the real problem was he didn't know enough about Ada to make sense of the official report so he mostly made a lot of incorrect statements that were rather self-serving. Basically the lesson to be learned from the Ariane V explosion was that no progamming language can save you from really stupid managers.

Re:Language Magic Bullets

[ginbot462]

Your the second person to mention this. But, I could argue that there exists a set of all specs, and my buggy program perfectly executes one of those specs. In just happens the spec says to blue screen when connecting a scanner during a presentation.

we need it where it matters

[r00t]

All that vulnerable client-side code (image libraries, HTML parser, etc.) would be immune to buffer overflows if it were in Ada.

Even better, write it in proof-carrying Ada. (while an aritrary theorem prover is impossible, one can get a theorem prover to work in practice via minor tweaks to the input)

Re:we need it where it matters

[dpilot]

I was grabbing someone's .sig and stuffing it into my "quotes" file, and found this relevant tidbit...

Imagine a surgeon who discovers how much money can be saved by purchasing Xacto blades instead of using blades manufactured to more stringent standards. That is exactly the situation we are currently facing when contractors decide to use C or C++ instead of Ada. On the surface one gets the same result. It is only that superficial result that counts for the lowest bidder.

- Richard Riehle

Re:we need it where it matters

[bnenning]

All that vulnerable client-side code (image libraries, HTML parser, etc.) would be immune to buffer overflows if it were in Ada.

Or Java, C#, Python, or anything else that doesn't allow stomping on arbitrary memory locations. C is the exception in terms of how badly and easily you can shoot yourself in the foot, yet for some reason we keep using it in scenarios where security and reliability are much more important than performance.

Re:we need it where it matters

[Nimey]

Unix syscalls in Ada: like ripping your cock off to give yourself head. -- anonymous

Re:In Soviet Amerika

[Anita Coney]

"P.S. Have fun paying high price for your addiction to oil."

I can't help but wonder what industrialized country you live in that is somehow not addicted to oil.

Generating Ada CSDs

[HockeyPuck]

If anyone is programming in Ada, I highly recommend the program jGRASP http://www.jgrasp.org/. From the site:

jGRASP is a lightweight development environment, created specifically to provide automatic generation of software visualizations to improve the comprehensibility of software. jGRASP is implemented in Java, and runs on all platforms with a Java Virtual Machine (Java version 1.5 or higher). jGRASP produces Control Structure Diagrams (CSDs) for Java, C, C++, Objective-C, Ada, and VHDL; Complexity Profile Graphs (CPGs) for Java and Ada; UML class diagrams for Java; and has dynamic object viewers that work in conjunction with an integrated debugger and workbench for Java. The viewers include a data structure identifier mechanism which recognizes objects that represent traditional data structures such as stacks, queues, linked lists, binary trees, and hash tables, and then displays them in an intuitive textbook-like presentation view. Another great product from the academic community.

Anything that forces discipline is good.

[ErichTheRed]

I don't think I'm the only one who has had to work with really lousy programming and IT coworkers. One of the good things about the past was that programmers had a much harder time hiding their mistakes. In the days of dual-core processors and tons of RAM, even a mediocre programmer can get Java or any of the .NET languages to produce code that works. Of course, readability, maintainability and speed aren't really a factor.

Is going back to Ada and other similar languages a good idea? Maybe. But I think you could get the same result by just demanding better quality work out of existing languages. People have correctly pointed out that the languages aren't really to blame, because you can write garbage in just about any language.

I sound like an old fogey, but I'd much rather see a smaller IT workforce with a very high skill set than a huge sea of mediocre IT folks. This would help combat outsourcing and the other problems affecting our jobs. Almost everyone I've heard complaining the loudest about outsourcing has been either downright lazy or just not very good at what they do.

I'm primarily a systems engineer/administrator. There are many parallels in my branch of IT to the development branch. We've got the guys who can really pick a system apart and get into the guts of a problem to find the right answer. We also have the ones who search Google for an answer, find one that solves half the problem, and wonder why the system breaks a different way after they deploy it.

Not sure how to solve it, but I think it's a problem that we should work on.

Re:Anything that forces discipline is good.

[Petaris]

Whats wrong with searching Google?

Its a tool that can lead you to valuable information just as asking a colleague or consulting a book or other publication can. No one knows everything or has come across every issue, but there is usually a good chance someone has. Just because you have seen someone use it to find information who then did a half-assed job of fixing the issue doesn't mean the tool they used is no good or always lends itself to half-assed fixes.

Re:Anything that forces discipline is good.

[ErichTheRed]

Nothing's wrong with _starting_ your search there. I'm referring to the people who find the first word match on Google, and treat that answer like it's religion. It really takes someone who has practical experience to figure out which advice is good and which will lead you down a bad road.

Just peruse any IT forum site for common tech questions. You will see 10 answers for the same question, some of which are totally ridiculous. However, they're not totally ridiculous to someone who hasn't worked in the field long enough to know better.

Think about how different our profession is from, say, medicine or law. Imagine if your doctor went on Google and searched for a procedure. Wouldn't you hope he knew how to figure out who actually knew what they were talking about?

Re:Anything that forces discipline is good.

[Jherek Carnelian]

I'll second that. Expert use of google is a very valuable skill. But you can't get there just be searching google a lot, you have to have a good working knowledge of the problem domain too.

Re:Anything that forces discipline is good.

[sapgau]

I don't find anything wrong with using Google to get at reference information. The best way to scan MSDN, Oracle, or any software tool reference is by using google to scan the site for you.

Copy pasting code verbatum is another matter altogether and I agree is stupid.

Re:Anything that forces discipline is good.

[david_thornley]

I've been working in this field for a long time, and one thing I've never found hard is to find mediocre programmers who can write something unreadable, unmaintainable, and slow that kinda works. This applied back when the best commercial computers were far less powerful than the cheapest thing you can buy from Dell today.

Of course, it's now much easier to design a truly ugly and awkward user interface now. (It's also much easier to design a good one, but that's not what we're talking about, right?)

I'm quite fond of Ada

[Alistair Hutton]

I'm actually quite fond of Ada as a language. Yes, it's a very verbose language but unlike, say Java or C#, the verbosity gives you a lot of stuff. It gives you good threading. It gives you a very good encapsulation. It gives you a very nice parameter system for procedures/functions That's a point, it seperates between procedures and functions. It gives very, very, very good typing. Very good typing. It's very good. I like it. It's what I want when I'm doing strong, static typing rather than the wishy-washy getting in the way mess that many other main-stream languages. When I use a type I want it to mean something. It's a good language to teach students about programming in my opinion.

Re:I'm quite fond of Ada

[zsau]

Can you side-effect in functions like you can in Delphi and Pascal? If so, what's the advantage of the distinction? I've never understood it, as I went through some badly maintained code with functions that never set the value of "Result".

Re:In Soviet Amerika

[bobbonomo]

I just have to answer to a post like this (and to all the rest like it) not for the content because it is an opinion amongst others but that the poster did not have the courage to attach a name to it.

Do you not believe in what you say? ...and have the guts to stand up for it. What? you worried the NSA is going to put the death squad after you? Come on!

Or is this just flame bait?

Maybe time to eliminate Post Anonymously on /. I tune in and post less frequently because of it.

You got something to say? Say it. I'm listening.

shhh! don't go blabbing this all over the place

[museumpeace]

I make a nice living rewriting Ada systems into C++. When DoD suspended the "only quote us system development costs based on Ada" requirement, most bidders dropped Ada like a burning bag of poop. Its best advances such as exception handling have been picked up by modern system programming languages and even Java. The doctrinaire variable type enforcements have yet to be equaled but OO it really aint. Bottom line, plenty of old defense software systems have few living authors who will admit to knowing the code and upkeep is expensive, talent hard to find. This is ironic since DoD spec'd Ada in the first place because it had a maintenance nightmare of hundreds of deployed languages. So of course the managers think a more popular language with "all the features" of Ada should be a porting target. Eventually even customers demanded modernization and compatibility ports.

I know a few die hard Ada programmers who just love it...but very few. The brilliance of the language can be debated but its moot: no talent pool to speak of.

And besides, Ada is really French. [why did GNU make an ada compiler??????????????]

technology market: you can't separate technical merits from market forces
open source: your market has a small leak and is slowly collapsing.

Re:shhh! don't go blabbing this all over the place

[KokorHekkus]

And besides, Ada is really French. [why did GNU make an ada compiler??????????????]

Actually. GNAT is the result of the US Airforce forking over $3 million to New York University and apparently part of that contract was that the copyright would be assigned to FSF.

Source:http://www.oss-in-atm.info/20051207/09-gasperoni.php

Re:shhh! don't go blabbing this all over the place

[mandolin]

I worked on Ada code for about 3 years (1997-2000, so it was a long time ago).

The language was really ahead of its time. It got a lot of things right:
-- decent type checking
-- exceptions
-- direct assignment of arrays
-- slices
-- range discriminator (think "foreach")
-- default values and designated initializers for record^Wstruct fields
-- strict separation of interfaces via modules
-- decent interface to external languages
-- generics
-- (arguably) 'in out' instead of ptrs
-- probably other stuff I've forgotten

All of this, and typically with a better syntax than C++. Not that that is saying much.

On the downside ...

-- Garbage collection which was optional to implement. We never used it.
-- Concurrency primitives built into the language, as opposed to library calls. I think this was an attempt to simplify programmers' lives, but it complicated the compiler support, and was limited anyway. You couldn't do spinlocks/rwlocks etc. w/out having to fall back to a library.
-- ... which you got to write the interface for yourself, because the standard Ada library support was weak.
-- GNAT is decent, but my understanding is that a lot of Ada compilers sucked.
-- No standard support for bitwise operators in Ada83 (fixed in Ada95).
-- I never got the hang of the Ada95 OO support. We never used it.

I'm a C programmer, and love it, but the worst Ada code I ever dealt with was code that looked like it had been written in C and directly converted. Unchecked_conversion()s everywhere. Ugh...

Re:shhh! don't go blabbing this all over the place

[Col Bat Guano]

"The doctrinaire variable type enforcements have yet to be equaled but OO it really aint."

OO it really is. It doesn't look like most OO languages, but it has all the features that define OO-ish-ness. Got it in Ada95 (with syntactical changes to make it look more like other languages in Ada2005), so I'm surprised you haven't seen it.

Perhaps you're stuck changing over Ada83 code?

Re:shhh! don't go blabbing this all over the place

[Col Bat Guano]

On the downside ...

-- Garbage collection which was optional to implement. We never used it.

The language allowed for garbage collection, but I don't think any compilers actually implemented it in the way we think of for languages like Java. You could allocate a storage pool for a particular access type (read pointer) which would make GC possible for that type pointed at.

-- Concurrency primitives built into the language, as opposed to library calls. I think this was an attempt to simplify programmers' lives, but it complicated the compiler support, and was limited anyway. You couldn't do spinlocks/rwlocks etc. w/out having to fall back to a library.
Ada95 vastly improved the concurrency support. Ada83 presumed that the rendezvous (very high level mechanism) would be sufficient, but it didn't work for some simple models (producer/consumer problems) leading people to implement low level features (simple locks) with high level expensive features (rendezvous). What were they thinking???
Ada95 has protected objects with auto computed guards which are -very- nice.

-- No standard support for bitwise operators in Ada83 (fixed in Ada95).
There was, but it was a bit of a fiddle. You'd have to use unchecked conversion to convert to a packed array of boolean, which you can then and/or/not/xor to your heart's content. Unchecked Conversion back again.
Ada95 is much simpler!

Re:shhh! don't go blabbing this all over the place

[jmccabe]

The comment was that Ada was the first _standardised_ OO Language which, in fact, it (Ada 95) was.

Re:shhh! don't go blabbing this all over the place

[jmccabe]

"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

[jmccabe]

That says more about the standardisation process than it does about OOP. Actually, it's more about language maturity.

Re:shhh! don't go blabbing this all over the place

[jmccabe]

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

[phunctor]

Hey museumpeace - I make a decent living playing with missile guidance problems in C++, but have used Ada in the past. And I'm keenly interested in upgrading from "decent" to "nice". Let's have lunch! (It sounds like we may be contemporaries; we can tell get-off-my-lawn jokes...)

--
phunctor

You scared me for moment there

[BigGar']

That was my aunt's name and she passed away many years ago.

I was running out the door with my zombie survival guide & bug out bag heading for my arctic hideout to escape the impending invasion and I noticed out of the corner of my eye a reference to programming.

Thank god, Aunt Ada was a tad weird when she was alive, I really didn't want to meet zombie Ada.

My problems with Ada

[HiThere]

1) Ada is cumbersome, especially when you are dealing with character strings of variable length.

2) Garbage collection is managed by hand.

3) Poor interfacing with C++. (Well, so has most everything but C++.)

4) Programs in Ada tend to be HUGE!!!. That's the big one. I'm talking about source code size here, not binary size, which is reasonable.

5) If you don't know the type of data you're reading in, it's difficult to handle it. This is both a problem and an advantage.

6) Ada's handling of inheritance is very different from that of most other languages. Lisp is probably the language that comes closest to it. You could think of it as noun dominated rather than verb dominated. (I.e., instead of functional it's ??? I don't know the proper term. It works, but it's a very different model. Calling the inheritable types objects isn't really appropriate (and the term isn't used).)

Re:My problems with Ada

[drxenos]

When is the last time you used Ada? 1) See: Ada.Strings.Unbounded 2) Ada leaves that choice up to the programmer (like C++) (see: pragma controlled). The next version of Ada will have an STL-like library, which will at least reduce the need for GC. 3) See: pragma Export(C, Foo, "foo") and Convention(C, Foo). Some compiles even support CPP in place of C, with automatic translation between C++ classes and exceptions. 5) You should always know the type of data you are dealing with (unless you are writing generics, which still has some limits for safety). 6) Ada's dispatching is based on the actual call being made. No need to mark members has virtual (C++) or to just make them all virtual (Java).

Re:My problems with Ada

[T.E.D.]

This is actually the best post I've seen on this topic so far. I do have some minor issues with it though

1) Ada is cumbersome, especially when you are dealing with character strings of variable length.

String issues are the single biggest bugaboo I've seen Cish programmers have with Ada. Ada's built in strings are fixed-sized and sized perfectly to their contents (no Cish null terminator). You'd think this would be a trivial difference, but it completely changes how (and when) you need to create and handle your strings. People who insist on handling strings the same way they would in C get really frustrated.

Fortunately Ada, like C++, comes with a variable-length string class in its built in class libraries.

2) Garbage collection is managed by hand.

You have to be kind of careful here, as different people think different things when you say "Garbage collection". If you mean you can't allocate memory with abandon and expect the runtime to automaticly generate cleaup code for you like Java does, that's true (unless you run on the JVM, then it works just like Java). But this is no different than how C and C++ work.

But there are tricks. For instance, if you declare an access type with a limited scope, there are ways to get all objects of that type to be automaticly garbage-collected when that type goes out of scope. Since you can declare functions in other functions (which C's don't allow), this is more useful that you might at first think.

4) Programs in Ada tend to be HUGE!!!. That's the big one. I'm talking about source code size here, not binary size, which is reasonable.

That's more a reflection of Ada's users than the language. DoD programs tend to be huge. Ada was built to help make huge programs like that managable. There's really nothing stopping an Ada program from being small, except the deveoplers themselves.

Your other points are bang-on. I think they are working on an update for the language that will allow Java-ish notation for calling class methods, but the current syntax is not typical. A lot of people are syntax-fixated enough that this really puts them off.

Re:My problems with Ada

[HiThere]

I didn't say there weren't solutions to those problems. Merely that the problems exist.

1) Unbounded strings is a partial solution, but it doesn't blend nicely with string constants, so it's not a good solution.

2) I don't like C or C++ and garbage collection either. I'm considering boost C++ for a project, but I'll probably opt for some language with decent garbage collection.

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.) And Ada doesn't even handle interfacing with C well (which isn't unusual, it's a hard problem...macros and other #define's).

5) I can tell what kind of data I'm dealing with at run time, but dealing with this in Ada is unpleasant. Think of a container of objects that resides on a disk. If you read something in, it will tell you what kind of thing you've retrieved, but if you need to have that type hard-coded into your program, you've got to run through considerable contortions to deal with this. It's hard to handle this well and still be efficient at run time, but to me it's a continual irritation if I'm trying to use Ada.

6) I think I understand what you're saying, but I guess I was too vague. Ada's model of objects *IS* a data structure. What you inherit is that data structure, which you can extend. Operations on the structure aren't a part of the "object". Operations, however, are typed to deal with particular groupings of objects. (I'm not clear on precisely when you need to say type'class, but I haven't used Ada much because of the other irritations.)

Yes, I'm picky. I acknowledge that. Currently I'm using Python while I wait for D to develop into a suitable language. (Insufficient libraries is the main problem. Again there's problems connecting to libraries written in C or C++ . Nobody seems to handle that well. Macros and other preprocessor abominations appear to be an intractable problem. If D doesn't shape up in time I'll probably either switch to Boost C++ + Boost Python, or Python + Pyrex + C. Neither option thrills me, but both look possible. So does D + C + Python...though that one looks fragile. And maybe D + Pyrex + Python. But anything involving Python is going to presume that a compatible interpreter is installed on every system that hosts it.

Re:My problems with Ada

[drxenos]

6) Ah, I get what you're saying now. Yeah, I don't like that either.

Re:My problems with Ada

[bar-agent]

To me there are just two good viable language designs: Low-level (C/C++) and scripting languages (Lua, Perl, etc.). The mid-level languages are the worst of both worlds (compiled and slow).

Don't forget the high-level compiled languages, like Scheme, Dylan, and Haskell, that most people haven't heard of.

Re:My problems with Ada

[bnenning]

But anything involving Python is going to presume that a compatible interpreter is installed on every system that hosts it.

py2exe and py2app can help there, although I'm in the process of dealing with their poor support for eggs.

Re:My problems with Ada

[HiThere]

I maintain that Ada programs tend to be huge. On small translations to a different language I've occasionally had size reductions of over 50%.

I'll grant that there are reasons, and they're reasonable arguments (about each particular feature). I'm just not certain that they're convincing, especially when taken together.

OTOH, it clearly depends on just what you're doing. "Hello, World!" is smaller in Ada than in Java (though C and Fortran are yet more compact).

This was really brought home to me recently when I tried to translate some old Ada-83 neural networking code into a more modern language. It became not only smaller, but much more comprehensible. Partially this was due to automatic allocation and freeing of memory in the modern language, and partially it was due to Ada just being verbose.

Additionally, private variables should NOT need to be declared in files that are supposed to be shared publicly. I know some of the reasons, and it's still a bad decision. (C++ deserves criticism here also, but it has so many worse problems that why bother.) The language I'm currently most interesting in, D (Digital Mars D), has ALL of the program file possibly hidden, and the compiler generates an interface file which defines the publicly visible data.

Well, all languages are trade-offs. There's no way to avoid it. I think Ada would have been a much sounder basis than C, but C was what AT&T promoted to the world. By the time that the DOD got around to promoting Ada, most programmers had made their choice. That the early compilers cost an arm and a leg didn't make converting anyone who didn't *NEED* to use Ada any easier. Most people never even had a chance to look at it.

Re:My problems with Ada

[jmccabe]

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:My problems with Ada

[T.E.D.]

I maintain that Ada programs tend to be huge. On small translations to a different language I've occasionally had size reductions of over 50%.

(Assuming you are talking about source file size) 50% is way too much for it to be syntax reduction. Most likely, I'd say you were doing some refactoring too. If that's the case, I'd be inclined to think the refactoring was more repsonsible for the decrease than the particular languages involved.

Then again, my experience with refactoring tends to be more along the lines of turning one 10000 line source file into fourteen 20 to 200 line source files. So %50 for a best case seems rather small.

Additionally, private variables should NOT need to be declared in files that are supposed to be shared publicly

I could agree with this as a language user. As someone who has studied compiler construction I'm not sure how you would feasibly do this though. Something has to be there to tell the compiler how large variables of that type are. Most languages (Ada included) have a trick where you can leave a machine-word sized stub (usually a pointer) in the specification file and defer the defintion of the structure to the implementation file, but it would be nice to be able to do away with that hack. I'll go look at "D" and see what it does.

Ada was designed for multiple CPUs

[nurbles]

When I was in the USAF (1984-88) I was sent to Ada training. When I finished, we were given an exemption, allowing our system to remain in C. However, one particular feature of Ada seems more suited to current hardware than other languages: it was designed to allow many computers/CPUs to communicate via the rendezvous. I don't believe that C/C++, Pascal/Delphi, or any of the most commonly used languages can say that. (I'm sure someone knows of another language that does, but I suspect it isn't used very much when compared to the others.)

Couple that with the concept that, "if Ada will compile (and link) your application it will do what you asked it to do," it seems to me that Ada may have simply been 20 years or so ahead of its time. (smile)

Re:Ada was designed for multiple CPUs

[fitten]

However, one particular feature of Ada seems more suited to current hardware than other languages: it was designed to allow many computers/CPUs to communicate via the rendezvous.

"I can do it in C" was the line we always used when our Ada teacher said anything "could be done in Ada but nothing else".

"Rendezvous" was built into Ada explicitly but other standards have given it directly or through libraries to everything else. It's just thread synchronization that you can emulate/simulate/do in many other languages with similar code... semaphores, mutexes, events/conditionals, etc. but perhaps with a little more explicitness by the programmer.

The first thing to remember is that no (higher level) language gives magical properties to a computer. If one language can do it, I can guarantee that at least one other can tap into it as well... Machine Language being the easiest example because even magical Ada gets compiled into ML or interpreted by ML at one point or another... if it can be done, it can be done in ML. C is just a step up from Assembly/ML (we used to joke that C was portable Assembly).

You *might* can say that Ada was the first to actually have it as a construct defined in the language specification (I dunno the history of it, there may have been a language before Ada with it designed in) but even by Ada's heyday (mid- to late 80s), we could do it in C.

Re:Ada was designed for multiple CPUs

[mekkab]

A poorly implemented compiler can "break" rendesvous. We had a training class in ADA and we used the GNAT compiler; it was not-so-real-time, and you basically had to code around it.

Re:Ada was designed for multiple CPUs

[turgid]

However, one particular feature of Ada seems more suited to current hardware than other languages: it was designed to allow many computers/CPUs to communicate via the rendezvous. I don't believe that C/C++, Pascal/Delphi, or any of the most commonly used languages can say that.

Back in the late 80's/early 90's there was a descendant of Pascal called Modula-2 which was quite sophisticated and had co-routines as part of the language. There were a few compilers for the PC, including JPI Topspeed Modula-2 and a shareware one called Fitted Software Tools Modula-2.

I had the shareware one, and it taught me good programming style. I had done a bit of C previously, but Modula-2 taught me about structure, strong typing and encapsulation. It made me think hard.

There are Free and free Modula-2 compilers still available.

Re:Ada was designed for multiple CPUs

[quanticle]

The advantage of having support for thread synchronization built into the language is standardization. If you look at C you'll see myriad threading libraries for different OS and processor architectures. Its virtually impossible to be an expert in using all those different modules. Ada, by building such functionality into the language, provides a consistent interface, meaning the programmer only has to learn one threading model that can be portably used across architectures.

Re:Ada was designed for multiple CPUs

[nurbles]

"we could do it in C" is kinda what started this topic. Just because some of the popular languages have some synchronization (which is compiler and/or OS dependent, by the way) doesn't mean that the compiler will be helping you to check your intent at those places, or even if you're using sync where necessary. I don't remember Ada well enough to say it knew when synchronized access to data was necessary, but I suspect it did (or could).

As for everything ending up as machine language, well, that's just shorthand for dynamic wiring configurations made possible by transistors and gates... We can reducto ad absurdem, but that isn't relevent to the comments in any way. But, I can at least mention that around 1987 there was a company called Rational Ada (or something like that, they were in Mountain View, CA) that had an Ada hardware platform that did dynamic type and range checking in parallel with execution. So on their platform, even the ML was 'Ada' in that it had strong type and range rules.

FWIW, I am now a C programmer, and have been for the past 24 years. The USAF sent me to Ada class, and it looked "neat" but my department had no access to a fully validated compiler nor hardware to run any of those that were just starting to become available. So I never got to do anything "real" with it. Just playing with toy implementations like GNAT that weren't validated. (Remember, this was in the late '80s -- GNAT might be validated now, I don't know.)

Re:Ada was designed for multiple CPUs

[Col Bat Guano]

Just playing with toy implementations like GNAT that weren't validated. (Remember, this was in the late '80s -- GNAT might be validated now, I don't know.)

Compilers are run by a formal test (ACATS (http://www.ada-auth.org/acats.html)), but the Ada name is no longer trademarked (which required companies to validate before they could market their compiler as an "Ada" compiler).
Gnat is certainly an up to date compiler and implements all of the features required in the language, and has been instrumental in adding new features which have subsequently made it into the language in subsequent revisions.

Re:Ada was designed for multiple CPUs

[fitten]

I agree with you somewhat.

However, in practice, there are basically two threading/synchronization libraries/models... POSIX and Windows. The advantage of POSIX threads is that it is supported on just about everything, even where Ada doesn't exist (some embedded systems) and has interfaces in many languages, not just one, so it's API is similar across many languages/platforms - learn it once and use it in your favorite language(s), even as your project changes and the platform/languages change.

Then there's Windows threading (and even some POSIX support) that's on... well... Windows platforms.

Re:It is not just the language

[dprovine]

I think that any strongly typed language with lots of compile time and link time checks would be about as good (e.g., Java).

In Ada, you can declare a variable to be an integer in the range 1..100, and if it goes outside that range at any point during its lifetime, an exception is immediately thrown. In most languages, you'd have to check it every time you assign it.

Also, you can declare subtypes which not only define ranges but wall themselves off from each other. If you declare "MonthType" and "DateType" as types, and then ThisMonth and ThisDate as variables, you can't say assign ThisMonth to ThisDate (or vice-versa) without an explicit cast, even if the value stored is within range.

I programmed in Ada more-or-less exclusively for a year, with all the warnings possible turned on, and it did change a bit how I think about programming. I always know, instantly, what type any object is and what its limits are, because I got so used to thinking about those things when using Ada.

Not that it's perfect, or the ultimate, or anything. I had a job where I wrote C only for about 2 years, and that definitely changed how I thought about programming too. When writing C++ I have sense of what the computer is going to have to do to actually run the code.

There's a quote that any language which doesn't change how you think about programming isn't worth knowing. Ada built up my mental macros for making sure my types and values were in order, and for that alone it was worth learning and using for a year.

Re:I clicked too early...

[eclectro]

... i thought this story's title read, "the return of ABBA."

ABBA was an early 80's rockband. ADA was an early 80's programming language. ABBA is seeing a resurgence in interest now. ADA is also seeing increased in interest now. ABBA consisted of four singers, and ADA consisted of four programming languages.

Coincidence? I too think not. Take a chance on it.

Re:It is not just the language

[Alistair Hutton]

I think that any strongly typed language with lots of compile time and link time checks would be about as good (e.g., Java). Java, all the verbosity of Ada without any of the benefits. I can't work out how Java managed to make programmers type so many characters without achieving anything. Java's compile time checking is decent but seriously weak when compared to Ada. I've always liked the Ada compiler pointing out my spelling mistakes :-)

Experience with ADA

[MagnumChaos]

I had ADA in all 4 years of my college schooling, and I have just graduated in December. ADA is a complicated, cumbersome, yet extremely powerful and EFFICIENT language than many other popular varieties. I have seen this through experience. Programming algorithms and doing numerical analysis may seem difficult at first with ADA, but when you break the algorithm down into its necessary steps and requirements, creating packages that can inherit when needed, and check the packages and program for errors and bugs in the code at compile time is a blessing. It has saved me from doing extra work in all of my classes, and has helped prevent me from making the most horrible, and embarrassing mistakes. It's also a great language to learn as your first programming language. The concepts it can help introduce and refine is just great. I'll be honest, too. I'm not a very good programmer, but ADA, in the long run, helped me write my code better than a C/C++ compiler could have.

Ada never went anywhere...

[nullkill]

My first three foundation CS courses (back in 2001) were all taught in ADA. This provides the benefit of qualifying me to talk on the subject, with the drawback of providing a heavily biased opinion...

Because of the nature of the language, you HAVE to know what you are doing to write a program in Ada. Getting something to compile in Ada pretty much guarantees you get something that will run reliably.

Schools that train programmers starting with Java or C++ provide the benefit of making their graduates highly employable, but with a greater risk of turning out highly incompetent programmers.

Ada never went anywhere, there has just been a large increase in the number of developers trained on other languages. The reason its 'Returning' is because almost any Project that uses Ada does provide for a success story (As long as you use developers who have been trained on Ada (Googling for source examples is not training)). Its a professional language for applications that just have to run. (Examples of great software written in ada: (Air Traffic Control, Flight Software, Hello World, etc...)

As I said, my opinion is biased.

Re:In Soviet Amerika

[zienth]

Please don't feed this troll.

Hurray!

[Zarf]

I worked in Ada for a few years. I guess I better go and dust off my books.

And, here I spent all that time learning Java. Sheesh.

Political Agenda

[David Greene]

Look, can we get beyond the "government is always inefficient" meme? It's just not true. Many government projects come in on schedule and on budget. Some project are late and over budget. Guess what? It happens in the private sector too.

Government is actually more accountable to the people than private corporations are. Numerous cost controls are in place. Public officials are elected. I have not seen the same level of scrutiny in the private sector.

So let's move beyond the ultra conservative and libertarian talking points, ok?

Re:Political Agenda

[DocHoncho]

So let's move beyond the ultra conservative and libertarian talking points, ok?

But but but Reagan said...

Re:I clicked too early...

[skoaldipper]

Take a chance on it.

Was expecting "take a chance on me" instead, but I got it.

Overall, well done, sir. Well done.

Oh, yeah, and by the way, is it any coincidence that they're both anagrams? And, what's really surprising, if you mathematically extract the alphanumerics; ABBA = ADA; where A=1, B=2 [...] Z=26. Coincidence? I think not too.

Less about language, more about scheduling

[galen]

Speaking from my own experience as a software "engineer" working on defense contracts for the last decade, I would say their success on this project is more likely due to proper scheduling/budgeting than whatever tools the developers used. More often than not, when estimating schedules and costs for software projects managers and developers both tend to focus on code implementation time and forget about thorough design, testing, and rework time. Add to that the nearly inevitable requirements changes that occur over the life of a project and you have a disaster waiting to happen.

In my time I've seen several projects succeed and several projects fail. Those that succeeded always began with a robust and flexible design that would allow for growth and changes down the line. Those that failed were often rushed to implementation with just enough design to get the job done, then struggled to keep up with customers' changing requirements. I've seen every major programming language, development environment, operating system, and tool du jour used on both sides of the succeed/fail fence and never once did it make a bit of difference to the success or failure of the project. Personally, I'd be much more interested in seeing this project's WBS than hearing about how Ada may or may not have helped.

(As a parenthetical side note, there is definitely a dis-incentive to succeed in that those contracts that get dragged out year after year struggling to appease the customer continue to get funding while a successful project's funding ends when it's scheduled to end, leaving the development team looking for more work.)

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:In Soviet Amerika

[Anita Coney]

We're talking about an alleged "addiction" to oil. In the US only 7 percent of our electric power is created from petroleum. Therefore, 93% of our electricity is not created by oil. So, what exactly is your point about France? Thanks. I won't be holding my breath.

Reminds me of structured programming

[shoor]

Back in the 70s there was a big fuss being made about something called "Structured Programming". A lot of people took notice when a big project, an indexing system for the New York Times was finished with remarkably few errors. Yet, that success did not seem to become the norm. (It's mentioned briefly in the wikipedia article on 'structured programming').

COBOL used to be touted as a great language because it was 'self documenting'. Yet a lot of retired COBOL programmers got a last hurrah when they were hired to update obscure code in this 'self-documenting' language to handle dates with the year 2000 in them back at the end of the 90s.

Basically, I think what it boils down to is discipline and talent in the development process. That is far more important than the choice of language. To some extent, I would buy the idea that the fewer lines of code required to write out a program, the better, because there are fewer chances of errors. But even that can be taken to extremes in a language like APL, or if the lines refer back through obscure nests of classes. By few lines of code I mean a few readable lines of code that a programmer can look at and actually know what is supposed to be happening and how.

Re:In Soviet Amerika

[maxwell demon]

According to this statistics, about 1/3 of the energy in France comes from oil (or at least, came from oil two years ago), with another 1/7 from natural gas. Remember, electricity is only part of the energy consumption. Electric cars are the exception, and so is electric heating of buildings.

Having 33% of your energy production dependent on oil can well be considered "addicted". Would the oil sources disappear over night, you'd certainly have much trouble (as would the rest of the industrialized world).

inevitably

[fred fleenblat]

I think the main issue that people are afraid to talk about here is that Ada will soon be replaced by a language based entirely on cat macros.

50k line projects.. so could be in C

[Maxo-Texas]

Nasa...
There was a period where any program projected to be over 50k lines had to be in Ada.

So they did the only logical thing.. broke projects into 50k line components.

Upsurge in the use of Ada

[lbrenta]

I am glad to confirm the upsurge in the use of Ada. Google Groups had a thread about that just a month ago: http://groups.google.com/group/comp.lang.ada/msg/edc2dd0acb7bed50

ada sucks

[lordholm]

I write code in Ada at the moment. It is part of the data handling used in a satellite.

Although it is decent for the application side, the parts I am writing deals with low level access to the hardware, and for this Ada absolutely SUCKS big-time.

Also the typing system is ridiculous, basically, you define a new type for everything, with certain constraints (this is part of enhancing safety). But, this means that you have several hundreds of types to track, it would be better if the constraints were enforced in contracts for the functions and procedures, but no, that is not how Ada works, instead I spend about 30% of my time looking up type definitions for various integer types.

It is a very sucky language that force you to write more lines of code and makes it difficult to write unit-tests for your code (without having the unit test in the same package as the code, but we are of-course not allowed to embed the unit tests in the flight software).

Anyhow, Ada suck!!!

Re:ada sucks

[SteveAstro]

Its not "sucky" if the code works, is resilient and debuggable. Points aren't awarded for how few lines you can get away with.

Steve

Re:ada sucks

[bnenning]

Points aren't awarded for how few lines you can get away with.

Lines you don't have to write don't have bugs.

Re:ada sucks

[SteveAstro]

Thinking and writing type declarations stops bugs....
Steve

Re:ada sucks

[jmccabe]

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.

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 :-) 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.

Re:ada sucks

[lordholm]

Yes, you can do things with child packages. But in order to squeeze out the last percent of coverage, sometimes, you need access to the internals of the package.

The problem with Ada is that you cannot do that, unless you move all the package state into the spec (well, the private parts in the spec). This said, the problem is that the encapsulation rules of the Ada language makes unit-testing with 100% coverage very difficult and time consuming.

As said, there is a lot of things that you CAN do in the language, but they are not necessarily simple and easy to do. The encapsulation rules in Java are much more suitable for writing good unit-tests.

I do think that as part of the application layer of the embedded software, Ada is decent. But for the system layer, the language is more a nuisance.

One of the key issues is that the language actively encourages verbosity over clarity, meaning that something that you could write as one line of C (and very easy to read C by the way), can sometimes span several lines in Ada, which mean that you spend more time reading and trying to understand the expression because it is so long, this is especially noticeable when expressing complex bit wise expressions.

Ada forces more design ...

[AHumbleOpinion]

Oddly, they're saying a language which is slower for people to write, and considerably more obscure than most languages, is the reason something is done under-budget and quickly? It seems like those traits would make it more secure, but take much longer to make...

Ada may force more up front design and less seat of the pants hacking. This can lead to fewer bugs and less reworking of code. Some of the worst code I've seen came from otherwise intelligent people who jump write in and expeditiously write a lot of code fast rather than taking some time to think about things. Sadly, others end up having to spend time cleaning up such messes, or it ships and users end up with buggy code.

I'm usually not happy with things in C/C++ until the third rewrite, perhaps in Ada I'd be happy on the second rewrite. :-)

C A R Hoare on Ada

[jchandra]

Hoare had written an interesting paper on Ada titled The emperors old clothes on Ada.

He writes

And so, the best of my advice to the originators and designers of ADA has been ignored. In this last
resort, I appeal to you, representatives of the programming profession in the United States, and citizens
concerned with the welfare and safety of your own country and of mankind: Do not allow this language
in its present state to be used in applications where reliability is critical, i.e., nuclear power stations,
cruise missiles, early warning systems, anti-ballistic missile defense systems. The next rocket to go
astray as a result of a programming language error may not be an exploratory space rocket on a harmless
trip to Venus: It may be a nuclear warhead exploding over one of our own cities.

Re:C A R Hoare on Ada

[EdF]

Hoare later recanted this bit, and strongly recommended the language as a foreward to one of its textbooks.

Re:C A R Hoare on Ada

[jmccabe]

... 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.

The reason for ERAM success

[oecocsystems.com]

I am Oliver E Cole, the president of OC Systems (oec@ocsystems.com). The Ada compiler and associated tools used by ERAM is PowerAda, done by OC Systems. We have worked closely over a number of years with the ERAM project and its predecessors. Yup, they are using Ada because of all its robustness and features, but they also have a good mature software development process. Part of a muture process is choosing the right language and tools for the job. Sometimes php is the right choice, sometimes C, C++ and sometimes Ada. For a project like Air Traffic Control (very long lived, high quality) a strong argument can be made for Ada. Ada catches a lot of errors "automatically" and is designed for big systems.

Re:The reason for ERAM success

[Anonymous Coward]

Oliver,

I worked with your tools on this project. They worked great. I agree that Ada was the right tool for this job. I also have the opinion that Ada causes programmer burn-out and it is highly probable that not all the code in the system that was in Ada should have been in Ada.

Re:I clicked too early...

[fitten]

Unpossible... ABBA's drummer died a few weeks ago :(

lolcode.com

[jediknil]

(In case anyone doesn't get this, it's already here, albeit not yet complete.)

Re:lolcode.com

[fred fleenblat]

OMGPONIES!!!!

As a Delphi developer

[Windcatcher]

I must admit I wished Delphi had some of the features that Ada has (though there appears to be a lot of commonality). Delphi is already awesome, but with some of Ada's features it would be uber.

Not OO

[ucblockhead]

Ada didn't fail because it was hard to use. Ada failed because it had the misfortune to be a non-Object Oriented language that arrived right when the object oriented paradigm was taking the software engineering world by storm. It's a bit of a joke to blame its failure on being difficult given that it showed up nearly the same time C++ did.

Re:Not OO

[wfstanle]

I don't think that you know what you are talking about. Yes, Ada-83 was not OO but Ada-97 and Ada-2005 are OO ( with caveats ). The exceptions to OO lead to more secure code.

Re:Not OO

[ucblockhead]

You said it yourself: Ada-83 was not OO. That is why it failed. C++ first hit in '85 and OO took off in the late eighties. By the time '97 rolled around, Ada was already long dead in the market.

Ahead of schedule

[leuk_he]

"ahead of schedule and under budget, which is something you don't often hear about in government circles"

If you put your double(or more actual, tripple it up) up schedule far ahead enough, let sales cut it in half, you can actually do a project on time.

High Integrity Systems

[blue_teeth]

Don't know why is this news. Ada is used in High Integrity System
for long long time.

http://www.praxis-his.com/sparkada/index.asp/

Cheers
BT

Ada does ASICs

[FBSoftware]

Your comment indicates that you don't really know how to use Ada. I use Ada to write what are basically device drivers for complex ASICs. I would argue that Ada is the very best choice for low-level hardware interfacing because it supports precise specification of data layout (size, endianness, record bitfields, etc.) Done right, all of this is a compile time activity without any runtime penality. Ada is also a good language for writing simulations of hardware.

You certainly don't have to (and shouldn't) create new & different types for everything. Types (should) arise from thoughtful design.

Re:Ada does ASICs

[lordholm]

I do know how to use Ada, and in fact, for some tasks it is pretty good (protocol decoding for example).

But you have to basically define your record type twice in order to do this.

My assertion is that it sucks for low level hardware access because you need to write arbitrary data to hardware (yes it is possible, but it is cumbersome), some time (a lot of times actually), you need to do type punning, and this is just cumbersome in Ada (yes you can do it, but it is painful), and sometimes you need to add inline assembly (yes, you can do that in GNAT, but finding the documentation for this is not the easiest task).

Also, most low level issues are horribly badly documented (such as calling conventions), and there are no shift operators, meaning that your code will be littered with X / 2**Y (making the code more or less unreadable), there is also no way to properly do an arithmetic shift in Ada on a modular type.

Further, the language does not separate the keywords for bitwise or and logical or, which leads to statements that are not very easy to grasp on the first view. The language also actively encourage a ridiculously verbose code style, that actually makes the code more difficult to read, since you need to read more lines (or longer lines) for what can be expressed in a more compact form.

Further the rules for pointers and whether they can be passed into other functions in Ada are encouraging the use of global variables (a guaranteed way to fail if your program is using multiple threads).

Not to forget the idiocies with the package system, causing weird issues like circular package dependencies (Java did it right in this aspect).

Other complaints I may add is that all the Ada compilers that I have played around with are horribly slow.

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).

There are a lot of things that you can do in Ada, but the syntax that have been adopted is designed to force programmers to write two times as much code as is actually necessary.

Re:Ada does ASICs

[darkwing_bmf]

"Also, most low level issues are horribly badly documented (such as calling conventions), and there are no shift operators, meaning that your code will be littered with X / 2**Y (making the code more or less unreadable), there is also no way to properly do an arithmetic shift in Ada on a modular type."

Check out the "interfaces" package included with the language. It has all of these things (at least in Ada95).

Re:Ada does ASICs

[Col Bat Guano]

I do know how to use Ada, and in fact, for some tasks it is pretty good (protocol decoding for example).

But you have to basically define your record type twice in order to do this.
You have to define it once, then define how it is laid out. You only do it once, and it helps separate the logical from the physical. I don't think it's that big a deal.

My assertion is that it sucks for low level hardware access because you need to write arbitrary data to hardware (yes it is possible, but it is cumbersome) How is it cumbersome? Define an address and poke data at that address. Use the generic System.Address_To_Access_Conversion and you'll be sweet.

Also, most low level issues are horribly badly documented (such as calling conventions)
You can specify a calling convention (e.g. pragma Convention (C, myfunction);) which causes you to use C convention. Scalars are passed by pass in, pass out, other variables are passed by reference (this is defined in the language).

...and there are no shift operators, meaning that your code will be littered with X / 2**Y (making the code more or less unreadable), there is also no way to properly do an arithmetic shift in Ada on a modular type.
I don't know what version of Ada you are using, but Ada95 (the 13 year old version of the language) has package Interfaces, which defines Shift_Left, Shift_Right, Shift_Right_Arithemetic, Rotate_Right and Rotate_Left as intrinsic functions (i.e. direct code inserts) for all the major data sizes.

Further the rules for pointers and whether they can be passed into other functions in Ada are encouraging the use of global variables (a guaranteed way to fail if your program is using multiple threads).

The rules are to prevent dangling pointers. They don't cause real problems - define your types and access types in a package at the library level, and you'll never have any problems. Think about how what a pointer is pointing at (stack based variable?) and realise that Ada's normal access types won't leave you with a dangling pointer and you'll understand how they work.

Not to forget the idiocies with the package system, causing weird issues like circular package dependencies (Java did it right in this aspect).
Yep it was pretty silly. They finally fixed it with Ada2005, but I think the syntax leaves something to be desired.

Other complaints I may add is that all the Ada compilers that I have played around with are horribly slow.

The Gnat compiler is the one I'm most familiar with, and it seems to run ok. I certainly like the quality of its error messages (the best I've -ever- seen).

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).
You'd need to show us code that would be faster in the C world than it would in the Ada world. There is nothing intrinsic to the language that prevents similar features from being compiled into the same code.

Re:Ada does ASICs

[jmccabe]

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.

John

Re:Ada does ASICs

[lordholm]

Interesting article indeed. But this is not really any news, handwritten assembly is not efficient on complex CPU architectures such as modern CPUs or DSPs (with a few exceptions naturally). It started already with the first RISC machines in the early 80s.

Re:Ada does ASICs

[jmccabe]

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).

Re:Ada does ASICs

[lordholm]

A lot of languages can be optimised more than C due to C's pointer semantics. Especially troublesome is that two pointers may alias the same objects (this is especially noticeable if one compares C with Fortran).

It is however possible in C99 to use the restrict keyword to tell the compiler that aliasing is forbidden, this put C on par with Fortran in speed on big mathematical problems. This is also an issue when comparing C with Ada, but easily addressed with restricted pointers.

By the way, I assume you are the same McCabe that shows up in the code complexity measurements that we produce.

Re:Ada does ASICs

[jmccabe]

By the way, I assume you are the same McCabe that shows up in the code complexity measurements that we produce. oh no - I'm not that old! :-)

Maybe a language that has learned from the past

[donglekey]

Maybe it would be best to use a language that is just as fast (or faster) than C++ but has learned from the past like D. The language is maturing yes, but the design is excellent.

Ada is not fun

[caveman]

I guess the Internation Obfuscated Ada Code Competition is a non-starter then.
(Notes that ioacc.org is unregistered)
Compare IOCCC

Ada: When it HAS to be correct

[dwheeler]

Ada has a lot going for it when it "has to be correct every time"; that is its main purpose. The big advantage is that the language maximally checks everything at compile time - so if it HAS to work correctly every time, that's a big plus. It also has more run-time checks. It even has some extra features that let it be more specific. It has a nearly-unique ability to specify number ranges; if you spec a variable as being in the range 1..100, then any attempt to assign outside that range is immediately detected. That turns out to detect lots of errors before they get out of hand. It's not the best language for EVERY purpose, but it has its place. I have a tutorial here, if you're curious: Lovelace tutorial.

Re:In Soviet Amerika

[rk]

If Anonymous posts bother you, set them to -6 score in your preferences, and as long as you read posts with your threshold at 0 or more, you'll never see them.

Re:It is not just the language

[ghjm]

I agree that learning the most interesting programming languages changes the way you think about all programming languages. And certainly, C makes you think more about what's going on under the covers, which is undoubtedly a good thing.

But when writing C or C++, you really only have a sense of what a VAX or PDP-11 would have had to do to run the code. You don't have a very good sense of what a modern processor actually does - nothing in C or C++ gives you an intuitive understanding of pipelining, of the cost of cache misses, etc. If you look at the object code produced by a good modern optimizing compiler, you would probably be surprised how far it departs from what you thought you were doing.

So while C does give you some slight exposure to low-level concepts, in the modern age it really doesn't serve as a good substitute for actually hand-writing some assembly code. It's a bit like taking a walking tour of Paris using an audio guide narrated by Peter Ustinov in 1972. It's hard to separate the Paris part from the Ustinov and the 1972 parts.

-Graham

If Ada, why not Delphi? Component Pascal?

[Latent Heat]

In some ways, Delphi has its own problems with the way Borland has decided to implement Object Pascal in a quirky way and all of the Windows-specific features that probably should be in a library -- the language is otherwise pretty much tied to Windows these days.

But of all of these Pascal-derived languages, why Ada? What about Wirth's Component Pascal? But how about Delphi?

The thing about Delphi is that it compiles like a bat-out-of-Hell while last I heard Ada compilers are these complex ponderous things. A lot had to do with Delphi preserving enough of the structure of Pascal that was compiler friendly; the word I heard is that Ada is far from compiler friendly.

Why worry that a thing is compiler friendly -- should it not be programmer friendly at leave the work to the computer. Yes, up to a point, but if something is not compiler friendly, how are we to know that the compilers don't have hidden bugs? Besides, fast compiles means something, even on Core-2 Duos and all of that. Have you compiled anything under Delphi lately and compared that experience to anything else?

You could say the ultimate in compiler friendly syntax is Lisp, but I think there has to be some middle ground some something more infix and readable. I think that Delphi, or at least Object Pascal if you are thinking other platforms (think Free Pascal) is that middle ground, not Ada.

"Why Ada succeeds where C fails"

[airdrummer]

i worked in ada, late '80s, early '90s, alsn, wrote a troff clone;-) i had just learned c & chafed @ the strictness (i don't need no steenkin compile-time checks;-) but i grew to appreciate it...definitely leads to better code.

http://www.adaic.org/atwork/trains.html gives an interesting case history of the superiority of ada for teaching real-time programming:-)

" The only difference between the years in which teams succeeded in implementing their projects and those in which no team succeeded was the implementation language."

A small nitpick about Ada Spark

[fnc]

It is not exactly a extension of Ada. It is actually a subset of Ada that can be annotated and statically analysed. That said it was an interesting article. Ada had many problems when it started (bad and expensive implementations, since it was a big topdown design with many inovations - I think it was the first language with generics), but is probably the best system language nowadays for things that do not use garbage collection (things that are usually done with C/C++). And since there is an current free Gnu Ada compiler (Gnat), it should be more used.

Rats, "Committee" Cliche hurt

[Tablizer]

If it gets in style, it will be one less cliche example of "see what happens to things designed by committee?"

Re:Rats, "Committee" Cliche hurt

[Alistair Hutton]

Dude, (modern) C++ is what happens when you design by committee. Ada is what happens when a small technical group is convened to come up with a general purpose language.

Typically poor tools

[LostMyBeaver]

Last time I programmed Ada was for a class in the University around 1991. What I recall is that language documentation was poor at best. I also recall that the compilers generated error messages which must have been worded to save ink on the teletype.

This article has convinced me that maybe I should evaluate if Ada has advanced, but I'm predicting beforehand that given the minimal interest in it, it probably has not come too far during this time.

If I find otherwise, I'll come back here and eat my words.

P.S. Back then, the libraries were not quite so huge hehe

Re:It is not just the language

[smellotron]

> In Ada, you can declare a variable to be an integer in the range 1..100, and if it goes outside that range at any point during its lifetime, an exception is immediately thrown. In most languages, you'd have to check it every time you assign it.

I know it's not the same, but can't you get the same effect in other languages?  In particular, C++ can be used to implement numbers with ranges and units.  Something like this...

template <int min_value, int max_value, typename type_tag>
class checked_integer;

struct distance_tag { };
struct time_tag { };
struct speed_tag { };

typedef checked_integer<1, 100, distance_tag> distance_t;
typedef checked_integer<1, 10, time_tag> time_t; // whoops, colliding with C runtime, ignore that
typedef checked_integer<1, 10, speed_tag> speed_t;

// add some other function or template specification that distance / time = speed

meters_t distance = 30;
seconds_t time = 5;
speed_t speed = distance / time; // compiles
meters_t whoops = distance / time; // doesn't compile

meters_t distance = 100000; // throws exception when instantiated with out-of-range value

Has ADA really been forgotten?

[Uncle Phat]

Anyone noticed how similar PL*Sql (Oracle) and TSql (Sql Server) are to ADA? Even Oracle Forms uses an ADA like language for all it's behind the scene's coding...

Ada != enterprise?

[tgv]

Are you telling me that you can't do enterprisey architectures in ADA? But where would we get our daily dose of humor (http://thedailywtf.com/ from then? This has to be stopped!

Productivity (or the lack thereof)

[david.emery]

Here's another Ada experience:

Where I used to work, we did an IR&D project on incremental formal verification, using SPARK (a provably correct subset of Ada, see http://www.praxis-his.com/sparkada/ ) We were implementing a subset of the SCPS protocol, a variation on TCP designed for satellites and large latency networks. I coded the sequential processing in SPARK, and added 'normal Ada' for the concurrent/timing related aspects. (This is before SPARK added support for concurrency.) As our control, another guy with experience doing protocols coded the same stuff in C.

One thing we needed to code was the timeout in TCP/SCPS, i.e. "send a message and wait N milliseconds. If you timeout, generate an error." I knew this should be doable with Ada95 Asynchronous Transfer of Control, a feature of the language I hadn't used before. I read the RM, talked to Ben Brosgol :-), and then wrote 5 lines of code. The 'control' doing his code in C spent the same amount of time writing 200 lines of code.

Guess which implementation had a bug in it?

But by conventional cost/size/effort/productivity models, he was 40 times more productive that week than I...

dave

Strong typing and Java weakness

[david.emery]

People rarely add apples to oranges. But they often screw up and add count-of-apples to count-of-oranges, i.e. most type errors are made with scalar types. And that's a problem I have with Java. In Ada everything can be strongly typed (and you learn from experience just how valuable typing scalars can be after a while...)

  In C, things like typedef and lint can be your friends here.

But in Java, scalars are weakly typed, and I haven't seen any practical way to add this on, e.g. with a standardized pre-processor. I think that's a significant weakness in Java.

dave

ADA is perfect for this type of system

[briddle]

ADA failed in use as a general purpose language only because it was never intended to be one. It was designed for the US Military as a language for aircraft autopilots. Until ADA, every new aircraft autopilot's chipset was programmed with its own proprietary assembler and compiler. There were nasty crashes because each new aircraft essentially was running version 1.0 of the autopilot. ADA was designed from the ground-up to be for "man-rated" systems - systems where lives were on the line if the system failed. With ADA, each new autopilot's bidder merely had to provide ADA for the chipset and existing, proven autopilot code could be re-used. ADA is outstanding for that purpose and saved the military a ton of money and issues. ADA is designed such that it can handle and restart after virtually any kind of failure. And it is designed such that, if a program compiles, it will almost never fail. It may not do what you want it to, but it will almost never outright crash. Unfortunately, the US Congress saw the success ADA had and decided that all new US code should use the same approach. But ADA is a poor language for general usage for several reasons. One is that wants to be the ultimate supervisor rather than subject to another supervisor. Another problem is that there are absolutely no standard bindings or API's for business processes like reporting, databases, sorting, etc. And a third problem is that it takes far longer to program since constructs that save time to program but might be done incorrectly do not even exist in the language. But an air traffic control system doesn't need business API bindings, doesn't have to be just one more sub-program in a general purpose OS environment, and can endanger thousands of lives if it fails. That is a near perfect match for ADA. I have written ADA for military projects and have professional code running in 13 other computer languages over the last 30 years, so I feel qualified to comment on this. People who compare it to dissimilar languages like C, C++, T-SQL (give me a break), either do not know ADA or never really understood it. It really is the right language for a man-rated system.

ADA - Pascal - Delphi

[Corson]

Ada has turned into Pascal in the '80s and then into Delphi in the '90s.

It is not surprising that Ada is going through a "rediscovery" phase. A few days ago I was discussing with a professional software developper the pros and cons of Java and I realized that C programmers who migrated to Java did so for some of its features that Pascal had long before Java was even "born". It is likely that most Java programmers were never exposed to either of Ada, Pascal, or Delphi. Perhaps it's not too late; a fully featured, non-time limited, free version of Delphi (Turbo Delphi Explorer http://cc.codegear.com/free/turbo) is available from Codegear, the Borland spin-off.

Ada isn't just for Defense

[Void_Ptr]

Many commercial flight management systems are written in Ada. Ada is a MUST HAVE skill if you want to work in Aerospace, either military or commercial.

Re:In Soviet Amerika

[petermgreen]

Electricity is NOT what the "oil addiction" is about. Afaict no first world country gets a significant portion of their electrity from oil because it just doesn't make economic sense to generate electricity from it. Most electricity comes from coal, natural gas, dam based hydro or nuclear.

Afiact europe tends to be less sensitive to oil price increases than the USA because of tax structures that have discouraged SUV ownership and better public transport networks. but we europeans would definately be hit hard by a major oil shortage.

Ada worked well for teaching

[Robb]

Ada was always a really nice teaching language as it forces the programmer to be very specific in thinking about why and how their code is going to work. An interesting property is that the more "clever" you try and get the more verbose you have to be (casts and conversions have to be explicit). This means that if actually required they tend to get encapsulated behind a clean interface just because they are so ugly.

Ada

[multiplexo]

You'll hate the compiler, but you'll love the whip and jackboots.

Late binding.

[krischik]

Actually the only OO features missing Ada 83 where late binding and inheritance for record types.

Ada 83 had:

* Operator overloading.
* Function overloading.
* Generics.
* Inheritance for primitive types (type Day_Of_Month is new Integer range (1 .31);)

The later became important later when inheritance "as we know it" was added: It fittest perfectly into the existing type system.

Saying all that: Late binding was the "hype" and it was missing.

Martin

Re:Late binding.

[ucblockhead]

C++ doesn't have late binding. Inheritance for "record types" is required for OO. Neither operator overloading, function overloading or generics have anything to do with OO. "Inheritance for primitive types" as is pretty trivial, existed in Pascal, and is hardly anything to do with OO.

You don't even mention polymorphism, which is the essence of OO.

So when you say "the only features it was missing", you mean "it had none of the features that make a language object oriented".

Re:Late binding.

[Weedlekin]

First you say "C++ doesn't have late binding", and then "You don't even mention polymorphism, which is the essence of OO".

Polymorphism, late binding, and dynamic binding are different ways of describing the same thing, so if, as you claim, C++ doesn't have late binding, then it cannot have polymorphism, "the essence of OO".

Re:Late binding.

[krischik]

Hmm, "function overloading" not needed. True, but it would mean that the following would not be possible:

class A
    {
    void print ();
    }

class B
    {
    void print ();
    }

and that would result in a very poor OO language.

And as I said Ada 83 could do:

type A is record ... end record;
type B is record ... end record;

procedure Print (this: in A);
procedure Print (this: in B);

And no, Pascal did not have "Inheritance for primitive types". Pascal only had range type.

Ada has:

type Circle is new Float range 0.0 .. 360.0;
subtype Quarter is Circle range 0.0 .. 90.0;

If you know Pascal you know that in Pascal you could not specify the parent type of an range and neiter could you specify ranges for floating points - it was allways Integer.

The later is especialy restricting as it prevented:

type Byte is new mod 256;
for Byte'Size use 8;

Martin

You got the order wrong.

[krischik]

Pascal was first. Ada and Delphi are both Pascal decendens - that is Ada and Delphi are sibelings.

Martin

Re:what I don't like about python

[cduffy]

For those who don't know enough Python to see this as a troll -- this could only happen in such a way as to cause undesired flow control (rather than an up-front parse error) if one isn't following PEP-8 conventions and is mixing tabs and spaces. Newer interpreters will stop this from happening anyhow, and static checking tools for Python will catch it (and have caught mixed-whitespace conditions for ages).

If one is following PEP-8, a single space being wrong could cause an up-front syntax error, but never invalid runtime behavior.

So, to the parent -- if you genuinely allowed code that won't pass pychecker (or even allow a module import w/o raising a syntax error) onto a production system, you might as well upload C source to a critical system without so much as compiling it on dev or QA hosts first; either way, you deserve what's coming to you.

Re:the imminent return of the really cool language

[Haeleth]

Fortran and cobol are recently making a comeback as well. It seems to be cool, again. Does this mean we will see them as a .net application? Suppose so.. I can see it now Visual Cobol, and Visual Ada and Visual Fortran....

What do you mean, "will see"? They're all available already! For COBOL, see e.g. NetCOBOL or Net Express. For Fortran, try Fortran for .NET Language System. For Ada, there's A#...