b_haughey@ccvax.ucd.ie (Brian J Haughey) (10/17/90)
TEXTS Node: Mel Previous: Top Up: Top
-- Source: usenet: utastro!nather, May 21, 1983.
[I got this version from AIDA, a DEC-2060, in 1983 - b_haughey@ccvax.ucd.ie]
A recent article devoted to the *macho* side of programming
made the bald and unvarnished statement:
Real Programmers write in Fortran.
Maybe they do now,
in this decadent era of
Lite beer, hand calculators and "user-friendly" software
but back in the Good Old Days,
when the term "software" sounded funny
and Real Computers were made out of drums and vacuum tubes,
Real Programmers wrote in machine code.
Not Fortran. Not RATFOR. Not, even, assembly language.
Machine Code.
Raw, unadorned, inscrutable hexadecimal numbers.
Directly.
Lest a whole new generation of programmers
grow up in ignorance of this glorious past,
I feel duty-bound to describe,
as best I can through the generation gap,
how a Real Programmer wrote code.
I'll call him Mel,
because that was his name.
I first met Mel when I went to work for Royal McBee Computer Corp.,
a now-defunct subsidiary of the typewriter company.
The firm manufactured the LGP-30,
a small, cheap (by the standards of the day)
drum-memory computer,
and had just started to manufacture
the RPC-4000, a much-improved,
bigger, better, faster -- drum-memory computer.
Cores cost too much,
and weren't here to stay, anyway.
(That's why you haven't heard of the company, or the computer.)
I had been hired to write a Fortran compiler
for this new marvel and Mel was my guide to its wonders.
Mel didn't approve of compilers.
"If a program can't rewrite its own code,"
he asked, "what good is it?"
Mel had written,
in hexadecimal,
the most popular computer program the company owned.
It ran on the LGP-30
and played blackjack with potential customers
at computer shows.
Its effect was always dramatic.
The LGP-30 booth was packed at every show,
and the IBM salesmen stood around
talking to each other.
Whether or not this actually sold computers
was a question we never discussed.
Mel's job was to re-write
the blackjack program for the RPC-4000.
(Port? What does that mean?)
The new computer had a one-plus-one
addressing scheme,
in which each machine instruction,
in addition to the operation code
and the address of the needed operand,
had a second address that indicated where, on the revolving drum,
the next instruction was located.
In modern parlance,
every single instruction was followed by a GO TO!
Put *that* in Pascal's pipe and smoke it.
Mel loved the RPC-4000
because he could optimize his code:
that is, locate instructions on the drum
so that just as one finished its job,
the next would be just arriving at the "read head"
and available for immediate execution.
There was a program to do that job,
an "optimizing assembler",
but Mel refused to use it.
"You never know where its going to put things",
he explained, "so you'd have to use separate constants".
It was a long time before I understood that remark.
Since Mel knew the numerical value
of every operation code,
and assigned his own drum addresses,
every instruction he wrote could also be considered
a numerical constant.
He could pick up an earlier "add" instruction, say,
and multiply by it,
if it had the right numeric value.
His code was not easy for someone else to modify.
I compared Mel's hand-optimized programs
with the same code massaged by the optimizing assembler program,
and Mel's always ran faster.
That was because the "top-down" method of program design
hadn't been invented yet,
and Mel wouldn't have used it anyway.
He wrote the innermost parts of his program loops first,
so they would get first choice
of the optimum address locations on the drum.
The optimizing assembler wasn't smart enough to do it that way.
Mel never wrote time-delay loops, either,
even when the balky Flexowriter
required a delay between output characters to work right.
He just located instructions on the drum
so each successive one was just *past* the read head
when it was needed;
the drum had to execute another complete revolution
to find the next instruction.
He coined an unforgettable term for this procedure.
Although "optimum" is an absolute term,
like "unique", it became common verbal practice
to make it relative:
"not quite optimum" or "less optimum"
or "not very optimum".
Mel called the maximum time-delay locations
the "most pessimum".
After he finished the blackjack program
and got it to run,
("Even the initializer is optimized",
he said proudly)
he got a Change Request from the sales department.
The program used an elegant (optimized)
random number generator
to shuffle the "cards" and deal from the "deck",
and some of the salesmen felt it was too fair,
since sometimes the customers lost.
They wanted Mel to modify the program
so, at the setting of a sense switch on the console,
they could change the odds and let the customer win.
Mel balked.
He felt this was patently dishonest,
which it was,
and that it impinged on his personal integrity as a programmer,
which it did,
so he refused to do it.
The Head Salesman talked to Mel,
as did the Big Boss and, at the boss's urging,
a few Fellow Programmers.
Mel finally gave in and wrote the code,
but he got the test backwards,
and, when the sense switch was turned on,
the program would cheat, winning every time.
Mel was delighted with this,
claiming his subconscious was uncontrollably ethical,
and adamantly refused to fix it.
After Mel had left the company for greener pa$ture$,
the Big Boss asked me to look at the code
and see if I could find the test and reverse it.
Somewhat reluctantly, I agreed to look.
Tracking Mel's code was a real adventure.
I have often felt that programming is an art form,
whose real value can only be appreciated
by another versed in the same arcane art;
there are lovely gems and brilliant coups
hidden from human view and admiration, sometimes forever,
by the very nature of the process.
You can learn a lot about an individual
just by reading through his code,
even in hexadecimal.
Mel was, I think, an unsung genius.
Perhaps my greatest shock came
when I found an innocent loop that had no test in it.
No test. *None*.
Common sense said it had to be a closed loop,
where the program would circle, forever, endlessly.
Program control passed right through it, however,
and safely out the other side.
It took me two weeks to figure it out.
The RPC-4000 computer had a really modern facility
called an index register.
It allowed the programmer to write a program loop
that used an indexed instruction inside;
each time through,
the number in the index register
was added to the address of that instruction,
so it would refer
to the next datum in a series.
He had only to increment the index register
each time through.
Mel never used it.
Instead, he would pull the instruction into a machine register,
add one to its address,
and store it back.
He would then execute the modified instruction
right from the register.
The loop was written so this additional execution time
was taken into account --
just as this instruction finished,
the next one was right under the drum's read head,
ready to go.
But the loop had no test in it.
The vital clue came when I noticed
the index register bit,
the bit that lay between the address
and the operation code in the instruction word,
was turned on--
yet Mel never used the index register,
leaving it zero all the time.
When the light went on it nearly blinded me.
He had located the data he was working on
near the top of memory --
the largest locations the instructions could address --
so, after the last datum was handled,
incrementing the instruction address
would make it overflow.
The carry would add one to the
operation code, changing it to the next one in the instruction set:
a jump instruction.
Sure enough, the next program instruction was
in address location zero,
and the program went happily on its way.
I haven't kept in touch with Mel,
so I don't know if he ever gave in to the flood of
change that has washed over programming techniques
since those long-gone days.
I like to think he didn't.
In any event,
I was impressed enough that I quit looking for the
offending test,
telling the Big Boss I couldn't find it.
He didn't seem surprised.
When I left the company,
the blackjack program would still cheat
if you turned on the right sense switch,
and I think that's how it should be.
I didn't feel comfortable
hacking up the code of a Real Programmer."smithwik@pioneer.arc.nasa.gov (R. Michael Smithwick -- FSN) (10/24/90)
In article <7380.271c3129@ccvax.ucd.ie> b_haughey@ccvax.ucd.ie (Brian J Haughey) writes: >TEXTS Node: Mel Previous: Top Up: Top > > -- Source: usenet: utastro!nather, May 21, 1983. > >[I got this version from AIDA, a DEC-2060, in 1983 - b_haughey@ccvax.ucd.ie] > > > A recent article devoted to the *macho* side of programming > made the bald and unvarnished statement: > > Real Programmers write in Fortran. > [deleted 250 lines of an admittedly great story about "Mel", the wonder-coder] While it is easy to call Mel a genius as a result of this story, I'm not too sure he could be called a "real programmer" by todays standards. A very clever programmer, yes, but if he were to try his cutsie hacks in production code (unless it really needed it) he would be bounced from the companys payroll in nothing flat. There is nothing to be proud of when one writes code so very cryptic someone else has to waste 2 weeks of company time to figure out a how a loop exits. One of the best lessons I learned in school was in my first Fortran class. Our teacher put a code fragment up on the board and asked us what it did. All 30 of us pondered it for a few minutes unable to decipher the intricacies of the routine. Finally our teacher explained that it simply cleared out an array. Suddenly the lights went on! "Of course!" we thought in unison, "why, how remarkably clever!". The instructor said "I bet you thought that this was clever". We all nodded hoping that one day we could all be clever enough ourselves to write like that. 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. So whenever I find myself writing a cryptic routine, I think of George, and wonder if he would use it as an example in his class. If the answer is yes, I rewrite it. >> mike smithwick << Any opinions are my own since nobody else would ever want them. "Colonize Cyberspace!"
smsmith@hpuxa.ircc.ohio-state.edu (Stephen M. Smith) (10/25/90)
In article <1990Oct23.235720.16178@nas.nasa.gov> smithwik@pioneer.arc.nasa.gov (R. Michael Smithwick -- FSN) writes: > >There is nothing to be proud of when one writes code so very cryptic >someone else has to waste 2 weeks of company time to figure out a how a >loop exits. > >One of the best lessons I learned in school was in my first Fortran >class....[deletion] > ... 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. S. "Stevie" Smith \ + / <smsmith@hpuxa. \+++++/ " #*&<-[89s]*(k#$@-_=//a2$]'+=.(2_&*%>,,@ ircc.ohio-state. \ + / {7%*@,..":27g)-=,#*:.#,/6&1*.4-,l@#9:-) " edu> \ + / BTW, WYSInaWYG \ + / --witty.saying.ARC
cgy@cs.brown.edu (Curtis Yarvin) (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> >smithwik@pioneer.arc.nasa.gov (R. Michael Smithwick -- FSN) writes: >> ... 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. Right - but you have to make the distinction between _cryptic_ code and _obfuscated_ code. Cryptic code is hard to understand because it gets the job done very well, but needs to carry out arcane manipulations to do it. Obfuscated code intentionally makes a simple task complex. If you find yourself writing cryptic code, code that is impossible to read but gets the job done very well, just comment it. Comments are cheap. But anyone who intentionally writes obfuscated code or uncommented cryptic code, and expects others to deal with it, should be shot - I agree with you there. Nonetheless we must recognize that, despite the best efforts of "software engineers," there is a place in the world for cryptic code. -Curtis "I tried living in the real world Instead of a shell But I was bored before I even began." - The Smiths
spg@alpha.sunquest.com (Steve Gibbons) (10/25/90)
In article <54296@brunix.UUCP>, cgy@cs.brown.edu (Curtis Yarvin) writes... >In article <6089@nisca.ircc.ohio-state.edu> smsmith@hpuxa.ircc.ohio-state.edu (Stephen M. Smith) writes: >Right - but you have to make the distinction between _cryptic_ code and >_obfuscated_ code. An example is interpreted code on limited memory systems where variable names, function names and program tags all take space in the programs partition. These are generally the first elements to be obfuscated (such that one winds up with variable names like x1,x2,x3; and program tags like a1,a2,a3. ..And heaven forbid that you should be in the situation that I am in where the overhead for function calls is so severe that one winds up using global variables on a regular basis > Cryptic code is hard to understand because it gets the >job done very well, but needs to carry out arcane manipulations to do it. >Obfuscated code intentionally makes a simple task complex. There is also the case of indirection and self-modifying/interpreted at runtime code. in some environmetnts the benefits of obfuscation far outweigh those of the straight-forward "code for all cases" approach... Take a look at the capabilities/drawbacks to MUMPS... (one of a handfull of ANSI standard lingos) and then tell me more... ____________________________________________________________________________ | Steve Gibbons, H.I.S. Interfacing | 602/885-7700x2649 or 602/296-8936(Fax) | | Sunquest Information Systems | spg@{alpha|nereid|beta}.sunquest.com | | 930 N. Finance Center Drive |----------------------------------------| | Tucson, Arizona 85710-1343 | "*I* didn't do it... ;-)" -Me | ---------------------------------------------------------------------------- P.S. obfuscated/obscure code should be no excuse for REQUIRING two weeks to debug a piece of code... it was mismanaged, to begin with... :)
dab@Oswego.EDU (Dave Bozak) (10/26/90)
In article <1990Oct23.235720.16178@nas.nasa.gov> smithwik@pioneer.arc.nasa.gov (R. Michael Smithwick -- FSN) writes: > >There is nothing to be proud of when one writes code so very cryptic >someone else has to waste 2 weeks of company time to figure out a how a >loop exits. > >One of the best lessons I learned in school was in my first Fortran >class. Our teacher put a code fragment up on the board and asked us what >it did. All 30 of us pondered it for a few minutes unable to decipher the >intricacies of the routine. Finally our teacher explained that it simply >cleared out an array. Suddenly the lights went on! "Of course!" we thought >in unison, "why, how remarkably clever!". The instructor said "I bet you >thought that this was clever". We all nodded hoping that one day we could >all be clever enough ourselves to write like that. 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. > I have this scrap of paper on my desk. It contains part of a signature line from some article posted a long time ago. My apologies to the person who created this, but I can't give you your due. The statement fits here quite well: Thou shalt make thy program's purpose and structure clear to thy fellow man by using a familiar style, even if thou likest it not, for thy creativity is better used in solving problems than in creating beautiful new impediments to understanding. I have shared this will ALL of my students, and continue to do so every semester. -dab /\ David Alan Bozak, Computer Science Department / \ SUNY College at Oswego, Oswego, NY 13126 (315) 341-2347 _____/____\_____ Internet: dab@rocky.oswego.edu / / \ \ or dab%rocky.oswego.edu@nisc.nyser.net /____/ \____\ UUCP: {cornell!devvax,rutgers!sunybcs}!oswego!rocky!dab
c_grant_c1@verifone.com (10/26/90)
In article <1990Oct23.235720.16178@nas.nasa.gov>, smithwik@pioneer.arc.nasa.gov (R. Michael Smithwick -- FSN) writes: > In article <7380.271c3129@ccvax.ucd.ie> b_haughey@ccvax.ucd.ie (Brian J Haughey) writes: >>TEXTS Node: Mel Previous: Top Up: Top >> >> -- Source: usenet: utastro!nather, May 21, 1983. >> >>[I got this version from AIDA, a DEC-2060, in 1983 - b_haughey@ccvax.ucd.ie] >> >> >> A recent article devoted to the *macho* side of programming >> made the bald and unvarnished statement: >> >> Real Programmers write in Fortran. >> > [deleted 250 lines of an admittedly great story about "Mel", > the wonder-coder] > > While it is easy to call Mel a genius as a result of this story, I'm > not too sure he could be called a "real programmer" by todays standards. > A very clever programmer, yes, but if he were to try his cutsie hacks in > production code (unless it really needed it) he would be bounced from the > companys payroll in nothing flat. > > There is nothing to be proud of when one writes code so very cryptic > someone else has to waste 2 weeks of company time to figure out a how a > loop exits. > > One of the best lessons I learned in school was in my first Fortran > class. Our teacher put a code fragment up on the board and asked us what > it did. All 30 of us pondered it for a few minutes unable to decipher the > intricacies of the routine. Finally our teacher explained that it simply > cleared out an array. Suddenly the lights went on! "Of course!" we thought > in unison, "why, how remarkably clever!". The instructor said "I bet you > thought that this was clever". We all nodded hoping that one day we could > all be clever enough ourselves to write like that. 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. > > So whenever I find myself writing a cryptic routine, I think of George, > and wonder if he would use it as an example in his class. If the answer > is yes, I rewrite it. > > > >> mike smithwick << > > Any opinions are my own since nobody else would ever want them. > > "Colonize Cyberspace!" I think that you are possibly missing the point about the Real Programmers (tm) thread. A Real Programmer doesn't care if nobody else can read his code. Writing readable code is almost as bad as commenting your code. Remember, users should be grateful they get anything at all. If it works, ought to be good enough. After all, what would be the challenge writing code if it's so simple minded any feeb could understand it. Mind you, I write code for a living also but I'm not a Real Programmer in that sense. But thinking about the image of the Real Programmer in previous messages, I'm not sure that's all bad. Grant China Disclaimer: All opinions above are mine. If my company wants them too then they'd better give me a raise!
seanf@sco.COM (Sean Fagan) (10/28/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> >>There is nothing to be proud of when one writes code so very cryptic >>someone else has to waste 2 weeks of company time to figure out a how a >>loop exits. Yes, there is. Programming can be considered an art. Note that the program in question was a *game*. "Mel" had a much more enjoyable time writing that program than anyone playing it ever did. Getting the last possible cycle out of a program is a fun way to relax, for some hackers. >>In otherwords, be clever when you have to, not just to show off. And, again: the program in question was a game. Not only that, but just a short time ago (20+ years), programmers *had* to write like that, on a lot of machines. Or are you two so complacent with VM and 20+MIPS machines that you think noone ever has to worry about real time, or fitting the critical sections of a program into memory, or trying to deal with real-world devices. Try reading the source code to some device drives, at times. That's about the closes you're likely to get, I suppose, to what programmers had to deal with 30 years ago or so. >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. A fine goal. Now, he should also give you an assignment, and require that it take X or less CPU seconds. If you don't make that goal, you fail that assignment. -- -----------------+ Sean Eric Fagan | "*Never* knock on Death's door: ring the bell and seanf@sco.COM | run away! Death hates that!" uunet!sco!seanf | -- Dr. Mike Stratford (Matt Frewer, "Doctor, Doctor") (408) 458-1422 | Any opinions expressed are my own, not my employers'.
harkcom@potato.pa.Yokogawa.Co.jp (Alton Harkcom) (10/29/90)
In article <1990Oct23.235720.16178@nas.nasa.gov> smithwik@pioneer.arc.nasa.gov (R. Michael Smithwick -- FSN) writes: =}While it is easy to call Mel a genius as a result of this story, I'm =}not too sure he could be called a "real programmer" by todays standards. =}A very clever programmer, yes, but if he were to try his cutsie hacks in =}production code (unless it really needed it) he would be bounced from the =}companys payroll in nothing flat. I would still say Mel is a real programmer. If he were worried about being bounced by a bunch of suits because he didn't do things so that they could understand it, then he would be a professional programmer ;_) <- My smiley's nose was broken by a renegade yuppie professional programmer because I didn't say anything nice about the only language he can program in... -- -- $@2#2OEE5!3t<02q<R(J PA$@#15;#22](J TEL 0422-52-5748 FAX 0422-55-1728 E-mail harkcom@pa.yokogawa.co.jp
nather@ut-emx.uucp (Ed Nather) (10/30/90)
In article <9402@orca.wv.tek.com>, alanj@nevermore.WV.TEK.COM (Alan Jeddeloh;685-2991;61-201;292-9740;orca) writes: > <In response to various postings criticizing Mel's programming style> > > Ah, you young wipper-snappers just don't understand how it *was* back then! > > You have to realize that early computers measured their cycle times in > microseconds, not nanoseconds, and their memory in kilobytes, not megabytes. > Some of them measured their cycle times in *milliseconds*. > Mel wrote his programs, at the time, for the LGP-30, a drum machine which measured instruction execution times in milliseconds. The computer had a whopping 16Kbytes of memory (4K words 32 bits each) with interlaced sectors so sequential instructions would not require a whole drum revolution. It was a single-address machine. He later "graduated" to a much bigger machine (8K words, 32 bits) with a 2 address structure [operand address + jump address] much like the IBM 650 (for those with long memories) but internally binary instead of BCD. It was, so far as I know, the last of the drum machines. We managed to shoehorn a complete Fortran II compiler onto that drum, tables and all, but just about that time SDS came out with a core-memory machine people could afford and so the machine died in the marketplace. > We not longer can afford to write programs they > way they did in the "good old days", the days of Mel. But it isn't fair to > judge Mel by today's standards. > > -Alan Jeddeloh (503) 685-2991 I agree. Remember, even the term "software" sounded new and funny -- a kind of take-off on "hardware" -- and the dialog between man and machine was not complicated by the expectation that anyone (*anyone*) would ever read the code. Code was for machines to read, not people. Comments? Well, if you needed to *remind* yourself of something later, maybe, but if it was that complicated it probably wouldn't fit into memory anyway. Another point of reference: the number of computers that could expect to be sold was seriously limited for the future because there would not be enough programmers to keep them busy. By that people meant *professional* programmers, people in white smocks who tended the IBM and Univac monoliths behind the glass doors and wrote the programs they ran, mostly in assembler. Mere mortals were not allowed to write programs. As Hamming put it in a talk I heard, the "closed shop" system, where you told a "professional" what your program should do, and he wrote it for you, "...is a system guaranteed to get an extremely efficient program written that will solve the wrong problem." comp.nostalgia anyone? -- Ed Nather Astronomy Dept, U of Texas @ Austin
dwh@twg.com (Dave W. Hamaker) (10/31/90)
zaft@nswses.navy.mil (Gordon C Zaft) writes: > The real solution, of course, is to make people write a program, >then, 3 years later, have them revise it. For people that weren't >around 3 years earlier, have them revise someone else's code. This >will provide first-hand evidence of why one should write clear, >well-commented code. It has been my experience, on code I don't have to worry about others having to maintain, that documenting each program on the assumption I _will_ revisit it years hence (verses the cost of spending a little longer reorienting myself on those I actually end up revisiting) seems to require _more_ total time and effort. In short, your solution does not work for me. That doesn't make me feel superior either. It makes it hard to decide how much commenting is optimal, since I'm not writing them for myself as much as for whomever might encounter my code later. I think it is possible to go too far also, where a comment can be less than useless, because it tells you nothing useful yet you have to read it to find that out. An example might be: ++i; /* increment the index variable */ Anyone else experienced this? -Dave Hamaker dwh@twg.com
gary@cgdisis.cgd.ucar.edu (Gary Strand) (10/31/90)
> Dave W. Hamaker >> Gordon C Zaft >> The real solution, of course, is to make people write a program, then, 3 >> years later, have them revise it. For people that weren't around 3 years >> earlier, have them revise someone else's code. This will provide >> first-hand evidence of why one should write clear, well-commented code. > It has been my experience, on code I don't have to worry about others > having to maintain, that documenting each program on the assumption I > _will_ revisit it years hence (verses the cost of spending a little longer > reorienting myself on those I actually end up revisiting) seems to require > _more_ total time and effort. In short, your solution does not work for > me. It does for me. A case in point, I wrote a relatively trivial but tedious package in which keeping track of where you where geographically speaking was the most important thing. Also, since it ran on a CRAY X-MP/48 (that is, a 64-bit machine), if-tests were always done using the "difference less than sigma" fashion, since equality is a rarity when you're also trying to keep accuracy. I wrote it and documented it *fully* (I even made a nice hardcopy guide for it) during the summer of 1987. Jump forward three years to summer 1990. Boss wants me to dust off that old code and get it to work on a different initial data set. Boy, was I glad I had all that documentation. The Gary Strand and his style of 1987 are quite different from me and my style today. I was tempted to rewrite a bunch of the older stuff because it didn't match what I write now. Of course, that would very likely break what wasn't broken, and my boss did not want me to have to re-test and re-check everything, when he wanted results *now*. So, even if you and only you are the sole person to ever see that code (and have to maintain and/or use it) again, it's best to have plenty (of course, not excessive) documentation around, else you might be surprised at just how much you forgot and have to spend time retracking your ideas and then whack yourself on the head and say "Oh yeah, *now* I remember why I did <X> that way!" when a little note could have saved all that heartache. Why add more variables to the equation than necessary? ["Overcommenting"] > Anyone else experienced this? Yes, of course. Now, if I was given a choice between "overcommenting" and "undercommenting", I'll take too much over too little every time. Yes, way too many comments are a drag, and it can be overdone, but I'd rather see 1 comment line for a trivial line of code than 1 comment for 200 (or even 20) lines of complicated mish-mash, which was so "obvious" when it was written, even if you're the one who originally wrote it. -- Gary Strand Look, it's trying to think. Internet: strandwg@ncar.ucar.edu Voicenet: (303) 497-1383
mrk@gvgspd.GVG.TEK.COM (Michael R. Kesti) (11/01/90)
In article <8187@gollum.twg.com> dwh@twg.com (Dave W. Hamaker) writes: >It has been my experience, on code I don't have to worry about others having >to maintain, that documenting each program... How can you ever be certain that nobody other than yourself will have to maintain your programs? I feel that one should try to code as if one might get run over by a truck on the way home tonight! > I think it is possible to go too far also, where >a comment can be less than useless, because it tells you nothing useful yet >you have to read it to find that out. An example might be: > > ++i; /* increment the index variable */ The problem with this type of comment is that it answers the question "What did you do?" rather than the more important "Why did you do it?" I usually depend on the reader to be able to figure out what, but rarely why. Just to add fuel to the fire, I think that using "i" (or any other single letter name" for a variable is horrible practice. Try searching for all occasions of it in a function! -- ============================================================================ Michael Kesti Grass Valley Group, Inc. | "Like one and one don't make two, mrk@gvgspd.GVG.TEK.COM | one and one make one." !tektronix!gvgpsa!gvgspd!mrk | - The Who, Bargain
wb8foz@mthvax.cs.miami.edu (David Lesher) (11/01/90)
Others said: >>It has been my experience, on code I don't have to worry about others having >>to maintain, that documenting each program... >How can you ever be certain that nobody other than yourself will have to >maintain your programs? I feel that one should try to code as if one >might get run over by a truck on the way home tonight! This reminds me of one of my favorite computer cartoons. The widow is standing at the gravesite, and the deceased's boss is saying: I realise this is a bad time to ask, But did Bob ever say anything to you about source code? -- A host is a host from coast to coast.....wb8foz@mthvax.cs.miami.edu & no one will talk to a host that's close............(305) 255-RTFM Unless the host (that isn't close)......................pob 570-335 is busy, hung or dead....................................33257-0335
john@newave.UUCP (John A. Weeks III) (11/01/90)
In article <1990Oct25.170925.15756@oswego.Oswego.EDU> dab@oswego.Oswego.EDU (Dave Bozak) writes: >I have this scrap of paper on my desk. [...] > Thou shalt make thy program's purpose and structure clear to thy > fellow man by using a familiar style, even if thou likest it not, > for thy creativity is better used in solving problems than in > creating beautiful new impediments to understanding. This is from Henry Spenser's 10 Commandments For C Programmers. I have not seen it posted recently...but it is a must have gem. -john- -- =============================================================================== John A. Weeks III (612) 942-6969 john@newave.mn.org NeWave Communications ...uunet!rosevax!bungia!wd0gol!newave!john ===============================================================================
kurt@tc.fluke.COM (Kurt Guntheroth) (11/02/90)
I am bemused by the people, mostly students, who revile the character Mel
for programming practices of which the acedemic community does not currently
approve. The fact of the matter is that Mel's programming practices don't
lead to maintainable code. But...
1. Mel lived in the days when 1K of code was a mammoth project, and
useful systems comprised a couple hundred machine instructions.
In Mel's day there was much less evidence that these practices were
suboptimal.
2. Mel programmed a computer with far less raw computational power than
today's pocket calculator. We have y^x and internal-rate-of-return
buttons on our calculators, but in Mel's day each was a program,
written and sold individually. Hacking drum positions could mean
the difference between acceptable and unacceptable response time on
iterative calculations.
So we're all very impressed with how well you can parrot what you've heard
about structured programming. But lay off Mel. He was an artist of a kind
that is becomming rare these days; someone who knew the difference between
what he was taught and what was necessary; someone who appreciated the beauty
in attempting to obtain adequate performance against impossible constraints.
Laughing at Mel is like laughing at the Egyptians for building the pyramids
before inventing bulldozers and cranes. The feat should be considered
greater because it was more difficult. The fact that Mel's code is more
efficient than the code we write nowadays should give you the creeps,
because in one important way, his code is better than ours, for all our
structured pretenses.
When you go to the store to buy four megabytes of RAM to run OS/2, remember;
the UNIX kernel once fit into 32K; Wordstar and Visicalc, the seminal word
processor and spreadsheet programs, ran on an 8080. You can always throw
RAM and CPU at an inefficient program to obtain adequate performance. When
someone learns to do the same job efficiently, however, your product wll be
dog meat.yeates@motcid.UUCP (Tony J Yeates) (11/02/90)
Isn't Fortran a bit "girlie" for a "Real Programmer". Assembler, C or ...machine code are surely where its at for real programmers. Real programmers write stuff like UNIX/C/gnu software/awk and prob. have arthritis in their typing finger(s)!
r3jjs@VAX1.CC.UAKRON.EDU (Jeremy J Starcher) (11/02/90)
In article <1990Nov1.175742.5383@tc.fluke.COM> kurt@tc.fluke.COM (Kurt Guntheroth) writes: > [Stuff Deleted] :So we're all very impressed with how well you can parrot what you've heard :about structured programming. But lay off Mel. He was an artist of a kind :that is becomming rare these days; someone who knew the difference between :what he was taught and what was necessary; someone who appreciated the beauty :in attempting to obtain adequate performance against impossible constraints. : When someone learns to do the same job efficiently, however, your product : will be dog meat. Hear Hear!!!! I first starting programming on a system that was so tight for memory that the video colour page was fare game for short term storage. If you played it really dangerous, the last 15 or so bytes of the stack could hold your interrupt routine (You just never filled you stack all the way up, thats all). I know [of] people who have written thier own version of languages that take less than 3K. (I have the PILOT source around here that takes just about 1K. The only other langaguage that was avalible on the machine was 6502 machine language. Not assembler. Hexadecimal words entered one at a time.) And no, those days are not over. Writing programs for a controller card is tight. On an IBM, dissemble your BIOS (try INT 10) and look at that code. Try re-writing it so it takes less memory. [climing off my soapbox] Sorry about the tirade... I just understand the need for writing little TINY programs that do the job well... -- --------------------------+--------------------------------------------------- Jeremy J Starcher ! No programmer programs in LOGO after reaching r3jjs@vax1.cc.uakron.edu ! age 14... r3jjs@akronvm.bitnet !
chuck@mitlns.mit.edu (11/03/90)
-Message-Text-Follows- In article <5044@iron6.UUCP>, yeates@motcid.UUCP (Tony J Yeates) writes... >Isn't Fortran a bit "girlie" for a "Real Programmer". Assembler, C or ...machine code >are surely where its at for real programmers. > >Real programmers write stuff like UNIX/C/gnu software/awk and prob. have arthritis in their >typing finger(s)! You've obviously never taken a look at some of the code produced by R. Brun and company at CERN. 99% in fortran *and* as sophistocated and complex as the GNU project. Examples: GEANT (See how fast you can write a package to track 100's of particles REALISTICALLY through 3D volumes containing MANY THOUSANDS of volume elements, made up of HUNDREDS of materials). This is not and easy problem, to be useful it has to be FAST. Imagine a program to track bullets being shot through your house. The bullet takes a "step" is it now hitting plaster, air, a 2x4, a nail in the 2x4, your sofa, a half empty can of soup in in your fridge? How does this material affect the flight of the bullet or bullet fragments? Don't forget to make sure the code can run about a million particles a day, to get statiscally useful results. COMIS full fortran 77 interpreter written (by a couple of Russians) in Fortran. This isn't some wimpy partial implimentation, its full F77. And you thought you couldn't write compiliers in Fortran? The list goes on but I hope I've made my point. Which is *not* about what is the best language, but that there are lot of programming gods programing in fortran. Chuck@mitlns.mit.edu
gary@ncar.ucar.EDU (Gary Strand) (11/03/90)
> chuck@mitlns.mit.edu >> Tony J Yeates >> Isn't Fortran a bit "girlie" for a "Real Programmer"? > The list goes on but I hope I've made my point. Which is *not* about what > is the best language, but that there are lot of programming gods programing > in fortran. NCAR is also a case in point. Here, practically all of the millions of lines of code is in FORTRAN. For example, a scientist in my group has a global ocean model, 1/2 degree by 1/2 degree resolution (721 x 282) and 20 vertical layers that can scoot along at over 1 gigaflop on a Cray Y-MP. I'm not even talking about the thunderstorm and CCM models that we have here, all in FORTRAN. -- Gary Strand Look, it's trying to think. Internet: strandwg@ncar.ucar.edu Voicenet: (303) 497-1383
dbell@cup.portal.com (David J Bell) (11/03/90)
>: But lay off Mel. He was an artist of a kind >:that is becomming rare these days; someone who knew the difference between >:what he was taught and what was necessary; someone who appreciated the beauty >:in attempting to obtain adequate performance against impossible constraints. Jeremy Starcher adds: >Hear Hear!!!! >I know [of] people who have written thier own version of languages that take >less than 3K. (I have the PILOT source around here that takes just about >1K. The only other langaguage that was avalible on the machine was >6502 machine language. Not assembler. Hexadecimal words entered one >at a time.) I well remember that! When I started programming *on a micro*, it was a similar situation. 4k of RAM in a SOL (8080), cassette tape for I/O, a 1K video page, monochrome ASCII only. 4K and later, 8K BASIC, PILOT, and a Tiny BASIC that took well under 1K to start with, patched in Hex to add feature after feature. We started with the bare bones, and ended up with a primitive floating-point package, and file I/O. The final version was still under 2K... Then there was adding functions to the BIOS, once I had the luxury of a decent assembler! It was totally amazing how much could be crammed into the SAME SIZE EPROM, as everybody kept feeding in ideas... Re-used code, dynamically modifying the RAM copy of ROM code in real time, code used as constants, code/constants used as indirect addresses, all the nightmare tricks necessary in truly limited-resource systems. I don't think I've ever had quite the fun or feeling of accomplishment since, no matter how many megabytes an application requires. Here's to the bad old days! Dave
peter@ficc.ferranti.com (Peter da Silva) (11/04/90)
Forth. Interactive multiuser development environment in 2K ROM. Beat that, small freaks! -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
diamond@tkou02.enet.dec.com (diamond@tkovoa) (11/05/90)
In article <10293@ubc-cs.UUCP> buckland@cheddar.ucs.ubc.ca (Tony Buckland) writes: >In article <1283@gvgspd.GVG.TEK.COM> mrk@gvgspd.GVG.TEK.COM (Michael R. Kesti) writes: >>Just to add fuel to the fire, I think that using "i" (or any other single >>letter name" for a variable is horrible practice. Try searching for all >>occasions of it in a function! >No sweat, if you have an editor that can find the pattern >"non-alphabetic, followed by 'i', followed by non-alphabetic". How does your editor know if the newline character preceding the line, or the newline character following the line, is supposed to be regarded as a "non-alphabetic" or not? (Adjust this question as necessary for other operating systems or file structures where a newline character might not be the line separator.) I've used a dozen editors that had search patterns including "beginning" and/or "end" of line, but none that accepted an "or" operation on line-break "or" character class, in a single search pattern. No sweat, just ulcers. -- Norman Diamond, Nihon DEC diamond@tkov50.enet.dec.com (tkou02 is scheduled for demolition) We steer like a sports car: I use opinions; the company uses the rack.
tjo@its.bt.co.uk (Tim Oldham) (11/05/90)
In article <1990Nov2.133932.14692@athena.mit.edu> chuck@mitlns.mit.edu writes: >And you thought you couldn't write compiliers in Fortran? Microfocus write their COBOL compilers, debuggers etc. in COBOL. Kids, don't try this at home. Tim. -- Tim Oldham, BT Applied Systems. tjo@its.bt.co.uk or ...uunet!ukc!its!tjo Well, you'd have a corporate siege mentality, too.
peter@ficc.ferranti.com (Peter da Silva) (11/06/90)
In article <1990Nov5.082657.28368@tkou02.enet.dec.com> diamond@tkou02.enet.dec.com (diamond@tkovoa) writes: > I've used a dozen editors that had search patterns including "beginning" > and/or "end" of line, but none that accepted an "or" operation on > line-break "or" character class, in a single search pattern. > No sweat, just ulcers. In vi, you can search for an identifier "i" with: /\<i\>/ Where \< and \> mean beginning or end of word (alphanumeric-to-nonalpha transition), and work at the beginning or end of a line. Existence proof, and I'm sure you can try it right there... -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
peter@ficc.ferranti.com (Peter da Silva) (11/06/90)
In article <04!^M_@uzi-9mm.fulcrum.bt.co.uk> tjo@its.bt.co.uk (Tim Oldham) writes: > In article <1990Nov2.133932.14692@athena.mit.edu> chuck@mitlns.mit.edu writes: > >And you thought you couldn't write compiliers in Fortran? > Microfocus write their COBOL compilers, debuggers etc. in COBOL. Kids, > don't try this at home. I'll see you and raise you one. I once had the "opportunity" of working on a Z-80 based multi-user accounting system, with the O/S largely in COBOL. No, it's been like 10 years and I don't remember what the system was called. If that relegates this to urban legend status, so be it. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
wb8foz@mthvax.cs.miami.edu (David Lesher,,255RTFM,255rtfm) (11/06/90)
>>And you thought you couldn't write compiliers in Fortran?
A Perkins Elmer I used (as little as possible) had a 8080
assembler written in Fortran. A file of 64K lines of db
statements took 40 minutes to assemble......
--
A host is a host from coast to coast.....wb8foz@mthvax.cs.miami.edu
& no one will talk to a host that's close............(305) 255-RTFM
Unless the host (that isn't close)......................pob 570-335
is busy, hung or dead....................................33257-0335anton@bkj386.uucp (Anton Aylward) (11/06/90)
A couple of years of maintaining other people's code taught me to write and document proterly, AND TO DOCUMENT THE DESIGN AS WELL AS THE CODE !!!!!!!!!!!!!!!!! I made a resolution that I never wanted anyone to think the thoughts about me that I was thinking about the people whose code I was working on. I hope I've lieved up to that. Small code ? Yes, but by design and careful thought as to what is the parsimoneous and general approach, not small for small's sake. Look at K&R's library with V7 (et al). Simple but very effective routines. Look at DOS libraries, rated by the number of functions they have, even if they are inaaproriate! /anton aylward
toma@tekgvs.LABS.TEK.COM (Tom Almy) (11/06/90)
In article <1990Nov5.082657.28368@tkou02.enet.dec.com> diamond@tkou02.enet.dec.com (diamond@tkovoa) writes: >In article <10293@ubc-cs.UUCP> buckland@cheddar.ucs.ubc.ca (Tony Buckland) writes: >>In article <1283@gvgspd.GVG.TEK.COM> mrk@gvgspd.GVG.TEK.COM (Michael R. Kesti) writes: >>>Just to add fuel to the fire, I think that using "i" (or any other single >>>letter name" for a variable is horrible practice. Try searching for all >>>occasions of it in a function! >>No sweat, if you have an editor that can find the pattern >>"non-alphabetic, followed by 'i', followed by non-alphabetic". >How does your editor know if the newline character preceding the line, >or the newline character following the line, is supposed to be regarded >as a "non-alphabetic" or not? >I've used a dozen editors that had search patterns including "beginning" >and/or "end" of line, but none that accepted an "or" operation on >line-break "or" character class, in a single search pattern. I imagine that there would be a problem with editors that treated lines as some special entity (example editors: vi and ed). For *many* years I used TECO which would easily search for <non-alphanumeric>i<non-alphanumeric> and I still have a copy of TECO which I could use. On MS/DOS I use Epsilon (an EMACS clone) which will also search "whole words only" as will the vererable WordStar, and it's clone editing environments in the Borland "Turbo" language programming environments. None of these editors treat the the "new line" character in a special way. In fact I'd often delete blank lines by doing global search and replace of "\n\n" with "\n". Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply
dwh@twg.com (Dave W. Hamaker) (11/06/90)
mrk@gvgspd.GVG.TEK.COM (Michael R. Kesti) writes: >In article <8187@gollum.twg.com> dwh@twg.com (Dave W. Hamaker) writes: >>It has been my experience, on code I don't have to worry about others having >>to maintain, that documenting each program... >How can you ever be certain that nobody other than yourself will have to >maintain your programs? I feel that one should try to code as if one >might get run over by a truck on the way home tonight! Programs I write on my own time for my own use are subject to my own whims. Of course, I don't give code like that away without either warning the recipient or enhancing the documentation. >Just to add fuel to the fire, I think that using "i" (or any other single >letter name" for a variable is horrible practice. Try searching for all >occasions of it in a function! grep '[^_a-z]i[^_a-z]' prog.c
karl@ima.isc.com (Karl Heuer) (11/07/90)
In article <1990Nov5.082657.28368@tkou02.enet.dec.com> diamond@tkou02.enet.dec.com (diamond@tkovoa) writes: >In article <10293@ubc-cs.UUCP> buckland@cheddar.ucs.ubc.ca (Tony Buckland) writes: >>No sweat, if you have an editor that can find the pattern >>"non-alphabetic, followed by 'i', followed by non-alphabetic". > >[What about line-boundaries?] I've used a dozen editors that had search >patterns including "beginning" and/or "end" of line, but none that accepted >an "or" operation on line-break "or" character class, in a single search >pattern. This is within the pattern space accepted by egrep. GNU Emacs can do it interactively. I believe the jim and sam editors use egrep-style patterns, too. With the help of a short program from my personal toolbox, I can do it without using any regular expressions at all. If I add in a slightly larger program (116 lines), I can exclude false hits from comments and string literals (`\n' and `%s' being the usual culprits). Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
dab@Oswego.EDU (David Alan Bozak) (11/08/90)
In article <P0X6D.G@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <04!^M_@uzi-9mm.fulcrum.bt.co.uk> tjo@its.bt.co.uk (Tim Oldham) writes: >> In article <1990Nov2.133932.14692@athena.mit.edu> chuck@mitlns.mit.edu writes: >> >And you thought you couldn't write compiliers in Fortran? > >> Microfocus write their COBOL compilers, debuggers etc. in COBOL. Kids, >> don't try this at home. > >I'll see you and raise you one. I once had the "opportunity" of working on >a Z-80 based multi-user accounting system, with the O/S largely in COBOL. > >No, it's been like 10 years and I don't remember what the system was called. >If that relegates this to urban legend status, so be it. >-- >Peter da Silva. `-_-' >+1 713 274 5180. 'U` >peter@ferranti.com let me add one more interesting note: while early history of PROLOG is muddled, I do know of an interpreter which was written in FORTRAN IV in the early 70's. Now THAT is an accomplishment! -dab /\ David Alan Bozak, Computer Science Department / \ SUNY College at Oswego, Oswego, NY 13126 (315) 341-2347 _____/____\_____ Internet: dab@rocky.oswego.edu / / \ \ or dab%rocky.oswego.edu@nisc.nyser.net /____/ \____\ UUCP: {cornell!devvax,rutgers!sunybcs}!oswego!rocky!dab
peter@ficc.ferranti.com (Peter da Silva) (11/08/90)
In article <9397@fy.sei.cmu.edu> prp@sei.cmu.edu (Patrick Place) writes: > In article <N0X6WXG@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > > In vi, you can search for an identifier "i" with: > > /\<i\>/ > But that wasn't quite the operation being asked for. Mo, but it solves the problem that he was looking for a solution for. Trying to use regular expressions to find ends of words is like trying to drive nails with an electric drill. > pattern Norman Diamond asked for is definitely hard to deal with. If you don't artificially constrain regular expressions it's easy. Linefeed is in principle just another character. You can do it in Lex no problem. i[ \t\n] Now you have to make sure the match space includes i but not the following text (i.e., it's not a context-free re). -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (11/09/90)
In <1990Nov5.082657.28368@tkou02.enet.dec.com>
diamond@tkou02.enet.dec.com (diamond@tkovoa) writes:
I've used a dozen editors that had search patterns including
"beginning" and/or "end" of line, but none that accepted an "or"
operation on line-break "or" character class, in a single search
pattern.
I seem to faintly remember at least some versions of TECO having such
an ability.
--
Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com>
UUCP: oliveb!cirrusl!dhesidwh@twg.com (Dave W. Hamaker) (11/09/90)
> Gary Strand >> Dave W. Hamaker (me) >>> Gordon C Zaft >>> The real solution, of course, is to make people write a program, then, 3 >>> years later, have them revise it. For people that weren't around 3 years >>> earlier, have them revise someone else's code. This will provide >>> first-hand evidence of why one should write clear, well-commented code. >> It has been my experience, on code I don't have to worry about others >> having to maintain, that documenting each program on the assumption I >> _will_ revisit it years hence (verses the cost of spending a little longer >> reorienting myself on those I actually end up revisiting) seems to require >> _more_ total time and effort. In short, your solution does not work for >> me. > It does for me.... [Illustrative case report omitted.] > So, even if you and only you are the sole person to ever see that code > (and have to maintain and/or use it) again, it's best to have plenty (of > course, not excessive) documentation around, else you might be surprised.... You are generalizing from your own experience here. It doesn't follow that everyone else shares your experience, even if most people do. No doubt, you think I am just naive and haven't been bitten yet. I've been programming professionally for over twenty years. Also, I didn't say I don't believe people who tell me they comment their code primarily so they can understand it later. That it's true for them doesn't automatically make it true for everyone; it doesn't even guarantee a majority, in and of itself. -Dave Hamaker dwh@twg.com P.S. inews doesn't like my reply being shorter than my quotes. It's actually forcing me to make this article _longer_ before it will accept my post. Sigh.
engbert@cs.vu.nl (Engbert Gerrit IJff) (11/09/90)
It seems I have missed the article starting this thread. Can it be reposted? (or e-mailed) Thanks, Bert.