No such thing as a small change | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Ok, I'm on the fence as a developer. I do both perl and java. Depends on who I’m doing it for or what it is, but I do know when to use the tools I have, even when in the language.
The problem with any language that has a tool-set, is that people will want to use the tools, sometimes too much. I'm not talking about things like DBI or what have you. I give you an example. I was once writing a throwaway script to fix up a data file in perl, and someone started telling me why I should use chomp vs chop (which I used), and the differences and what not. This was for a 20 line text file that was handed to me and needed to be fed into another process. All I wanted to do was take the 2 comma separated values and switch them around, per line. I know the file was uniform and it worked. Now this is a minor example, all about chop vs chomp. Was this a more production level thing or code that was to stay out in the wild, I would have made it do actual format checking and other things. Maybe even use a CSV module instead. But it's a tiny argument over that shows a case of over-engineering a solution. It's what a lot of people suffer from, independent of the tools around. The amount they over engineer is a function of what is sitting in front of them. A default install of perl has a good few handfuls of modules. If it's a one off thing with comma delimited files, I certainly would not go through the effort of installing a CSV parser unless I would use it over and over or it's production level. It's an easier module to install, I admit, but it takes time -- and I will less likely "install something" on a case-by-case basis. Sue me. :) Java on the other hand, comes with well over a few hundred different classes. On top of that, there are also a lot of tools (not functions per se) in the language, so you have OOP, private members, static methods, and what not, easily, readily available as well. Sometimes, you don't need OOP. Sometimes you don't need the security. Sometimes, you don't need to over engineer. We don't always need the abstraction. Java can be done to mimic other languages, but most people see the tools in front of them, and use them as such. They over-engineer. In the perl community, we have the opposite problem. Things like CSV parsers, or WWW::Mechanize aren't so obvious and available with all distributions on a default install, that people don't use them enough. You get beginners, neophytes and even those starting to become wise, under engineering. Things like File::Find can be done, to someone's needs, in a few lines of perl. But if it's not there in a tidy little document explaining the world to them, how would they have known when they aren't used to it? My theory is, people who become wise in programming, learn what tools are available and when to use them. So they learn to less over-engineer in java, and engineer more in perl, doing the right things vs "less desirable way."
Back to your point of the "only way". Yes. Sometimes it's retarded to re-invent the wheel. WHY would I write my own DBI is beyond words for me, as it's a solid architecture that few have even mimicked. Why should I implement hashes and an OOP architecture vs letting perl do it for me in it's native form? I can't think of an easy reason at all beyond experimenting with code. There are one true ways, but it won’t stop people from not knowing any better. There's no one-stop-shop for looking up, how do I pull down a web page, or do massive calculations. There is the cpan search engine, but it's not as convenient as having the entire shebang packaged up with perl with a neat little index.html explaining everything. One way? Totally agreed. Will anyone truly understand it within their first few days or even years of using perl? Unfortunately no. It’s not an excuse or a call to arms. It’s just a fact. :\
In reply to Re: There's Only One Way To Do It
by exussum0
|
|