6 ms·

Ada, C, C++, and Java vs. The Steelman (1997)

32 points by diegoperini 12y ago

jeffreyrogers 12y ago
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.
- brohee 12y ago
  I actually wonder how Go and Rust would fare, Rust very well I suspect...
  - Blackthorn 12y ago
    The document is right there. You don't have to wonder, you can calculate it for yourself.
- msbarnett 12y ago
  > 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 12y ago
    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.
    - vince_refiti 12y ago
      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.
    - copx 12y ago
      >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.
      - vertex-four 12y ago
        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.
- pjmlp 12y ago
  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".
  - Guvante 12y ago
    > 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.
    - jeffreyrogers 12y ago
      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.
TwoBit 12y ago
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 12y ago
  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.
e12e 12y ago
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.html http://docs.adacore.com/spark2014-docs/html/ug/spark_2014.ht... 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-released-today http://www.spark-2014.org/entries/detail/spark-pro-14.0-rele...
- pgeorgi 12y ago
  They released the GPL version last tuesday: http://libre.adacore.com/download/configurations http://libre.adacore.com/download/configurations
twic 12y ago
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.

32 points by diegoperini 12y ago

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.

brohee 12y ago
I actually wonder how Go and Rust would fare, Rust very well I suspect...
- Blackthorn 12y ago
  The document is right there. You don't have to wonder, you can calculate it for yourself.
msbarnett 12y ago
> 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 12y ago
  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.
  - vince_refiti 12y ago
    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.
  - copx 12y ago
    >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.
    - vertex-four 12y ago
      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.
pjmlp 12y ago
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".
- Guvante 12y ago
  > 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.
  - jeffreyrogers 12y ago
    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.

TwoBit 12y ago

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 12y ago
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.

e12e 12y ago

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.html http://docs.adacore.com/spark2014-docs/html/ug/spark_2014.ht... 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-released-today http://www.spark-2014.org/entries/detail/spark-pro-14.0-rele...

pgeorgi 12y ago
They released the GPL version last tuesday: http://libre.adacore.com/download/configurations http://libre.adacore.com/download/configurations

twic 12y ago

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.