Who's Using Ada? Real-World Projects Powered by the Ada Programming Language
seas.gwu.edu
seas.gwu.edu
Ada has a c binding package so it can call down to the OS libraries (networking, shared memory), which is great, but kills some of the niceness of living in an ada world.
When I was trying out GO, I got a little ada flashback for some reason.
The package system was good.
I disliked ada strings though.
When I left the industry, they were looking for alernative languages for new projects. GCC Ada compiler was being considered for maintaining older projects, seemed decent. http://libre.adacore.com/tools/gnat-gpl-edition/
Ada struck me as a language that would be a pain to write in(at least it would take a long time) but it was a pleasure to read. Even without an intimate knowledge of the language (I was a C++ guy) I was able to figure it out.
1. The JSF air vehicle C++ coding standards http://www.stroustrup.com/JSF-AV-rules.pdf
2. MISRA-C:2004 Guidelines for the use of the C language in critical systems http://caxapa.ru/thumbs/468328/misra-c-2004.pdf
3. MISRA C++:2008 Guidelines for the use of the C++ language in critical systems http://frey.notk.org/books/MISRA-Cpp-2008.pdf
Just check the archives.
Most likely because for writing fail safe software, it is better to use a language with built in support for safety, than using crutches.
But the real shocker is that you can't really write serious Ada for free, gnat is a pain, the free toolchain is a joke. My understanding is that there are good expensive private compilers out there. A few month back, I drank the cool aid and started a project in Ada, and the tools were a pain. The 'real time' system was ticking at a constant 1kHz. And making it tickless was looking tricky for a beginner. The formatting tool was bugging without an error message, the cross compilation toolchain for ARM is a pain, etc.
S: constant String := "Hello";
H: constant Character := S(1);Ada was mandated to be used for military applications but became largely irrelevant for commercial applications. It's now considered a white elephant [1] by many.
Not saying I like it or anything like that, but it definitely has its place.
numeric_limits<type>::max ()http://en.wikibooks.org/wiki/Ada_Programming/Attributes
Some of these would be methods in modern OO languages but many are unique to Ada.
Btw, Ada is on my list of languages to learn since 2011. I guess I will put it first on the 2015 good resolutions list :-)
Ada as A Second Language: http://amzn.com/0070116075
Programming in Ada 2005: http://amzn.com/0321340787
Programming in Ada 2012 by John Barnes: http://amzn.com/110742481X
I wonder if ADA wouldn't be better if they were subtracting features rather than adding them.
It's like a million pages. A second language handbook shouldn't be thicker than K&R. Do you know any short books that really assume I already know how to program?
Also, the Ada language standard and the rationale document are available for free. The standard is really more useful as a reference document, but it is surprisingly readable for a standards document.
class Bounded a where
minValue, maxValue :: a
So it is always the same constant, and it just changes value by what its type context is.Reading the wikipedia page for Ada didn't really give much insight into why the language is so heavily favored for applications like avionics software. Built in task based concurrency is certainly nice, but not a game-changer. Can someone more familiar with Ada explain what makes it so popular for high reliability applications?
Or is it a question of culture and tooling rather than the language itself?
x is and int between 1 and 200.
x gets asigned out of that range, exception is thrown. So we weren't manually checking everything.
Also I think it was mandated as a language for US government contracts, for a variety of reasons.
Also the syntax is designed to be as easy to understand as possible, typing out every word and using no three-letter abbreviations.
It's in general a language that was way ahead of its time, but survived because the DoD mandated it. Its main competitor is C, but that's mostly because the amount of engineers who know Ada out of school is really low, which is a shame, I think. Rust is way too new and Haskell has GC.
Pretty much. I write software for Medical Devices and culture and process is what it boils down to. Tooling helps. We use C, C++, C# among other languages. Language makes a little difference in reliability, but not much.
What matters in a nutshell: Know what you're building: need good Requirements
Analyze those Requirements for correctness, clarity and uniqueness (no conflicts)
Make sure your design meets all the Requirements and doesn't add anything: if you add a feature not in a Requirement, how will the testers know it's there? Verify the design: i.e., does it do what you need and does it do it "well." Does it barely function, or will it handle what you expect to be thrown at it or fail gracefully? Separate the concerns: e.g., need to be sure that the temperature is correct? The temperature control code and the temperature verification code should be decoupled from each other.
Code: probably where language makes the most difference, although different languages will influence your design.
Verify all design artifacts: review your Requirements, Designs, and all Code against predetermined quality standards. Reject anything that doesn't meet the standard. Build what you planned to build, and document what you built. Most errors will stem from Requirements problems.
That's Software Quality in a tiny nutshell ;-)
I remember seeing PL/SQL circa Oracle 8i and it looking a lot like ADA.
Not a coincidence. The designers of PL/SQL were largely inspired by Ada's basic syntax and structure.
It's not an acronym, by the way, so no need to all-caps it.
Prelude> let a = 1 :: Int
Prelude> let b = 2 :: Integer
Prelude> a+b
<interactive>:4:3:
Couldn't match expected type `Int' with actual type `Integer'
In the second argument of `(+)', namely `b'
In the expression: a + b
In an equation for `it': it = a + bArrrgh!! You mean "Lisp style". Lisp has had arbitrary-precision integers ("bignums") since 1971 -- long before Python was invented.
I think saying "unbounded int" is enough, but then people might say "what exactly do you mean by unbounded?" so I say it's about the same as a python int. Haskell itself predates python.
And IBM vacuum tube machines had arbitrary precision integers in the mid 50s, and transistor based ones in the 60s ;)
Okay, well, then, thank you for giving me the opportunity to educate people on a bit of history :-)
> IBM vacuum tube machines had arbitrary precision integers in the mid 50s, and transistor based ones in the 60s
I seriously doubt it. They may well have had variable precision, but I don't think they had unbounded precision. That is, there was always a limit such that a result over that limit would either wrap around or trap (I don't know which), but that limit could be different for different instructions. (I'll bet there was a hardware-enforced maximum limit too, on the order of 12 or 15 digits.)
It wasn't until 1969 that Knuth published algorithms for arbitrary-precision arithmetic. Also consider that arbitrary precision requires heap allocation, which certainly wasn't being done in hardware in the 1950s and -60s.
If you can substantiate your claim, I'll be suitably impressed, but I'm extremely skeptical.
So in the 50s they had integers with up to 2^9 - 1 (== 511) decimal digits.
In the 60s, the transistor-based one could do integers as big as your memory, the largest memory offered gave you up to 60K digits.
The two factors to be combined are added within core storage without the use of special accumulators or counters. Because any storage area can be used as an accumulator field, the capacity for performing arithmetic functions is not limited by standard-size accumulators or by a predetermined number of accumulators within the system.
[1] http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/140x/A2...
I ended up really enjoying programming in Ada and was unhappy about having to return to C++ when I went back to school that fall. It was a bit more work to write, but it was easy to read and when it compiled it usually did what you expected it to. It's a language that makes it difficult for you to shoot yourself in the foot.
Edit: In fact, I interned at an avionics company and they're slowly trying to entirely switch to model-based development, using certified software that generates the code for you.
This is a strange thing to say without explaining anyway. Would you care to expand on your point? I would expect Ada to run orders of magnitude faster than Python for a task like this.
I agree with this, but am not sure it's on point. Every software engineering class I've heard of is about as far as you can get from exploratory programming.
Since then, I've done pretty much nothing but C, but I do miss Ada's features from time to time.