|
Re: Is there ever a time Perl is the wrong choice?
by coolmichael (Deacon) on Feb 05, 2003 at 04:59 UTC
|
Perl isn't great at numerical analysis. For example, if you have a 1024x1024 matrix (possibly for a fourier analysis) it will eat up far more memory in perl than it will in C/C++. C/C++ isn't necessarily the best choice for this example either. There are modules that make it easier and more memory efficient, but I still don't think perl will the best tool for this.
Low level image processing in perl isn't that great either. There are a lot of modules in CPAN that interface to external utilities (like Image::Magick).
I can't really imagine anyone wanting to write a device driver in perl :)
All of this is IMHO of course. There might be really good ways to do all of these things with modules. | [reply] |
|
|
There are great modules for these things. The stuff that needs to be fast is written in C while a Perl framework holds it together.
Perl isn't great at numerical analysis. For example, if you have a 1024x1024 matrix (possibly for a fourier analysis) it will eat up far more memory in perl than it will in C/C++
PDL is great for 1024x1024 matrices.
Low level image processing in perl isn't that great either. There are a lot of modules in CPAN that interface to external utilities (like Image::Magick).
Imager is not an interface for external stuff.
I can't really imagine anyone wanting to write a device driver in perl :)
I'd like to be able to. Lots of devices don't need speedy drivers, and it'd be a great way to prototype!
There might be really good ways to do all of these things with modules.
There are indeed!
Juerd
- http://juerd.nl/
- spamcollector_perlmonks@juerd.nl (do not use).
| [reply] |
|
|
Imager is not an interface for external stuff.
A large part of Imager appears to have been implemented in C.
/prakash
| [reply] |
|
|
Re: Is there ever a time Perl is the wrong choice?
by adrianh (Chancellor) on Feb 05, 2003 at 09:12 UTC
|
Lots of reasons not to use perl :-)
Speed. Sometimes you need to do something faster than perl can.
Space. Perl's data structures are optimised for speed rather than memory usage. Sometimes that can cause problems if you're dealing with lots of data.
Appropropriate functionality. If I have to write a multi-platform GUI I'd probably pick Java/Swing over any of the current perl solutions. If I have to do a lot of predicate logic stuff I'd pick Prolog over current perl solutions. Etc.
I use perl most of the time - but only because perl is the best solution for most of the stuff that I write ;-)
There are also non-technical reasons.
For example, if you have a project that is mostly in language X, then it's probably easier to keep everything in X rather than switch part of it over to perl, even if its more suitable technically.
I switched part of a web project over to perl when most of the rest was C++ (because DBI & LWP made things almost trivial).
Bad decision on my part.
The extra overhead of another language (the glue between perl/C++, different style of test suite, having some of the team not understand what it did, etc.) caused far more problems that making part of the project easier to implement.
| [reply] |
Re: Is there ever a time Perl is the wrong choice?
by fokat (Deacon) on Feb 05, 2003 at 03:32 UTC
|
Well, for the last ten years I've probably written upwards of 50,000 lines of Perl and less than 500 lines of C/C++. I've been working in consulting and developing services at ISPs. Mind you, I wrote a RADIUS server, DNS server and part of an Email server in Perl. And many, many miscellaneous scripts in between. Like the ones I use to apply "configuration templates" in a network with hundreds of routers.
Could I have written all of this in other languages? Sure. But then I would have to multiply those lines by a factor of at least 4.
But I digress towards Perl's strengths. Certainly, there are times when you cannot afford some of the Perl's intrinsic tradeoffs. Or perhaps, times where you don't want to distribute your source code along with your executable. Those are the two only scenarios I could think (in my area of work) where Perl could be a second rate solution.
BTW, ++ to Marza for bringing such a (IMO) good and polemic question to the table.
Best regards
-lem, but some call me fokat
| [reply] |
|
|
| [reply] |
|
|
No, you can't. You can obscure your source code that way. Any means of distributing your program such that it still goes through a normal perl compile-to-optree, execute-optree cycle means that the source code is still available for the compiler to turn into an optree. This means that a properly motivated person could get your source code back.
Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).
| [reply] |
|
|
|
|
|
Re: Is there ever a time Perl is the wrong choice?
by Mr_Person (Hermit) on Feb 05, 2003 at 02:40 UTC
|
Well, there are certainly times when you don't want to use Perl. I don't see the Linux kernel being rewritten any time soon. If you need something that's as fast as it can possibly be, or want lower level control over the internels of the computer, something like C would probably be a better choice. Even Perl itself is written in C (and Parrot too).
That said, most everything I've developed has worked just fine under Perl and was probably quite a bit easier to write than if I'd used another language.
| [reply] |
Re: Is there ever a time Perl is the wrong choice?
by dws (Chancellor) on Feb 05, 2003 at 07:10 UTC
|
I wonder is there ever a chance that Perl would not be the optimal choice for a project?
Embedded, hard realtime. Perl doesn't even make the list.
| [reply] |
Re: Is there ever a time Perl is the wrong choice?
by toma (Vicar) on Feb 05, 2003 at 05:05 UTC
|
Of course! 'There is more than one way to do it'
is more general than perl itself.
One of the great advantages of perl is CPAN, and a
few other languages are also blessed:
When you use another language,
bring perl with you.
Instead of wasting time
with tedious integration problems,
use perl as duct tape.
If you want to understand languages
and problem spaces, check out MJD.
His insight is so deep that we have to drop
him a fiber so he can see daylight!
It should work perfectly the first time! - toma | [reply] |
|
|
... use perl as duct tape.
First thing that came to mind reading this was The Red Green Show. I never actually watch it, but the infamous duct-tape-can-be-used-for-anything thing is known by most people. Now, all we need to do is create The Blue Yellow Show, where the motto is perl-can-be-used-to-tape-anything-together :) merlyn can be Uncle Blue, and vroom can be the nerdy nephew :P
C:\>shutdown -s
>> Could not shut down computer:
>> Microsoft is logged in remotely.
| [reply] |
Re: Is there ever a time Perl is the wrong choice?
by webfiend (Vicar) on Feb 05, 2003 at 09:02 UTC
|
I couldn't really tell you from a technical standpoint. Perl has always been capable of doing what I needed it to. Some of these other folks with more demanding needs have already pointed out technical aspects of when not to use Perl.
My focus is usually a cultural aspect. Since I tend to do more contracting work, I have to look at the environment when I decide what would be "the right tool for the job". If the company has some reasonably skilled Perl folks, or it's most likely that I will be the one maintaining the project, I feel safe using Perl. If it's a bunch of Java people, though, I would lean towards using Python. It would take less work for them to stretch their brains around Python's capabilities than if I threw a few Perl modules at them.
Occasionally, when I just want to have some fun, I use Ruby. Because I can.
Still, I'd say Perl is the best tool for the job around three or four out of five times. The majority of the time, but nowhere near all the time. You just have to look at what you need, and who else will be looking at your code.
"All you need is ignorance and confidence; then success is sure."-- Mark Twain
| [reply] |
Re: Is there ever a time Perl is the wrong choice?
by dragonchild (Archbishop) on Feb 05, 2003 at 14:57 UTC
|
Other posters have spoken on the technical reasons not to use Perl. Basically, anytime you have to do something faster than a human can respond in less than (essentially) infinite RAM, you might not want Perl (but Perl will probably still do a decent job).
On another note, a lot of people discuss the fact if all you have is a hammer, everything you see is a nail. A lot of languages are like this. However, Perl isn't just a hammer. It is a complete toolbox, with a bulldozer and 90-foot crane, even! This makes it pre-eminently suited to nearly any job you would want to tackle. (And, frankly, nearly every job you would want to tackle with it, some kind soul already has contributed a module in CPAN to help.)
------
We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement. | [reply] |
|
|
Good point.
For the past two years or so, I've been writing a lot of Perl scripts to help with some analysis of our project. Specifically, I have a lot of Perl scripts that can open and read Excel files and retrieve information, and compile that information into a new Excel file.
My supervisor came to me not too long ago and asked me to write a script which would go through a huge Excel file (on the order of 12MB) and do a quick parsing of the text. The primary problem with the file as it was hinged on the fact that there was a series of extra characters in each cell. I don't remember exactly what the characters were, but a simple Find/Replace from within Excel reduced the problem to triviality.
As much as I love writing Perl scripts, this was not a good case for one. And as soon as I mentioned the Find/Replace, my supervisor could have kicked himself. He just saw a problem that Perl would be able to fix, and didn't think of anything else. :)
| [reply] |
Re: Is there ever a time Perl is the wrong choice?
by samtregar (Abbot) on Feb 05, 2003 at 18:28 UTC
|
I wrote a desktop GUI program a few years back called gRMA (http://www.tregar.com/gRMA) using Perl and Tk.pm. By the end of the project I was wishing I'd used TCL/Tk instead. I love Perl, but TCL's binding to Tk is considerably cleaner. Also, my TCL style is considerably simpler than my Perl style, which tends to be 90% OO. All things considered, I think gRMA would have been a better program in TCL/Tk.
But I've had more experiences where I built something in another language and later realized that I could have done it in half the time in Perl.
-sam
| [reply] |
Re: Is there ever a time Perl is the wrong choice?
by Wysardry (Pilgrim) on Feb 05, 2003 at 17:39 UTC
|
In general, any project where text doesn't make up the bulk of the processing or that involves low level access would likely benefit from being coded in something other than Perl.
Perl also tends not to scale very well in multi-threaded environments compared to other languages.
There are modules available to add functionality to the core language, but obviously this is less efficient than using a language with those functions built in.
I wouldn't want to attempt to code a raytracer in Perl, for example (or any math or graphic intensive program come to that).
Basically, Perl is a general purpose language with an emphasis on text processing, and if your project has a very specific task to perform, it will benefit from being coded in a language specifically designed for that task.
Adjustable spanners are okay for everyday use - such as bicycle maintenance - but you'd find it quicker and easier to use a quality socket set to strip down something like a performance car engine.
Choosing a programming language should be included as part of the design process, and whilst personal preference and experience level will be factors, suitability for the task should also have a high priority.
There's also an interesting (speed) comparison of 30 different computer languages at The Great Computer Language Shootout which you might find useful.
__________
"Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work." -- (Author Unknown)
| [reply] |
Re: Is there ever a time Perl is the wrong choice?
by IlyaM (Parson) on Feb 06, 2003 at 09:30 UTC
|
| [reply] |
Re: Is there ever a time Perl is the wrong choice?
by FoxtrotUniform (Prior) on Feb 06, 2003 at 19:29 UTC
|
Here's a rather pathological example I came across recently:
The problem was to build a minimum-change generator for k-permutations, so that each k-permutation differed in exactly one element from its predecessor. (This is sort of like a successor function, but you have more history around so it's a bit easier.) This "reduces" (heh) to finding a Hamiltonian cycle in a graph of all k-perms of the set you're given, where two vertices are adjacent if they differ by just one element. (How's that for a disgusting problem?)
A friend of mine wrote about thirty lines of Prolog to simulate such an algorithm. I would not want to try that in Perl. (Yes, you could probably do it with a particularly gnarly regex, or an explicit backtracking approach, but I bet it'd take you more than thirty lines.)
To me, in general, it's all about the builtins. For almost all of what I do, Perl has the right builtins. Sometimes Common LISP is a better choice. Sometimes Matlab is a better choice (in particular, for linear algebra. Sure, you can grab the right module off of CPAN, but if you use Matlab you don't have to).
--
F
o
x
t
r
o
t
U
n
i
f
o
r
m
Found a typo in this node? /msg me
The hell with paco, vote for Erudil!
| [reply] |
|
|
Any time you want to use MATLAB, it might be valuable to also check out PDL::LinearAlgebra (MATLAB-ish Perl wrappings around PDL wrappings of ultra-fast LAPACK routines).
| [reply] |
| A reply falls below the community's threshold of quality. You may see it by logging in. |