* The A-Z of Programming Languages: Ada, interview with S. Tucker Taft @ 2008-06-04 10:52 Ludovic Brenta 2008-06-04 14:14 ` Georg Bauhaus 2008-06-06 14:09 ` Ludovic Brenta 0 siblings, 2 replies; 14+ messages in thread From: Ludovic Brenta @ 2008-06-04 10:52 UTC (permalink / raw) http://www.techworld.com.au/article/223388/-z_programming_languages_ada?pp=1 -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: The A-Z of Programming Languages: Ada, interview with S. Tucker Taft 2008-06-04 10:52 The A-Z of Programming Languages: Ada, interview with S. Tucker Taft Ludovic Brenta @ 2008-06-04 14:14 ` Georg Bauhaus 2008-06-04 14:59 ` Ludovic Brenta 2008-06-06 14:09 ` Ludovic Brenta 1 sibling, 1 reply; 14+ messages in thread From: Georg Bauhaus @ 2008-06-04 14:14 UTC (permalink / raw) Ludovic Brenta schrieb: > http://www.techworld.com.au/article/223388/-z_programming_languages_ada?pp=1 > Has Ichbiah been right to be skeptical of Ada 95's OO? It does seem to have, uhm, rich structure, seen from a learners point of view. -- Georg ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: The A-Z of Programming Languages: Ada, interview with S. Tucker Taft 2008-06-04 14:14 ` Georg Bauhaus @ 2008-06-04 14:59 ` Ludovic Brenta 2008-06-05 2:01 ` Marc A. Criley 0 siblings, 1 reply; 14+ messages in thread From: Ludovic Brenta @ 2008-06-04 14:59 UTC (permalink / raw) Georg Bauhaus wrote: > Ludovic Brenta schrieb: > > http://www.techworld.com.au/article/223388/-z_programming_languages_ada?pp=1 > > > > Has Ichbiah been right to be skeptical of Ada 95's OO? > It does seem to have, uhm, rich structure, seen from a > learners point of view. This prompts the question: how would Ichbiah have implemented OOP in Ada? -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: The A-Z of Programming Languages: Ada, interview with S. Tucker Taft 2008-06-04 14:59 ` Ludovic Brenta @ 2008-06-05 2:01 ` Marc A. Criley 2008-06-05 13:58 ` Georg Bauhaus 0 siblings, 1 reply; 14+ messages in thread From: Marc A. Criley @ 2008-06-05 2:01 UTC (permalink / raw) Ludovic Brenta wrote: > Georg Bauhaus wrote: >> Ludovic Brenta schrieb: >>> http://www.techworld.com.au/article/223388/-z_programming_languages_ada?pp=1 >>> >> Has Ichbiah been right to be skeptical of Ada 95's OO? >> It does seem to have, uhm, rich structure, seen from a >> learners point of view. > > This prompts the question: how would Ichbiah have implemented OOP in > Ada? Perhaps barely, if at all. I was at an Ada conference in the early 90s where Ichbiah was a keynote speaker, and talking about the Ada 9X revision process that was just then getting underway. The only thing I clearly remember him stating in his presentation was that Ada 9X was not going to allow "any elephants in the tent". And I think OOP, in the context of Ada 83, would certainly qualify as an elephant. No matter how elegantly one might have conceived it. Subsequent to that presentation, as Tucker mentioned in the interview, Ichbian left the revision effort. Marc A. Criley McKae Technologies ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: The A-Z of Programming Languages: Ada, interview with S. Tucker Taft 2008-06-05 2:01 ` Marc A. Criley @ 2008-06-05 13:58 ` Georg Bauhaus 2008-06-05 14:13 ` Jean-Pierre Rosen 2008-06-05 15:00 ` Ed Falis 0 siblings, 2 replies; 14+ messages in thread From: Georg Bauhaus @ 2008-06-05 13:58 UTC (permalink / raw) Marc A. Criley schrieb: > Ludovic Brenta wrote: >> Georg Bauhaus wrote: >>> Ludovic Brenta schrieb: >>>> http://www.techworld.com.au/article/223388/-z_programming_languages_ada?pp=1 >>>> >>>> >>> Has Ichbiah been right to be skeptical of Ada 95's OO? >>> It does seem to have, uhm, rich structure, seen from a >>> learners point of view. >> >> This prompts the question: how would Ichbiah have implemented OOP in >> Ada? > > Perhaps barely, if at all. This seems surprising because classwide programming and dynamic dispatch seem to have been among the requirements of Ada 9X. (I got this idea from browsing the archives.) In an excerpt from a letter sent by Ichbiah to the Ada 9X group, a part of which is quoted in Meyer's OOSC2, Ichbiah appears to be addressing the increased complexity of the language, which is caused by the then new features and their combinations. He computes it to be approaching ~60_000 combinations. (I'll look up the details.) Might Ichbiah have thought that by some 80/20 rule, you can overdo things if you create Ada 9X the way it was around 1992? IIUC what Taft says in the interview, Ichbiah didn't like the _way_ OOP was to be implemented. OTOH he had been working on a Simula compiler at INRIA. So maybe OOP alone was not the elephant. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: The A-Z of Programming Languages: Ada, interview with S. Tucker Taft 2008-06-05 13:58 ` Georg Bauhaus @ 2008-06-05 14:13 ` Jean-Pierre Rosen 2008-06-05 19:40 ` Georg Bauhaus 2008-06-05 15:00 ` Ed Falis 1 sibling, 1 reply; 14+ messages in thread From: Jean-Pierre Rosen @ 2008-06-05 14:13 UTC (permalink / raw) Georg Bauhaus a �crit : > IIUC what Taft says in the interview, Ichbiah didn't like the > _way_ OOP was to be implemented. OTOH he had been working on a > Simula compiler at INRIA. So maybe OOP alone was not the elephant. > Certainly. Actually, Ichbiah was well aware of the benefits of OOP, and actually that's why he insisted for having derived types in Ada83, against the opinion of the rest of his team. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: The A-Z of Programming Languages: Ada, interview with S. Tucker Taft 2008-06-05 14:13 ` Jean-Pierre Rosen @ 2008-06-05 19:40 ` Georg Bauhaus 2008-06-05 20:46 ` Dmitry A. Kazakov 0 siblings, 1 reply; 14+ messages in thread From: Georg Bauhaus @ 2008-06-05 19:40 UTC (permalink / raw) Jean-Pierre Rosen wrote: > Georg Bauhaus a �crit : >> IIUC what Taft says in the interview, Ichbiah didn't like the >> _way_ OOP was to be implemented. OTOH he had been working on a >> Simula compiler at INRIA. So maybe OOP alone was not the elephant. >> > Certainly. Actually, Ichbiah was well aware of the benefits of OOP, and > actually that's why he insisted for having derived types in Ada83, > against the opinion of the rest of his team. Thanks. As promised, here is what Meyer quotes from Ichbiah's resignation letter: "A massive increase in complexity will result from 9X adding one or more additional possibilities where Ada now offers two. For example, 9X adds: [...] access parameters, to IN, OUT, and IN OUT; tagged types, to normal types; dispatched subprogram calls, to normal subprogram calls; use type clause, to use package clauses; ... With 9X, the number of interactions to consider is close to 60,000 since we have 3 or more possibilities in each case (that is, 3^10)." (OOSC2, �33.7, p.1095) The comment "adds: tagged types, to normal types" is particularly interesting, I think, because it touches on a consequence of this distinction: sloppy versus exact base type systems: Eiffel tries to have basically one kind of type definition, namely the class---even though "expanded class" "adds one or more additional possibilities", if I may aim Ichbiah's comment at Eiffel. Compiler magic is/was used for types such as INTEGER or REAL. Some operations of INTEGER are "require"-predicates used for testing whether or not an integer value fits a subsets of INTEGER, e.g. 8-bit integers. Ada, as mentioned by Ichbiah, has "normal" types for defining integers, reals, etc., and tagged types for defining polymorphic types. You want integers between 0 and 10_000 only? Define a corresponding normal type, or do "normal" derivation from another integer type adding the needed constraint. (Part of the language since Ada 83 as pointed out by J.-P. Rosen above.) What I find so interesting is that these ways to define basic types might show that there are undeniable reasons to require two type definition mechanisms. (I guess this is not news to people who worked on either Ada 9X or Eiffel, but it appears to be news to a new audience tackling the base type system. And the presence of one or the other always affects programs.) Do the Eiffel base types work well? Do they match the "normal" integer types of Ada in practice? Using cut&paste polymorphism and renaming one can change INTEGER to a different INTEGER with more specific require predicates, predicates even more powerful than Ada's range constraints(*). Still, people coming to Eiffel have more than once asked for more programmer control of basic Eiffel types such as INTEGER and FLOAT. Messing with base types, renaming and cluster management do not look like the best solution. So maybe there is good reason to have both normal types, and tagged types, even if this complicates the language? _____ (*) Some hard work has been done with the goal of enhancing Ada's type constraints in the sense of DbC. It has been published as AIs and elsewhere. X'Post -- Georg Bauhaus ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: The A-Z of Programming Languages: Ada, interview with S. Tucker Taft 2008-06-05 19:40 ` Georg Bauhaus @ 2008-06-05 20:46 ` Dmitry A. Kazakov 2008-06-06 17:57 ` Georg Bauhaus 0 siblings, 1 reply; 14+ messages in thread From: Dmitry A. Kazakov @ 2008-06-05 20:46 UTC (permalink / raw) On Thu, 05 Jun 2008 21:40:55 +0200, Georg Bauhaus wrote: > "A massive increase in complexity will result from 9X adding one or more > additional possibilities where Ada now offers two. For example, 9X adds: > [...] access parameters, to IN, OUT, and IN OUT; tagged types, to normal > types; dispatched subprogram calls, to normal subprogram calls; use type > clause, to use package clauses; ... With 9X, the number of interactions > to consider is close to 60,000 since we have 3 or more possibilities in > each case (that is, 3^10)." (OOSC2, �33.7, p.1095) I cannot decode this, so let it be... > The comment "adds: tagged types, to normal types" is particularly > interesting, I think, because it touches on a consequence of > this distinction: sloppy versus exact base type systems: In which sense "sloppy/exact"? > Ada, as mentioned by Ichbiah, has "normal" types for defining > integers, reals, etc., and tagged types for defining polymorphic types. Tagged types aren't polymorphic. Only their classes (closures of) are. > You want integers between 0 and 10_000 only? Define a corresponding > normal type, or do "normal" derivation from another integer type > adding the needed constraint. > (Part of the language since Ada 83 as pointed out by J.-P. Rosen above.) Well, I understand this complain. Actually, there is no semantic difference between: subtype S is T ...; -- "Normal" derivation and type S is new T with ...; -- "Abnormal" derivation and with Ada 2005 type S is interface and T; -- "Horrific" derivation Clearly, all of them should have same syntax. Clearly interfaces are superfluous when abstract types could do anything they do and more. Further, interfaces are damaging to software design. One is forced permanently factor out interfaces out of types instead of trivial interface inheritance from concrete types. > What I find so interesting is that these ways to define basic types > might show that there are undeniable reasons to require two type > definition mechanisms. Really? I'd like to deny some of them. (:-)) > So maybe there is good reason to have both normal types, and tagged > types, even if this complicates the language? No, there is no substantial difference between two mechanisms, once one has separated polymorphic (class) and specific (type) as Ada 95 did, all types become "normal." Abnormal are classes, which you aren't forced to use as they are completely orthogonal to "normal" types. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: The A-Z of Programming Languages: Ada, interview with S. Tucker Taft 2008-06-05 20:46 ` Dmitry A. Kazakov @ 2008-06-06 17:57 ` Georg Bauhaus 2008-06-06 19:34 ` Dmitry A. Kazakov 0 siblings, 1 reply; 14+ messages in thread From: Georg Bauhaus @ 2008-06-06 17:57 UTC (permalink / raw) Dmitry A. Kazakov wrote: > On Thu, 05 Jun 2008 21:40:55 +0200, Georg Bauhaus wrote: > >> "A massive increase in complexity will result from 9X adding one or more >> additional possibilities where Ada now offers two. For example, 9X adds: >> [...] access parameters, to IN, OUT, and IN OUT; tagged types, to normal >> types; dispatched subprogram calls, to normal subprogram calls; use type >> clause, to use package clauses; ... With 9X, the number of interactions >> to consider is close to 60,000 since we have 3 or more possibilities in >> each case (that is, 3^10)." (OOSC2, �33.7, p.1095) > > I cannot decode this, so let it be... That I don't believe. >> The comment "adds: tagged types, to normal types" is particularly >> interesting, I think, because it touches on a consequence of >> this distinction: sloppy versus exact base type systems: > > In which sense "sloppy/exact"? Sloppy/exact in the sense of mapping the set of problem or solution values to a set of type values 1:1, bijectively. When all you have is int, INTEGER, Int, etc. but your set of whole numbers has bounds strictly inside (min machine-int, max machine-int), say, then one type system allows you to exactly give the lowest and highest whole number that your (sub)type is to have. Another type system, namely that of Qi, even permits computing a set of values using a Turing complete type declaration language. So "only odd natural numbers" will be a perfectly normal Qi type. A type definition that basically must use "int", but the set of values is between 0 and 1_000_000, is sloppy in that it does not express the set, neither to the reader nor to the compiler. You might recall the report that an embedded systems teacher from a US university has summarized here. A base type system that is a more exact representation of the solution sets does help in programming. >> Ada, as mentioned by Ichbiah, has "normal" types for defining >> integers, reals, etc., and tagged types for defining polymorphic types. > > Tagged types aren't polymorphic. Only their classes (closures of) are. Yes, and you define tagged types in order to get classwide polymorphic types. There are no class-wide types rooted at some non-tagged type. There is a universal type. This, I think, reflects the tagged vs normal distinction Ichbiah is listing. >> You want integers between 0 and 10_000 only? Define a corresponding >> normal type, or do "normal" derivation from another integer type >> adding the needed constraint. >> (Part of the language since Ada 83 as pointed out by J.-P. Rosen above.) > > Well, I understand this complain. Actually, there is no semantic difference > between: > > subtype S is T ...; -- "Normal" derivation No, that is not meant by "normal" derivation; rather type S is new T; -- Semicolon, no "with" > Clearly, all of them should have same syntax. Yes, I speculate that this is what Ichbiah might have liked, and why he list "9X adds: tagged types, to normal types; " > Clearly interfaces are > superfluous when abstract types could do anything they do and more. > Further, interfaces are damaging to software design. One is forced > permanently factor out interfaces out of types instead of trivial interface > inheritance from concrete types. Trivial? >> So maybe there is good reason to have both normal types, and tagged >> types, even if this complicates the language? > > No, there is no substantial difference between two mechanisms, once one has > separated polymorphic (class) and specific (type) as Ada 95 did, all types > become "normal." Abnormal are classes, which you aren't forced to use as > they are completely orthogonal to "normal" types. Whatever the mechanisms are, two mechanisms are never even close to "the same" if the programmer has to learn a great deal in order to see how they are substantially the same. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: The A-Z of Programming Languages: Ada, interview with S. Tucker Taft 2008-06-06 17:57 ` Georg Bauhaus @ 2008-06-06 19:34 ` Dmitry A. Kazakov 0 siblings, 0 replies; 14+ messages in thread From: Dmitry A. Kazakov @ 2008-06-06 19:34 UTC (permalink / raw) On Fri, 06 Jun 2008 19:57:26 +0200, Georg Bauhaus wrote: > Dmitry A. Kazakov wrote: >> On Thu, 05 Jun 2008 21:40:55 +0200, Georg Bauhaus wrote: >> >>> "A massive increase in complexity will result from 9X adding one or more >>> additional possibilities where Ada now offers two. For example, 9X adds: >>> [...] access parameters, to IN, OUT, and IN OUT; tagged types, to normal >>> types; dispatched subprogram calls, to normal subprogram calls; use type >>> clause, to use package clauses; ... With 9X, the number of interactions >>> to consider is close to 60,000 since we have 3 or more possibilities in >>> each case (that is, 3^10)." (OOSC2, �33.7, p.1095) >> >> I cannot decode this, so let it be... > > That I don't believe. You must. (:-)) I really do not understand what he writes about. >>> The comment "adds: tagged types, to normal types" is particularly >>> interesting, I think, because it touches on a consequence of >>> this distinction: sloppy versus exact base type systems: >> >> In which sense "sloppy/exact"? > > Sloppy/exact in the sense of mapping the set of problem or solution > values to a set of type values 1:1, bijectively. > > When all you have is int, INTEGER, Int, etc. but your set of > whole numbers has bounds strictly inside (min machine-int, > max machine-int), say, then one type system allows you to exactly > give the lowest and highest whole number that your (sub)type is to > have. Another type system, namely that of Qi, even permits > computing a set of values using a Turing complete type declaration > language. So "only odd natural numbers" will be a perfectly normal > Qi type. A type definition that basically must use "int", but > the set of values is between 0 and 1_000_000, is sloppy in that > it does not express the set, neither to the reader nor to the > compiler. I see. But this is an invalid distinction. Your statement is not about properties of the types. It is about types being improperly used. You can misuse a tagged type in the same or a worse way as you did integer. >>> Ada, as mentioned by Ichbiah, has "normal" types for defining >>> integers, reals, etc., and tagged types for defining polymorphic types. >> >> Tagged types aren't polymorphic. Only their classes (closures of) are. > > Yes, and you define tagged types in order to get classwide > polymorphic types. No. Tagged types are defined in order to have inheritance. Class-wide programming (polymorphism) is an orthogonal issue. Often you can have a rich hierarchy of types, but no polymorphic objects. It really depends on the application. Polymorphic objects appear only when specific types become indeterminable at compile time. > There are no class-wide types rooted at > some non-tagged type. There is a universal type. This, I think, > reflects the tagged vs normal distinction Ichbiah is listing. But the point is that any type should have a class rooted in it. The distinction made between tagged and non-tagged was arbitrary. tagged vs. non-tagged is actually by-reference vs. by-compiler-choice. Ada 95 did a mistake conflating these. >>> You want integers between 0 and 10_000 only? Define a corresponding >>> normal type, or do "normal" derivation from another integer type >>> adding the needed constraint. >>> (Part of the language since Ada 83 as pointed out by J.-P. Rosen above.) >> >> Well, I understand this complain. Actually, there is no semantic difference >> between: >> >> subtype S is T ...; -- "Normal" derivation > > No, that is not meant by "normal" derivation; rather > > type S is new T; -- Semicolon, no "with" This is not a derivation, it is cloning. (Another mistake of Ada 95 was that type cloning was lost for tagged types. Cloning is an important operation of types algebra independent of classes and inheritance. So you need the monstrous generics in order to clone tagged types, loosing taggedness on the way.) >> Clearly interfaces are >> superfluous when abstract types could do anything they do and more. >> Further, interfaces are damaging to software design. One is forced >> permanently factor out interfaces out of types instead of trivial interface >> inheritance from concrete types. > > Trivial? Consider: type A is ...; procedure Foo (X : A); type B is private A; -- B inherits only the interface of A (not Ada!) This is trivially equivalent to: type Anonymous_Interface_Of_A is limited interface; procedure Foo (X : Anonymous_Interface_Of_A) is abstract; type A is new Anonymous_Interface_Of_A ...; overriding procedure Foo (X : A); type B is new Anonymous_Interface_Of_A; Does this look difficult? >>> So maybe there is good reason to have both normal types, and tagged >>> types, even if this complicates the language? >> >> No, there is no substantial difference between two mechanisms, once one has >> separated polymorphic (class) and specific (type) as Ada 95 did, all types >> become "normal." Abnormal are classes, which you aren't forced to use as >> they are completely orthogonal to "normal" types. > > Whatever the mechanisms are, two mechanisms are never even close to > "the same" if the programmer has to learn a great deal in order to > see how they are substantially the same. This only because he is forced to learn the same thing twice. Then he will learn combinations of these two same things in different contexts. Yes, this leads to a combinatorial explosion, which is absolutely unnecessary. Look how introducing totally superfluous interfaces exploded the language. You have limited, non-limited, protected, synchronized etc interfaces, where single word "abstract" would be enough! So? "entities must not be multiplied beyond necessity" -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: The A-Z of Programming Languages: Ada, interview with S. Tucker Taft 2008-06-05 13:58 ` Georg Bauhaus 2008-06-05 14:13 ` Jean-Pierre Rosen @ 2008-06-05 15:00 ` Ed Falis 2008-06-12 1:57 ` Randy Brukardt 1 sibling, 1 reply; 14+ messages in thread From: Ed Falis @ 2008-06-05 15:00 UTC (permalink / raw) On Thu, 05 Jun 2008 09:58:36 -0400, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> wrote: > IIUC what Taft says in the interview, Ichbiah didn't like the > _way_ OOP was to be implemented. OTOH he had been working on a > Simula compiler at INRIA. So maybe OOP alone was not the elephant. > I wasn't there, but rumor had it that JDI wanted to use the term "class" (rather than "tagged type") for consistency with other OO languages. I don't know what his other disagreements were. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: The A-Z of Programming Languages: Ada, interview with S. Tucker Taft 2008-06-05 15:00 ` Ed Falis @ 2008-06-12 1:57 ` Randy Brukardt 2008-06-12 7:25 ` christoph.grein 0 siblings, 1 reply; 14+ messages in thread From: Randy Brukardt @ 2008-06-12 1:57 UTC (permalink / raw) "Ed Falis" <falis@verizon.net> wrote in message news:op.ub96mfvb5afhvo@naropa... > On Thu, 05 Jun 2008 09:58:36 -0400, Georg Bauhaus > <rm.dash-bauhaus@futureapps.de> wrote: > >> IIUC what Taft says in the interview, Ichbiah didn't like the >> _way_ OOP was to be implemented. OTOH he had been working on a >> Simula compiler at INRIA. So maybe OOP alone was not the elephant. >> > > I wasn't there, but rumor had it that JDI wanted to use the term "class" > (rather than "tagged type") for consistency with other OO languages. I > don't know what his other disagreements were. I *was* there, and that was a major contention between two groups. (I was on Ichbiah's side on this argument, but I didn't quit when I lost. ;-). I don't recall any technical objections that he had. The whole discussion degenerated into something rather theratical. I don't want to go into detail, because I don't want to speak ill of the dead (or of the living, for that matter). I personally thought that using derived types (which no one understood in Ada 83) to implement classes was a mistake. Tucker was adamant on this point. I'm still not sure if he was right, but I'm used to it now. (Adding overriding indicators surely helps a lot, by indicating the programmers intent.) Randy. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: The A-Z of Programming Languages: Ada, interview with S. Tucker Taft 2008-06-12 1:57 ` Randy Brukardt @ 2008-06-12 7:25 ` christoph.grein 0 siblings, 0 replies; 14+ messages in thread From: christoph.grein @ 2008-06-12 7:25 UTC (permalink / raw) On 12 Jun., 03:57, "Randy Brukardt" <ra...@rrsoftware.com> wrote: > I personally thought that using derived types (which no one understood in > Ada 83) What do you mean? I used type derivation a lot in Ada 83 with much benefit for handling physical types adding new operations on the derived type. And there is the trick attributed to John Goodenough to add user- defined equality to any type. > to implement classes was a mistake. Tucker was adamant on this > point. I'm still not sure if he was right, but I'm used to it now. Why this? I think that using the Ada 83 type derivation facility for this is very natural. Why invent a completely new technique? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: The A-Z of Programming Languages: Ada, interview with S. Tucker Taft 2008-06-04 10:52 The A-Z of Programming Languages: Ada, interview with S. Tucker Taft Ludovic Brenta 2008-06-04 14:14 ` Georg Bauhaus @ 2008-06-06 14:09 ` Ludovic Brenta 1 sibling, 0 replies; 14+ messages in thread From: Ludovic Brenta @ 2008-06-06 14:09 UTC (permalink / raw) Ludovic Brenta wrote: > http://www.techworld.com.au/article/223388/-z_programming_languages_ada?pp=1 Not yet slashdotted (I'm a bit surprised) but there are some nice comments on OSNews: http://www.osnews.com/comments/19824 -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2008-06-12 7:25 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-06-04 10:52 The A-Z of Programming Languages: Ada, interview with S. Tucker Taft Ludovic Brenta 2008-06-04 14:14 ` Georg Bauhaus 2008-06-04 14:59 ` Ludovic Brenta 2008-06-05 2:01 ` Marc A. Criley 2008-06-05 13:58 ` Georg Bauhaus 2008-06-05 14:13 ` Jean-Pierre Rosen 2008-06-05 19:40 ` Georg Bauhaus 2008-06-05 20:46 ` Dmitry A. Kazakov 2008-06-06 17:57 ` Georg Bauhaus 2008-06-06 19:34 ` Dmitry A. Kazakov 2008-06-05 15:00 ` Ed Falis 2008-06-12 1:57 ` Randy Brukardt 2008-06-12 7:25 ` christoph.grein 2008-06-06 14:09 ` Ludovic Brenta
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox