b_haughey@ccvax.ucd.ie (Brian J Haughey) (10/25/90)
In article <6089@nisca.ircc.ohio-state.edu>, smsmith@hpuxa.ircc.ohio-state.edu (Stephen M. Smith) writes: > In article <1990Oct23.235720.16178@nas.nasa.gov> > >> ... The instructor went on, >>"don't ever write code like this! Considering the fact that none of you >>were able to figure out what it did demonstrates that it is very >>poor code". >> >>In otherwords, be clever when you have to, not just to show off. > > Exactly. Fortunately as a new student to programming I have a very > good instructor who emphasizes this very thing. In the first weeks > of class he has already emphasized portability and threatened to > anonymously distribute each of our own programs to the rest of the > class just to see if WE can be easily deciphered by our own colleagues. I don't want to start a whole thread on this topic, but I feel I couldn't let this stuff pass. First of all, when I write code I make no apologies for its succintness or cleverness. The project I am working on involves writing code in assembler for the 1802 microprocessor. (Please ! No flames ! If it's good enough for space probes...). Because of the relatively small address space, we are hard-pressed to fit in all the features and capabilities that we are committed to doing, even using bank-switching and other methods. I do not write obscure code for the sake of being obscure. Any code I write is designed to be as small and fast as possible. If it is not clear what the code does, then I comment it. But I will be damned if I will ignore the optimal (or a more optimal) algorithm for the sake of some moron who is brain-dead and can't figure it out from the code and comments. It seems to me that there is a strong element of quiche-eating entering computers these days. Perhaps it's that people who heretofore would not have taken to computers now feel "Ah, computers are very important. I should learn to program". Frankly, most of these people probably have no aptitude for hard-core programming. Sure, they can write payrolls and lotus macros. But they certainly shouldn't have the cheek to criticise the code of a better programmer merely because they can't understand it. Once the code is properly commented, and is efficient, it is sufficient ! Flames to Alt.Flame or Alt.Stupidity Witty articles to Comp.misc Regards, bjh "There's no future in time travel" Internet : b_haughey@ccvax.ucd.ie
magnus%thep.lu.se@Urd.lth.se (Magnus Olsson) (10/26/90)
In article <7386.2726d343@ccvax.ucd.ie> b_haughey@ccvax.ucd.ie (Brian J Haughey) writes: >First of all, when I write code I make no apologies for its succintness >or cleverness. The project I am working on involves writing code in >assembler for the 1802 microprocessor. (Please ! No flames ! If it's >good enough for space probes...). Because of the relatively small >address space, we are hard-pressed to fit in all the features andcapabilities >that we are committed to doing, even using bank-switching and other >methods. Having recently read through the data sheet for the 1802, I can understand why you have to write obscure code. You have my sympathies... :-| >I do not write obscure code for the sake of being obscure. Any code I write >is designed to be as small and fast as possible. If it is not clear what >the code does, then I comment it. >Once the code is properly commented, and is efficient, it is sufficient ! I think this is a very important point: The code has to be properly commented. If you have some compelling reason to write code that may be a bit obscure to others, then be sure to comment it, so it is clear what it does! I've once had the doubtful pleasure of having to understand a Fortran IV program that calculated atomic energy levels (I was going to add some new features to it). Now, this program was written by "real programmers" in the late sixties, and run on some really small and slow machines by todays standards, so I don't blame them at all for producing some pretty obscure code - they simply *had* to re-use COMMON variables for different things in different subroutines and things like that. What *did* cause me a lot of trouble was that the code was almost totally undocumented - in 5000 lines of code, there couldn't have been more than five or ten comments! Good programming style is important, and there are certain rules, like "Don't use GOTO's", which should be followed perhaps 99% of the time, not only because it makes your program more readable to others, but also because it reduces the risk of your making a mistake. Sometimes, however, you have to break these rules. The sad thing is that a lot of people seem to think of these rules as immutable laws, written down in the Holy Scriptures of Computer Science: "Thou Shalt Not Use The Abominable Goto In Thy Programs". Maybe one should put the point about "obscure" programming like this: Don't write obscure code or invent "clever" constructs unless you really have to. If you have to, be sure to comment exactly what your code does. Don't do it just to show how clever you are. An example: Suppose I want to exchange the values of the two integer variables A and B. The standard way of doing it is TEMP:=A; A:=B; B:=TEMP; Another way, which "saves" you from declaring the temporary variable, is A:=A+B; B:=A-B; A:=A-B; This is (arguably) "clever". It also totally obfuscates the meaning of the code. Normally, the gain of not having to declare a temporary variable is totally negligible and does not compensate for the lack of readability. Also, the code above is non-portable: If you decided to change the type of A and B to some type where addition and subtraction aren't defined (e.g. if you switched from representing people by their SSN (which is common in Sweden) to representing them by their name), then you'll have to rewrite the code. Conceivably, there could be a case where you really have strong reasons to use the "clever" code (e.g. on a Basic machine with only 26 variables). In that case, nobody should blame you for using it. If you're using it just to show off (which many hackers seem to be doing all the time), it's another matter. Magnus Olsson | \e+ /_ Dept. of Theoretical Physics | \ Z / q University of Lund, Sweden | >----< Internet: magnus@thep.lu.se | / \===== g Bitnet: THEPMO@SELDC52 | /e- \q
peter@ficc.ferranti.com (Peter da Silva) (10/26/90)
In article <7386.2726d343@ccvax.ucd.ie> b_haughey@ccvax.ucd.ie (Brian J Haughey) writes: > First of all, when I write code I make no apologies for its succintness > or cleverness. The project I am working on involves writing code in > assembler for the 1802 microprocessor. Pretty little thing, isn't it? Nice Forth platform, too. Do you use the SCRT or the token-table threaded approach in the design notes? (hey folks, 16 16-bit registers in 1976 or so is nothing to sneeze at. If only iNTEL had deigned to notice it!) IMHO, if you can't appreciate the 1802 you're not a Real Programmer. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
dbc@bushido.uucp (Dave Caswell) (10/27/90)
(>>"don't ever write code like this! Considering the fact that none of you (>>were able to figure out what it did demonstrates that it is very (>>poor code". (>> (>>In otherwords, be clever when you have to, not just to show off. (> (> Exactly. Fortunately as a new student to programming I have a very (> good instructor who emphasizes this very thing. In the first weeks (> of class he has already emphasized portability and threatened to (> anonymously distribute each of our own programs to the rest of the (> class just to see if WE can be easily deciphered by our own colleagues. ( (I don't want to start a whole thread on this topic, but I feel I couldn't (let this stuff pass. [stuff deleted] (It seems to me that there is a strong element of quiche-eating entering (computers these days. Perhaps it's that people who heretofore would not (have taken to computers now feel "Ah, computers are very important. I (should learn to program". Frankly, most of these people probably have no (aptitude for hard-core programming. Sure, they can write payrolls and (lotus macros. But they certainly shouldn't have the cheek to criticise the (code of a better programmer merely because they can't understand it. (Once the code is properly commented, and is efficient, it is sufficient ! Just like anything else in life, you write for a particular audience. If I'm working on a system with a group of poeple, and we're thinking about hiring a new person we show them some code we've written. If they don't understand it, they don't get hired, we don't rewrite the code. Everyone I interview gets code to write, and code to read. I've had people with (they said) four years experience working with BSD UNIX, start crying during an interview. That isn't pleasant, but relying on them as co-workers is even less pleasant. I require the same amount of expertise reading and writing in my particular programming language as I do in an English teacher reading and writing English. It is well-known that there are orders of magnitude differences among programmer's ability, it is hard to believe that many of the best ones can't understand the language they are using to communicate. In summary, write for good programmers (people who know the language well), retrain (if possible) the poor ones. -- David Caswell dbc%bushido.uucp@umich.edu
beldin@peachs.enet.dec.com (Rick Beldin) (10/28/90)
In one of my first jobs, I picked up some code that another person (not an intentional programmer, let alone a real one) had done. He had hacked it up about a week before we were supposed to release it to production (manufacturing application s/w) and then handed it off to me with a list of 'enhancements' (bugfixes) I was supposed to do. He then disappeared - too busy with other projects. I nearly screamed when I saw this code (is this section dead?, how do we get here? What the hell is this? Where are the comments?). I struggled with it for about 3 days and then I printed the whole thing out (somewhat over 1000 lines) on 132 column paper and proceeded to grade it like my software engineering teacher used to do to my assignments. I failed him and laid the paper on my bosses desk. The next day my boss called us both in, asked me to draw up a set of coding standards and asked my colleague to follow them. Funny how he kept coming to ME with questions about how HIS code worked! +-----------------------------------------------------------------------------+ | Rick Beldin email: beldin@rhett.enet.dec.com | | Digital Equipment Corporation | | VMS Workstation Support | | Alpharetta, GA | | | | "Opinions expressed are my own - definitely not those of my employer" | | | +-----------------------------------------------------------------------------+
davet@cbnewsj.att.com (Dave Tutelman) (10/29/90)
In article <URO61N8@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > In article <7386.2726d343@ccvax.ucd.ie> b_haughey@ccvax.ucd.ie (Brian J Haughey) writes: > > First of all, when I write code I make no apologies for its succintness > > or cleverness. The project I am working on involves writing code in > > assembler for the 1802 microprocessor. > > (hey folks, 16 16-bit registers in 1976 or so is nothing to sneeze at. If > only iNTEL had deigned to notice it!) > IMHO, if you can't appreciate the 1802 you're not a Real Programmer. Let's see; 1990 - 1976 = 14 years. Go back another 14 years and it's 1962. And you're STILL not back to the inception of the Royal McBee LGP30 (the machine Mel hacked on - check the story). In 1961, it became the CCNY engineering school's first computer. So Mel was indeed a REAL PROGRAMMER. He didn't do what he did to be obscure; he really needed to if he wanted performance/function out of the machine. Take it from me, the LGP30 was NOT a powerful box unless your alternative was slide rule and pencil. Shouldn't this thread be moved to alt.folklore.computers? Dave
news@bbn.com (News system owner ID) (11/10/90)
Model 3/60 FC-4-P5 4 MB memory 141 MB Hard Disk 60 MB 1/4" Tape 16" Color Monitor 1152X900 All Documentation Used less than 10 hours, one year old From: ddoherty@bbn.com (Diane M. Doherty) Path: bbn.com!ddoherty Will sell for best offer. Call Tony (617) 245-6895
rhys@batserver.cs.uq.oz.au (Rhys Weatherley) (11/10/90)
news@bbn.com (News system owner ID) writes: >Model 3/60 FC-4-P5 >Used less than 10 hours, one year old >Will sell for best offer. Call Tony (617) 245-6895 Could it be Tony that you're selling your Model 3/60 so you can get a "REAL" machine that must be programmed with toggle switches and things? Rhys. P.S. Note subject line of Tony's message.
rlr@bbt.UUCP (rader) (11/17/90)
peter@ficc.ferranti.com (Peter da Silva) writes: > b_haughey@ccvax.ucd.ie (Brian J Haughey) writes: >> First of all, when I write code I make no apologies for its succintness >> or cleverness. The project I am working on involves writing code in >> assembler for the 1802 microprocessor. > >IMHO, if you can't appreciate the 1802 you're not a Real Programmer. Hee, hee, hee! Yup, I worked at JPL, programming the Project Galileo Command and Data Subsystem. Quite an interesting endeavor, considering this virtual machine scheme implemented on 6 networked 1802s. All assembler, mind you! (Well, we had an in-house Structured Assembler, based on macros). And now I get the ignoble task of programming the Z8! -- ron rader, jr rlr%bbt@rti.rti.org = Opinions are my own and do not | | i gotta six- rlr%bbt$rti.rti.org@CUNYVM = necessarily reflect those of | | pack, & nothin' to do ...!mcnc!rti!bbt!rlr = BroadBand Tech. (SO THERE!) *** Punk ain't no religious cult, punk means thinking for yourself - DKs ***