Assessing the Ada Language for Audio Applications
electronicdesign.com
electronicdesign.com
It's basically a more strict (in terms of safety) Ada
That being said, SPARK and the affiliated tools (particularly gps (? Programming Studio?) are much nicer to use than the other formal verification tools I've tried. (Frama-C, much as I do like it, is obviously more a research project; Dafny is undocumented. I haven't tried any of the Java options.)
https://maniagnosis.crsr.net/2017/08/programming-language-sy...
/slightly tongue-in-cheek
Ada seems to have first class support for concurrency which is important for web apps. What are the downside ADA? looks like GCC supports it. Obviously the ecosystem isn't going to match Java's. But i wonder how does it fair against Go or Rust.
Mostly that very few people use it[1], which causes a kind inverse network effect, if you will. So finding people fluent in Ada is more difficult than finding people fluent in more popular languages.
Also, AFAIK the library situation is not very good. I guess this is not that much of a problem for embedded programming, but for building regular applications (like a web server or a DBMS) it kind of sucks.
[1] Telling this from memory, and I am by no means an expert, so take this with a grain of salt. But I think part of the reason that Ada is not popular is that it acquired a reputation for being large and complicated early in its life. The last time I looked at Ada, it did not seem that complex compared to C++, but I guess the reputation has stuck. Also, for a while (I have no clue how long and right now I am too lazy too look it up) the language was trademarked/copyrighted/whatever by the Pentagon, and if you wanted to call the shiny new compiler you just wrote an Ada compiler, you had to submit it to the Pentagon for certification, which I assume was both expensive and slow. Therefore very few people outside the aerospace / DOD contractor sector used the language to begin with. It's a shame, really. It took me a while getting used to it, but once I got past that, I found it a very nice language (as long as I did not need much in the way of third party libraries).
GNU one is pretty ok nowadays but that is too late. (GNAT) It started in 1992. Compare to 80s for C++ and late 70s to C. Even Fortran was earlier.
In comparison, first C compiler was BSD licensed while C++ sample compilers were open front-ends to C.
The language didn't have the marketing Java "portability" did and by the time of open implementation it lost the new language sheen.
Similar problem caused the decline of Pascal. FreePascal only became useful in around 1999. GNU Pascal was laughably bad. Thus it is quite dormant despite pretty great support from Borland early on.
It is telling that we have 3 modern C++ compilers, a slew of older ones (some reasonably recent), countless C compilers too. A bunch of Java VMs and compilers.
Ada 2012 really caught my eye a while back. Looking at it from a C++ standpoint:
Pros:
- Already has concepts (aka generics)
- Already has contracts
- Already has modules (aka packages)
- Has really well thought out multi-threading (aka tasking)
- The SPARK subset of Ada, allows for contract based formal verification (i.e. provable correctness)
- The Ravenscar Profile, restricts the compiler to only allow for code which is safe to use in a free-standing system (for 'bare-metal' targets)
- You can still write wrapper bindings to use C or C++ libraries
Cons:
- It is most spectacularly not a terse language, I appreciate it was an intentional design decision for safety critical contexts, but it's quite mentally taxing to read any sizeable block of code
- The ALGOL/Pascal like syntax is very off-putting for a lot of people have had to work with those in the past.
- The GNAT compiler is available in 3 flavours 1) GNAT pro which you pay a lot of money for, is the most up to date compiler, and you can use commercially 2) GNAT GPL which is similar to pro but if you use commercially it must be under GPLv3 terms. 3) FSF GNAT which is analog to g++ so you can use commercially but compiler updates and fixes are rolled in at a much slower rate and lagging behind the other two options. Considering the 3 options available for a lot of businesses they would have to be able to fork the money for GNAT pro in order to use Ada commercially
- Smaller community (and possibly less active online) means that it's harder to reach out for community support or start a collaborative project
- The language and toolchain have, by design, very high constraints, regarding correctness. This means that you are not easily allowed to relax or shortcut aspects of your software. This is obviously a good thing but the downside of this is that initial prototyping/feasibility work may take much longer than in other languages.
- The perpetuation of the myth that it is only suitable for high cost and high-criticality applications (Avionics, ATC, Aerospace, Railway systems, etc.) means that there are less market opportunities for Ada developers, which leads to less people being driven to learn Ada which means the barrier to entry for using Ada in other suitable markets (distributed systems, medical applications, automotive) is much greater.
For the most part, as a professional Ada programmer, I agree with you on every point of your analysis. I personally like algol like syntax, but would like Ada to be less verbose at times.
I just want to say that there is now a fourth option, gnat pro developer, that is more reasonably priced than gnat pro, and more targeted towards regular companies' needs rt. Safety critical: https://www.adacore.com/gnatpro/developer
I would love it if all these companies were more price transparent but ultimately they are not selling in high volumes, like the likes of MSVC, so I would hazard guess they probably depend a lot more on the margins from each individual sale.
I think the author meant “does not include a garbage collector in the language”.
In my experience developing Ada software, not being able to depend on a garbage collector being present means that code intended to be used by others must manually manage memory. This means that it must manage memory exposed to client code and document who (the library or the client) is responsible for deallocation of a given data structure. In effect, this makes Ada no more reusable or composeable than C.
[1] http://www.adaic.org/resources/add_content/standards/05rm/ht...
Ada has controlled and limited objects, which allows implementation of shared/unique_ptrs, so that's not true. As in c++, if you are in a performance sensitive area you will not use those, but that's also true with a GC, and then you have other options, like memory pools or static allocation.
> In effect, this makes Ada no more reusable or composeable than C.
I think you meant "with regards to memory management" :). As pointed out above, that's not true.
Also beyond memory management Ada has a generics model that composes much better than C++, due to being based on contracts for generic formals (think C++ concepts lite).
In general your statement strikes me as oversimplifying to the point of being simply incorrect.
> Does the current standard provide for automatic deallocation such that one need never instantiate Unchecked_Deallocation?
The standard provide a host of containers and pointer-like constructs that would indeed allow you to never use Unchecked_Deallocation. There's one caveat: Performance.
> Without a garbage collector, who deallocates graphs of objects with circular references?
Like in other languages where you rely on ref-counting, you need to use weak references for that. This requires a bit more explicitness from the programmer.