in reply to RE: why i may have to leave perl...
in thread why i may have to leave perl...

It's hard to imagine any role that Perl couldn't fill, with the proper adjustment.

(Okay, I'm aware I'm taking this one statement a little out of context. But this is a pet peeve of mine for people who see Perl as a hammer, and everything else as nails.)

Actually, it's easy to imagine dozens of roles that Perl is completely unsuitable for. It will never be found in automotive embedded systems (engine/transmission computers), life support applications, microwave ovens, cellular phones, or any other application where the hardware cost is driven by volume, or certain types of compliances must be met.

There are a couple of factors here: One is that the lowest hardware cost is almost always achieved by using a minimal hardware configuration. Unless you're willing to use a 386 or better processor, and a corresponding environment that will support a real O/S (read 4+ MB memory, 2+ MB ROM), this is rarely co-incident with lowest cost. Perl is an application that requires an underlying operating system to be effective. People may port it to the Palm Pilot, but one has to ask oneself "Is this *really* useful?". Most of the time, such exercises are for the demonstration of "coolness", not practicality. This is evidenced by the fact that Linux and it's cousins still aren't practical on the hardware used by most PDAs. And this is also why MS has a market for WinCE (or whatever they call it now), and Palms are running Palm O/S.

Considering that minimum hardware cost for a 386, 4MB of RAM, 2MB ROM, supporting circuitry, yada yada yada is still about $50 in large volumes, are you going to pay that surcharge so your microwave oven can have a "Linux/Perl Inside" sticker? I sure won't. And neither will the normal consumer.

Perl will never be suitable for writing kernel mode device drivers. I'm sure someone will do it, just to show that it can be done, but it's not the correct model for driver development. Remember that Perl is still written in 'C'. There's a good reason for this. It's because 'C' is still the right tool for writing as close to assembly as possible, and maintaining portability. Possibly this might change when Perl-to-EXE actually works, but I seriously doubt it.

Another factor is that Perl will (in all probability) never be certified for military and life support programming, such as Ada is. There are a number of reasons for this, ranging from the requirements for strong type checking of variables and arguments, (current) lack of ANSI certification to compile time evaluation (How many times have you not realized you misspelled a subroutine name until it coughs a hairball at runtime?) and practical automated CASE tools.

I've said this before, I'll say it again: Perl is a hell of a language. It's very full featured, it has features that few others languages have, it's well accepted, etc. But, remember this: One of the things that makes Perl so useful is CPAN. Without the people that have written these modules and made them publically available (GPL, Copyleft, whatever), Perl would be seriously lacking. How'd you like to lay out $100 for, under the typical licensing schemes for most "DOS/Windows" libraries? I'm pretty sure it wouldn't be anywhere as popular as it is now. One of the major reasons (I believe) that Perl is so widely accepted is because of the underlying distribution model.

On a slightly different note, one little thing that bothers me about Perl is the lack of structures such as 'C' supports. I know that structures can be emulated, but the ability that 'C' has of mapping a block of memory to a structure, accessing the individual elements with ease, then stepping a pointer to the next block is missing. This makes it much more difficult to implement access to memory mapped devices, and other objects that can't be conveinently remapped into Perl idioms. I'm sure someone will immediately correct me on this (probably tilly...), but that's my take on it as a long time 'C'/assembly/Forth programmer.

Good programmers know when to use the right tools for the right job. These decisions are, of course, mediated by management (always runaway when management endorses a methodology. Nothing like an edict "all future code will be object-oriented" from people who don't even know how to reboot their own computers), development time & time to market, maintainability, and half a dozen other factors. Know when to hack Perl, when to sling 'C', and when to hand-craft assembly. Just because you know a way to make it *work* in Perl doesn't mean that Perl is the answer.


e-mail jcwren