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: 10ad19,23963231b5359f74 X-Google-Attributes: gid10ad19,public X-Google-Thread: 11440e,23963231b5359f74 X-Google-Attributes: gid11440e,public X-Google-Thread: 103376,23963231b5359f74 X-Google-Attributes: gid103376,public X-Google-Thread: 101deb,23963231b5359f74 X-Google-Attributes: gid101deb,public X-Google-Thread: 1073c2,23963231b5359f74 X-Google-Attributes: gid1073c2,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 15:52:31 PST Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!sn-post-01!supernews.com!news.supernews.com!not-for-mail From: Pete Thompson 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, 06 Jun 2001 15:53:06 -0700 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <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> <9fli1b$4aa$1@nh.pace.co.uk> X-Newsreader: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: newsabuse@supernews.com Xref: archiver1.google.com comp.lang.ruby:10440 comp.lang.ada:8277 comp.lang.awk:2834 comp.lang.clarion:21257 comp.lang.java.programmer:74234 comp.lang.pl1:829 comp.lang.vrml:3571 Date: 2001-06-06T15:53:06-07:00 List-Id: On Wed, 6 Jun 2001 11:25:28 -0400, "Marin David Condic" wrote: >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 Well, sure it's subject to abuse. However, that's the fault of the programmer, not the language itself. I too froth at the mouth whenever someone makes a stupid use of operator overloading in C++, or write unnecessary compound statements. >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..." Maybe I've just been lucky enough to have never worked in a workplace with programmers like that who insists on trying to look clever in their code, and thus I have no problems like that. Should I be forced to move on to a more verbose language because other people had bad experiences? >> 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.) You have deadlines. Miss the deadlines and you're going to piss the stockholders off. More experienced people are generally faster than newbie coders, and new hires with experience tend to hit the ground running faster. No need to wait for them to learn the ins and out of the API that your company happens to be using, if they already know it. I'll explain more below. >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 If you're asking for my personal experiences, then yes it would hurt everyone (including the shareholders and customers) if I needlessly broke the code up into multiple statements that used up more clock cycles, especially if it's a piece of code that needs to be called often. I work in the gaming industry. Speed is king. Just make damn sure that you comment your algorithms. Unfortunately, people do tend to try to be needlessly terse and cram many instructions into a single line because they think that's a good way to optimize when it in fact accomplishes nothing. When hiring new people, we expect them to know at least the basics of the API we're using (DirectX, OpenGL, whatever), some 3D math, and some of the bells and whistles. We've got deadlines. We can't afford to hire pure newbies. A certain level of experience is a must. And yes, we do look for people with good coding practices -- no sloppy stuff, please! That'd just slow down the other team members. We once had a vacuum salesman with no programming experience applying for a job... want him? :) Of course there are the odd times when we do hire programmers from another industry, but we generally stick them with the task of creating tools and utilities until they learn the gaming fundamentals. Sometimes they're quite happy with creating tools, and never want to work on games directly. If I was working for, say, a bank, then yes I would write slow and reliable code that would last for years and be easily readable by people 10 years down the road. If I was writing software for a weapons research facility, then I'd be sweating over every line and be agonizingly descriptive (/* here is the auto-destruct function. I say again, here is the auto-destruct function. WARNING! Danger Will Robinson Danger! */). However, working in the gaming industry is a bit unforgiving in the sense that your code generally becomes obsolete fairly quickly. Just about the only thing we can keep from project to project are the libraries, interfaces, and platform-independent functions, and even they may need changing as new platforms ship. Spend too long programming, and your game becomes obsolete before it even ships, like a certain over-hyped game... *cough*Daikatana*cough*. As such, writing long-term code is a bit of a wasted effort (unless if it's REALLY useful and generic such as a quicksort function), and that time would be better invested in tweaking the eye-candy to attract more customers. >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. Well, sure. Pointer arithmetic in C/C++ is inherently unsafe and encourages obfuscation. However, it also promotes flexibility. That's always been an acknowledged trade-off in C/C++ - with flexibility comes responsibility. I don't see how you can clean up the notations to reduce bugs, though, short of getting rid of pointers altogether (which I definitely DON'T want to see happen in C/C++). >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 Well.. it's always hard to predict how creative the programmer can be. Java was supposed to be "clean"... of course it didn't take too long for people to prove otherwise :) On the flip side, be too restrictive, and you could end up with a dead language. People complained about Pascal because it was so "structured". It really depends on the programmer - like you said, anything can be taken to the extremes, and even the greatest language in the world can end up looking horrible in the hands of a talented (ahem) programmer, and there's not much we can do to "fix" this. I've accepted this about C/C++: I know it's not perfect, and I do bitch about it off and on, but it works well for me for what I need to do. A hammer's just so damn useful, but I still sometimes hit my thumb.