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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f5d71,d275ffeffdf83655 X-Google-Attributes: gidf5d71,public X-Google-Thread: 109fba,d275ffeffdf83655 X-Google-Attributes: gid109fba,public X-Google-Thread: 146b77,d275ffeffdf83655 X-Google-Attributes: gid146b77,public X-Google-Thread: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public From: adam@irvine.com Subject: Re: Ada vs C++ vs Java Date: 1999/01/19 Message-ID: <780so2$u83$1@nnrp1.dejanews.com> X-Deja-AN: 434224240 References: <369C1F31.AE5AF7EF@concentric.net> <369DDDC3.FDE09999@sea.ericsson.se> <369e309a.32671759@news.demon.co.uk> <77ledn$eu7$1@remarQ.com> <77pnqc$cgi$1@newnews.global.net.uk> <8p64spq5lo5.fsf@Eng.Sun.COM> <8p6vhi5mv34.fsf@Eng.Sun.COM> <8p6yan1xger.fsf@Eng.Sun.COM> X-Http-Proxy: 1.0 x11.dejanews.com:80 (Squid/1.1.22) for client 192.160.8.21 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Tue Jan 19 03:04:39 1999 GMT Newsgroups: comp.lang.ada,comp.lang.c++,comp.vxworks,comp.lang.java X-Http-User-Agent: Mozilla/3.0 (X11; I; Linux 2.0.34 i686) Date: 1999-01-19T00:00:00+00:00 List-Id: In article <8p6yan1xger.fsf@Eng.Sun.COM>, Mike Coffin wrote: > > Matthew Heaney writes: > > > I am interested in specifics. List 5 specific language features by > > which you conclude Ada is "complex." > > I'll have to answer based on Classic Ada; I haven't had occasion to > look seriously at the latest version. > > Here are some broad areas that I think are way too complicated: > > 1. Generics. Ada generics are much more complicated and harder to use > than need be. So don't use them. > If you insist on complete run-time type checking, > ML's type system is easier to use and more powerful. (I don't > blame Ada for this: Hindley-Milner-style type systems probably > didn't exist and certainly weren't widely known.) I know that > there were some efforts to get some type-inference technology into > Ada Mark II or whatever it's called, but I don't know if any > succeeded. > > On the other hand, if you're of the opinion that exceptions do > happen, and that type exceptions are just another kind of > exception, OO type systems such as Java and Smalltalk are a *lot* > simpler than Ada's. I don't know enough about ML's type system to comment. However, I've never thought of Ada's type checking system as complicated. You have types, and for each type you can have subtypes. When you move stuff from one variable to another, or from an expression to a parameter, or whatever, the types have to match. That's the basic idea. How hard is that to understand? It does get a bit more complicated when Ada 95's tagged types and class-wide types are involved. > 2. Rendezvous. Compare accept/select/when, with all their > permutations and ramifications, with SR's "in" statement which is > much more powerful. (This is chiefly because "when" clauses can't > reference entry parameters in Ada). In fact, compare all of Ada's > interprocess communication with SR's. SR's is much more powerful > and easier to use. (But I'm biased; I worked on SR back when the > world was new :-) So don't use rendezvous. (I don't know anything about SR, but your fictional programmer never mentioned this; he was trying to argue for using C.) > 3. Treatment of variables shared between tasks. Task A changes a > variable. When does task B see the change? Trying to maintain too > much generality made Ada much more complicated than any language I > can think of in this regard. It's not so much that the language > rules are complex, it's that writing programs that work reasonably > given then weak language rules is so hard. Anyone know of another > language that tries to conflate shared-memory and distributed > programming? So don't use tasks. > 4. Parameter passing. Three modes; named parameters; default values > (but not for in-out parameters, for some reason). If you say "for some reason", then you really haven't grasped what the in-out parameter mode is for. It's for passing a variable that the procedure is supposed to modify. A default value would make no sense. > In spite of all > the features, the behavior is mostly unspecified for arrays and > records. I fail to see how this is "complicated". It's really simple. An "in" parameter is one that goes IN to the procedure. The procedure uses it as INput, not as OUTput. An "out" parameter is one that the procedure uses as OUTput; it's not used as INput and should not use whatever value the parameter has when the procedure starts. An "in out" parameter is both INput and OUTput. The procedure takes its current value as INput, but may modify the value, i.e. OUTput. How is this complicated? I'm sure my 16-month-old could understand it. (Well, that's an exaggeration, but he's very good at taking everything out of a box and putting it back in, and the concept behind Ada parameter passing isn't much more difficult that that.) Meanwhile, in C, if you declare a parameter type to be a pointer, you can't tell whether the procedure actually wants to input a pointer, or whether it wants to input the address of an array, or whether it's trying to emulate Ada's "in out" parameter. Is Ada really more complex here? Which one is harder to learn, harder to use, harder to read? As far as being unspecified for arrays and records, that's just not true. It works just the same as scalars. If you have an IN OUT record or array parameter, the variable used by the caller has its value passed to the procedure, and the procedure gives the variable a new value. Same as for anything else. What's unspecified is that you don't know whether the variable gets its new value at the end of the procedure or at some time before that, but usually that doesn't matter. In fact, that's a good feature, because it has allowed compilers that will pass *small* records and arrays in registers and lets the procedure work with them efficiently in registers, while in some languages, your only option is to pass the address of the record or array and force the procedure to make indirect registers through that address. I know, you probably think the only computer around is the register-challenged Intel 80x86/Pentium, in which this isn't an issue because there aren't enough registers for passing parameters. As for default values: So don't use them. > Compare with rules of C, Java, or almost any other > language: they lack *all* these nifty features and seem to get > along fine. So does assembly language, for that matter. > 5. Overloading. Do result types matter? Do parameter names matter? > Do default values matter? Why, or why not? And, hey: > parameterless subroutines and enumeration literals look sort of the > same. Can they overload each other? Can they hide each other? If > so, when and where? It could be worse though, as C++ demonstrates. So don't use this feature. Out of the five things you think are "way too complicated", four and a half of them are things that you don't need to use to program in Ada. I mean, if your complaint is that "Something I can do easily in C [the language your fictional programmer wanted to use] is complicated to do in Ada", you might have a valid argument. But all these examples are more of the form "Something is complicated in Ada that C doesn't support at all." So how is Ada's "complexity" a negative? OK, so tasks might be complex, but if you have a program that doesn't need them, so what? And if you have a program that does require this kind of concept, is it "less complex" to do it in C, where you'd have to write all the synchronization and task-switching and time-slicing routines yourself? Maybe "overloading" seems complex (although I don't see why), but C doesn't have it at all, so you have to come up with distinct names for everything---so why can't you just do the same thing in Ada? Ada does not put a gun to your head and say you must understand and use overloading. It's a nice feature if you want to use it, but if you don't, don't---why would that be a point against using the language? I recently bought Quicken Deluxe 99. There are a lot of options on there that I don't understand at all, and I'd have to do a fair amount of reading to see if I wanted to use them and then to use them effectively. So what? Does this mean I'm supposed to return the program to the store? The program does the things I need to do all the time nicely, and I like it; and as for the other features, maybe if I have time I'll look into it, but I don't need to know anything about them in order to use the rest of the program. Ada is pretty much the same way, and I just can't understand why this "too complex" argument is used so often as a reason not to use Ada (particularly by people who want to use C). It seems silly. > Next time I make a joke I'll make it about something that people don't > take so damn seriously. Death, famine, or nuclear winter maybe. :-) No, next time you make a joke that's not intended to make a point, write it in such a way so that it looks like it's not intended to make a point. Sometimes humor is just to make people laugh, but sometimes it's a good form for expressing an opinion. Since several people (including myself) have assumed you were attempting the latter, I'd say that the fault lies in your writing style, not in our being humor-impaired. And if you were really trying to make a point, then expect your point to be criticized. -- Adam -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own