From my point of view at the time, any language that the US Government would mandate as a required technology MUST be flawed. A language embraced by a large bureaucracy must be full of large bureaucratic nonsense. That was the thinking, at any rate. Ada, along with Cobol, was a frequent target of snarky jokes. In the mid-80s, the cool kids were programming in C (while being paid to program in Basic or Cobol or Fortran).

I freely admit these notions were likely borne out of ignorance, but I imagine this reputation stifled its adaptation outside of government circles. Would you want to use a language mandated by the DMV?

C had the great advantage that a C compiler would fit in MS-DOS's address space with some room left over for the symbol table.

I've never hacked Ada; it seems to have been totally eclipsed by languages like OCaml that give you a rich type system and a good degree of speed, but when I was learning about programming and languages it seemed insane that people didn't go for Ada. Was being able to be sloppy really that alluring? Did people just love segfaults?

It makes a lot more sense to think of it in terms of irrational actors making choices for largely social/political reasons rather than calculated cost-benefit models.

Basically everything makes more sense that way. HN just had a big thread about the death penalty that illustrated this perfectly. Some people just believe things because they want to. It's really, really hard to be accurate to reality.

What could have been done to make Ada popular? How can we hack humans to prevent huge losses like this from occurring? What's the Ada of 2014?

One of the big drivers in language popularity in the long run is how many people can become familiar with a language by using it, and by having all the implementations be terribly expensive you're almost automatically limiting the number of people exposed.

I think companies that did this (much less so today than in the past) saw the languages as their profit centers, not the eco systems. Microsoft, Borland, Zortech and a whole pile of others were in a never ending battle to get the programmers on board. Every computer came with at least one programming language pre-installed (usually some form of BASIC). What you did after learning BASIC (and some of its limitations) was dictated by need and funds.

For most people that meant that their second language was some variety of assembler. For others to re-implement Forth (since that was doable). A C compiler was something you could still buy on a regular salary.

To get exposure to Lisp, ADA, Modula-2 or any one of a whole bunch of other high level languages required shelling out significant bucks. So during what we might refer to as my 'formative years' as a programmer none of these really nice languages made it to my computers.

While we're at it, I'd love to see some Erlang programmers take a look at Rust as well and tell us where we're falling down on concurrency. Sadly, both of these languages seem underrepresented in the circles that I frequent.

See: http://en.wikipedia.org/wiki/VHDL#Design_examples vs: http://en.wikipedia.org/wiki/Ada_programming_language#Language_constructs

Same "use packagename". Same "entity foo is", same block definition by "begin [...] end entity"

Coincidence, or is there a historical reason for this?

Edit: The answer was in the VHDL article itself: "Due to the Department of Defense requiring as much of the syntax as possible to be based on Ada, in order to avoid re-inventing concepts that had already been thoroughly tested in the development of Ada,[citation needed] VHDL borrows heavily from the Ada programming language in both concepts and syntax."

I'm making broad generalizations, but as examples, if you wanted to build a program to perform some numerical analysis or maybe build an analytical simulation you could pick fortran and you'd likely find libraries and examples to help you out. If you wanted to build a simple web page backed by a database you could grab php & some of its libraries and you would be quickly constructing web pages. With java you could find examples of tools / libraries for churning through databases and also plugging into various web application frameworks. If you wanted to write a PhD about computer languages you could use lisp :P. I've found great value in python personally because the examples were decent and more importantly it was easy to see how to build the programatic bridges into the other languages and libraries I wanted to use. I'd strongly argue that ruby and node.js popularity can be partially traced to seeing the "fun" and / or neat examples that are shown off in tutorials. They show how to leverage the constructs provided by each language's common libraries and the resulting programs are interesting / neat to some number of potential adopters.

In the 90s when I looked at ada there wasn't much in terms of libraries that I could leverage to explore problems that interested me at the time.

Again, not every language has to be ideally suited to writing video games or web pages to be useful. Ada the language might have outstanding academically interesting aspects. If it doesn't help me solve real world problems I care about though it's less likely I'll invest the time to learn about it.

1. Invented by and for a bureaucracy known for its extravagance and wastefulness.

2. Verbosity of a degree only before seen in COBOL.

3. A focus on avoiding errors above all else. For people who have a positive/benefits focus like most hackers, this negative focus is very unappealing and provokes references to anal-retentive pedants and so forth.

