Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ada is not just another programming language (1986)

sci-hub.se

Post reply on HN
Print view View original

41–50 of 68 posts

Re: Ada is not just another programming language (1986)

#41

Post by mananaysiempre »

vrotaru wrote: post #39
mseepgood wrote: post #17

Earlier quoted context omitted.

Wirth removed this again in Oberon, because experience with Pascal and Modula showed that it is not worth it.

Not sure that is the actual reason. (Also define worth it) Wirth had developed that original, but misguided (IMO) notion that the faster a compiler can compile itself the better it is. Consequently he has removed a lot from latest iterations of its languages/compilers Pascal had an enum-like feature we could define an enumerated type. Wirth removed it because... `CONST` should be enough for everyone. Obviously it has…

I’m not sure this was the reasoning. None of the languages in the direct Algol heritage have any sort of parametric polymorphism, including for range bounds, so working with arrays (which were, at least in Pascal, the primary application of range types) was either constant and repetitive fighting with the compiler or unsafe escape hatches all the way. (Usually both.) I believed this was the primary motivation for the removal of ranges.

(Of course, it’s literally impossible to make polymorphic range bounds work completely, due to the undecidability of Peano arithmetic. The most convincing attempt I’ve seen that doesn’t just go full dependent types on you is ATS, and even that is not exactly the friendliest of environments.)

Another system whose evolution was explicitly guided by self-compilation speed is Chez Scheme, and it’s a fine one. Generally it seems to me that it’s a valid optimization principle, but not a global one: you can fall into an unfortunate local minimum if you start in the wrong place. ... Well, so what, it’s not like there are any infallible design principles in programming.

Re: Ada is not just another programming language (1986)

#42

Post by Jtsummers »

thesuperbigfrog wrote: post #40
adrian_b wrote: post #16

Earlier quoted context omitted.

True, but nevertheless Ada is an important language in the history of programming languages. After 1970, there were less and less innovations in programming languages, in the sense of features that have not existed in any earlier languages. Many new languages have been introduced since then and some of them might be better than most previous languages, but usually the new languages offer only new combinations of feat…

>> The defect that is most universally accepted is that it is too verbose. Another huge barrier (especially to early adoption) was the cost of Ada toolchains. Even today, there are proprietary Ada implementations that cost thousands of dollars per seat.

There are also C and C++ toolchains that cost similar amounts (if you want to use them for safety critical systems). But they do have more free or open source options than Ada does. Fortunately FSF GNAT is free and unencumbered (unlike AdaCore's release of GNAT GPL).

Re: Ada is not just another programming language (1986)

#43

Post by Jtsummers »

adrian_b wrote: post #35
adrian_b wrote: post #23

Earlier quoted context omitted.

Somewhat more verbose. A great part of the verbosity is due to the fact that unlike CPL/BCPL/B/C and the languages inspired by them, which have replaced the Algol statement parentheses begin and end with "{" and "}" or similar symbols, Ada uses relatively long words as statement parentheses, e.g. loop and end loop . On the other hand, a good feature of Ada is that it followed Algol 68 in having different kinds of sta…

Moreover, besides the long statement parentheses, the other main source of verbosity in Ada is that Ada does not use abbreviations. Most programming languages use a set of abbreviations that have appeared in either PL/I or Algol 68, but Ada does not use them, for example Ada uses constant, procedure, character, integer instead of const, proc, char, int .

Even setting aside keywords, the real verbosity with Ada is that nearly everything is explicit, not implicit. In C you have many implicit conversions between (similar) types, in Ada these are always explicit. In C++ you have implicit instantiation of templates when they get used, in Ada you must explicitly instantiate a generic before it's used.

On the other hand, arrays carry their range information with them and you don't need to pass that explicitly like in C. And having types with explicit ranges means you can use them and trust that they'll work correctly (which may include erroring out when used incorrectly, like adding 1 to the largest value), but in most other languages you'd have to include explicit range checks at (potentially) numerous locations throughout the code (did we start with a correct value, did we end with a correct value).

Tradeoffs.

Re: Ada is not just another programming language (1986)

#44

Post by tored »

vrotaru wrote: post #39
mseepgood wrote: post #17

Earlier quoted context omitted.

Wirth removed this again in Oberon, because experience with Pascal and Modula showed that it is not worth it.

Not sure that is the actual reason. (Also define worth it) Wirth had developed that original, but misguided (IMO) notion that the faster a compiler can compile itself the better it is. Consequently he has removed a lot from latest iterations of its languages/compilers Pascal had an enum-like feature we could define an enumerated type. Wirth removed it because... `CONST` should be enough for everyone. Obviously it has…

If you read the paper, From Modula to Oberon by Wirth, I already linked in a pervious comment when answering the question about subranges, you can also find the reasoning behind the removal of enumerations.

"Enumeration types appear to be a simple enough feature to be uncontroversial. However, they defy extensibility over module boundaries. Either a facility to extend given enumeration types has to be introduced, or they have to be dropped. A reason in favour of the latter, radical solution was the observation that in a growing number of programs the indiscriminate use of enumerations(and subranges) had led to a type explosion that contributed not to program clarity but rather to verbosity. In connection with import and export, enumerations give rise to the exceptional rule that the import of a type identifier also causes the (automatic) import of all associated constant identifiers. This exceptional rule defies conceptual simplicity and causes unpleasant problems for the implementor."

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.578...

Re: Ada is not just another programming language (1986)

#45

Post by adrian_b »

Jtsummers wrote: post #43
adrian_b wrote: post #35

Earlier quoted context omitted.

Moreover, besides the long statement parentheses, the other main source of verbosity in Ada is that Ada does not use abbreviations. Most programming languages use a set of abbreviations that have appeared in either PL/I or Algol 68, but Ada does not use them, for example Ada uses constant, procedure, character, integer instead of const, proc, char, int .

Even setting aside keywords, the real verbosity with Ada is that nearly everything is explicit, not implicit. In C you have many implicit conversions between (similar) types, in Ada these are always explicit. In C++ you have implicit instantiation of templates when they get used, in Ada you must explicitly instantiate a generic before it's used. On the other hand, arrays carry their range information with them and yo…

You are right.

However the Department of Defense requirements prohibited any kind of implicit conversions, without making any distinction between safe conversions, which preserve the value and which are reversible, and unsafe conversions, like truncations or roundings or signed to unsigned conversions.

The complete lack in Ada of some very frequently needed implicit conversions is annoying and it does not decrease the likelihood of bugs, but it increases the likelihood of bugs due to code bloat that can obscure the erroneous absence of some meaningful operation.

However, this defect is on DoD, not on the Ada authors.

Re: Ada is not just another programming language (1986)

#46

Post by tored »

open-source-ux wrote: post #29
tored wrote: post #27

Earlier quoted context omitted.

Found this paper "From Modula to Oberon" by Wirth himself http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.578... "Subrange types were introduced in Pascal (and adopted in Modula) for two reasons: (1) to indicate that a variable accepts a limited range of values of the base type and to allow a compiler to generate appropriate guards for assignments, and (2) to allow a compiler to allocate the minimal storage…

Thank you :-) It seems subranges could be something of a double-edged sword. Too many enumerations and subranges in a program adds complexity. However, without them I presume the guards need to be coded manually elsewhere in the program. It's really fascinating to see the reasoning a programming language designer makes when choosing what feature to include - or exclude.

