|Pathologically Eclectic Rubbish Lister|
Re: Perl needs The Solutionby spiritway (Vicar)
|on Jul 20, 2006 at 17:27 UTC||Need Help??|
jimt, ++ for a well-written and reasonable post. As others have noted, you've apparently given this topic considerable thought. Still, I disagree with many of your comments.
For one thing, I disagree that Perl is endangered, or that it "needs" this or that. And especially I disagree that it should morph into something else, something closer to PHP. Perl is Perl - that's what it is. What you're saying sounds much like the schoolyard logic - if you will be someone different from who you are, kids will like you better. Maybe so - but that's not who you are. Are you really better off if more people like who you pretend to be?
To my understanding, Perl was designed to offer a great number of solutions - TIMTOWTDI is not a bug or a fluke, it is built in deliberately from the ground up. It's a feature. Taking that out of Perl is like taking the caffeine out of coffee or something equally sinful. No decapitated coffee for me.
Your concerns about n00bs is, I believe, unwarranted. Maybe PHP is simpler to use; but is it as useful overall? If it is, I haven't seen it. How about Java? You think a newcomer would choose it over Perl? How much of a language do you need to know, to write a "Hello, World" program? How many lines of code would it take to do it? How many minutes or hours would you have to learn before you could do it? One of the things that helps attract a new user is how easy it is to begin writing useful (or at least, working) programs. But that won't keep them. As they grow, they'll want to get fancier. PHP won't offer much room to grow. Python and Ruby would, but they have their own learning curves.
I also disagree that Perl is in "trouble". It's not as though Perl were a corporation whose life depended on exceeding last year's quarterly profits. If lots of people decide not to use Perl, then ... well, fewer people will use Perl. There won't be any massive layoffs, no major corprate restructuring. The remaining people, including the volunteers who write and maintain Perl and its modules, will carry on - or they won't. At least, we each have a voice in the matter. If we want to contribute money or code, we can. I think there are enough people who believe in Perl to carry it, even if it is abandoned by the mainstream.
What you suggest - coming up with The Solution(s) - might attract newcomers; but have you considered the effect it might have on the old-timers, the people who have helped to make Perl what it is today? You could very well drive these people away, and that would be disastrous.
I think your objections are based on the perception that choice and disagreement are bad things. I .. uh, disagree. A respectful, reasoned disagreement and structured discussion of differences is, IMNSHO, a healthy thing that can result in great benefits. Sure, the Monks bicker here, sometimes. We get into deep, heated holy wars about how to capitalize Perl (or is it PERL, or perl?), as though all our code would evaporate if we got it wrong. But most of the time, the Monks are reasonable and thoughtful, the disagreements voiced inoffensively. I've learned at least as much from the "wrong" answers offered to a quesion, as from the "right" ones.
To be honest, I don't really believe there is any such thing as the "right" answer, except perhaps in some trivial cases. Much depends on what you are trying to accomplish. What is *usually* right may not always be right; it may be completely wrong for your particular use. By having the Monks present all kinds of choices - from the obvious to the subtle, from the ridiculous to the sublime - you learn many things, not just the exact answer to your question. One thing you might learn is how to make good choices. Having someone else tell you, via The Solution, might be comforting. But I believe it's better if you know how to make that choice yourself. Chances are that the programming problems you face will have some unique aspects to them, that won't always fit into pre-conceived formats. You'll need to have options available, know what those options are, and know why one is better in this case than another. To do this, you'll need to practice. And what better way to practice, than to read the posts here and try them out yourself?
Bottom line: I'd rather think for myself and accept the risks, than let someone else do my thinking, and be "safe".