|
Re: Death and Return of TIMTOWTDI
by dragonchild (Archbishop) on Jun 02, 2004 at 03:09 UTC
|
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
| [reply] |
|
|
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] |
|
|
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.
| [reply] |
|
|
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: Death and Return of TIMTOWTDI
by perrin (Chancellor) on Jun 02, 2004 at 04:00 UTC
|
Most people who try to build something that already exists on CPAN are not doing it because they have looked at what's there and found it inadequate. Most of them are doing it because they haven't looked, or are too lazy to read the code that's already there and learn from it, or are too arrogant to accept a solution written by someone else. There Is More Than One Stupid And Inefficent Way To Do It would be a better acronym for the majority of cases you are describing.
If anyone posts a question saying "I have looked at X module, but found it didn't work for me becuase of Y" they will probably not be sent off to CPAN. State your research, if you have any, and you will get more appropriate answers. It's that simple. | [reply] |
|
|
I agree with perrin completely.
If you want to learn how to solve problems, read code that solves problems well. Don't fiddle around with half-baked solutions that you think might possibly solve problems. Don't argue with people who've solved these problems multiple times. Be humble enough to learn.
| [reply] |
|
|
Or, in looking, they didn't evaluate well enough to determine that the goals and/or implementation of another project really were in line with what they were doing. It may not have worked "because of Y", but "Y" may have been perfectly in line with both their own goals and the the goals of "X module".
For example, I had developed a module that seemed like a nice generalist solution to coding web applications. I'd even done some research first to see if I could use something else, but hadn't seen anything that seemed quite in the vein I was considering; at the time, I can see now, I wasn't terribly clear on the scope of my own project. However, when I started looking around for a namespace after developing my implementation, I ran across CGI::Application again, and, in thoroughly reviewing it, discovered that it did what I was doing, and better. I could have saved a lot of effort if I'd been more clear in what I needed to do and more flexible in seeing how another module could be adapted to suit my needs.
I think that's the issue I see most frequently with duplicate projects on CPAN -- new authors haven't completely reviewed the scope of their own projects, much less that of existing projects, including the TODO lists and goals. More often than not, it appears that they could have simply contributed to existing modules, thus improving the codebase out there and preventing needless duplication of effort.
| [reply] |
|
|
Most people who try to build something that already exists on CPAN are not doing it because they have looked at what's there and found it inadequate. Most of them are doing it because they haven't looked, or are too lazy to read the code that's already there and learn from it, or are too arrogant to accept a solution written by someone else. There Is More Than One Stupid And Inefficent Way To Do It would be a better acronym for the majority of cases you are describing.
This is an attitude that does not help. Generally, in online communities, when a person asks a question, it is assumed they have no idea what they are doing, and are told to go to Google, or to search CPAN. Yes, this community is better than some others (including nonPerl related), but really this is not answering their questions.
I agree that looking through code can be effective for learning, but not everybody can read and type Perl fluently. Now, if a link to an article was given to the question, I would not complain. This way, people who are use to other languages can check out how it would be done.
Again, I believe that this thread was more about learning rather than doing, as this site is mostly for educational value (yes, this is an educational site... you cannot even escape it when you're not at school ;) ).
You're argument is not a new one, and I am surprised I cannot find it on CPAN, despite the ammount I've seen it.
| [reply] |
|
|
This is an attitude that does not help. Generally, in online communities, when a person asks a question, it is assumed they have no idea what they are doing, and are told to go to Google, or to search CPAN.
Maybe I was a little harsh. I've heard a lot of insane things justified with TMTOWTDI over the years, and sometimes it just gets under my skin.
I think that you have a hypothetical (or real) question in mind that colors this issue for you, just as I have one that does the same for me. "Take a look at Some::Module" is a useful and helpful response to the sort of question I have in mind: "What's a good way to do X?"
A more precise question merits a more precise answer. Say what you have figured out so far ("I looked at Tree::DAG_Node, but I don't think it's a good fit for me becuase I need to do...") or what your special circumstances are ("I want to learn how HTTP works and am having trouble following the LWP code...") and you get a more useful answer. You can't expect to get a dissertation on how to write e-mail handling code in reponse to a simple "How do I write a mail filter?" question.
And again in the eye of the beholder: I feel like I've seen this "your CPAN referrals are curtailing my TMTOWTDI" argument at least a dozen times in the Meditations. That's fine. There are times when CPAN does not have the answer. It is always a step along the path though.
| [reply] |
Re: Death and Return of TIMTOWTDI
by fuzzyping (Chaplain) on Jun 02, 2004 at 02:04 UTC
|
CPAN is an excellent repository for proven, reusable code. It's also an attic full of cruft and redundancy. However, I don't really see the scenario you're describing, where folks who are seeking guidance for a particular task are brushed aside to CPAN.
Usually, seekers are in search of a) syntactical or algorithmic assistance, or b) a task in need of a solution. The former is almost always answered with a bit of code and explanation. The latter will most often be resolved with a link to CPAN and general usage guidelines for the module in question. I have not seen the death of TIMTOWTDI, as you claim.
Update: removed P.S. comment, I confused the OP for vroom.
| [reply] |
|
|
Well, maybe the wrong nodes just appear to me when I view this site.
It is not so much the decent answers I am concerned with. A lot of the threads I read either deal with slightly trivial scripts, or are redundant code, and they nondecent answers replied. The nondecent answers are still littered in amongst some nice incite, so there is still hope.
It is not really just here. Perhaps it is due to my learning curve hitting where it is, but when I see others answer with, "use the CPAN entry," I feel as though it might hold that person back as a programmer.
I've seen another community(slightly less perl related, it is a gaming related development site), where posts similar in quality could earn bannings, because the sort of thing went on too long. One site, people just kept answering to perfectly decent questions stuff like, "Use linux," "use Mozilla," or use some different sort of software. Which really is only avoiding the question.
I've also seen a few other perl communities where the staff instituded a rule of 'no CGI' (which I think really hurts them) and if the question does not fall into their narrow downed category of what to ask, or already has a module, you get a nice kick.
I am seeing this CPAN thing at the stage of the former. Where, we are starting to get the people going, "oh just use this software," in reply to their problem when coding new software.
Though I will admit, this site is not that bad.
| [reply] |
Re: Death and Return of TIMTOWTDI
by baruch (Beadle) on Jun 02, 2004 at 02:13 UTC
|
I think much depends on how much time you have to spend on something. If you have a deadline, you probably would do better to grab what you can and avoid reinventing the wheel. Much of the time we just don't have the luxury of time to play with something, which I think is one reason there is so much crappy commercial software out there - they had to beat the competition, so they couldn't do the testing they should have.
On the other hand, if you do have the time, I think it's a wonderful thing to reinvent the wheel. IMNSHO, it's the best way to really learn how to do things. I suppose it's like building something yourself, instead of buying it, or (in the case of CPAN) downloading it. Maybe your product isn't as flashy, nor as efficient; maybe it doesn't work nearly as well. But - it's yours. To me there is something highly satisfying about creating a product by myself, even if it's a poor shadow of what is already out there.
And you never know - you just might be the one who finds a better algorithm, or approaches the problem in a unique, original way that turns out to be better than what's already available. You probably aren't going to do this for pay, though. Your boss will want you to produce results, not art. It's up to the amateurs to make a piece of software that is not only effective, but also efficient and (ideally) elegant.
בּרוּך
| [reply] |
|
|
Well, maybe there should be something in this site's set of FAQs that should specify some way to let people know, in the question, or answer, if the post requires a deadline to be quite as relavent?
As per reinventing the wheel. Hey, it brought us Linux and Open Office. It is something that much of GNU is built upon (for fear of companies like SCO). For things done only in spare time, wasn't that how Larry Wall originally released Perl? What about UNIX, wasn't that a part time thing for Ken Thompson? Just gather a nice ammount of example part time projects, and I am sure most bosses will know it might be a decent investment :)
| [reply] |
|
|
| [reply] |
|
|
|
|
|
|
As per reinventing the wheel . . . Linux . . .
Open Office . . . GNU . . . Perl . . . UNIX . . .
Each of those things were created because existing wheels were simply not round enough in one way or another. Linux was created because Tannenbaum wanted to spend his time as a professor, not as king of the hackers (as he himself put it in a recent essay). Open Office was simply an Open Source version of StarOffice, built out of a need for an office suite not made by Microsoft. GNU reinvented all kinds of wheels for mostly political reasons. Perl and Unix were created because of the ineffectiveness of existing tools.
In my mind, there are two reasons for reinventing wheels, as the examples above show: 1) existing wheels are not good enough (either for technical or political reasons), or 2) you want to learn how to do it on your own.
#2 is usually not relevent in a business environment, because its hard to justify to your boss that you should spend a lot of time coming up with a solution that someone else has already solved and is freely giving away. OTOH, it might be done during off-moments at work or other spare time. #1 will be the more likely case.
----
send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.
| [reply] |
|
|
Right - Linux, OpenOffice, Unix, C, even Perl, were all things that someone built in spite of there already being something similar out there. And the people did many of these things on their own, for the love of the work and not for the money. Come to think of it, even Einstein wrote his three major papers (including the special theory of relativity) in his spare time.
In my experience, most bosses are too caught up in the so-called bottom line, that they overlook how much valuable stuff is done by people on their own. They usually can't see beyond the next financial report. But that's OK. Many of us do for fun what others wouldn't do for money. Getting paid would kind of take the fun out of it, IMNSHO.
| [reply] |
|
|
|
|
|
|
|
|
|
|
What about UNIX, wasn't that a part time thing for Ken Thompson?
No, actually it was built by Ken Thompson out of AT&T's necessity for a multiuser, multiprocessing operating system to be used in-house for its own information processing department.
| [reply] |
|
|
|
|
Re: Death and Return of TIMTOWTDI
by jepri (Parson) on Jun 02, 2004 at 05:48 UTC
|
Shades of Paul Graham here, but it is appropriate.
I've never seen TIMTOWTDI as being interpreted as "let's write the same code over and over". I've always seen it as a way to reduce the endless debates over whether OO is better than procedural is worse than functional style. It calms people down and lets everyone get on with the job, rather than spending all our time bickering over whose paradigm is the best.
Not all code is equal, and some of it is worse than others. That link is a good example because the poster is spending hir time improving code rather that rewriting it in a different way.
Apprectice joiners practise making furniture. Apprectice potters practise making pots. Neither of these people try to sell their work as master-class. Apprentice programmers practise writing code, then upload it to the web and complain that people are overlooking their natural genius by recommending a solution that is already on CPAN.
If somebody thinks they want to try something that is already on CPAN, why not let them?
We don't stop them. We can't stop them, as much as we might like to.
Similar, kind-of to why there are several Linux Distros
There are multiple (GNU)Linux Distros because they fill different needs. Each has a different sort of community revolving around it. But mostly, it's a waste of everyone's time.
The time to duplicate work is when the current project is beyond hope of repair. Even an unresponsive maintainer is a poor reason to duplicate code. You'd be better forking hir code and improving it.
Mainly, duplicating code is the mark of people who can't understand the current code base, or why it does what it does. Rather than extending or modifying the current code base, they build their own, which will invariably aim to 'be better', and is almost always worse.
For the clearest example of this, look at the state of window managers for X-Windows. There are like, 30 window managers. All of them do exactly the same thing. All of them were written to 'correct the problrm with XXX window manager'. None of them have any more functionality than early nineties window managers, and the entire field has stagnated.
From my browsing through CPAN, it seems that templating toolkits are approaching the same fate - everyone writes their own, and there's a few on CPAN already. All it needs is for a few more people to upload their own special and better template toolkit and we'll have 30 indistinguishable toolkits and no advances in that field either.
And since perl wasn't around in the 1970's I suspect you are referring to algorthms from then. So what? Most communications devices rely on algorthms that are 100's of years old. If you can improve them, I'll laud you as a hero. If you just reimplement the same thing and clutter CPAN, I'll complain.
Update: For an even clearer example of everyone rewriting the same thing over and over like Sisyphus, check out the number of 'portals' and content management systems.
Please, stop writing more portals.
____________________
Jeremy
I didn't believe in evil until I dated it.
| [reply] |
|
|
Well, really, I don't quite buy your argument about window managers. Since when does somebody who uses a posix system use something other than the main four. Even then, most people care even less, as they have Gnome or KDE running ontop of their window managers. The only other option I've seen, that is noteworthy other than the main four, is blackbox, which is a solution for limitted resources. What I am trying to say, is I have not seen the large bulk of the window managers you said were there. At most, I can remember FWVM(????) clones, and any Linux Desktop back then was not even as good as Windows 3.x
As per my comments on everything already being coded, that was a sarcastic comment asking why Perl is even in existance, as anything we would want done on the computer was programmed in the 1970s, early 1980s. Yes, I was refering to algorythems, but those, well, most, were already implemented in some language at that time. I was trying to say that CPANs very existance is built in redundancy.
| [reply] |
|
|
most people care even less, as they have Gnome or KDE running ontop of their window managers.
That's pretty much the essence of my point. Pretty much all window managers are interchangable, which implies they are equivalent. If they weren't equivalent, you wouldn't be able to swap one for another. And if they are equivalent, why bother maintaining the existance of more than one?
I don't really think it is fair comparing window managers to MSWindows - MSwindows was a desktop environment, something that the Unix world didn't really have until KDE/GNOME (unless you want to count Sun's miserable attempts).
Regards your (sarcastic) comments on CPAN, - my apologies, it's hard to see that humour in writing sometimes. Your slightly broken English makes it hard to see your point there.
What you appear to overlook twice now, is that CPAN modules sometimes do use 1970's code. A lot of modules are thin wrappers around C code, some of which is quite old (usually not 70's though). So there's your code reuse. I don't see the redundancy at all. In fact, I request that you back up your comments about redundancy in CPAN, because I can't see it.
The only redundancy that gets into CPAN is when people upload their redundant code, as you have declared that you intend to.
You also appear to be suffering massive confusion between the idea of redundant code, and reusing and improving on code. You are confusing 'use what is already written' with 'everything has already been written'. CPAN's existance is not built in redundant because there is the constant addition of new code that has never been seen before in the world.
This point is so obvious to everyone else on this thread that it seems apparent you are just trolling. So I guess I've been trolled and hence I lost, but I don't think I'll insert my quarter for another round.
____________________
Jeremy
I didn't believe in evil until I dated it.
| [reply] |
|
|
|
|
|
|
What I am trying to say, is I have not seen the large bulk of the window managers you said were there.
According to http://www.freebsd.org/ports/index.html there are 116 entries in the X11 window manager section. Granted, not all of them are window managers, but then, not all available window managers made it into the FreeBSD port collection.
| [reply] |
|
|
Re: Death and Return of TIMTOWTDI
by Zaxo (Archbishop) on Jun 02, 2004 at 01:57 UTC
|
| [reply] |
Re: Death and Return of TIMTOWTDI
by duff (Parson) on Jun 02, 2004 at 02:50 UTC
|
The people that are likely to code something equal to or better than what's on CPAN are also the same people that aren't likely to be asking about it in a public forum (except perhaps the small public forum of an IRC channel where they know several perl gurus are lurking). For the majority of cases, people are trying to solve a problem. To get work done. To meet a deadline. To get this problem out of the way so that they can get on with the stuff that they are really interested in! As a first approximation, "use a module from CPAN" is the best answer to give. If someone really wants to learn how to do it themselves so as to better understand perl or the "it" that is their problem, there's nothing stopping them. If they lack the fortitude to press on in the face of an existing implementation, then I say that's Darwinism doing it's thing! :-)
| [reply] |
Re: Death and Return of TIMTOWTDI
by hv (Prior) on Jun 02, 2004 at 03:29 UTC
|
I quite agree, but doing it right requires a sense of balance, and a degree of self-knowledge - it usually isn't a good idea to try to reinvent every wheel.
In my case, my main interests drive me to constantly reinvent templating modules and database abstractions, and after 10 years of that I feel I'm close to understanding why it is difficult to design the perfect abstraction within those domains, and what I might be able to do about it.
Nonetheless, I'm happy to grab code from others when it solves a problem that I'm either not particularly interested in (Email::Valid for example) or one that is not core enough to my work to justify the effort of reinventing it (say Math::BigInt).
Regrettably I think it is in the nature of a community such as this to be inherently conservative. I was going to give the recent discussion of CGI::Builder as a perfect example, provoking some vitriol but no noticeable analysis of why the author had chosen to code in so non-standard a fashion, but checking it I see that the discussion has continued in a more useful vein since I last saw it (prompted in part by the appearance of the author), so perhaps there is hope yet.
But in any case radicals and revolutionaries don't tend to build large stable systems providing help to thousands of perl users. :)
Hugo
| [reply] |
Re: Death and Return of TIMTOWTDI
by PodMaster (Abbot) on Jun 02, 2004 at 03:47 UTC
|
If somebody thinks they want to try something that is already on CPAN, why not let them? If they do, they might get a better understanding of how the code on CPAN works. Even possibly might be able to add that knowledge to their current projects....*snip*... Currently, I am working on several things...
I forbid you (especially) and everybody who thinks they want to try something that is already on CPAN from doing so. You must use what is already on CPAN or you'll ...
Can you help me debug my CGI POST request parser?
Zzzzzzzzzz.....
The community won't let me TIMTOWTDI :(
| MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!" | | I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README). | | ** The third rule of perl club is a statement of fact: pod is sexy. |
| [reply] |
Re: Death and Return of TIMTOWTDI
by tkil (Monk) on Jun 02, 2004 at 06:37 UTC
|
I would prefer it if the first answer was not "look
on CPAN, and don't attempt to try yourself."
As others have pointed out, that's not always the first
answer. The "look on CPAN" answer does tend to
get used when people start asking: "How do I handle this
corner case? What about this special situation?" It is
exactly this sort of "institutional knowledge" that a
repository such as CPAN is perfect for accumulating.
The other reason that long-time users often resort to
telling novices to "use CPAN" is because they want to
provide a working solution, but they don't have the time
or energy to teach the novice all the way up through the
ranks.
Finally, I find that there are many modules on CPAN
that are right at the boundary where "work required to
understand the interface" is just about equal to "work
required to replicate their functionality 'by hand'".
What tends to happen is that it is easier to open-code
a solution that handles 90-95% of the cases; it's those
last few percentages that require ugly special code,
pleas to Seekers of Perl Wisdom, and responses
to "use CPAN" and/or "let's make that a module".
The latter, however, eventually grows enough hair that
when the next novice comes along, looking to solve the
first 90% of their problem, says "wow, that module's
too complex, I can just solve it with my own code like
so..."
| [reply] |
Re: Death and Return of TIMTOWTDI
by andyf (Pilgrim) on Jun 02, 2004 at 09:07 UTC
|
You deny code Utopia? Hast thou not seen the Way? One Operating System to rule them all.
Written in the Peoples Standard Language, a marvel of elegance and consistency. One almightly monolithic
library of perfect, proven code forever seemlessly flowing together with childlike simplicity into infinite configurations.
They say there is no redundancy or functional overlap in Code Utopia. Every computable operation has been implemented perfectly, once and
only once, thoroughly documented and reused optimally.
As we toil in our tangled pits of misery, one thought, one hope, one dream gives our souls the breath of life to carry on, Code Utopia!
But who is this iconoclast amongst us Brothers? Who would lead us from the path of light?
You bring doubt to this house Heretic. The Devil take your Distros! Your diversities and version forks are Sin!
Fold back your branches and repent sinner.
Repeat with us..
One Operating System to rule them all,
One Language to rule them all,
There can be only one way to do it,
There can be only one,
Code Utopia.
| [reply] |
|
|
One OS to rule them all,
One Runtime to bind them,
One Company to bring them all
And in the darkness bind them,
In the land of Redmond where the Windows lie.
| [reply] |
Re: Death and Return of TIMTOWTDI
by adrianh (Chancellor) on Jun 02, 2004 at 11:14 UTC
|
Currently, I am working on several things that I know have definitely got to be somewhere on CPAN. Why? To learn how to code that sort of thing. Maybe, if the results of the labour to make that code are comparable to that on CPAN, maybe CPAN might get a new entry. If anything, the person coding the redundant code will learn something (Hopefully).
There is nothing wrong with that. Re-implementing something is an excellent way of learning. I do it myself.
I firmly believe that everybody should write their own compiler at some point in their programming life :-)
However I would not throw code I write for learning at CPAN unless it does something that the existing modules doesn't do well. This would seem counter productive to everybody concerned.
Choice is good, and I would prefer it if the first answer was not "look on CPAN, and don't attempt to try yourself." Not that this concept might hold any relevance here. Why has TIMTOWTDI died?
Choice is of course good. However I cannot see how not pointing people to CPAN is going to increase choice. Quite the opposite.
TIMTOWTDO has not died. People take new approaches to solving problems on CPAN all of the time. I don't think anybody can say we have a lack of, for example, templating modules on CPAN.
Indeed the problem we have with CPAN is not a lack of approaches, but people re-implementing the same kind of solution again and again and again. Helping nobody.
I'm basically in agreement with perrin's comment. Most people who reject CPAN modules are doing it for exactly the wrong reasons.
One of the skills you need in being a good developer is knowing how to reuse software. This is a skill that needs to be learned by more people. Pointing people to CPAN is an excellent way to encourage people to learn it.
Far better for people to go solve new interesting problems than repeatedly solve old ones in the same way. One of the best ways for finding new and better solutions is to learn from old ones. Ignoring them doesn't help.
| [reply] |
Re: Death and Return of TIMTOWTDI
by Ryszard (Priest) on Jun 02, 2004 at 07:32 UTC
|
Does that mean we simply should use 1970s software?
If the solutions work, why not? Just because its old doesnt necessarily mean its bad, of course it doesnt mean its good, it just means if the shoe fits, wear it.
| [reply] |
|
|
Do you particularly like coding in PL/I, COBOL, Pascal and Prolog?
Generally most "modern" languages accomplish what those older languages could. Just the "modern" languages look prettier.
| [reply] |
Re: Death and Return of TIMTOWTDI
by demerphq (Chancellor) on Jun 03, 2004 at 22:59 UTC
|
I wrote a node something like once. I've also put a lot of effort into reinventing a very widely used module. I don't recommend it really. Its pretty hard to do well. Most attempts are half-assed. I think I rewrote from scratch my implementation about 6 times before I was happy with it.
For instance the anonnymonk elsewhere in this thread mentionedConfig::Inifiles, which IMO is begging for a rewrite. I use it all the time, and more than once I've thought to myself I could do better. I probably will never even make the attempt tho. It works and its there and to me its not that interesting a problem and the things I would do better wouldn't be that much better to make it worth the time.
---
demerphq
First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi
| [reply] |
Re: Death and Return of TIMTOWTDI
by perlfan (Vicar) on Jun 02, 2004 at 21:04 UTC
|
People rewrite programs for different reasons:
- As a beginner because they do not know other solutions exist
- As a moderately experienced user because they think they can do a better job
- As a wizard because they know they can do a better job
...finally, the wizard becomes tired and makes the decision to trust what others have done.
I think everyone should go through these phases because it allows one to learn even if that is not their goal. I would not really trust any programmer that hasn't gone through the humbling "I think I can do it better" phase because that is the only way to get to the "I know how to do it better" phase.
Additionally, reinventing the wheel (as pointed out above) really has little to do with TIMTOWTDI. Reinventing the wheel happens out of ignorance, and doing it another (better?) way is a product of hubris (or even real pride) which is a tenant of the Perl Community, right? | [reply] |
|
|
Tkil nailed it on the head for me.
Some modules are a pain to find and install. That keeps getting better, but you have the Roth modules, and even though CPAN now has a Win32::API, certain functions are only found in the Roth modules. Then you have Jenda's repository, which is indispensable for those of us working with Windows. However, it now means install documentation has to include setting up PPM with 3 repositories, and downloading 8 modules. Then there's TK....
Sometimes you already have 90% of the solution, and just need to figure out why a variable is falling out of scope. I remember coming here as a newbie and trying to do a hard regex (at the time). I was pointed to the still experimental Parse:RecDescent module as a means to solve this problem. You wanna talk about way more complex than the original problem.....
CPAN is also littered with modules that have been quasi-abandoned, again improving, which just turn out to be time sinks. You spend two hours tracking down and installing the module to find out it's broken, requires two other modules that you can't find, or has documentation that wouldn't clue the original author in on how to use it.
As far as fixing modules, TMTOWTDI also leaves our perl dialects almost incomprehensible to one another sometimes. Even the most immaculate code can contain syntax conventions that are unfamiliar, and many a module owner thinks he's playing perl golf in there. It becomes easy to say "Screw it. I get the basic logic...."
Sure, maybe it's irritating to help noobs get some syntax right time and time again, but evading a hard problem, or a syntax mistake by using a Module doesn't make them any better programmers, they just won't learn about something until they find a hurdle that they can't circumvent with a module. In my experience, I sat down and looked hard at the solution someone was nice enough to post for me, and I learned about regexes in the process.
| [reply] |
|
|
| [reply] |
Re: Death and Return of TIMTOWTDI
by sintadil (Pilgrim) on Jul 04, 2004 at 18:35 UTC
|
Similar, kind-of to why there are several Linux Distros
Each relatively incompatible with the others and for the most part not interoperable, standard, or well-documented (cf. the FreeBSD Handbook).
If applying TMTOWTDI to CPAN would result in such a fractured, broken mess, then I personally believe that TMTOWTDI and CPAN should remain as you see them.
| [reply] |
|
|
And FreeBSD has all the reason and effort to sell the linuxes?
The main reason that the Linuxes are incompatible would be that they use different styles. Different styles that are not decently analigous to this thread.
The one that screams to me the most is the Package formats. You have RPMs, .deb, source .tgz, and the ports system. We are not here to argue which is the best, but generally, most will agree that they prefer one above the others (well, of the linux users anyways). This is something that splits linux but cannot really be applied to CPAN.
The next one is how they handle initd and runlevels. Some do it BSD style. Others do it System V style. Something that would not bother CPAN.
As for documentation... that is the maintainer of the project's job, not the people distributing the project. So unless the people making the distro are making custom software to go with that distro, there really is no reason for them to document it.
However, there are other differences between Linux distros, that show this point. Keep in mind, that I will generally use any linux that does not make use of RPMs, so I tend to be more blind to differences. How do I know I am blind? I let a 'windows expert' (yes, we all know what that means) use my system, and he did not think KDE resembled anything he touched before.
Differences are there that we don't notice, and while certain differences may cause problems in one area, they will be benign in others.
| [reply] |