

Ada, C, C++, and Java vs. The Steelman (1997) - diegoperini
http://www.dwheeler.com/steelman/steeltab.htm

======
e12e
For those interested in this, SPARK 2014 (a strict Ada subset of sorts) might
be worth a look:

[http://docs.adacore.com/spark2014-docs/html/ug/spark_2014.ht...](http://docs.adacore.com/spark2014-docs/html/ug/spark_2014.html)

[http://docs.adacore.com/spark2014-docs/html/ug/tutorial.html](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...](http://www.spark-2014.org/entries/detail/spark-
pro-14.0-released-today)

~~~
pgeorgi
They released the GPL version last tuesday:
[http://libre.adacore.com/download/configurations](http://libre.adacore.com/download/configurations)

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

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

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

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

~~~
phaker
> _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.

~~~
copx
>You're doing harm by spreading misinformation.

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...](http://libre.adacore.com/tools/gnat-gpl-
edition/faq/#licensing)

~~~
e12e
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 ... ;)

------
twic
Wow:

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

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

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

