Ada, C, C++, and Java vs. The Steelman (1997)
dwheeler.com
dwheeler.com
http://docs.adacore.com/spark2014-docs/html/ug/spark_2014.ht...
http://docs.adacore.com/spark2014-docs/html/ug/tutorial.html
Apparently the commercial version was released on the 8th April, and a GPL version should be out this month:
http://www.spark-2014.org/entries/detail/spark-pro-14.0-rele...
Also, I remember hearing/reading somewhere, possible in a class I took on compilers, that the Ada language was so complex that it very likely would never have completed development if it were not backed by the government.
Ada has seen 2 major updates to its standard -- the Ada 2005 and Ada 2012 standards.
> Also, I remember hearing/reading somewhere, possible in a class I took on compilers, that the Ada language was so complex that it very likely would never have completed development if it were not backed by the government.
There's a lot of weird myths floating about about the complexity of Ada. By the standards of the early 80s its certainly somewhat more complex than, say, C or Pascal, but it's orders of magnitude less complex than the C++ standard, and certainly easier to parse and compile. By modern standards its certainly a simpler language than Java.
I think it is helped by having a FOSS reference compiler (GNAT) and the required increase in terms of secure software quality, specially when human lives are at risk.
It should be noted that the free version of said compiler may only be used to produce software released under a GPL compatible license. This is unusually restrictive and rules out Ada for most people right away.
It is either Free Software only or an expensive commercial subscription to AdaCore's services. I mean the "expensive" is a guess, but given that they do not list prices on their website but ask you to contact their sales department, we can assume they are far from cheap.
In a world where you can develop commercial, closed source software in all popular languages using free tools this seems anachronistic. I understand that AdaCore needs to make money somehow and this is probably the best business strategy for them, but still, it seriously limits the appeal. The appeal of Ada in general too, because it seems there is no (truly) free, modern Ada compiler.
Interestingly enough the situation seems to be similar for most of the failed languages of days gone by. If you look for implementations you only find DOS era stuff and X thousand dollar "solutions" which milk the enterprise/government legacy code market.
There are required certification processes in place that most FOSS will never pay.
For example, if you go the C or C++ route, the code has to be validated against the MISRA standard, with specific tooling.
This is another game league than the app of the day thing.
> The GMGPL license in either GNAT Pro runtime or GNAT-FSF runtime permits software that is licensed under a license that is incompatible with the GPL to be linked with the output of Ada standard generic libraries that are supplied with GNAT without breaching the license agreement.
If you use the version of GNAT provided as part of GCC from GNU (which is a year or so behind), or the paid-for version of GNAT from AdaCore, you can distribute your program without distributing the source. If, however, you use the GPLed version of GNAT from AdaCore, your own code has to be distributed under something compatible with the GPL.
The Wikipedia article could do with a cleanup, really.
No. No. No.
GCC GNAT is under GPL 3 with GCC runtime library exception, the same license as the rest of GCC.
Before GPL 3 it was licensed under GMGPL -- GNAT Modified GPL, which was very similar to the the current license as the "runtime library exception" is intended to unify similar exceptions from several GCC compilers, for example if you're using C++11 on GCC you are bound by the exact same license.
I'm sorry if i'm not as nice as I could be. Every time Ada is mentioned someone chimes in with mythical license woes. You're doing harm by spreading misinformation. This myth needs to die.
E.g. I have every reason to believe you and the others commenting on this, but I'm going to have to confirm for myself that this is correct.
Blame AdaCore. I based my statement on the information on their website [1]. They certainly try to convince people that you have to buy GNAT Pro if you want to build non-GPL compatible software.
Based on the other comments here, it seems it is actually possible to use GNAT, with an alternative FSF runtime, to build non-GPL compatible software without a license. Great, however AdaCore certainly likes to keep quiet about that possibility (for understandable reasons). Also as a potential user I would be worried about the quality of said runtime, given that it probably has no serious users and very little manpower behind it.
[1] http://libre.adacore.com/tools/gnat-gpl-edition/faq/#licensi...
Not long ago HN discussed a very interesting project based on it: https://news.ycombinator.com/item?id=7656300 ... and I didn't realize GNAT was so constrained.
While composing this I noticed other comments trying to clarify the situation, I'll have to check for myself, which is not a good way to "do business".
Nowadays, Ada is not more complex than most mainstream languages, specially when you take in consideration all the undefined and unspecified cases in C and C++.
To a certain extent, all the older languages still in used nowadays were also backed by the goverment.
Funny anecdote, One of the first IDEs for strong typed languages was targeted at Ada, the R1000 computer system, created by a young company named "Rational Software".
That is an odd way of putting it. Aren't undefined/unspecified behaviors allowed to be implemented in whatever is simplest for the compiler if it prefers? Sure many modern compilers leverage them to expand the power of their optimization engines, but that isn't really a language difficulty case.
* 2C. Syntactic Extensions. The user shall not be able to modify the source language syntax. In particular the user shall not be able to introduce new precedence rules or to define new syntactic forms.*
Sounds like somebody had had a bad time with LISP at some point. Or maybe the point of that requirement is to combine with this one:
* 1E. Simplicity. The language should not contain unnecessary complexity. It should have a consistent semantic structure that minimizes the number of underlying concepts. It should be as small as possible consistent with the needs of the intended applications. It should have few special cases and should be composed from features that are individually simple in their semantics. The language should have uniform syntactic conventions and should not provide several notations for the same concept. No arbitrary restriction should be imposed on a language feature.*
To make LISP programmers explode with outrage.
Joking aside, requirement 2C sounds good to me. Having dealt with macros in a few languages, and DSLs in Ruby, i'm not convinced they carry their weight in the long run.
Nitpick:
5E. Initial Values. There shall be no default initial-values for variables.
Java: partial. Java defines initial values for all types, though recommends against using them and Java compilers attempt to warn of such use.
Eh, no. Local variables don't get initial values, and you can't read from them before their first definite assignment. Fields in objects get initial values, and i'm not aware of any standard recommendation against, or compiler warning for, their use.
That said, common best practice these days is to declare fields final, which means they get vaguely similar semantics to local variables - they have to be assigned values in the constructor (or their declaration, or an instance initialiser), and they can't be read from in the constructor before that assignment. The minor difference is that if the constructor calls an instance method, that instance method can refer to uninitialised final fields. It should be noted that although the compiler allows this, Joshua Bloch doesn't, and if you do it, he will come to your house and beat you with a sock full of billiard balls.
C++ used to follow a similar mindset but this has changed. So we might see built-in fixed point support there in future.