861087a@aucs.uucp (Andreas Pikoulas) (02/27/90)
From Paul Tom's book "Computer Information Systems" page 169
" Not only do organizations standarize programming languages, they also
develop coding styles so that programs written by different programmers
all follow good coding conventions. While SOME consider programming a
"creative activity", a programmer should be as creative as a bricklayer
following a blueprint for building a wall on a house. Creative programming
, like accounting , can only get the user into trouble. "
Please elaborate on this by e-mail. I plan to send your answers to the
author.
Thanks in advance
A n d r e a s
Andreas Pikoulas| UUCP :{uunet|watmath|utai|garfield}!cs.dal.ca!aucs!861087a
TOWER 410 | E-MAIL : 861087a@AcadiaU.CA
WOLFVILLE-NS | Phone(voice) : (902) 542-5623
CANADA B0P 1X0 | ------- IF YOU CAN'T CONVINCE THEM, CONFUSE THEM. --------
****************************************************************************sed@sppy00.UUCP (Steve Driscoll) (02/27/90)
It depends on what you call creative. If creativity is finding new ways to make a program run more effective (faster, more reliably, etc.) then by all means, be creative. If you mean to run off on your own to build the finest, most elegant solution to some problem, regardless of what is specified or in spite of time schedules then I'd say I could do without the creativity. -- *** ** * | | OO CC L CC // *** ** * | | O O C L C // *** ** * | | O O C L C // *** ** * | | OO CC LLL CC // Bringing information to people!
jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) (02/28/90)
After a few years in the field, I have come to a personal commitment to practice good craftsmanship in everything I do. If a program is worth writing it is worth writing well. It requires great creativity to design and write good software. It also results in good business, because good software has fewer problems, and this results in less maintenance cost. The programming standards of an organization don't stifle creativity, at least not the creativity of a disciplined craftsman, any more than they would in say, a cabinet shop. -- John Dudeck "You want to read the code closely..." jdudeck@Polyslo.CalPoly.Edu -- C. Staley, in OS course, teaching ESL: 62013975 Tel: 805-545-9549 Tanenbaum's MINIX operating system.
gwyn@smoke.BRL.MIL (Doug Gwyn) (02/28/90)
In article <25eb63c7.6a42@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes:
-After a few years in the field, I have come to a personal commitment to
-practice good craftsmanship in everything I do. If a program is worth
-writing it is worth writing well. It requires great creativity to design
-and write good software. It also results in good business, because good
-software has fewer problems, and this results in less maintenance cost.
All that is fine, and hurray for you.
-The programming standards of an organization don't stifle creativity, at
-least not the creativity of a disciplined craftsman, any more than they
-would in say, a cabinet shop.
Now, THAT depends on the standards. It definitely is not true that ANY
standard is better than none. For example, DoD contracts call for really
stupid deliverables, including documentation conforming to coding standards
that a good, experienced software craftsman would not voluntarily obey.doerschu@rex.cs.tulane.edu (David Doerschuk) (02/28/90)
In article <1990Feb26.234217.23251@aucs.uucp> 861087a@aucs.UUCP (Andreas Pikoulas) writes: > > From Paul Tom's book "Computer Information Systems" page 169 > > " Not only do organizations standarize programming languages, they also >develop coding styles so that programs written by different programmers >all follow good coding conventions. While SOME consider programming a >"creative activity", a programmer should be as creative as a bricklayer >following a blueprint for building a wall on a house. Creative programming >, like accounting , can only get the user into trouble. " > >Please elaborate on this by e-mail. I plan to send your answers to the > author. >Andreas Pikoulas| UUCP :{uunet|watmath|utai|garfield}!cs.dal.ca!aucs!861087a Mr. Tom is describing an old problem and trying to use a sledgehammer to solve it. If programming tasks were as simple as he describes; we would have developed methods for directly mapping the requirements onto finished code. There is research going on now directed towards "natural language compilers", but the problems are significant and (IMHO) not completely solveable. *Very* interesting stuff, though. He (Tom) doesn't define "creative programming"; so I can't comment on whether I think its bad or not! Certainly there are constructs and techniques that should be avoided: relying on undocumented features of the OS, self-modifying code, etc. but to relieve programmers of all creative tasks would seem to be self-defeating...all your most productive programmers would quit! Managing programmers and dividing tasks between architects and programmers is an art/science. For a somewhat more enlightened and realistic account, I strongly recommend Frederick P. Brooks' book: "The Mythical Man-month". Brooks ran the OS/360 project at IBM in the middle 1960's, and his book describes the things he learned during this mammoth task. He's a very smart guy, and his experiences are *highly relevant* to modern programming. In summary, for what its worth, here's what I think: 1. Anyone who thinks that programmers involved in a commercial development situation should be able to do any damn thing they want is dead wrong. 2. Anyone who thinks that creativity should be suppressed in ANY employee (much less PROGRAMMERS, for god's sake!) is crazy. Thank's for the bandwidth! BTW, is Tom's book current? It sounds dated, like something from back in the late 60's or early 70's when some of the big corporate jobs were getting out of hand and a discipline (ANY discipline!) was being looked for to control the mess. Dave Doerschuk doerschu@rex.cs.tulane.edu
new@udel.edu (Darren New) (03/01/90)
In article <25eb63c7.6a42@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: >If a program is worth >writing it is worth writing well. Have you never heard of a one-time program? Or were you not referring to this kind of program? -- Darren
dbinette@van-bc.UUCP (Dave Binette) (03/01/90)
Company coding "standards" being inflexable and seldom stringent provide a limited degree of conformity. If they were truly rule-based the process could be automated. I had the displeasure of working for a company that believed that interrupts were evil incarnations of pending disaster and they insisted on using polling techniques exclusively. It was awfull.
jfh@rpp386.cactus.org (John F. Haugh II) (03/01/90)
In article <12533@nigel.udel.EDU> new@udel.edu (Darren New) writes: >In article <25eb63c7.6a42@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: >>If a program is worth >writing it is worth writing well. >Have you never heard of a one-time program? Or were you not referring to >this kind of program? -- Darren One time programs are the exception, and not the rule. The typical program last far longer than the author intended and is worked on by dozens of individuals. Cruft attracts more cruft, and before you know it, the damned thing has reached critical mass and taken on a life of its own. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org
jcp@decuac.DEC.COM (Jolly C. Pancakes) (03/01/90)
In article <2317@rex.cs.tulane.edu>, doerschu@rex.cs.tulane.edu (David Doerschuk) writes: > Managing programmers and dividing tasks between architects and programmers > is an art/science. For a somewhat more enlightened and realistic account, > I strongly recommend Frederick P. Brooks' book: "The Mythical Man-month". > Brooks ran the OS/360 project at IBM in the middle 1960's, and his book > describes the things he learned during this mammoth task. He's a very > smart guy, and his experiences are *highly relevant* to modern programming. Another book that I would highly recommend is one that came out a little over a year ago - "Peopleware" by Tom DeMarco and another author. It concentrates on workgroup theories and the creative nature of programming (and makes some great arguments against mandatory neckties and..... The Furniture Police !). -- jcpatilla jcp@decuac.dec.com "Fling your beavers aloft!"
alan@george.Jpl.Nasa.Gov (Alan S. Mazer) (03/02/90)
In article <12533@nigel.udel.EDU>, new@udel.edu (Darren New) writes: > In article <25eb63c7.6a42@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: > >If a program is worth >writing it is worth writing well. > Have you never heard of a one-time program? Or were you not referring to > this kind of program? -- Darren What is a one-time program? Is that a program to solve a problem that will never come up again? I don't think there's any such thing. Either you rewrite it next time you need it, or you have to figure out your old code, or you write it well the first time. I agree with the original statement. -- Alan # "But seriously, what could go wrong?" ..!cit-vax!elroy!alan alan@elroy.jpl.nasa.gov
gwyn@smoke.BRL.MIL (Doug Gwyn) (03/02/90)
In article <12533@nigel.udel.EDU> new@udel.edu (Darren New) writes: >In article <25eb63c7.6a42@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: >>If a program is worth >writing it is worth writing well. >Have you never heard of a one-time program? Even so-called "throw-away" programs are worth writing well. That doesn't mean you have to code them portably, or document them for future maintainers, etc. A lot of people seem to think that a job can be done sloppily faster than doing it carefully. This is often not true.
jdarcy@pinocchio.encore.com (Jeff "lowercase d" d'Arcy) (03/02/90)
jdudeck@polyslo.CalPoly.EDU (John R. Dudeck): > If a program is worth writing it is worth writing well. new@udel.edu (Darren New): > Have you never heard of a one-time program? Or were you not referring to > this kind of program? Experience has taught me that one-shot programs have a very noticeable tendency to turn into official (sometimes even released) tools. Thus, I think it's safe to say that JRD's assertion does in fact apply to all programs. Jeff d'Arcy OS/Network Software Engineer jdarcy@encore.com DISCLAIMER: I don't represent Encore any more than you do
brister@td2cad.intel.com (James Brister) (03/02/90)
In article <12533@nigel.udel.EDU> new@udel.edu (Darren New) writes: > >If a program is worth >writing it is worth writing well. > Have you never heard of a one-time program? Or were you not referring to > this kind of program? -- Darren Trouble is, a lot of "one-time programs" end up hanging around for MUCH longer than expected. James -- -- James Brister brister@td2cad.intel.com Intel Corp. {decwrl,oliveb}!intelca!mipos3!td2cad!brister
exspes@bath.ac.uk (P E Smee) (03/02/90)
In article <12533@nigel.udel.EDU> new@udel.edu (Darren New) writes: >In article <25eb63c7.6a42@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: >>If a program is worth >writing it is worth writing well. >Have you never heard of a one-time program? Or were you not referring to >this kind of program? -- Darren I used to believe in one-time programs, but over the years I've discovered that if I write something, no matter how 'one-time', I will end up reusing it eventually. Sometimes simply as the base on which to write a new one-time program which performs some similar task, but even (or especially) then it is helpful if the original throwaway program was written properly. This is not to say that I never write hacked-together stuff, but I try to restrict it to times where it is critical that something be done NOW rather than right. Even then, I try to be a bit neat, as it helps to prevent careless programming mistakes which hurt even more at times like that. -- Paul Smee, Computing Service, University of Bristol, Bristol BS8 1UD, UK Smee@bristol.ac.uk - ..!uunet!ukc!bsmail!smee - Tel +44 272 303132
nhess@dvlseq.oracle.com (Nate Hess) (03/03/90)
In article <12533@nigel.udel.EDU>, new@udel (Darren New) writes: >Have you never heard of a one-time program? Or were you not referring to >this kind of program? -- Darren I have heard of them, certainly. I have just never seen one. --woodstock -- "What I like is when you're looking and thinking and looking and thinking...and suddenly you wake up." - Hobbes nhess@oracle.com or ...!uunet!oracle!nhess or (415) 598-3046
emv@math.lsa.umich.edu (Edward Vielmetti) (03/03/90)
My "one time" programs tend to be 80 characters or less and are generally written as shell pipelines or perl one-liners. --Ed
jharkins@sagpd1.UUCP (Jim Harkins) (03/03/90)
In article <12253@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <25eb63c7.6a42@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: >-The programming standards of an organization don't stifle creativity, at >-least not the creativity of a disciplined craftsman, any more than they >-would in say, a cabinet shop. > >Now, THAT depends on the standards. It definitely is not true that ANY >standard is better than none. For example, DoD contracts call for really >stupid deliverables, including documentation conforming to coding standards >that a good, experienced software craftsman would not voluntarily obey. I'll definately agree with that, the way things look now we'll have code like /* increment counter */ i++; And now they're talking about commenting standards! (the above is just the coding standard.) I can just picture changing that comment to "increment the unsigned integer i being used as a counter while going through the array of foos looking for bars". If you look at the DoD's 2167 software development spec you get the feeling that every rule in there is because not doing it caused somebody somewhere a problem. It's more of a CYA than anything else, everybody can point to something in the pile of documents and say "the standard says they'll do this, my job was to check it, they did it. It's not my fault." I think it's interesting that last November I posted a request for info and/or advice on writing software under 2167. In return I got absolutely no advice but I was deluged in messages like "yeah, 2167 sucks" and "it's unfortunate the military demands a methodology that is as outdated and proven wrong as this one". -- jim jharkins@sagpd1 "I've found by and large that when the flu gets you, the best thing to do (other than go to bed, which is boring) is to go conquer something." -Jerry Pournelle
jfh@rpp386.cactus.org (John F. Haugh II) (03/03/90)
In article <11270@encore.Encore.COM> jdarcy@pinocchio.encore.com (Jeff "lowercase d" d'Arcy) writes: >Experience has taught me that one-shot programs have a very noticeable >tendency to turn into official (sometimes even released) tools. Thus, >I think it's safe to say that JRD's assertion does in fact apply to all >programs. Experience has taught me that even code which was scheduled to be dumped from a product stands a chance of being picked up and turned into an official feature. Code I added as a porting tool on a project I am currently working on suddenly became a "feature" when someone noticed how useful it was. Now it's a "documented feature" ... Moral is, always put your best algorithm forward ;-) -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org
sergio@squid.rtech.com (Sergio Aponte) (03/03/90)
In article <1990Mar1.233732.22488@elroy.jpl.nasa.gov> alan@george.Jpl.Nasa.Gov (Alan S. Mazer) writes: >In article <12533@nigel.udel.EDU>, new@udel.edu (Darren New) writes: >> In article <25eb63c7.6a42@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: >> >If a program is worth >writing it is worth writing well. >> Have you never heard of a one-time program? Or were you not referring to >> this kind of program? -- Darren > >What is a one-time program? Is that a program to solve a problem that >will never come up again? I don't think there's any such thing. Either >you rewrite it next time you need it, or you have to figure out your old >code, or you write it well the first time. I agree with the original >statement. > >-- Alan # "But seriously, what could go wrong?" > ..!cit-vax!elroy!alan > alan@elroy.jpl.nasa.gov On non friendly OS sometimes you need to modify data, to load it into a database, and it is easier to write a "filter" program to change or even load the data. Once the data is loaded, what do you need the program for? In UNIX, sed, awk and many other filters can help you do this, but the universe is bigger than UNIX. (Is it?) I replied to the original post thru e-mail (as requested), but there is something I would like to mention. The rules/procedures/style imposed many times has nothing to do with good programs. Companies don't want to depend on "joe" or "joan" to be around to maintain the code, so they want to make sure the next guy can read it and maintain it, and I don't blame them. But don't confuse that with them been concerned over product quality. Another place were this rules are applied is in college. Many teachers are not concerned with creativity. They want to be able to correct 30 programs in one night. If they apply the right rules,structure and style they can make it so there is only ONE solution to the problem, and anybody that differs is wrong. I took an assembly language class, were the teacher wanted all routines in front, ala PASCAL, and the main code at the end, so he had us do a jump to a label (like a goto) to execute the main, but the listings looked great ! Doesn't this defeat the reason you are writing assembly in the first place? Sorry to go on... there are my 2 cents worth.. ;-) ------------------------------------------------------------------------------- | Internet: sergio@squid.rtech.com Sergio L. Aponte, MTS @ Ingres Corp. | | UUCP: {sun,mtxinu,pyramid,pacbell,hoptoad,amdahl,cpsc6a}!rtech!squid!sergio | -------------------------------------------------------------------------------
dce@smsc.sony.com (David Elliott) (03/03/90)
In article <18084@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes: >Moral is, always put your best algorithm forward ;-) Not only that, but think about maintainers. I spent my first 3 years out of college fixing bugs in and generally cleaning up Unix code from BSD, AT&T, and just about every other place imaginable. It may sound like a simple style issue, but putting braces inside of things like "if" statements can really help out the person fixing your broken code. Another thing: If you use the shell by any method, learn how to use it. I don't know how many times I've had to fix things like grep $* /usr/local/lib/phones and sprintf(buf, "/foo/bar %s", file_given_by_user); system(buf); (If you don't know why these examples are broken, learn!) -- David Elliott dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce (408)944-4073 "...it becomes natural, like a third sense." -- Homer Simpson
ggw@wolves.uucp (Gregory G. Woodbury) (03/03/90)
In article <1990Feb26.234217.23251@aucs.uucp> 861087a (Andreas Pikoulas) writes: > From Paul Tom's book "Computer Information Systems" page 169 > > " Not only do organizations standarize programming languages, they also >develop coding styles so that programs written by different programmers >all follow good coding conventions. While SOME consider programming a >"creative activity", a programmer should be as creative as a bricklayer >following a blueprint for building a wall on a house. Creative programming, >like accounting, can only get the user into trouble. " > >Please elaborate on this by e-mail. I plan to send your answers to the > author. Despite the note about e-mail elaboration, I think this really needs to be aired publicly. Here is my response.... There are two main problems with this attitude. 1) It assumes that computer programming is dealing with some exact problem that has exactly one correct solution. 2) It assumes that the bricklayer reading a blueprint for a building wall will have nothing inexact or creative to do. To pick up the 2nd point first. The "average" bricklayer (if such a person exists) may not have to challenge his ingenuity over 90% or so of a strech of wall. But, the particular patterning of bricks around a window or door, especially if the opening is of a non-conventional shape, may require a great deal of ingenuity and problem-solving. To add to the situation, sometimes the architects patterning of brick colors, or even the use of stonework other than the rectangular regularity of brick, may require several hours of thought before the placement of a particular stone, or even in the selection of which stone to put where! I have tried my hand at both bricklaying and stonemasonry (there is a difference!). I enjoyed it (except for climbing ladders) but discovered that I could earn more by sitting inside and programming computers for a living. The author exhibits the usual elitist attitude that the "blue collar" trades do not require creativity or ingenuity. A little bit of "on-the-job" research would show him why a master carpenter or a master stonemason can earn as much or more than a programmer. Now, back to point 1. In the "average" programming situation (if there is such a thing) there are probably "usual and customary" algorithims and procedures that will do what is necessary. But, in certain situations, especially when dealing with a new class of problem, or in implementing a newly invented technique (e.g. a new statistical tool or writing a compiler for a new computer architecture) the situation may require a lot of thought and ingenuity (read creativity) to "do the right thing". To add to the situation, the architects of the system may impose specific coding or documentation standards that may require several hours (or days) of thought in order to determine how to code within the requirements. I suspect that the original quotation, lifted out of its context is badly misrepresenting the authors intention. If he is trying to say that ALL PROGRAMMING is just routine laying down of one brick after another, then he is insulting the profession. On the other hand, if he is (as I suspect) classifying only a certain aspect of programming (i.e. the development of accounting packages) then he may be correct. I would like to have a little more context for this particular quotation. -- Copyright 1990, Gregory G. Woodbury, electronic re-distribution allowed -- Gregory G. Woodbury Sysop/owner Wolves Den UNIX BBS, Durham NC UUCP: ...dukcds!wolves!ggw ...dukeac!wolves!ggw [use the maps!] Domain: ggw@cds.duke.edu ggw@ac.duke.edu ggw%wolves@ac.duke.edu Phone: +1 919 493 1998 (Home) +1 919 684 6126 (Work) [The line eater is a boojum snark! ] <standard disclaimers apply>
seibel@cgl.ucsf.edu (George Seibel) (03/04/90)
In article <12533@nigel.udel.EDU> new@udel.edu (Darren New) writes: >In article <25eb63c7.6a42@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: >>If a program is worth >writing it is worth writing well. >Have you never heard of a one-time program? Or were you not referring to >this kind of program? -- Darren Sure, as long as you're willing to delete the source and executable as soon as the job is done. If you aren't willing to do that, then it by definition isn't a one-shot deal. One-shot hacks have a way of turning into bigger and bigger hacks... George Seibel, UCSF seibel@cgl.ucsf.edu
res@cbnewsc.ATT.COM (Rich Strebendt) (03/04/90)
In article <12533@nigel.udel.EDU>, new@udel.edu (Darren New) writes: > In article <25eb63c7.6a42@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: > >If a program is worth >writing it is worth writing well. > Have you never heard of a one-time program? Or were you not referring to > this kind of program? -- Darren There is nothing so long-lived as a useful one-shot program!!! All programs, regardless of expected lifetime, should be written in a style that is amenable to future changes. This is not difficult to do, and any PROFESSIONAL programmer should take pride in his/her ability to do so. I completely agree with Mr. Dudek: > >If a program is worth >writing it is worth writing well. This simple fact should be prominently displayed in every programmer's office !!! Rich Strebendt ...!att!ihlpb!res r.strebendt@att.com
jak@sactoh0.UUCP (Jay A. Konigsberg) (03/05/90)
>In article <25eb63c7.6a42@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: >If a program is worth >writing it is worth writing well. There are many times a program seems like its a one-timer, though the mood of the net is correct, it will probably be reused if it is at all useful. My solution for Bourne Shell scripts was to write a program generator that provides much of the formatting, input, file handeling and trap code needed. Though most of the options are prompted for, it is now possible to write a "one-time" shell script that is 80% generated code and very tight. One note here, this program is always in development and I keep as a programmers program. Therefore, it doesn't always look as good as the code it produces - oh well. -- ------------------------------------------------------------- Jay @ SAC-UNIX, Sacramento, Ca. UUCP=...pacbell!sactoh0!jak
gil@banyan.UUCP (Gil Pilz@Eng@Banyan) (03/05/90)
In article <214@van-bc.UUCP> dbinette@van-bc.UUCP (Dave Binette) writes: >I had the displeasure of working for a company that believed that interrupts >were evil incarnations of pending disaster and they insisted on using >polling techniques exclusively. Sounds like a religious problem to me. Did you tell them to talk to Bob about it ? "and you try to refuse when they judge your worth by the hour time after time after time" - r.e.m. Gilbert W. Pilz Jr. gil@banyan.com
sdc@scottsun.cs.umd.edu (Scott Carson) (03/06/90)
I find that it always helps to keep these two things in mind: 1. Creativity is no substitute for knowing what the hell you're doing. 2. A methodology is no substitute for creativity. -sdc
matt@group-w.uchicago.edu (Matt Crawford) (03/06/90)
) >Have you never heard of a one-time program? ) ) I have heard of them, certainly. I have just never seen one. I saw one, one time. So I'm sure I'll never see another ...
jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) (03/06/90)
I didn't realize that the remark I had posted to comp.sys.ibm.pc had somehow gotten cross-posted to comp.unix.wizards. I don't consider myself a wizard, I don't normally read this group, and my first hint was a flaming email message asking whether reading the specs was part of the job, implying that I hadn't read the referral of follow-ups to email. Anyway, after reading the thread of discussion, I feel a little better, since a lot of you seem to have agreed with my remarks. One last quote: I have a professor who tells us, "If you do not show TLC towards your own code, do not expect any from me, either!" -- John Dudeck "You want to read the code closely..." jdudeck@Polyslo.CalPoly.Edu -- C. Staley, in OS course, teaching ESL: 62013975 Tel: 805-545-9549 Tanenbaum's MINIX operating system.
peter@ficc.uu.net (Peter da Silva) (03/06/90)
People write once-only programs all the time. It's just that in UNIX, they never get stored anywhere. For example: $ for i in *.c; do if grep errno $i; then > ed - $i << ! > /^#include <errno.h>/a > extern int errno; > . > w > q > ! > fi; done $ -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'
madd@world.std.com (jim frost) (03/06/90)
peter@ficc.uu.net (Peter da Silva) writes: >People write once-only programs all the time. It's just that in UNIX, they >never get stored anywhere. For example: [example deleted] % ln -s /dev/tty foo.c % cc foo.c main() { printf("hello world\n"); } ^D % jim frost saber software jimf@saber.com
mercer@ncrcce.StPaul.NCR.COM (Dan Mercer) (03/07/90)
In article <7858@tank.uchicago.edu> matt@group-w.uchicago.edu (Matt Crawford) writes:
:) >Have you never heard of a one-time program?
:)
:) I have heard of them, certainly. I have just never seen one.
:
:I saw one, one time. So I'm sure I'll never see another ...
Gee, I probably write 10-20 a month. Most don't do much of anything
and are purely of an educational nature (after 10 years in this business,
I have learned a 'Show Me' attitude towards documentation. I've
found more than my share of discrepancies between the way something
works and the way the doco says it works). I also write a lot of
one shot awk programs. Since those programs are written inside of
vi then !awk 'ed, they don't even survive the editing session.
However, that's only a quibble. Years ago I hacked up a couple of
one shots that were only gonna last as long as a quick demo to my boss.
Inelegantly coded, uncommented and undocumented. And still in use.
With new additions hammered on at intervals. Impossible to support,
impossible for even me to understand any more. Worse, I've had
requests for them, but I'm too ashamed to hand them out (people
would think me MAD!!!HA!HA!HA!). Not that they'd even be portable.
So my rule of thumb is, if you don't intend to erase the file as soon
as you're done, do it up right the first time.
Course, I break the rule all the time.
--
Dan Mercer
Reply-To: mercer@ncrcce.StPaul.NCR.COM (Dan Mercer)jharkins@sagpd1.UUCP (Jim Harkins) (03/07/90)
In article <EMV.90Mar2161110@duby.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes: > >My "one time" programs tend to be 80 characters or less and are >generally written as shell pipelines or perl one-liners. > >--Ed These are the worst, I find that 6 months later I spend more time trying to figure out how to use that 1-liner I left laying around than it would take me to write another to do the same thing. The original assertion stands. -- jim jharkins@sagpd1 "My hope is that we can use tariffs to force Japan to open their markets to imported goods. My fear is I'll be forced to buy lousy American made stuff."
dan@kfw.COM (Dan Mick) (03/07/90)
Two totally unrelated requests, to anyone who might be listening: First request: I'd like an editor that's essentially vi with the ability to *easily* switch between buffers; that is, I'd like to do something like ":e filename" and have all my current files still in the ":e #" ":rew" ":n" list, and I'd like to have ":p" take me to the previous, and I'd like marks to be associated with a filename, etc. Please don't tell me to use EMACS or some such; I don't want to learn Yet Another Editor if I can help it. Ideal would be diffs to vi source or a vi clone with sufficient extensions. It's hard to believe that all the vi addicts haven't wanted to edit more than one file without having another window or virtual console up... Second request: I'm running SunOS 3.2 on a Sun-3/50; the TCP/IP code is for the birds. I've looked at the possibility of splicing in BSD 4.3 code, but it's too complex without SunOS sources; too much has changed from 4.2->4.3. Therefore, I'm looking for 4.2BSD TCP/IP code, namely, /usr/src/sys/net and /usr/src/sys/netinet. We are AT&T 5.3.1 source licensees, and I've already talked to Keith Bostic at UCB; to get source from them would require proof of license exchange, a 1/2" tape we don't have, a way to read it, etc. I'm reasonably sure there are no AT&T restrictions on this code; it surely looks completely invented at CSRG, but I'd like to appeal to anyone with 4.2 source to work something out with me and a mail transfer. We're not talking a lot of source at all; the 4.3 stuff looks like about 300K total, and I must believe the 4.2 stuff is smaller, as at least SLIP is not included. Email to the Reply-To: above should prove fruitful; please, let me know your ideas and recommendations. I'm desperate for both of these.
dan@kfw.COM (Dan Mick) (03/07/90)
<sigh> Of course the subject line is screwed. Sorry.
gordon@sneaky.UUCP (Gordon Burditt) (03/09/90)
>> >If a program is worth >writing it is worth writing well. >> Have you never heard of a one-time program? Or were you not referring to >> this kind of program? -- Darren > >There is nothing so long-lived as a useful one-shot program!!! Ok, here's my definition of a one-time program: A one-shot program is a short program that isn't supposed to be executed, and either doesn't compile or compiles with bad code generation using some compiler of interest. Its only function is to demonstrate a compiler bug. Example (made up but something very close really happened): main() { # ifndef NOBUG register # endif unsigned int i = 4; foo( i <<= i ); /* compiler error: no table entry for op REG */ } /* nobody ever bothers to write foo() */ Gordon L. Burditt sneaky.lonestar.org!gordon
allbery@NCoast.ORG (Brandon S. Allbery) (03/10/90)
As quoted from <655@sagpd1.UUCP> by jharkins@sagpd1.UUCP (Jim Harkins): +--------------- | In article <EMV.90Mar2161110@duby.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes: | >My "one time" programs tend to be 80 characters or less and are | >generally written as shell pipelines or perl one-liners. | | These are the worst, I find that 6 months later I spend more time trying to | figure out how to use that 1-liner I left laying around than it would take | me to write another to do the same thing. The original assertion stands. +--------------- Not necessarily. My one-liners---with one exception case---are like Ed's; but they're *literally* one-shot. I type them in at the shell prompt, they run, that's it (unless I use "fc -e"; rare). The one exception case? The equivalent of aliases, for use within programs which don't run csh or ksh or to allow quick modification to e.g. menus. For example, I have a large number of entries on my MultiView menu which point to scripts in $HOME/bin; those scripts are one-liners. So my MultiView menu runs a program called "netnews", which runs either "emacs -f gnus" or "rn" or "tn". The other case is used in program development at telotech: a command called (for example) "acpl" which does ". asqlinit; exec ACPL ${1+"$@"}"---"asqlinit" is a script which sets up the Accell (tm Unify Corp.) environment, and is sourced by any command or script which wants to use Accell on telotech. Both of these sub-cases are always very simple. And yes, this applies with Perl as well. Not as often, since I'm not as "up" on Perl as, say, Randal (or Larry), but I do use it with such interactive one-liners. And if I *do* write something complex, it gets commented. You see, I *have* had the problem of going back and trying to figure out what I was smoking when I wrote *that* bit of code. [ ;-) ] ++Brandon -- Brandon S. Allbery (human), allbery@NCoast.ORG (Inet), BALLBERY (MCI Mail) ALLBERY (Delphi), uunet!cwjcc.cwru.edu!ncoast!allbery (UUCP), B.ALLBERY (GEnie) BrandonA (A-Online) ("...and a partridge in a pear tree!" ;-)
amull@Morgan.COM (Andrew P. Mullhaupt) (03/12/90)
On the subject of one-time programs: How about the ultimate one-time program - the one at the end of the control tree of nuclear retaliation, say. I would guess that this one-time (hopefully no-time) program is fairly large, and subject to a lot of documentation and review. (But like all programs, never enough.) There is the (perhaps apocryphal - (apocalyptic ?)) story of the KIM-4 microprocessor. The story goes that this chip was intended for controlling warheads, and for this purpose, it had a special pin, and corresponding instruction, which set this pin high. Then the warhead was detonated. It isn't clear if the processor was expected to get to the next instruction before being destroyed by X rays - etc... Also: Wouldn't the ideal operating system be a 'one-time' program? Start it once, and it never goes down. (Not even for maintenance - because it's ideal... unless it's destroyed by X-rays, of course.) Later, Andrew Mullhaupt
bzs@world.std.com (Barry Shein) (03/12/90)
>What is a one-time program? Is that a program to solve a problem that >will never come up again? I don't think there's any such thing. Sure there is, consider a program which generated the tables used for interpolating sin and other trignometric functions in a math library. Why would you need to run that program after it works correctly once? -- -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
stripes@eng.umd.edu (Joshua Osborne) (03/13/90)
In article <1990Mar12.102407.9956@world.std.com> bzs@world.std.com (Barry Shein) writes: >Sure there is, consider a program which generated the tables used for >interpolating sin and other trignometric functions in a math library. What if you get a new box that has a diffrent FP format? Or a 128 bit doubble? Then you want to run it again to get more accurcy... -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Mutitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "Don't try to change C into some nice, safe, portable programming language with all sharp edges removed, pick another language." - John Limpert
gph@hpcc01.HP.COM (Paul Houtz) (03/29/90)
ggw@wolves.uucp (Gregory G. Woodbury) writes: >The author exhibits the usual elitist attitude >that the "blue collar" trades do not require creativity or ingenuity. A >little bit of "on-the-job" research would show him why a master carpenter >or a master stonemason can earn as much or more than a programmer. >Now, back to point 1.... >to the situation, the architects of the system may impose specific coding or >documentation standards that may require several hours (or days) of >thought in order to determine how to code within the requirements. Right on, Gregory!!!!! I'll make one final note: The type of coding described in the example, where it is so straightforward as to require no thought, has probably been written many thousands of times already. In otherwords, if a little thought and "creativity" were put into the code to begin with, maybe it wouldn't have to be written again, and again, and again.