|
in reply to Why Perl?
I'll counter your points with:
- So's python
- So's python
- Likewise with python (although admittedly not as good as the CPAN)
- Likewise python
- But you probably don't want to
- Yup, but that's not what most people do these days. It might apply to your group, but even then they'd probably be better off using proper APIs instead of "screen scraping"
- Just like python
- Your personal taste is not a good reason for other people to use it
:-)
Of all your reasons, the only one that I find compelling is that there are lots of useful things on the CPAN. |
Re^2: Why Perl?
by Preceptor (Deacon) on Jul 18, 2013 at 12:33 UTC
|
Yes, Python is a good scripting language. What point are you trying to make though? Would you assert it's a _better_ choice?
My personal taste isn't a reason to make other people use it, no. But my knowledge of it means it's something I can teach them how to use, when I can't of something I'm _not_ familiar with.
| [reply] |
|
|
In environments like the one that you're describing my main reason for preferring Perl over Python is that typically more people are already basically familiar with Perl. If you want someone to start programming full time then Python is a good choice, but people who just want to automate a small piece of their daily work or move some simple shell scripts into something slightly more advanced usually can make faster progress with Perl.
One of the reasons behind that I think is that Perl is closer to C. So in companies where the main code base is C that is a big plus point for Perl.
That's just my opinion, though, maybe in other organisations that looks completely different.
| [reply] |
|
|
What point are you trying to make though?
My point is that the OP's list of reasons "why perl" aren't very good reasons, because they mostly don't separate perl from the herd of other languages. "It's what I know and so it's what I can teach" is, however, an excellent reason for teaching in perl, provided that the desired end point isn't "the students know perl" but "the students know a dynamic language" or something like that.
They can then use their new knowledge of programming (gained via the medium of perl) in whatever similar language they find is most appropriate for the task at hand. IME the choice of which language is most appropriate is hardly ever determined by technical or linguistic matters, but by what your colleagues are most familiar with and what they've already got code written in. Taking my current job and task as an example, the best language from a technical PoV would probably be something like SML or Haskell, because I'm constantly getting my arse kicked by data type problems. But the rest of the application has already been written in perl, by perl programmers, so the best language from the social PoV (which is more important than the technical PoV) is perl.
| [reply] |
Re^2: Why Perl?
by wee (Scribe) on Jul 18, 2013 at 21:44 UTC
|
CPAN is both bad and good. For example, how many XML parsing modules are there? Do you know which ones are best? Fastest?
I personally love the CPAN (name another langauge that can give you Lord of the Rings dates like Date::Tolkien::Shire can or comes with a built-in Enigma machine like Crypt::Enigma can provide). But sometimes there are too many choices, and lots of cruft to wade through.
| [reply] |
|
|
CPAN is both bad and good. For example, how many XML parsing modules are there? Do you know which ones are best? Fastest? Now that is a strange argument. Would you be happier if your choice was limited to only one mediocre module rather than 10 modules ranging from bad to excellent?I have over twenty screwdrivers in my toolchest. None of them will be good for all jobs. Some are versatile, some are specialized; Some I may have used only once (but I was oh so happy I had the right tool at my disposal then), some are used almost daily. Will I throw them away when someone invents a screwdriver that can work more-or-less-somewhat-OK in all circumstances? Of course not! The more choice there is, the better. Yes, it will take a while to get used to your tools and you have to build up experience to know when to use which tool, but after a while your hand grabs the right one without thinking.
CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James My blog: Imperial Deltronics
| [reply] |
|
|
It's a strange argument on the face of fit, but nonetheless true. It's easy to go grab the first module you find, and not realize that it's not been actively maintained, might have been superceeded by another module, etc. There's a lot of stuff on the CPAN -- that's good. But there's a lot that lain fallow on the CPAN -- that might not be so good.
Your screwdriver analogy presupposes that all your screwdrivers work equally well. But what if you couldn't easily see the tips before selecting them? You can guess how big a screw one might be used for based on handle size, but what if you needed to pull each one out partway in order to make sure that the tip wasn't bent or stripped?
There's no reason to throw anything away, but there ought to be something that prevents people from having to manually wade through a toolchest trying each tool in order to find what works. Perhaps a voting/rating system or something, not too sure what the solution is to be honest. But I've always felt the CPAN was a double-edged sword, expecially for newer users. Quite a few wheels have been re-invented there. And now I'm out of metaphors. :-)
| [reply] |
|
|
|
|
