Re: The Illusion of One-Offs
by footpad (Abbot) on Aug 16, 2001 at 20:59 UTC
|
Well, I wouldn't call this unpopular; I'd call it the natural evolution of a programmer learning to be pragmatic. The Three Virtues can be applied to any programming language, discipline, or environment. (They can even be applied to other forms of creative problem-solving.) After all, you just described Laziness in action.
I do disagree with the use of script, though probably for the same reasons you avoid it. After all, would you call Javascript rollovers a program? They certainly require the same sort of research, discipline, and testing that "programs" do, but I think you'd run into a certain amount of resistance from others (generally non-IT people) if you insisted on calling them programs. (Indeed, I think the general response might be "What-ever.") Similarly, certain folks insist on calling .CGI files "scripts" no matter how involved.
Now, that's not to say you can't think of them and treat them as programs. That's just discipline. My point being that you should think of them as whatever you want, but use terminology appropriate for your audience. There are few things more annoying (to me, at any rate) than folks who insist you adopt their mental model about something.
I realize you didn't do that and I'm not saying you do or did. I'm just pointing out that no matter what you personally think about something, you need to communicate with others that have different opinions and experiences. All too often, many holding strong ideas and opinions are not receptive to other points of view. I believe it's far wiser to hold your ideas and to allow others to hold theirs. (Who knows? They just might be onto something.) Thus, it seems wise to allow others to develop their own opinions and to adapt to those opinions as needed. Educate as needed; ignore as necessary. But never give up hope that others will learn from your successes and approaches. Similarly, you shouldn't be afraid to grow from someone else's ideas.
Speaking of learning from your successes, have you given thought to uploading selected bits from your library? Not only would you get feedback, but it's likely that others would find them useful, educational, and interesting. Perhaps not, but it shouldn't hurt.
And, finally, I do agree that there are far fewer "one-off's" than most people realize. Heck, I've even take code used to learn the behavior of a given feature and plopped it straight into a production app. You should always give a certain amount of thought toward the possibility of reuse. Don't carry it too far, but at least consider it.
--f
| [reply] |
|
footpad says:
Speaking of learning from your successes, have you given thought to uploading selected bits from your library?
I would really like to but they are mostly a collection of mandane little tasks that I'm simply too lazy to do over and over again. :-)
Also, there are things in many of them that I would not be permitted to share with anyone outside the corporation. Therefore, I really don't own them. Non-disclosure agreements are definitely binding. :-)
Mick
| [reply] |
Re: The Illusion of One-Offs
by dga (Hermit) on Aug 16, 2001 at 20:55 UTC
|
I believe you are reaching for one of the three primary Perl virtues, laziness. This would be to never rewrite something you already wrote once before. I seek one day to be at one with all of the virtues but still have attained none of them to any great degree.
May your path to enlightenment be fulfilling.
Your fellow traveller on the path to Perlvana.
| [reply] |
Re (tilly) 1: The Illusion of One-Offs
by tilly (Archbishop) on Aug 16, 2001 at 20:43 UTC
|
My rule of thumb is that if it takes me more than 15 minutes to write, it is no longer a one-off, and if it takes more than 5 then it already probably isn't a one-off.
OTOH if I have created the right libraries for myself, then I can get a lot done in 5 minutes. :-) | [reply] |
Re: The Illusion of One-Offs
by perrin (Chancellor) on Aug 16, 2001 at 19:55 UTC
|
| [reply] |
|
Thanks perrin,
All of my modules here are with package names and most are OO Modules, thanks to Damian Conway's book, Object Oriented Perl.
Mick
| [reply] |
Re: The Illusion of One-Offs
by E-Bitch (Pilgrim) on Aug 16, 2001 at 19:23 UTC
|
Actually, mrmick, I'm still in your previous stage. I have only known perl for about 3 months or so, and am just beginning to realize what you just mentioned. Do you have any advice from your trials and tribulations? I still have yet to learn packages (who needs to write one when you are only using the program once :) )
_________________________________________
E-Bitch
Tempora Mutantur Nos et Mutamur in Illis
"The Times are Changed Even as We are Changed in Them"
| [reply] |
|
| [reply] |
(jeffa) Re: The Illusion of One-Offs
by jeffa (Bishop) on Aug 17, 2001 at 01:30 UTC
|
Actually, i have been enjoying the art of writing programs
and then throwing them away - the goal being to practice
having to remember 'how to do it' without having to RTFM
or ask someone else.
This, of course, is not at all practical - but i find it
does improve my 'improvisation' skills. :)
jeffa
A flute with no holes is not a flute . . .
a doughnut with no holes is a danish.
- Basho,
famous philosopher
| [reply] |
Re: The Illusion of One-Offs
by Hanamaki (Chaplain) on Aug 16, 2001 at 21:04 UTC
|
Getting oneself organized is a big hazzle and I have
always envied this people who handle Filofaxes, mountains
of paper and computer files with ease. I know there are CVS
and all that stuff you can use for tasks beyond
programming but I still have files like "paper.draft" "paper.
new", "paper.best", "paper.endversion", "paper.done" etc. pp.
A Nightmare!!!
Fortunately, there is one place I am organized: Perl.
Thanks to Perl I was educated to have a ":lib" and a "site_perl".
Exploring the ":lib" and CPAN helped me to get much more
organized and to get a feeling for classification.
I throw away a lot of Programms I wrote for "one-time" use
and usually I do not regret it. These little Data Munging
programms are faster written than remembered as already
(partly) written.
On the other hand, If I write a function I know I have to
use again, or find a nice little function here on perlmonks,
in books, newsgroups etc. I will more or less copy and paste
it into one of my categorized "Hanamaki::" moduls. Of course
some bigger scripts will become modules on their own.
Hanamaki | [reply] |
Re: The Illusion of One-Offs
by Ri-Del (Friar) on Aug 17, 2001 at 00:46 UTC
|
I have to completely agree concerning the Illusion of One-Offs. In another (shudder) language I was using this summer for an internship, I came to the same conclusion. It became apparent that much of what I was writing could be combined into a simple module/object and reused in whatever section of the program that I was working in. By abstracting the program to be able to handle general situations rather than distinct individual ones, I began to think of Turing and his early computational machines, and how he wanted to develop a general machine that would take any sort of algorithm, and that's when I realized that this is actually a fundamental part of computers that each of us deals with at both high and low levels. Our entire experience is mediated by a constant abstraction. Perl itself is an abstraction that greatly simplifies our tasks.
Imagine having to do in machine code what we do with Perl.
In the end the very language we are communicating with seems to be an abstraction of the actual concepts. When each of us uses a word to describe something we are not in actuality describing it to the fullness of its nature, but rather using a name to identify a concept. It is this fundamental principal that seems to be ever evolving in the languages we use to program (be they scripts or programs =) or the manner in which we program ourselves. That's a cool thought provoking idea you have there mrmick. | [reply] |
Re: The Illusion of One-Offs
by hsmyers (Canon) on Aug 17, 2001 at 01:19 UTC
|
For me there is a sort of natural progression in all of this. For instance, I generally can't stand to duplicate a line of code unless I really have to. An obvious rule says that if you have to do the same thing from more than one place, make it a function. If you abstract this to the level of .pl files, then you can't really think of any of your code as throw-away. Same rule here says that if you use it more than once make it a module! O-O if you like, but re-use is your friend here.
There is another idea that comes to mind. From the point of view of craftsmanship, your code should be the best you can make it. It would be better to think of it staying around forever (given the number of 'prototypes' that ship, this is all to real) rather than heading for the bit bucket--even if true. If coding is done with the idea of one-of, it is all to easy to let that slip into 'knock off' or worse. hsm | [reply] |
Re: The Illusion of One-Offs
by Anonymous Monk on Aug 17, 2001 at 23:32 UTC
|
Doing this is certainly sensible, and whilst I am semi-sensible, a coder should feel no obligation to do likewise. TMTOWTDI. | [reply] |
|
I beg to differ with what is implied by many of my estemed seniors.
The conventional wisdom is that you should code anticpating future requirements. It is assumed that extra work now will save future work. It is thought to be cheaper to add features during design than it is during testing or maintenance
The extreme programming people disagree. They argue that anticipating features is a waste of time because you will guess wrong most of the time.
If you assume that planning ahead pays off, you are inclined to remember all the times that planning paid. You are less inclined to remember the times the up front costs were not recovered.
The XP way is to code only as much complexity as you need right now. If you can get by with csv files now, don't install Oracle.
This is not to say that you shouldn't save your simple good-enough-for-now programs. When (if) the time comes to put them to new purposes, spend the energy to make them more complex (general)
The XP religion doesn't require the faithful to pile spaghetti on top of spaghetti. "Good enough for now." alone probably won't work well. There are other XP principles (build the test code first, program in pairs, talk to the customers, revise and improve whenever possible, etc) that keep things in balance.
| [reply] |