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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 11390f,4c42ac518eba0bbe X-Google-Attributes: gid11390f,public X-Google-Thread: 1014db,4c42ac518eba0bbe X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,4c42ac518eba0bbe X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,4c42ac518eba0bbe X-Google-Attributes: gid109fba,public From: Alan E & Carmel J Brain Subject: Re: Programming language vote - results Date: 1997/10/21 Message-ID: <344D4787.260@dynamite.com.au> X-Deja-AN: 282158922 References: <344BCED0.2D51@dynamite.com.au> <877355167snz@genesis.demon.co.uk> <62fau3$fko$1@latte.cafe.net> Organization: @home Reply-To: aebrain@dynamite.com.au Newsgroups: comp.lang.ada,comp.lang.apl,comp.lang.c,comp.lang.c++ Date: 1997-10-21T00:00:00+00:00 List-Id: Kaz wrote: > >>Hence my preference for Ada. When listening to C weenies - er - > >>enthusiasts talking about how their code is so tight, so efficient, and > >>above all so impenetrable that it's obviously superior to another > >>solution (in Ada so clear that "Any Fool could have written that"), I > >>have to take a dried-frog pill and count to 10. > In any case, Ada's clarity of expression is extremely overemphasized > by Ada ween^H^H^H^Hadvocates. The word you're looking for is "Fanatics". As in people who are so busy fighting, they've forgotten what they're fighting for. I have been known to suffer from this myself, as you may have guessed, but I try to keep it in check. Sometimes it's difficult. > Ada source has very little to guide the eye, due to its lack of the use of > concise graphical symbols. Blocks delimited by BEGIN and END simply do not > nest visually. Concur. Chroma keying helps, as it does in any similar language. But even {} is not really good, unless used in the style xxxxxxx { xxxx xxxxx } rather than xxxxxxx { xxxx xxxxx } > The comments introduced by -- simply don't stand out very well. As opposed to // ? Have to think about this one, I can't see there's much to choose. */ and /* on the other hand, seem significantly worse. But what about other languages/methods? How can this be done better? Over 2 U for suggestions. > The input character set is excessively restricted, and simple () > parentheses are too overloaded in meaning because {} and [] aren't available > (is x(y) a function call or an array ref?). Does it matter? Sometimes, yes, it does, and the overload is then a right pain. Other times, the degree of abstraction that is optimal is such that you don't need to know, and this is more often the case in the domains I've been working in. For example, TheGuestList(x) could be: a function that examines a database on system 345 then assembles the name into a record, then makes a call to a server outside the system to find the dietary restrictions, then after completion asks for operator input from another terminal so we can allocate a seat , or it could be a simple reference to an array. In either case though, what you end up with is a guest and the data. How that's done, especially on a distributed system where the data is all over the place, is irrelevant to the issue. More to the point, you can make a system where everything is hard-coded in a table and get your segment working correctly, while the team(s) doing the server and HCI get their act together 2 months late. The fact that other languages have this problem, and worse, is immaterial. > As a result, your brain has to do a lot more analysis when reading code, > since you have to subconsciously check the syntax and even some semantics > to glean information that could be lexically determined. Excellent point, Sir! Agree that all languages I've seen have this problem. Some worse than others, eg fred*bill; - declaration or multiplication? > Ada programs tend to be verbose and amorphous looking, qualities which occlude > the meaning. (I'm talking about conventionally formatted programs, too e.g. > GNAT sources. It wouldn't be fair to pick a purposely obfuscated example, > just like it wouldn't be fair to choose an obfuscated C example.) Partial agreement. Example: A loop through an enumerated type (this is fairly common to a lot of problems, right?) C++ (with Hungarian-like Notation) //---------------------------------------------------------- enum TrafficLight_E [ Red_KE = 1, Amber_KE, Green_KE ]; const MaxTrafficLight_K = Green_KE + 1; for (int index = 1; index < MaxTrafficLight_K ; index++) { // some statements } //---------------------------------------------------------- compared with: Ada (with TypeRecord notation) --/////////////////////////////////////////////////////////// type TrafficLightType is (Red, Amber, Green); for index in TrafficLightType loop -- some statements end loop; --/////////////////////////////////////////////////////////// In some ways, the C++ is more verbose, is it not? > Although Ada is great, I wouldn't advocate it on grounds of lexical or > syntactic convenience or readability. You'd have to be crazy! To me, in the above example, the Ada is more readable. And a heck of a lot easier to type. Examples are always suspect, however, and I agree completely that you can always find a pathological case. Yet to me, this one is not atypical: The Hungarian Notation for C++ seems neccessary to me, since in C++ you're vitally interested in the representation. Sure, it's a maintenance nightmare when an int changes to a long, but the benefits far outway the disadvantages. At least IMHO. In Ada, you've got better things to worry about than the representation, as a general rule. And when you do need it, you use a representation clause, such as one that makes Red equal to (binary) 100, Amber to 010 and Green to 001, as they may well do if you're controlling/reading via a parallel port. Your thoughts? I'm especially interested since you obviously know something about Ada-83 or -95 as well as C/C++. Unlike most critics, I hasten to add. Are you familiar with APL too? The comment symbol there is not exactly obvious! -- aebrain@dynamite.com.au <> <> How doth the little Crocodile | Alan & Carmel Brain| xxxxx Improve his shining tail? | Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM abrain@cs.adfa.oz.au o OO*O^^^^O*OO o oo oo oo oo By pulling MAERKLIN Wagons, in 1/220 Scale