> without them I presume the guards need to be coded manually elsewhere in the program.

That is my conclusion as well, reading the Oberon manual a SET seems just to be a normal set but for integers only, thus you have to manually check if your integer value is part of the set within the procedure itself, however that check will be a runtime check, not a compile time check if you had a proper enumeration type (I assume). And to my understanding Oberon doesn't have any error handling, so how exactly you would promote a out of range check to an error is unknown to me.

I guess that you would probably want to define constants to fill the set with, thus adding some more noise.

  CONST RED = 1;
  CONST GREEN = 2;
  CONST BLUE = 3;
  SET COLORS = (RED, GREEN, BLUE)
So you can use it a procedure call

  draw(RED);
Compare to Pascal enumeration

  type COLORS = (RED, GREEN, BLUE);
It feels like Wirth was somewhat obsessed with the idea of type extension with Oberon, it should be possible to import any module (program) and extend it without restrictions and enumerations created a problem how you would extend it.

If you have a color module defining the enumeration COLORS together with a bunch of procedures accepting COLORS, then in another custom module you want extend COLORS with the color YELLOW plus some YELLOW specific procedures.

But if you pass an extended enumeration E' to a procedure that accepts the base enumeration E, which should be legal similar how you can pass T' as T, the procedure would receive illegal values, in this case YELLOW. What you need to do instead is create your own CUSTOM_COLORS enumeration, manually include every color from COLORS and add YELLOW, and when calling procedures within the colors module type cast from CUSTOM_COLORS to COLORS enumeration. Perhaps this is the type explosion Wirth was referring to.

Out of range would still be problem if you extend a SET, but you avoid type casts.

This is how I interpret Wirth reluctance to enumerations (and subranges).

https://www.inf.ethz.ch/personal/wirth/Oberon/Oberon07.Repor...

Re: Ada is not just another programming language (1986)

#48

Post by CRConrad »

Jtsummers wrote: post #42
thesuperbigfrog wrote: post #40

Earlier quoted context omitted.

>> The defect that is most universally accepted is that it is too verbose. Another huge barrier (especially to early adoption) was the cost of Ada toolchains. Even today, there are proprietary Ada implementations that cost thousands of dollars per seat.

There are also C and C++ toolchains that cost similar amounts (if you want to use them for safety critical systems). But they do have more free or open source options than Ada does. Fortunately FSF GNAT is free and unencumbered (unlike AdaCore's release of GNAT GPL).

> But they do have more free or open source options than Ada does. Fortunately FSF GNAT is free and unencumbered (unlike AdaCore's release of GNAT GPL).

Sorry, I don't quite get what you're trying to say here. You mean unencumbered by being free or open source?

Re: Ada is not just another programming language (1986)

#49

Post by Jtsummers »

CRConrad wrote: post #48
Jtsummers wrote: post #42

Earlier quoted context omitted.

There are also C and C++ toolchains that cost similar amounts (if you want to use them for safety critical systems). But they do have more free or open source options than Ada does. Fortunately FSF GNAT is free and unencumbered (unlike AdaCore's release of GNAT GPL).

> But they do have more free or open source options than Ada does. Fortunately FSF GNAT is free and unencumbered (unlike AdaCore's release of GNAT GPL). Sorry, I don't quite get what you're trying to say here. You mean unencumbered by being free or open source?

GNAT GPL removes the runtime exception, so if you build something with it linked to its standard library, it's also supposed to be open sourced. This means you can't (in a legal/technical sense, not a true prohibitive sense) make closed source software with it. FSF GNAT doesn't remove that exception, so it can be used in releasing closed source software.

That's the encumbrance that GNAT GPL imposes and FSF GNAT does not.

Post reply on HN