upl@puff.WISC.EDU (Future Unix Gurus) (04/20/87)
In article <3222@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) writes: >In article <672@puff.WISC.EDU> upl@puff.WISC.EDU (Future Unix Gurus) >writes about Modula 2: >>I still recommend it to anybody who, like me, knows and despises C ! > >Well, I know and despise C, and I don't recommend switching Modula 2, >because I despise it even more. Unless what you despise about C are >the umpteen syntactic quirks, and ambiguities in the language >definition (C: What it lacks in readability, it makes up for with >ambiguity!), there's not much point in switching. > >Once you get past those (to a distance of about 4 feet :-), the two >languages are identical, and suffer the same problems: > > 1) Typing is broken. In different ways, though. The casting is a little quirky. Outside of that, I'm not sure I understand your complaint. The typing is hard, with an attempt to allow circumvention. Outside of the above mentioned quirks, I haven't had any complaints about this. (Ofcourse, you have to LIKE hard typing, like I do.) > 2) Dynamic data structure extension isn't transparent. Non comprende, explain please? > 3) Functions are second-class citizens. Again, I don't know what you are talking about. Please describe rather than generalizing. > 4) Types are (at best) third-class citizens. See above. > 5) The languages aren't self-extensible. > What do you mean by "self-extensible"? I have built up quite a library of higher level routines, organized into modules. Clearly this isn't what you are talking about. What is? >Many of these faults can be forgiven, if a language suffers from only >a couple. But _all_ of them are deadly. They combine to make it >painfull to go from an algorithm in my head to a running version. And >that's what a language is supposed to be for. > Whaddya want, a DWIM statement?? :) :) >Like going out a buying a copy of Manx, there aren't enough different >languages to choose from. And in this case, the differences are to >small to make the change seem worthwhile. Especially since you really >need a C compiler to deal with most of the PD software. > This assumes you want to modify the PD stuff. You can get executables real easy in any moderate sized Amiga community. All in all, I can't really answer your concerns, or even say I agree with you, because I don't understand them. Some of them are stated to vaugely, others seem to be because of my ignorance (I assume "self-extensible" is language community jargon. We have TOO MUCH DAMN JARGON in our field , not your fault- just a pet peeve of mine. Computer science would be a much simpler, more efficient, and more fun discipline if all the various sub-groups were taught a common language - like ENGLISH!) Jeff Kesselman uhura!captain@puff.cs.wisc.edu
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (04/21/87)
Ok, I apparently opened a can of worms. Let's me give some more data. I'm going to stick with C, though. In article <680@puff.WISC.EDU> upl@puff.WISC.EDU (Future Unix Gurus) writes: >In article <3222@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) writes: >> 1) Typing is broken. In different ways, though. >The casting is a little quirky. Outside of that, I'm not sure I understand >your complaint. The typing is hard, with an attempt to allow circumvention. Typing is mushy, at best. Integral types can be treated as being the same type. Ditto for float/double. There is no concept of "abstract type" at all. For instance, I can't write a routine which works with any type that allows some set of operations. In a one-line summary, types are tied to the machine, with restrictions the machine doesn't have, and not tied to what I work with. And I'll be the first to conceede that most other languages have this problem. "Types" are touchy subject. Contact me by mail if you really wanna hear more. >> 2) Dynamic data structure extension isn't transparent. >Non comprende, explain please? When adding an element to a dynamic data structure, I have to get space for it, create pointers to the space, and then make sure the space is put back in the heap later. I'd much rather say: (append x y) or even list$addh(x, y) and have all that done for me. >> 3) Functions are second-class citizens. >Again, I don't know what you are talking about. Please describe rather >than generalizing. The term "second-class citizens" is well-known phrase. Basically, it means that there are things that you can't do to them that you can do to other object. For instance, I can't decide if two functions are identical. All you can really do is manipulate pointers to functions. >> 4) Types are (at best) third-class citizens. >See above. Same, except even more restricted. Basically, C doesn't have any way to manipulate types at all. Variables can't hold them, and the type of variables can't be tested (other than at compile or lint time). >> 5) The languages aren't self-extensible. >What do you mean by "self-extensible"? I have built up quite a library of >higher level routines, organized into modules. Clearly this isn't what >you are talking about. What is? Gee, and I thought that phase was self-explanatory. Self-extensible: Extensible in itself. Adding functions doesn't extend the language. Adding operators, types, and control structures does. C lets you add types, and that's about it. >>Many of these faults can be forgiven, if a language suffers from only >>a couple. But _all_ of them are deadly. They combine to make it >>painfull to go from an algorithm in my head to a running version. And >>that's what a language is supposed to be for. >> >Whaddya want, a DWIM statement?? :) :) Actually, I want DWISHM (Do What I Should Have Meant) statement, at least if I can't have PL/Prohpet to program in! :-) :-) :-) I really want something that works in the objects I work with when building an algorithm, in a notation at least not to far from what I think in. Of course, the language the algorithm is bound for affects the way I think, so any language that is based in a mathematical notation is off to a running start. >This assumes you want to modify the PD stuff. You can get executables >real easy in any moderate sized Amiga community. Gee, does FAUG and BADGE qualify as "moderate sized" :-)? But *of course* I want to modify it. Otherwise, I wouldn't be who I are. >All in all, I can't really answer your concerns, or even say I agree with >you, because I don't understand them. Some of them are stated to vaugely, >others seem to be because of my ignorance (I assume "self-extensible" is >language community jargon. We have TOO MUCH DAMN JARGON in our field >, not your fault- just a pet peeve of mine. Computer science would be >a much simpler, more efficient, and more fun discipline if all the >various sub-groups were taught a common language - like ENGLISH!) There is to much jargon. But there are some things - like *-class citizenship, and self-extensible, that are hard to describe briefly. I'll conceede to vagueness with #2 and #1. But it was on purpose for #1; that's a messy topic. Maybe it would have been best if I hadn't started this. Language design is an ongoing research field, and highly personal. What I want from a language may not be at all what you want from a language. <mike -- Here's a song about absolutely nothing. Mike Meyer It's not about me, not about anyone else, ucbvax!mwm Not about love, not about being young. mwm@berkeley.edu Not about anything else, either. mwm@ucbjade.BITNET
hugo@gnome.cs.cmu.edu (Peter Su) (04/21/87)
>> 2) Dynamic data structure extension isn't transparent. > >Non comprende, explain please? Well, in other languages like CLU and LISP, the compiler/interpreter/runtime has some smarts and will garbage collect storage that you aren't using anymore for you. Thus, you don't have to worry about it. You allocate the storage you need, use it, and then when you don't use it anymore, LISP just grabs it back. BASIC in fact, usually does this with string storage... >> 3) Functions are second-class citizens. >Again, I don't know what you are talking about. Please describe rather >than generalizing. >> 4) Types are (at best) third-class citizens. >See above. >> 5) The languages aren't self-extensible. >> >What do you mean by "self-extensible"? I have built up quite a library of >higher level routines, organized into modules. Clearly this isn't what >you are talking about. What is? > While it is true that you can build nice libraries and such in C or MODULA, again, other languages have better support for this. I think the three points made above are complaining about the fact that extensions that you put into the language have a different syntactic structure than facilities that are already in the language. For example, if you add a complex number type to C, then you can't use "+" to add complex numbers, you have to use say, "cadd()" instead. In this way, C isn't self extensible and you can think of C functions as being "second-class". On the other hand, in C++, you can add a complex kind of "+" operator, and it's operation is from then on, totally transparent. You just say "foo+bar" like you always have. LISP and FORTH are also like this, in that the syntax used for lanugage extensions is the same as that used for the core language. Add a function to lisp, and you call it just like you call all the other lisp function that you have. Now, when we really get fancy, there are the languages like CLU, ADA (yuck) and Smalltalk, oh yeah, C++ too, where not only can you extend the operators of the language, but also its basic data types. That is, you can define a data structure, and the operations that can be performed on that data structure, and incorporate you new type into the language in a very easy way. Not only that, but from then on, when you use the type, the idea is that you would only access the structure with the operations that you have specified, and the language *enforces* this. Thus, when you define a complex number type in CLU, and say, operations to get the real and imaginary part, the person outside the module can only ever get the real and imaginary part using the functions you have given him. The big deal is, that you can change the representation of the type arbitrarily, and as long as the operations you give out still work, no code breaks. Note that Pascal and C, and Modula really don't let you do this very easily. No matter what you do, whoever is using you library can always bypass your interfaces and look directly at the bytes of the data structure, and this causes bugs, and all sorts of nasty things. This idea of "abstract data types" has been floating around a long time, but no one really seems to pay much attention to it in practice. We all just keep hacking in the mucky waters of C... Oh well, Cheers, Pete -- ARPA: hugo@cmu-cs-gandalf.arpa BELL:412-681-7431 UUCP: ...!{ucbvax,ihnp4,cmucspt}!hugo@cmu-cs-gandalf.arpa USPS: 5170 Beeler St., Pittsburgh PA 15213 QUOT: "What's that I smell? I smell home cooking. It's only the river!" _ Talking Heads -- ARPA: hugo@cmu-cs-gandalf.arpa BELL:412-681-7431 UUCP: ...!{ucbvax,ihnp4,cmucspt}!hugo@cmu-cs-gandalf.arpa USPS: 5170 Beeler St., Pittsburgh PA 15213 QUOT: "What's that I smell? I smell home cooking. It's only the river!" _ Talking Heads
grr@cbmvax.cbm.UUCP (George Robbins) (04/22/87)
In article <3242@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) writes: > >Maybe it would have been best if I hadn't started this. Language >design is an ongoing research field, and highly personal. What I want >from a language may not be at all what you want from a language. > <mike Well, let's at least try to keep the heat down. What one wants in a programming language on a theoretical basis is not exactly the same thing that one wants from a specific language implementation or compiler. I think the flames started because a couple of people had different world views, rather than any factual disagrement, otherwise the exchange has been somewhat informative. Let's leave the nit-picking, sarcasm and gleeful trouncing to that talk.noise groups and concentrate on information. -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
gore@nucsrl.UUCP (04/29/87)
/ nucsrl:comp.sys.amiga / hugo@gnome.cs.cmu.edu (Peter Su) / > [...] The big deal is, > that you can change the representation of the type arbitrarily, and as long > as the operations you give out still work, no code breaks. > > Note that Pascal and C, and Modula really don't let you do this very easily. > No matter what you do, whoever is using you library can always bypass your > interfaces and look directly at the bytes of the data structure, and this > causes bugs, and all sorts of nasty things. If you are talking about Modula-2 (which is what the rest of the discussion deals with), then this is one limitation that it doe NOT have. There is a reasonable way (maybe not great, but, in my book, acceptable) to dissassociate the implementation of an ADT (Abstract Data Type) from its specification. It uses what is called an "opaque type". Basically, you make the type you want to export (i.e., the type the users of your module will see) a pointer to a type you will actually use for implementation. You also export the routines you plan to provide. All of this happens in the specification part of the module. In the implementation part of the module, you actually declare the type that you plan to use in the implementation. Whoever is using the library cannot bypass your interfaces. Jacob Gore Northwestern University, Computer Science Research Lab {ihnp4,chinet}!nucsrl!gore