I would agree with others who pointed out the other problem "won't run on a computer I can buy - and anyway I can't afford the compiler". This is not to criticise the compiler developers but nonetheless it was a problem.

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

And yes, I do realize that the verbosity and safety are good qualities and certainly can teach a lot, but for a 17/18 year old who may have never seen a programming language before, its pretty crazy. It should definitely be taught at higher levels, so as to reinforce good programming standards and practices. Have a few years of wild screw-ups and crazy bugs and gain an understanding of why you need safety and so on.

Yeah, I liked Ada because it was very readable, and decomposition into smaller units was easy. I always liked the package concept.

Our compilations weren't all that slow. Maybe an hour or so for 500,000 lines of code. It was always best to compile units individually, not to build everything and compile all at one time. It could take days to get through compile-time errors that way. A lot were due to mismatching data types.

Once we tried to upgrade to a new version of the compiler, but couldn't get it to work with our legacy code. We had the vendor send us an engineer from Phoenix, and he could never get it to work, so we gave up and kept using the old compiler.

I hear Ada is still popular in Europe. There were a lot of useful improvements in Ada95 that eliminated some of the clunky features.

On large systems like ours we had subdivided the code into many separate functional units. Each unit consisted of a directory of multiple packages that all worked to perform a certain function. Each FCI directory would usually contain an interface spec and code for interfacing to any other FCI that needed to share data with it. There were a couple of ways to share data. One way was to send an FCI a message that we were putting data into shared memory, and then the other would grab the data. Another way was to just send a message containing the actual data. This worked ok for small amounts of data. I think to communicate with external devices at the lowest level we were calling c code.

Software engineering in a large project is actually more fun than in a small group I think. There's more activity and hustle and bustle. Also it does force a certain amount of discipline that one would rarely do on an individual basis. Some of the code reviews could be brutal. Or it least so it seemed.

Testing was always a challenge on the real hardware because it always involved multiple computer systems networked together sometimes with wireless devices, and it could be a challenge just to get them all stable and talking together, let alone getting your own code working. When we went to a test facility for a week or two to test we always kept our fingers crossed. Usually nothing would work for the first two or three days and then on Thursday and Friday the problems started to go away and were magically solved, and we could go home successful. It was always very nerve wracking because of course there was a whole management schedule that depended on it.

Of course the boring part was writing software requirements documents, software design documents, test procedures and the like. We weren't supposed to design while coding, and weren't supposed to write any code until our design was complete. But a lot of times we didn't know how to design it, so we would write code in advance and call it prototyping. But if we reused our prototype code we could get huge code counts during the code phase, because we had already written that during the design phase and charged it to design.

Since we got assessed partly by the amount of code we could write in a given time, sometimes you would find people, who instead of writing a subroutine would just duplicate the same code multiple times. It increased their code count. It really didn't pay to write really tight, highly efficient code because of the development time constraints. However, then during testing you might have to go back and fix it to perform better.

It just wasn't my thing, although I deeply admire the language. There has been fantastic new stuff in the 2005 and 2012 versions. Like the Ravenscar profile for embedded and safety-critical systems.

And just like the "Young Lispers" did with Lisp, Ada had some sort of renaissance, where a lot of Ada stuff was going into Debian and young Open Source people dreamt of re-writing the Internet. :-)

I think it was partly the tool chain that repulsed me. There is really only one compiler in existence if you're a hobbyist: GNAT.

Nowadays Adacore are pretty open, having a big Open Source compiler download page and all, but back then, you could get GNAT, as shipped with GCC, or "big GNAT".

GNAT, as shipped in GCC, was always at least one version behind, and since Adacore always hired everyone who got familiar with the GCC frontend, it was highly dependent on Adacore. So no "second source" where GCC maintainers could step up if Adacore ever left. The Ada frontend just was a second class citizen.

"Big GNAT" was something everyone would have liked to use, but it was expensive. So that was out of the question.

Well, I got it, as part of a special University cooperation program, but only after signing that I would only use it for the assigned coursework, that I would never distribute it to anyone etc. pp.

Oh, and how did Adacore manage to keep it closed? I mean wasn't the predecessor, on which GNAT was based, GPL'ed?

Yes, and "big GNAT" also was. Kind-of.

Rumor has it that Adacore basically told all of their customers unofficially "sure, you're legally free to distribute it, it's GPL after all. Just don't be surprised if we don't pick up the phone for a few hours when you need support".

