You Used Perl to Write WHAT?! 307
Esther Schindler writes "Developers spend a lot of time telling managers, 'Let me use the tool that's appropriate for the job' (cue the '...everything looks like a nail' meme here). But rarely do we enumerate when a language is the right one for a particular job, and when it's a very, very wrong choice. James Turner, writing for CIO.com, identifies five tasks for which perl is ideally suited, and four that... well, really, shouldn't you choose something else? This is the first article in a series that will examine what each language is good at, and for which tasks it's just plain dumb. Another article is coming RSN about JavaScript, and yet another for PHP... with more promised, should these first articles do well."
Its simple (Score:5, Insightful)
ob (Score:4, Insightful)
Ray Tracing (Score:5, Insightful)
But the most profound part of the whole article, and I admonish everyone coding Perl to remember this:
This applies to any language. If you can do it multiple ways, pick the readable one.
Re:Both sides... (Score:5, Insightful)
That's why the "right tool for the job" is sometimes the tool that meets the greatest cross-section of a company's needs rather than a jumble of tools that are ideal at a lot of little tasks.
e.g. While it's fashionable to hate Java these days, you have to admit that it does have a rather massive cross-section of needs it can meet. Thus one of the reasons why it's so popular in large companies. Yet a smaller company might find more value in using Ruby toolkits to do all their work. Ruby may not be ideal for some of the less glamorous back-end tasks, but tools like Rails gain so much on the front end that Ruby meets a greater cross-section of needs than Java would.
refund (Score:5, Insightful)
Re:idiots (Score:4, Insightful)
Now, perl might not be the best language on the entire planet for web scripting and such, but to suggest that it is actually on the negative side of the graph in being web appropriate is just dumb. And I don't need to be a CIO to understand that.
Re:My favorite example (Score:2, Insightful)
Just sounds like text processing to me, which Perl (and most scripting/shell languages) are designed for.
Re:is your company weak? (Score:3, Insightful)
OK, so not all languages are well matched to solving all problems, but keeping it down to a managable number also serves to avoid some major grief in future.
Re:is your company weak? (Score:5, Insightful)
Re:According to the article.. (Score:4, Insightful)
Re:An Intelligent FrI$T Psot. (Score:4, Insightful)
Re:Both sides... (Score:5, Insightful)
I hate the "right tool for the job" cliche. Not because it's necessarily wrong, but because it tends to be used by people who automatically assume that their tool is the right one and wish to stop any serious discussion about other possibilities.
Re:is your company weak? (Score:4, Insightful)
But the problem isn't 'picking up a language', it's picking up 3. If we hire a new recruit, to expect him to learn 3 new languages immediately is ridiculous. So we don't -have- a ton of different languages in use, we have a choice few that cover everything reasonably well. In fact, since I started, we have dropped 1 and almost dropped another. (They're waiting on me to have time to rewrite that last program in another language.)
In addition to not having to have new recruits learn those 2 languages, we also don't have to maintain the software needed for those 2 languages. That saves employee time and computing power both.
And in truth, I tried to suggest adding a new language a few months ago... And after discussion, we decided the benefits didn't outweigh the costs. I was the only one who already knew the language at all, and it wasn't -that- much better than what we had.
If we were a huge company with thousands of employees, it might make sense to have specialists in each of the languages and also use 'the right tool for the job'
Re:is your company weak? (Score:5, Insightful)
Re:is your company weak? (Score:3, Insightful)
Re:is your company weak? (Score:3, Insightful)
If it is a one time throw away script to fix a one time problem then yes the programmer can use what ever he wants.
But if it is a tool then you may need to have other people maintain and work on it.
You can write any program in any language. Yes some are better than others but how well you know the language is also important. Also having multiple vendors for a language is also really useful. If only one vendor supports the language then they have a lot of control over your company. Take Foxpro and Visual Basic as examples.
Whoosh! (Score:2, Insightful)
Re:Ray Tracing (Score:5, Insightful)
In a college computer architecture class, we had to write an emulator for a system designed "by the professor". Basically all tight loops performing really basic operations, and a lot of synchronization. We were given sample microcode and programs to test with, and when we turned it in he ran it with different microcode and programs to guarantee accuracy. Accuracy was required to pass, but your grade was based on performance and clarity.
They only perfect score went to an emulator written in Perl. The built-in hash tables, and some smart programming combined with the ease of parsing the microcode and program data created not only the fastest (some classmates used C, C++, lisp, or Java to write their emulators) emulator, but also the easiest to read of the group.
It's the programmer that creates slow, unreadable code, not the language.
It's "Hard" to learn a few languages? (Score:3, Insightful)
There is a difference between keeping a well stocked and maintained tool-box that covers the basics and being a compulsive tool collector. There's also a difference between keeping a well stocked and maintained tool-box that covers the basics and using a screwdriver for everything. That's the same mentality that tries to use the tip of a hunting knife to turn a precision screw.
Another useless article (Score:3, Insightful)
What people tend to forget is how extensible a language can be, especially Perl. Blanket statements like "Perl should not be used for the web" is misinformed at best. No one wrote web scripts in Ruby before Rails -- it's all about the framework. Go give the Catalyst framework a try, and tell me again not to use Perl for the web.
As for high performance computing, remember that the perl interpreter does a few things very well, very fast. We ended up rewriting our web crawling infrastructure at $WORK from Nutch and Lucene in Java to a custom distributed Perl architecture against Xapian. Not only is it much more 'pluggable' than the original solution, we ended up getting a huge increase in speed out of the deal, even putting it up against 64-bit Java. It's anecdotal, and mileage will vary, but there are times that Perl is just better at crunching text than anything else.
Too many people write off Perl as a relic of the past. What people fail to see is the new Perl renaissance that is quickly approaching. It's a good time to be a Perl developer, judging by the job market.
4 Signs You're An IT Tool (Score:3, Insightful)
I was expecting the standard litany of anti-perl 'wrong tool for the job' comments in this article, but the 'four things' you're not supposed to do made me laugh:
Check. No discussion necessary, but did it even need to be pointed out? Really, if you're even thinking about doing real-time apps in any interpreted language, you need to have your head examined.
The example provided points out that using a simplistic perl script that calls 'system' to move files around generates a lot of needless sub shells and processes. OK - good point. However, in the example he provides, he replaces the inefficient perl script with an efficient perl script. How does that help make your point? Unless the point is 'try to write good code' - which isn't language specific.
This is just short-sighted and stupid, and the author suggests we use PHP or Ruby on Rails. OK - there are a lot of choices here, and all of them have advantages and disadvantages. But after reading that I should be using PHP, this quote made me spit coffe on my keyboard: "You should especially avoid using perl for traditional CGI-style form processing; this code tends to be hard to read and maintain because the HTML ends up inlined inside the perl code." Clean, elegant and properly designed code can be written in any language. Some languages encourage this, some make it difficult. Ruby encourages, but I'd stake my reputation on the claim that PHP makes it very hard. Perl is neutral on that spectrum.
Check. No discussion necessary, but did it even need to be pointed out? Oh, I used that one already.
Re:Its simple (Score:3, Insightful)
Re:4 Signs You're An IT Tool (Score:3, Insightful)
Check. No discussion necessary, but did it even need to be pointed out? Really, if you're even thinking about doing real-time apps in any interpreted language, you need to have your head examined.
Yes. It needed to be pointed out. Look at where the article is published: a magazine targeted at _IT managers_. Many of these people don't really understand the basics of what the languages the programmers they employ are. Articles like this that introduce the strengths and weaknesses of a language might help prevent them from making braindead decisions on the basis of recommendations from fanboy programmers.
But after reading that I should be using PHP, this quote made me spit coffe on my keyboard: "You should especially avoid using perl for traditional CGI-style form processing; this code tends to be hard to read and maintain because the HTML ends up inlined inside the perl code." Clean, elegant and properly designed code can be written in any language. Some languages encourage this, some make it difficult. Ruby encourages, but I'd stake my reputation on the claim that PHP makes it very hard.
Not really. I've written MVC applications using a homebrew template engine as the view component in PHP, and it wasn't hard. The only real issue with PHP is that it makes it too easy to program badly... programming well in it is no harder than other languages.
Re:Bollocks (Score:3, Insightful)
Probably because the CIO author is highly ignorant of the existence of CPAN and some of the high quality modules it archives and distributes. One particularly high quality module is Template Toolkit [cpan.org]. It is an incredibly powerful templating system. Some would even say it is too powerful (you could write enter programs in the template language). But what I have found is that power was purposely put there because there are instances where you need to do something fancy in the template or view rather than the controller code. And I have found it actually turns out cleaner than the equivalent in something built on J2EE.
CPAN is also a whole lot more active than other library inventories. While some authors do tend to give up on maintaining their modules, there are lots of reports and patches submitted along-side the modules as well as test reports on systems where successfully/unsuccessfully installed. There are often multiple submissions of the same concept of a module but with varying implementations. This gives you many choices and lets you explore various implementations until you find one that suits your needs.
Here's a list of other awesome modules that extend perl or implement various concepts:
In other languages or platforms there's also been issues with third-party libraries. For example in Java you could spend days trying to get a library or tool to work in your IDE. With perl and unix that's not the case. You simply go onto CPAN, see if someone's done it. If someone has, you'll be up and running in under a minute.
language vs library (Score:5, Insightful)
I wonder if this whole discussion is off the mark. Languages are for the most part trivial. And universal. "It's the libraries, stupid" is sometimes how I feel. If it was easy to link in or call any library function from any language, then half of this discussion would immediately be seen to be irrelevant. So Perl is "the right tool for the job" because it has the ability to apply regular expressions to strings? But, you know, C can do that too thanks to this PCRE library. Hashes? C can do that too via another library. In case anyone has forgotten, Perl itself is written in C. I read that Perl 6 has vastly improved the interface to other languages, especially C libraries.
These day, whenever I write a new program it often feels as if I'm creating yet another language. A simple, superficial, limited language, but nonetheless, a language. Program needs a configuration file? Whip up a suitable format (language) for that. Needs to save data? Barf out this big data structure into a YML file. Want some way to run the interface from a batch process, or otherwise automatically? Start turning the user interface into a language. Want to connect Perl 5 and C? Get acquainted with XS, a "language" the Perl folks felt it necessary to create for that purpose, because Perl 5 wasn't good enough alone. Want to compile a large project written in C? Get familiar with the language of Make, because while C certainly could do it, C isn't so good for that. Is ANT a "language" for building Java projects? Where's the line between language and library?
I suppose where things lead to a new language is when someone wants to implement a new concept and the established ways aren't good enough. Or has a way to eliminate a bad programming practice, but some elements of an existing language must be dropped to do it. For instance, wouldn't be nice to have variable length parameter lists in C, as C's own printf function does? Too bad it's such a pain to do that in C. How about lazy evaluation and currying so we can have infinitely long parameter lists? Oops, guess the C call stack can do recursion, but isn't too well suited to expressing that sort of thing, time to make another language, Haskell. Do we want to pass along a pointer to a structure, or a copy of a structure? Java defaulted to pointers where C did not, but then said Java didn't use pointers. Nice not to have to type in ampersands and asterisks all the time, but still, I find the thinking misleading. Then there's garbage collection. The consensus is that garbage collection is overall a good thing, but that a good programmer can do better than the automatic garbage collector. And so on.
Sheesh... (Score:3, Insightful)
First, and more than sufficiently, of all: who the $curse is going to be taking coding language advice from CIO Magazine? If it's a real practicing software developer, they need to turn in their geek card and coder license immediately. And if it's a CIO or other PHB-level entity, for the love of $DIETY, don't let him start dictating software tool choices on the basis of stuff like TFA!
Second, the author of the article sounds like he has only ever dabbled with Perl, sysadmin-tool-like. He betrays a disturbing unawareness of the recent development in frameworks and methodologies in the Perl universe that track most of the major software development trends and tools available in other communities. His advice, positive and negative, seems stuck in basic out-of-the-box Perl 5.6 or something. Most of the time, that's plenty good enough for the ol' sysadmin "Swiss Army Scripting Language" approach, but certainly missed out on a lot of good work. (The reader comments after the article call him out on this pretty well, so I won't rehash.)
Third, a lot of the advice is universal, not Perl-specific. I mean, stuff like "Don't use Perl in an obfuscated fashion" is like "Don't drive a 1973 Dodge Ram pickup truck while drunk." Very true, very sage advice, but the problem is not Perl (or the truck), it's the obfuscation (or the drunkenness). Code readability is a timeless, domainless, endless problem. The only reason Perl gets picked on for readability is basically bad PR.
Frankly, a lot of TFA just sounds like an excuse to fill up a few column-inches the editor needed filled in.
Re:ob (Score:3, Insightful)
Re:idiots (Score:3, Insightful)
Re:Ray Tracing (Score:4, Insightful)
To the contrary, I think everyone should write a ray-tracer in Perl. Or, more generally, every programmer should take his or her favorite language and use it for something it's spectacularly bad at. Like ray-tracing in Perl.
Part of the reason is to show that yes, you can use just about any language for just about any task. But that doesn't mean you should. Using a language unsuited to a project gets you familiar with the bounds of the language, so you have a pretty good idea before you start whether or not the language is a good fit for a given task. And it can often teach you a lot about the language, because you'll have to explore the little nooks and crannies to figure out how to get it to do what you want.
The other part of the reason is that everyone needs a little humbling. This is especially true for anyone who says, "I used to use {language_x} until I discovered {language_y} and realized that {x} is TEH SUCK!" That usually just means that {y} is more suited to what you're doing now. Go code something non-trivial that {y} is unsuited for, and see if you don't end up cursing your new favorite just as much as you curse your old favorite.
Re:I call bullshit (Score:3, Insightful)
Oh, perhaps the kind that provide exclusive or small-reach services? e.g. If I ran a local salon, how many people would reasonably be hitting my site simultaneously? I might not be able to afford to have someone build me a scalable J2EE online-appointment system, but I could probably afford a small Ruby on Rails site. Scalability for my site would be handled by throwing hardware at the problem, as it's a LOT cheaper in this case than trying to pay for a massive development effort.
And if my site is well and truly straining under the load applies to it (for a single-shop salon!) then I've got a lot bigger problem with over-booked schedule than with my technology.
To carry that example one step further, I would probably look at opening new locations to solve my overbooking problem. Each location could get its own scheduling system on a different subdomain, thereby solving my issues for the near future. If I manage to get so popular as to need a unified solution, then it's probably time to rearchitect the technology AND the business to meet the demand. (As good as we programmers like to think of ourselves, we can't possibly predict the issues that will be involved in such a changeover to the extent to where we can deliver the original solution with that sort of adaptability in mind while still doing it inexpensively.)
People keep saying this... (Score:5, Insightful)
The problem is not learning the syntax and basic idioms. Agreed, that's pretty quick, particularly if you have a good reference.
The problem (and the time sink) is the *ugly* side of every language. The parts of the standard libraries that sucked, and were reimplemented elsewhere (but you gotta know that...). The functionality where everyone who "lives with" the language grabs X open source library to implement -- not Y! it's a POS! -- but you don't know that yet. The language features that have secret, illogical gotchas for special cases. The bugs in the compiler or interpreter that are easy to avoid -- once you've been burned once. The code that will break cross-platform compatibility for obscure reasons. The code that will make it almost impossible to internationalize later, because you didn't learn how that support worked yet.
Granted, the cost of these things with any reasonable mature language should not be enormous (though it depends how long you go down a wrong path...), and you can allow for it, but it's always a significant risk *especially* if you don't have someone on the team (perhaps the new team who has to maintain your old code) who's already more-or-less expert level.
But either way, you have to allow *something* for that cost, and sometimes it's not worth it just to use the absolute best tool for the job when you have a pretty close fit available.
Re:People keep saying this... (Score:3, Insightful)
This is worthy of a mod +5 - Wish I Said It Myself. It bears repeating. Syntax can learned in a few hours, figuring out the quirks can last you a lifetime.
Re:4 Signs You're An IT Tool (Score:3, Insightful)