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.1 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00, PDS_BTC_ID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 10ad19,23963231b5359f74 X-Google-Attributes: gid10ad19,public X-Google-Thread: 1073c2,23963231b5359f74 X-Google-Attributes: gid1073c2,public X-Google-Thread: 11440e,23963231b5359f74 X-Google-Attributes: gid11440e,public X-Google-Thread: 101deb,23963231b5359f74 X-Google-Attributes: gid101deb,public X-Google-Thread: 103376,23963231b5359f74 X-Google-Attributes: gid103376,public X-Google-Thread: 107a89,23963231b5359f74 X-Google-Attributes: gid107a89,public X-Google-Thread: 10a146,23963231b5359f74 X-Google-Attributes: gid10a146,public X-Google-ArrivalTime: 2001-06-06 08:46:25 PST Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!supernews.com!isdnet!psinet-france!psiuk-f4!psiuk-p4!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ruby,comp.lang.ada,comp.lang.awk,comp.lang.clarion,comp.lang.java.programmer,comp.lang.pl1,comp.lang.vrml Subject: Re: Long names are doom ? Date: Wed, 6 Jun 2001 11:25:28 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9fli1b$4aa$1@nh.pace.co.uk> References: <83WP6.3874$yc6.728572@news.xtra.co.nz> <3B1411D0.3AAF42E7@ftw.rsc.raytheon.com> <9f2nks$ibd$0@dosa.alt.net> <3B177EF7.2A2470F4@facilnet.es> <9f8b7b$h0e$1@nh.pace.co.uk> <9f8r0i$lu3$1@nh.pace.co.uk> <9fgagu$6ae$1@nh.pace.co.uk> <9fjgha$blf$1@nh.pace.co.uk> <35mqhtkdfma2rggv1htcaq6vfn2ihs67a1@4ax.com> NNTP-Posting-Host: 136.170.200.133 X-Trace: nh.pace.co.uk 991841131 4426 136.170.200.133 (6 Jun 2001 15:25:31 GMT) X-Complaints-To: newsmaster@pace.co.uk NNTP-Posting-Date: 6 Jun 2001 15:25:31 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ruby:10428 comp.lang.ada:8232 comp.lang.awk:2822 comp.lang.clarion:21222 comp.lang.java.programmer:74099 comp.lang.pl1:816 comp.lang.vrml:3558 Date: 2001-06-06T15:25:31+00:00 List-Id: "Pete Thompson" wrote in message news:35mqhtkdfma2rggv1htcaq6vfn2ihs67a1@4ax.com... > Hmm in that case, I should give you my sister's phone number. She can talk for > well over two hours on the phone before finally getting to the point :) > Verbosity for the sake of being verbose is as dumb as terseness for the sake of being terse. Whatever you put on paper needs to say something *useful* to the reader and do so in a *clear* manner. Verbosity or terseness must be used to serve some higher goal - not become goals in and of themselves. > I feel the same way about code: being verbose is all well and good, but > pointless verbosity can do more harm than good. It tends to hide the overall > picture as to what the function/application is *really* doing. It makes the > function look more complicated than it really is. It leaves you wondering if > you're somehow missing something because there's more to read than is really > necessary. > We agree here. I think that again I'd emphasize that it is neither verbosity nor terseness that makes something clear to the reader. Clarity of thought and expression are not going to come from either terse or verbose notation. First the thought has to be clear. Then you have to find a way of expressing that thought in a manner that will be understood by the audience. > As Roedy mentioned in some other message, it's a hard one to pin down since > it's such a subjective matter. Maybe it's futile to even try. > There is some subjectivity to it, but I would say "not entirely" I think that the notation in C is entirely too terse and subject to way too much abuse. Likewise, I think the syntax of Cobol is way too verbose and needlessly obfuscates with TMI. (Who thinks that "Add Gin To Vermouth Giving Martini." is somehow a better idea than "Gin := Vermouth + Martini;" ?) > Which one of the following do you prefer: > > i = i + 1; > > or > > i equals i plus one. > I like the first better. But I dislike things like I++ - not so much that particular one, but all the subtle variations that can take place. It changes meaning if it is in front or behind - but that only makes a difference sometimes. It can be mixed with other interesting variations and things like +=, etc. In the end, the "terseness" possible with this kind of operator is just plain not worth it. Way too subject to abuse. Way too easy to misconstrue meaning in complicated cases. Often ambiguous in definition leading to "implementation dependent", reliant on side effects, Etc. So to save the few keystrokes needed for "I := I + 1 ;" I give you "I++" and open the floodgates for the "Betcha can't guess what *this* line does!!!" kind of coding. Better to be rid of it and insist on the few extra keystrokes needed for Fortran-ish expressions and avoid all the trouble that will inevitably come from that programmer who will insist that "It should be intuitively obvious to any *COMPETENT* C programmer..." > Imagine a whole program written using the latter method. Would that really be > much fun to read? Compound statements would be nearly unreadable. > Imagine? Don't need to. Been there. Done that. Its called "Cobol Programming" > > Hmm.. I'd have to say that I agree and disagree. It really depends on what > industry you're in. If you're in the kind of industry where you're hiring > newbie programmers all the time, then yes, it's important to be as explicit as > possible. However, there are industries where programmers MUST be experienced > before they're hired. Does it really make sense to make your code as > newbie-ish as possible for them? (Again, without being cryptic). > Here's the issue: (And there's no way of getting around the question.) How is it that this MAKES MONEY FOR THE STOCKHOLDERS? (Sorry for shouting.) All industries hire newbies. Even experienced programmers are newbies to your code - otherwise they aren't new-hires. If I write simple, direct, straightforward code with good comments, good structure, good documentation, etc., then I've got code that a newbie to Language XXX can readily read and grasp (hopefully). Does it *HURT* the experienced programmer that you didn't write something in as few keystrokes as possible within Language XXX? I don't think so. (Like I said, whenever someone else picks up your program for the first time, they are a "newbie") Anything I do to help the newbie understand what is going on is at worst, not going to hurt the experienced programmer and at best will probably help him along as well. Now there are some things which are inherently complicated. If I need multitasking - that's going to be tough to express simply because it isn't a simple thing to do. Can't help you there by picking some kind of notational syntax perceived to be "better". I think it was Einstein who said "Things should be made as simple as possible - but no simpler." I guess what I'd prefer to avoid in a language syntax are the obvious pitfalls that repeatedly create errors and inevitably cause confusion and miscommunication. Doing that much accomplishes something. It will never make E := M * C**2 ; be as simple to understand as Y := M * X + B ; > > Well, that's sort of going to the extreme. If the syntax is a part of the > language itself, then it should be readable by anyone well versed with the > language. "i++" is not cryptic since that's a part of the language. > Read before what I said about opening up the floodgates. Some features of a language are *inherently* unsafe or encourage obfuscation or make it easy to introduce errors. In C (and in a number of other languages) you have well known "syntax traps" that make it easy to create compile time errors that are hard to locate. Similarly, there are "semantic traps" that make it easy to introduce run-time errors. (BTW, this is true of verbose languages like Cobol as well). I'm in favor of structuring the notation of a language such that it minimizes the risk of errors and maximizes the communication to the reader. IMHO, C's terse notation works against these goals. C's semantics work against these goals as well, but that's another debate. > If it's a "clever" (ab)use of the language, then you may need to reevaluate > what you're doing. I hate it when people try to cram 4 or 5 or more different > things into the same line. I just love reading stuff like c = a+++++b. (not) > I hear you. I agree with this. I'd prefer a language design that does not ALLOW something like what you just described, no matter how much "expressive power" can be gained for the attainment of Good And Noble goals. (Sort of an "ends justifies the means" argument?) Just because someone might rarely (and arguably) use this sort of notation to express something in a clear and concise manner, does not mean I want to frequently (and not so arguably) see these kinds of attrocities committed either because someone a) thought it was "clever" or b) thought it was "Intuitively Obvious To Any *Competent* Programmer" or c) both. One of the reasons I like Ada so much is because the syntax and semantics tends to avoid such obfuscations. Its not that you *can't* write bad code in Ada. (nor is it hard to write "concise" code - as long as we aren't simply counting keystrokes as the measure of "conciseness") Its just that it tends to steer you towards more straightforward and direct expression of what you intended to do. It also does an enormous amount of error checking and disallows certain things that cause errors commonly. The syntax also avoids common "syntax traps" found in other languages & makes it easier for the compiler to pinpoint exactly where you mistyped something. If you can't write good code in C, you aren't magically going to start writing good code in Ada. However, I think Ada provides a lot more help to the programmer who is capable of writing good code. > I guess we're pretty much arguing the same thing at this point. My own > contention is that there are programmers who are needlessly verbose that the > code looks more complex than it really is. > Anything can be taken to extremes. I've seen Ada code where the proliferation of types & subtypes got so bad that you couldn't tell the players without a scorecard. I've seen Ada code where the programmers thought tasks were so cool, they ended up using them like they were procedrues - to no advantage and with subsequent synchronization problems. Obviously, someone sent these dudes off to a class that taught Ada & OOD/OOP and they came back with half an understanding and lots of enthusiasm. The first attempt at using just about any language may result in drastically bad code because the newbie doesn't have the experience needed to make judgement calls about the things that are rather subjective. (How many subtypes should a program have? How many tasks should a program be broken down into? There are no iron-clad rules. Like pornography, I can't write you a uniform legal description, but I know it when I see it.) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/