As far as I know it never really leaked. For some time I was actively looking for some "big GNAT" archive on the net, but never found one.

Then I went into the real world, and !y first job was with Delphi (Object Pascal).

It's surprising no one discusses Delphi with Ada, because it had many of the same features with the same Pascal ancestry, but better tooling and aimed at commercial as opposed to defense work.

For a while it was very successful. It lost because of commercial reasons, but for a long time it was a better Visual Basic.

What. the.

Ada seems to have safety in mind, but isn't this achievable with static analysis ? Aren't there attempts to attach static analysis onto a compiler ?

The first semester all the students are introduced to basic programming concepts, and the language that's used for that is Ada. Then Ada is used to teach algorithms and compilation class. In fact in the second year, we had a full-time project where we wrote a compiler for a language close to Java (in terms of syntax and features), in Ada.

I remember being in my python phase at the time, and bitching at Ada's verbosity. But I realized how comfortable it is to let the compiler do most of the debugging for you, especially on very large projects that are structured as a pipeline (eg. a compiler, every part depends heavily on the other). When it compiles, it works 99% of time. Static typing/subtyping, generic package, all the time spent in the console with GNAT yelling at you really teaches you how to structure, secure and bullet proof your code. Ada really is a great teacher!

His argment that "Languages are accepted and evolve by a social process, not a technical or technological one." seems to apply here, also (in the context of the time) "Successful languages must have modest or minimal computer resource requirements."

A few years later (1988), I was working an a large military aircraft project that used Ada. We did a huge up front design with reams of design documentation. The first code that was written was a package of data types to ensure consistency. Unfortunately, there was very little Ada experience among the team and we sometimes designed ourselves into corners. Such problems were often solved by using "unchecked conversions" to get around the type enforcement, which defeated the purpose. The problems we had were similar to problems huge C++ projects would have a few years later.

The other problem we had was with the compiler. The government had placed high performance demands on the compiler, so it was highly optimized. Unfortunately, it would sometimes optimize away code that you needed. Fortunately, we could generate a code listing that interspersed the assembly output of the compiler with the corresponding Ada source code and thus find the problem. Usually adding an intermediate local variable to break up a complex calculation solved the problem.

In 1990, I got hired by a start up that was doing military contract work simulating radars for flight simulators. They had done all of their work in C, but now they had a contract that required Ada, so I became their "Ada expert." All of the C guys hated Ada because of its strictness. Ada wouldn't let you mix numeric data types without an explicit conversion, and that really chafed the C folks. It reminds me of today's dynamic/static typing debate.

The Navy ended up canceling the aircraft so they no longer needed our radar simulator. The next project I was on decided to use the new C++ language everyone was excited about. Ada was starting to fall out of favor, so waivers for the Ada mandate were getting easy to obtain.

At they time, I was thrilled to use C++. It seemed edgy compared to the bureaucratic nature of Ada. Now, however, I don't know if C++ was an improvement overall. It has some advantages, but also some disadvantages. I'm happy to see that the Rust guys are trying to learn from Ada. I was an inexperienced kid when I used Ada, so I am by no means an expert, but from what I do know, I think it still has something to teach us.

Ada has a lot of thing going for it I miss. It was rubust. Custom types (this is an int from 0-100, it goes out of range throw an exception). Records (structs) were nicely implemented. The package system really worked well for large software.

It was interesing. It suffered a lot from running on systems that are written in c. Although you can make system calls through a wrapper it was odd, so we wrote packages to interface with the underlying c libraries we need to call (java did this as part of core). We had a lot of libraries to make the networking and unix ipc work the same across our hpux and sun systems. The displays were written in C as it just wasn't really feasable in Ada.

It never reached the critical mass to get great tools, so debugging could be a pain. It didn't have a lot of useful third party libraries that make a language powerful and fun.

When your ada compiled there was a good chance it would work.

I do miss parts of it. When I see Go code sometimes I get flashbacks.

Ada's advantages start to really show when you deal with much larger pieces of software; what appears verbose or overly-strict at a smaller scale provides valuable assistance when dealing with large codebases.

Unfortunately, many seem to dismiss Ada after doing little more than looking at small code examples and complaining about verbosity...

So?

It's difficult to say but IMHO what he forgot is: the syntax. Ada was designed to be verbose, I think that programmers don't like verbose syntax.. Did someone tried to make a terser syntax for Ada? Elixyr seems to revive interest in Erlang, so..