From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,21960280f1d61e84 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII Newsgroups: comp.lang.ada Subject: Re: How come Ada isn't more popular? References: <1169531612.200010.153120@38g2000cwa.googlegroups.com> <1mahvxskejxe1$.tx7bjdqyo2oj$.dlg@40tude.net> <2tfy9vgph3.fsf@hod.lan.m-e-leypold.de> <1g7m33bys8v4p.6p9cpsh3k031$.dlg@40tude.net> From: Markus E Leypold Organization: N/A Date: Mon, 29 Jan 2007 16:50:16 +0100 Message-ID: User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:UW//4HuiTrixBlZnhAisjFf8D5w= MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit NNTP-Posting-Host: 88.72.222.69 X-Trace: news.arcor-ip.de 1170085529 88.72.222.69 (29 Jan 2007 16:45:29 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!newsfeed.freenet.de!news.unit0.net!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news2.google.com comp.lang.ada:8712 Date: 2007-01-29T16:50:16+01:00 List-Id: "Dmitry A. Kazakov" writes: > On Sun, 28 Jan 2007 16:06:48 +0100, Markus E Leypold wrote: > >> "Dmitry A. Kazakov" writes: >> >>> On Sun, 28 Jan 2007 00:24:27 +0100, Markus E Leypold wrote: > >>> Generics is a wrong answer and always was. As well as built-in lists you >>> are praising is, because what about trees of strings, trees of lists etc. >>> You cannot build every and each type of containers in. >> >> You missed my point. :-). A language with a Hinldey-Milner type system >> has a 'tree of something' type where something can be anything in >> every given instance of usage. > > You have X of Y. Granted, you can play with Y, but what about X? I don't understand the question ... > The point is, the language should not have either X or Y built-in. What Pursuing this argument further, a language also shouldn't have strings built in etc. :-). What I think, is, that having at least lists in the "standard library" and by that I mean functional lists, not arrays, not "containers", helps tremendously because that is such a common use case. > should be built-in is "of". The type system should be able to handle > parallel type hierarchies of X's and Y's bound by the relation "of". Yes. And exactly that is what a Hindley-Milner type system has built in. The lists in Haskell and Ocaml are just in the standard library (conceptually -- knowing that they are here, makes it easy to compile them by special rules and get a more efficient implementation or have special instructions in the underlying VM or reduction mechanism). >> So you get 'tree of foo' from it and 'tree of bar' when you use it >> like this, but there are no generics instantiated. There are trade >> offs, of course (like that you probably can't design such a language >> without GC and without loosing a certain degree of control of the >> representation of types), > > It is not obvious. I saw to good arguments for GC, so far. (it tend to > repeat in c.l.a and comp.object, a lot of foam around mouths... (:-)) Foam, yes :-). But you have to admit, that allowing a GC without ever having an actual implementation (execpt Martin Krischik's adaption of the B�hm collector) just too much teasing: You could have it, but no, it's not there. > Note that non-contiguous representations of objects is a way > different issue. It seems that you want the latter when you refer to > GC. Not necessarily, but I think it does help a lot towards efficient garabage collection. I might be mistaken, since I'm not really an expert in designing garbage collectors. > To me GC is about indeterminable scopes, upward closures and > other things I don't want to have... If yout have only downward scopes for "closures" and memory allocation this will, finally, interact badly with the fact that "implicit (i.e. static type safe) casting" of classes is also only possible downwards. My impression is, that all these things together rule out some useful designs, that would otherwise possible. Or to say it differenty: Object orientation w/o indeterminable scopes, upward closures and GC doesn't work well. Some abstractions cannot be implemented. This, of course is just a gut feeling. I do not know about research or empiricial studies that examine the influence that these various restrictions have on each other and how they act together. >> but since C D Hixson and me have been >> talking about usefuleness in a general sense, that doesn't count >> here. A useful language needs to have lists, you must be able to write >> recursive functions on lists and preferably in a functional way and >> you should not need explicit instantiation declaration for every >> instance (like 'of float', 'of int', 'of ...'). > Of course you need it. There cannot be a language with only first-class > objects. Well, yes. In a sense java (up to 1.4) was such a language. The only feasible way to built a general container was casting down to "Object" type and casting up later again. With the possibility of runtime casting errors. Bad. > Let types-1 be values, make them values. Then they will need no > declarations, just literals. Soon you will discover some types-2 which > still require declarations. Make them values too. An so on. At some level n > you will have to stop. Now, rename type-n = "type". value, type-k "value". See? You are where you have started. I do not understand your argument here. Care to give some example and I'll try write down how it is down in i.e. OCaml? Perhaps we're talking on cross purposes too, since I'm not sure I really wanted to desire the thing you insist I want. :-) >> Languages of the Algol-FORTRAN-C-Pascal-Ada group are all far from >> that ideal. Since a lot of programming these days is general list >> manipulation, everyday jobs become painful. > > There always was Lisp, for those who prefer declarations spelt in the form > of bracket structures... I'm not talking about syntax. I'm talking about types. Which -- strictly speaking -- lisp hasn't. there is only one (static) type in a dynamic type system, which is one large union (discriminant) type. >> Has anybody here aver wondered about the popularity of "scripting", >> like with Perl, PHP, Python and so on? > > I did. And? What was the result of your considerations? :-) > >> As I see it, the presence of >> lists and hashtables/dictionaries in those languages together with the >> absence of memory management is a factor in this popularity. Which I >> hope, if not proves, at least makes my point plausible. :-). > What about Excel? I have a theory. Look Turbo Pascal was hugely popular. Excel is just cancer of mind and organisation. People start to use it, the "application" grows and they miss the point where to stop. I've seen many "applications" that took away somewhere around 3-4 man months and would have been easy to write as web application with say Python or PHP and (God forgive me) MySQL in 1 month. > Why? That is simple, because it has 256 character long strings! > Borland made a great mistake lifting that limitation. Compare it > with MS-Excel, which is still limited to 32767 rows. That is the key > to success! (:-)) You make me laugh :-). So what Ada should do, is to introduce a String256 with appropriate restriction, and then we will succeed. Good plan ... :-))). >>> In my view there are three great innovations Ada made, which weren't >>> explored at full: >>> >>> 1. Constrained subtypes (discriminants) >>> 2. Implementation inheritance without values (type N is new T;) >>> 3. Typed classes (T /= T'Class) >> >> Here 2 things are missing: >> >> - parameterized types (see Java generics and the ML type system, the >> first is just borrowing from the latter). > > See pos.1. The constraint is the parameter of. In rare cases you wanted > different values of parameters producing isolated types you would apply 2 > to 1. Again I do not know what you're denying here... >> - Separation of implementation and type or to put it differently >> inheritance and subtyping compatibility. See the ocaml type system. > > That should be interface inheritance from concrete types. Yes, Ada misses > that. No, what I want is even different. 2 values / objects in the OCaml way of objects are just compatible if their type signatures (which are calculated by the type inference engine) agree or better one is contained in the other. This is a weaker contract than in Ada where at least a behavioural part of the contract is implied by inheriting the implementation, but which (except for generic packages) is useless, since you can destroy behaviour by overwriting a method with a misbehaved procedure. Actually what are classes in other languages should perhaps better be mapped to packages in Ada in the mind of the developer. >> I admit the contracts are weaker for allowing to instante a >> generic with a package with the "right type signature" as >> parameter instead of requiring an instance of another specific >> generic. > > There should be no generics at all... I'm not sure. Generics provide a relatively stric contract model. I like this. But the instantation requirement is cumbersome if compared with the way parameterized types work in other langauges (and that is exactly what I'm pulling from generics most of the time: parameterized types). Parameterized types are now 1:1 substitute for generics. ML has functors too, for a good reason. But they are what makes everyday live bearable. > >> But what is absolutely annoying, is, that the compatibility of >> objects is determined by inheritance instead by the type >> signature. > > I see it otherwise. Because "compatibility" is undecidable (for both the > computer and the programmer), the language must be strongly and > manifestedly typed. Since the contract can be broken by new methods anyway, the only thing that counts from a type safety point of view, is, not to break the abstraction to the underlying processor / VM, that is, to be able to call the methods with the right number of parameters and the right representation of the parameters (at the machine level). So the type signature is enough. It's really bothersome that one cannot supply a class X which is compatible to another class Y by just writing out the right methods. And BTW -- if inheritance is done right (the keyword here is binary methods and co- and contravariance -- have a look into the OCaml users manual), a class Y' derived from Y is not necessarily subtype compatible. So inheritance of implementations doesn't guarantee anything anyway. >> This makes things like the factory pattern necessary >> and it really doesn't work in general case. (And yes, Java and C++ >> share this defect). > > I am not sure what you mean, but when 3 is considered as 1, then > dispatching on bare type tags might become possible. 3? 1? Please elaborate? Is "dispatching on bare type tags" a good or a bad thing? You lost me there ... (my fault probably). > >>> P.S. All strings have fixed length. It is just so that you might not know >>> the length at some point... (:-)) >> >> Ah, well, thats splitting hairs. We are talking about 2 different >> lengths (of strings in C) here: The one is the allocated storage, the >> other the distance from the start to the first occurrence of the '\0' >> delimiter. Since strlen() returns the latter ... >> >> The problem I've been talking above, is of course to manage growing >> strings that might outgrow the allocated storage. > No, the problem is lack of abstract interfaces. Ah! Here we agree! That is the deeper problem. > I don't care about memory if I can make my object an implementation > of an abstract array interface. Yes. > There is no distance beyond the difference between two index values > of the array. There is -- (I1 - I2) but it's abstract in number of elements, not in units of memory. > You cannot (may not) associate elements of an array and its indices > with any memory locations. ACK. But my dear Dmitry -- What does your sentence "All strings have fixed length ..." mean than in this context, eh? [laughing madly and leaving the stage] Regards -- Markus