
Assessing the Ada Language for Audio Applications - gusthoff
http://www.electronicdesign.com/embedded-revolution/assessing-ada-language-audio-applications
======
MaxLeiter
If you're interested in using Ada, be sure to also checkout SPARK -
[http://www.adaic.org/advantages/spark-
ada/](http://www.adaic.org/advantages/spark-ada/)

It's basically a more strict (in terms of safety) Ada

~~~
mcguire
Ada is a language that I really _want_ to like, but I've never been able to
get enthusiastic about it.

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...](https://maniagnosis.crsr.net/2017/08/programming-language-syntax-
complaints.html)

------
dguaraglia
I'm surprised this article barely touches on the language-level concurrency
support in Ada. Back in university, Ada was the language we used to learn
concurrency. It kind of sucked, and you kind of hated it... until you had to
implement the same thing in C and wanted to shoot yourself, heh.

~~~
AstralStorm
Audio with a few exceptions in synthesis is rather stream oriented. So at most
you should get to build a pipeline.

------
titzer
If Ada had curlies and ran on the web, people would flock to it. But it has
Begin/End which looks antiquated to people.

/slightly tongue-in-cheek

~~~
camus2
I had a look at few of these language lately (ADA,FORTRAN) and they don't look
as bad as they sound, I mean they are not worse than PL/SQL syntactically.

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.

~~~
DoingIsLearning
> What are the downsides of Ada?

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.

~~~
Raphael_Amiard
That's a very interesting answer, thanks for taking the time to write it.

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](https://www.adacore.com/gnatpro/developer)

~~~
DoingIsLearning
That seems like the right direction to reduce the barrier to entry for smaller
development teams and consultants. Thanks for this update.

~~~
grok2
But you still need to fill out a form to get pricing!

~~~
DoingIsLearning
Arguable we could say the same from IAR or WindRiver?

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.

------
mcculley
> Ada has been designed to support garbage collection, but does include a
> garbage collector in the language, thus making it adapted for real-time
> applications.

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.

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

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.

~~~
mcculley
My last attempt at making reuseable Ada was with Ada95. Does the current
standard provide for automatic deallocation such that one need never
instantiate Unchecked_Deallocation? If so, I need to revisit it. Without a
garbage collector, who deallocates graphs of objects with circular references?

~~~
Raphael_Amiard
Hello McCulley, sorry I missed your answer.

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

