NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
--Larry Wall in perl.c from the perl source code
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
The problem of course... (Score:1)
I have this happen regularly. I admit I tend to be a bit "visionary" and see further ahead than many, and as a result a lot of my first implementations tend to be very general. They used to often be overly general, although I've tried to retrain myself a bit more lately.
The problem of course is that when you think you Ain't gunna need something that will be hard to change to using later once you establish standards for things.
You really Are going to need them, but you just don't realise it yet, when someone else in the project is working or thinking a bit further ahead.
There's also the whole issue of flexibility versus generalisation. The former is almost always good, the latter can often be bad. There are often small and cheap things you can do to make your code more flexible, so it can be used in ways you don't expect, without adding much bulk at all.
Reply to This
Re: (Score:1)
I haven’t had any luck trying to track this down, but Knuth is said to have something along the lines that each problem in software can be solved with either more or less abstraction, and that experience tells us which one is the way to go.
(If someone has a citation, I’d love to know it.)