Re: Where do you want to go today? (a little deeper than CGI.pm)

I don't mind people building on prior art, to either extend it or replace it. But before they start ripping up a perfectly fine piece of art, I want to know that they've studied it thoroughly, looked at it from all angles, in all angles of light, in the morning and night, under all weather conditions, until they can practically recite each line from memory (horribly mixing metaphors here, forgive me).

I have what I hope is a good instinct about whether this level of understanding has been accomplished, mostly based on the noises I make when I do it myself. {grin}

If someone tells me "I don't want to use CGI.pm, it's too _blank_", I say "pshaw! off with you, troll!"

If someone tells me "I want to rewrite CGI.pm this weekend, as an exercise in hubris", I say "do you know everything it does, and do you have the four months that it will take to do that?"

If someone tells me "I want to fix the problem where CGI.pm does X instead of Y contrary to spec Z, and I'll work with Lincoln to incorporate it into version N+1", I say "go for it!".

-- Randal L. Schwartz, Perl hacker

Comment on Re: Where do you want to go today? (a little deeper than CGI.pm)

Replies are listed 'Best First'.
Re: Re: Where do you want to go today? (a little deeper than CGI.pm) by Tyke (Pilgrim) on Feb 21, 2001 at 15:56 UTC
Sorry for chipping in on an older thread. merlyn, very often the only way that you can appreciate an existing module is by trying to reinvent it yourself. You get smacked by the same problems as the module author, and you learn to appreciate his/her response to those problems (or not as the case may be). A case in point was yet another getopt module that I wrote because none of the existing ones provided quite all the features I wanted (notably the use of argument files). That worked fine until I needed to start having to tweak it for features that existed in the standard modules. I have now gone back to using getopt::long, and adding my stuff by reprocessing @ARGV before extracting the options. The point is, that I now understand Johan's module and use it more effectively than I would have done otherwise. I feel pretty ambiguous about this question. On the one hand I'm in favour of rolling my own stuff in personal or low impact scripts. Sure it takes more time, but I'm learning... On the other hand, when it gets to production code, I have to agree with you. The problem isn't so much reinventing stuff (with all the mistakes to be made again) as having to maintain it afterwards. And I suppose that's where the problem really lies. It's our responsibility to <quote>The Community</quote> to make things as easy for them as possible... by providing guaranteed robust, maintainable code at low cost. But there's another responsibility to explore, understand and innovate in order to extend the robust code base. And in order to do that you need to feel free to step outside the tried'n'true and play by your own rules for a while.	[reply]

Replies are listed 'Best First'.

Re: Re: Where do you want to go today? (a little deeper than CGI.pm)
by Tyke (Pilgrim) on Feb 21, 2001 at 15:56 UTC

merlyn, very often the only way that you can appreciate an existing module is by trying to reinvent it yourself. You get smacked by the same problems as the module author, and you learn to appreciate his/her response to those problems (or not as the case may be).

A case in point was yet another getopt module that I wrote because none of the existing ones provided quite all the features I wanted (notably the use of argument files). That worked fine until I needed to start having to tweak it for features that existed in the standard modules. I have now gone back to using getopt::long, and adding my stuff by reprocessing @ARGV before extracting the options.

The point is, that I now understand Johan's module and use it more effectively than I would have done otherwise.

I feel pretty ambiguous about this question. On the one hand I'm in favour of rolling my own stuff in personal or low impact scripts. Sure it takes more time, but I'm learning... On the other hand, when it gets to production code, I have to agree with you. The problem isn't so much reinventing stuff (with all the mistakes to be made again) as having to maintain it afterwards.

And I suppose that's where the problem really lies. It's our responsibility to <quote>The Community</quote> to make things as easy for them as possible... by providing guaranteed robust, maintainable code at low cost. But there's another responsibility to explore, understand and innovate in order to extend the robust code base. And in order to do that you need to feel free to step outside the tried'n'true and play by your own rules for a while.

[reply]