Re: code reuse
Re: code reuse
- Subject: Re: code reuse
- From: has <email@hidden>
- Date: Thu, 29 Sep 2005 23:05:39 +0100
Shane Stanley wrote:
> >> One of the things I find -- and many others have also commented on -- is how
> >> little of what we seem to do lends itself to reusable subroutines.
> >
> > I don't buy that argument. [...]
>
>OK, let's have it your way -- we have day jobs that preclude it, and even
>professional programmers often can't pull it off. The result's the same. So
>why is the idea repeatedly being pushed if it's unsuitable for most mortals?
You give up rather easily. e.g. I'm a mere mortal, and yet I taught myself how to do it. Takes a fair bit of work to get really proficient, but if you're going to be spending several years doing this kind of work anyway then the long-term benefits will be worth worth working at it. And even a modest improvement can pay useful dividends. It can be tough going to begin with when you're still finding your feet, but the more you practise it the easier it gets.
> >> So you end up ... taking [a subroutine] you already wrote for something similar and modifying it to suit.
> >
> > That sort of statement's a honking big flag to anyone looking to refactor code
> > into reusable chunks; gold dust to a '49er.
>
>You're breaking into a language I don't understand, I'm afraid...
refactor: http://en.wikipedia.org/wiki/Refactor
reusable: http://en.wikipedia.org/wiki/Software_reusability
49er: http://en.wikipedia.org/wiki/California_gold_rush
Anything else is patois.
e.g. If you copy-n-paste a handler half a dozen times, each time making minor changes, it's a good bet that the resulting code can be rearranged to separate the bits that stay the same from the bits that changed; the former become a generic handler and the latter into additional parameters to that handler. Bloat and complexity are reduced, which makes for better code, plus you've also now got a nice reusable handler you can use the next time.
> > But unless you know all the tricks and techniques for transforming it from here to there
>
>So you're suggesting that for most users who still have a day job, avoiding
>things like libraries and code reuse beyond cut and paste is the smart thing
>to do?
(OK, 'all' was an exaggeration; even a subset of such skills can be useful. But anyway...)
Pretty much all scripters can benefit from _using_ existing third-party libraries. Not doing so is a huge missed opportunity, and it doesn't need many skilled scripters writing good-quality libraries to greatly benefit the entire community - it's one area where 'trickle-down economics' actually does work, and exceedingly well at that.
As for writing their own, that's a separate issue. Those who only dabble in AppleScript, writing small simple scripts, won't really benefit from sinking a ton of time and effort into learning how to develop their own, but for the sort of work they're doing they'll hardly need to anyway. For them, the odd bit of cut-n-paste is probably 'good enough'; its deficiencies not painful enough to warrant the cost of developing a better approach. But folks who regularly write significant production-quality workflow scripts will certainly benefit over time from developing these skills during the course of their work and/or on the side (unless their employer insists they write complete mud; in which case, who cares?).
Besides, you don't need to take a year out to master the complete A-to-Z of professional programming before writing another script, just make a point of always trying to make your next bit of code a little better than your last. Start with small things - the easy stuff (e.g. despite what you think, even trivial chunks of just two or three lines are worth extracting if they repeat regularly, as the overall improvement to your code is accumulative) - and gradually advance from there. Or do you believe that learning should cease as soon as one gets the hang of 'if' and 'repeat'? ;p
> > Insert obligatory 'premature optimisation is the root of all evil' comment
> > here.
>
>I'm not sure what you mean by premature here, but the simple fact is that
>time often matters.
It sounded like you were referring to runtime efficiency, rather than speed of development. If you meant the former, just Google the aphorism. If the latter, it's true that it can sometimes be hard justifying an extra day's development time right now even though it'll save a week's development time later on, especially to less enlightened employers of the "JUST MAKE IT WORK, NOW!!!!!" persuasion. But you'd also be a fool _never_ to take advantage of such opportunities when you can.
has
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden