Since this was written in 1997 and C, C++, and Java have all evolved considerably since then (And Ada?) I'd be interested to see an updated version of this.
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.
> Since this was written in 1997 and C, C++, and Java have all evolved considerably since then (And Ada?) I'd be interested to see an updated version of this.
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.
At least in Europe its use seems to be rising. At least that is my feeling from the Ada sessions at FOSDEM in the last years.
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.
>I think it is helped by having a FOSS reference compiler (GNAT)
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.
> It should be noted that the free version of said compiler may only be used to produce software released under a GPL compatible license.
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.
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.
I agree there may be some license surprises (a natural consequence of marrying a language with a runtime with the GPL, for better or worse) -- it might be worth to note that the code is under GPL, not AGPL -- so for most modern (read: SaaS) uses -- it doesn't matter. If you really are deploying a drone or something, it likely doesn't matter either, because a) you need to give your customer the source code anyway, b) your customer will gladly pay the fee for the commercial license -- and c) the project will be classified, so adacore could never legally sue you anyway (without risking indefinite detention as enemy combatants ... ;)
A myth with a kernel of truth, and a licencing situation that's in truth a bit complicated, means there's significantly more "friction" involved with a decision to use GNAT, and therefore to even begin thinking about messing with Ada or SPARK. As I note in another posting in this subtread, that not a good way of "doing business", and can do nothing but suppress interest in and use of Ada or SPARK.
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.
I believe the GNAT-FSF Ada compiler included as part of GCC (as distinct from the GNAT-GPL compiler that can be downloaded directly from AdaCore) can be used to create non-GPL software, see -
I read that a few times (and a few times in the past) and I find it more difficult to comprehend and reason about than the programming language itself. So, if I build something today and I want to distribute it WITHOUT distributing the source - can I do it? Yes, or no?
This is the bit that you need to pay attention to:
> 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.
There's a version of GNAT distributed by GNU, about a year behind AdaCore's version, which allows you to use the Ada libraries without your program coming under the GPL.
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".
For me, I have started to tinker with it because of the increase in the availability of documentation, especially from Adacore. Google will show you some high quality pdfs out there. There's also Adacore University. Also, the IDE - GNAT Programming Studio, is pretty good. I even used it to write some C.
Ada was complex for the time it was developed (1983), due to hardware constraints for compiler development.
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".
> specially when you take in consideration all the undefined and unspecified cases in C and C++.
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.
I'm not sure why you've been downvoted, because you're correct. The reason C has so many undefined and unspecified cases was so that the implementation was relatively easy for compiler writers.
* 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.
The paper says that C and C++ don't support fixed point numbers, though with C++ you can write a fixed point class that's nearly the same as a native version. However, it would still be nice if C or C++ supported a native fixed point type.
C's standard library is meant to be small and only include essential things. I remember the C99 standard being widely criticized for including support for complex numbers, a feature considered to be special purpose and thus unfit for the C standard. The following C11 standard addressed this, making support for complex numbers "optional" i.e. a standard conforming C compiler is no longer required to support them.
C++ used to follow a similar mindset but this has changed. So we might see built-in fixed point support there in future.
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...