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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,21960280f1d61e84 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!news2.volia.net!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: How come Ada isn't more popular? Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1169531612.200010.153120@38g2000cwa.googlegroups.com> <1mahvxskejxe1$.tx7bjdqyo2oj$.dlg@40tude.net> <2tfy9vgph3.fsf@hod.lan.m-e-leypold.de> Date: Mon, 29 Jan 2007 15:37:12 +0100 Message-ID: <1g7m33bys8v4p.6p9cpsh3k031$.dlg@40tude.net> NNTP-Posting-Date: 29 Jan 2007 15:37:12 CET NNTP-Posting-Host: 3019df05.newsspool2.arcor-online.net X-Trace: DXC=N\IoR:J@l2;L2C_`koXfC5A9EHlD;3Yc24Fo<]lROoR1Fl8W>\BH3Y2eOAdkg29\@EQhdRK]; X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:8679 Date: 2007-01-29T15:37:12+01:00 List-Id: 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? The point is, the language should not have either X or Y built-in. What 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". > 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... (:-)) Note that non-contiguous representations of objects is a way different issue. It seems that you want the latter when you refer to GC. To me GC is about indeterminable scopes, upward closures and other things I don't want to have... > 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. 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 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... > Has anybody here aver wondered about the popularity of "scripting", > like with Perl, PHP, Python and so on? I did. > 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. 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! (:-)) >> 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. > - 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. > 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... > 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. > 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. >> 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. I don't care about memory if I can make my object an implementation of an abstract array interface. There is no distance beyond the difference between two index values of the array. You cannot (may not) associate elements of an array and its indices with any memory locations. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de