Assessing the Ada Language for Audio Applications
electronicdesign.com
Assessing the Ada Language for Audio Applications
1–10 of 23 posts
Re: Assessing the Ada Language for Audio Applications
#2If you're interested in using Ada, be sure to also checkout SPARK - http://www.adaic.org/advantages/spark-ada/
It's basically a more strict (in terms of safety) Ada
Re: Assessing the Ada Language for Audio Applications
#3If 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
Re: Assessing the Ada Language for Audio Applications
#4If 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
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.
Re: Assessing the Ada Language for Audio Applications
#5I'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.
Re: Assessing the Ada Language for Audio Applications
#6If 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
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.
> What are the downside ADA?
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).
Re: Assessing the Ada Language for Audio Applications
#7Earlier quoted context omitted.
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.
> What are the downside ADA? 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…
I suspect the main reason Ada didn't get popular is that it took too long to get a reasonable open implementation of it.
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.
Re: Assessing the Ada Language for Audio Applications
#8I'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.
Audio with a few exceptions in synthesis is rather stream oriented. So at most you should get to build a pipeline.
Re: Assessing the Ada Language for Audio Applications
#9If 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
Doesn't stop people from using Ruby (Begin/End).
Re: Assessing the Ada Language for Audio Applications
#10> 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.