Re: Death and Return of TIMTOWTDI

The answer has never been "Look on CPAN and don't attempt it yourself". In fact, the answer has been more along the lines of:

If you want a solution that's battle-tested, look on CPAN.
If you think the available solutions are lacking, improve them, then post to CPAN if you are legally capable.
If you have the time, go ahead and play. Most of us do. But, don't whine when your half-baked solution doesn't work exactly as you wanted and costs your boss $XXXX and costs you your job.

In other words, it flips the question back to the questioner. We're not going to tell you what to do. We're going to give you a set of options and which of those options we would choose in your situation. We'll probably even tell you why.

And another thing - TIMTOWDI means "There Is More Than One Way To Do It." Where does the word "Good" appear? What about "Useful"? Or, maybe even "Simple"? There very often is only one simple, useful, or good way to do something, even in Perl. Especially in Perl.

What TIMTOWDI does mean is that the language is rich enough to be able to express something in more than one way. Most of those ways are utterly useless to non-geeks (and non-golfers). But, we geeks (and golfers) enjoy learning them. (It's why we're geeks or golfers.) Occasionally, two or three of those utterly useless solutions to unrelated problems come together and you get something like Quantum::Superpositions, Graph, or Algorithm::Loops. But, that has no bearing on the fundamental lack of merit that each individual TIMTOWDI has.

TIMTOWDI may be a guarantee, mantra, or whatever else. But, it usually isn't very useful.

Think about it this way - I, as a business analyst, need to know that there is a standard way of talking to a database in Perl. Otherwise, the language is unsafe, and therefore - unused. DBI is actually a major selling point for Perl in many industries. CGI is another. They are standards. Standards don't mean that TIMTOWDI is dead. It does mean that TIMTOWDI better shut up when the PHB is listening to the presentation!

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

Comment on Re: Death and Return of TIMTOWTDI

Replies are listed 'Best First'.
Re: Re: Death and Return of TIMTOWTDI by exussum0 (Vicar) on Jun 02, 2004 at 03:16 UTC
Don't forget 4. CPAN is not providing a nice enough solution. Most of the time, it's false, but don't forget, we don't write software to solve general solutions all the time. When working for some boss, you are providing a specific solution, and not all general software packages work right out of the box w/o a hitch. Most of CPAN is just algo's for doing some rather neat stuff. But some of the deeper things.. the bigger things.. may not be useful and needs that monkey work that we are all used to doing at some point or another. Bart: God shmod! I want my monkey-man!	[reply]
Re^2: Death and Return of TIMTOWTDI by dakedesu (Scribe) on Jun 05, 2004 at 03:54 UTC
Think about it this way - I, as a business analyst, need to know that there is a standard way of talking to a database in Perl. Otherwise, the language is unsafe, and therefore - unused. DBI is actually a major selling point for Perl in many industries. CGI is another. They are standards. Standards don't mean that TIMTOWDI is dead. It does mean that TIMTOWDI better shut up when the PHB is listening to the presentation! I will admit, I am not familure with the design behind DBI (haven't had the chance to check out the code), but there is also another standard SQL. Yes, I am aware that there are ways to work with DBI and SQL together... but then we bring in DBM. There are three standards, well, atleast DBI and SQL are standardised to my knowledge, that could present themselves to a table. Each with their purpose, and place of usage. As per CGI.pm, I personally do not like it. I've worked on some coding with a different interface, and blah, blah, blah, for things I think are slightly more my style. I've looked through the code for CGI.pm, it is pretty tight, however that tightness really removes some usability. (Yes, I know, I will now get about twelve flames saying that CGI.pm is God, and I obviously know nothing because of that). Most of that code appears hackish in nature (refering to CGI.pm of course), and well... that is a whole different discussion. -- Jamie Payne	[reply]
Re^3: Death and Return of TIMTOWTDI by dragonchild (Archbishop) on Jun 05, 2004 at 04:04 UTC
I will admit, I am not familure with the design behind DBI (haven't had the chance to check out the code), but there is also another standard SQL. You're right - you have no idea what you're talking about. DBI and SQL have nothing to do with each other; they are orthogonal technologies. The only link between them is that they are both related to RDBMSs in some way. DBI has to do with how to physically pass messages to a given database. SQL has to do with how you ask a database a question. DBM (which is mostly unrelated) has to do with how to store information in a database. When you use DBI, you generally pass messages written in SQL. As for CGI ... it is not God. It happens to be a piece of code that has been hacked to bits and optimized to Hell and back. It also happens to be the most used piece of Perl code ever, even more than strict. Now, if you want to roll your own CGI, go right ahead. I use a piece of hand-rolled CGI code for a specific purpose. But, don't expect others to use it. Stern does know what he's doing. (There is another node here by Ovid, I think, that discusses a code review of CGI and how it's quite amazing how unmaintainable it is.) ------ We are the carpenters and bricklayers of the Information Age. Then there are Damian modules.... sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon.* - flyingmoose I shouldn't have to say this, but any code, unless otherwise stated, is untested	[reply]
Re^4: Death and Return of TIMTOWTDI by dakedesu (Scribe) on Jul 04, 2004 at 08:47 UTC
You're right - you have no idea what you're talking about. DBI and SQL have nothing to do with each other; they are orthogonal technologies. The only link between them is that they are both related to RDBMSs in some way. DBI has to do with how to physically pass messages to a given database. SQL has to do with how you ask a database a question. DBM (which is mostly unrelated) has to do with how to store information in a database. When you use DBI, you generally pass messages written in SQL. So, please, master of wise archain arts. How is passing messages to a Database different from asking it questions? As I recall there are also the 'update' and 'insert' statements that do not sound like questions to me. They seem to imply commands to me. This post is not meant to be beillegerant, it is meant to ask a question so that I might learn more. -- Jamie Payne	[reply]
Re^5: Death and Return of TIMTOWTDI by mpeppler (Vicar) on Jul 04, 2004 at 09:30 UTC
Re^6: Death and Return of TIMTOWTDI by dakedesu (Scribe) on Jul 04, 2004 at 12:12 UTC
Some notes below your chosen depth have not been shown here
Re^5: Death and Return of TIMTOWTDI by dragonchild (Archbishop) on Jul 04, 2004 at 20:35 UTC
Re^6: Death and Return of TIMTOWTDI by dakedesu (Scribe) on Jul 05, 2004 at 15:52 UTC
Some notes below your chosen depth have not been shown here