Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

Re: Seeker Of Perl Sympathy

by Errto (Vicar)
on Jan 08, 2005 at 23:38 UTC ( #420607=note: print w/replies, xml ) Need Help??

in reply to Seeker Of Perl Sympathy

Whew. Tough question, and I may not be the best person to answer it, but I'll give it a whirl. I personally have encountered resistance to Perl (though not as strong as you describe) in two very different environments: 1) a Computer Science department at a prestigious academic institution, and 2) the IT department of a large corporation whose primary business has fairly little to do with IT.

First of all, I think part of the problem is simply technical; that is, many of these people have never seen well-written idiomatic Perl 5 code that takes advantage of things like modules, nested data structures, objects, coderefs, and m//x. The code they've seen consists mostly of global variables, typeglobs, eval-strings and indecipherable regexes.

Beyond that, it depends on the background so I'll try to address the two separately.

  • Computer Scientists view programming languages not only as tools, but also as objects of study. Those involved in areas such as formal semantics, compilers, and the like look askance at any language that cannot, say, be fully described by an LALR(1) grammar. They also take a pretty formal view of data structures. To them, a data structure such as a double-ended queue or a hash table has a strict interface whose implementation not only can but must be hidden from calling programs. They scoff at Perl's lack of data isolation of this kind and are not amused by the shotgun analogy. By the way, C does not have these kinds of data structures natively -- it's a very low-level language. But it is possible to implement data structures in C in a cleanly isolated way. The catch, of course, is that it's hard. C is enormously more difficult to write than Perl because you have to manage your own menory. All that said, many of these folks use Perl and recognize its strengths in one specific area: rapid prototyping. But they would never write serious code in Perl. In fact I once heard a professor say (and mind you I respect him enormously in almost all other aspects) that "there is no such thing as programming style in Perl."
  • In the corporate world it's something different altogether. In their case, it's a somewhat irrational fear that because Perl "naturally" lends itself to obfuscation, new developers may find it more difficult to pick up old code. CIOs have generally accepted PHP hook, line, and sinker, and will not listen when you warn them that the language is unscalable by design in terms of project complexity. The reason is that PHP is seen as easier and this is a big deal because CIOs have two issues to worry about that most open source developers don't: 1) tight deadlines, and 2) relatively weak developer talent for the types of applications they are often building. Also, and I don't know why PHP is allowed as an exception, corporations have a fear of any product, including software platforms, that do not bear the stamp of a particular vendor. I've seen many instances where people bought proprietary software that was utter crap when perfectly good open source solutions exist, just so that they can feel like it's the vendor's fault when the project doesn't work out as well as planned.

As for your proposed objections

Blinding speed? Tight, highly-predictable RAM usage?

Yes. That is an extremely common view. The hilarious part, of course, is that if they're talking about web applications then they're full of it because the overhead of interpreted languages is not where performance of web apps suffers, in almost every instance.

Compiling code into binaries so that nobody can read their source?

Yes again. And frankly, for code that's to be distributed to customers on a commercial basis, I honestly think that's a fair objection. Of course, if they believe Java is a solution here they're damned fools because decompiling Java is fairly trivial.

By the way, while it is true that writing obfuscated Java code would be nigh on impossible, C is another matter altogether. Obfuscated C contests were a venerable tradition before Perl was even born, and believe me I've seen "serious" C code that was pretty darn obfuscated.

Note: Please don't interpret my comments as dismissive of Computer Scientists. I greatly admire the work that they do and have some ambitions to return to the field myself. I just think some of them have silly attitudes about certain things.

Replies are listed 'Best First'.
Re^2: Seeker Of Perl Sympathy
by bradcathey (Prior) on Jan 09, 2005 at 13:29 UTC
    Yes. That is an extremely common view. The hilarious part, of course, is that if they're talking about web applications then they're full of it because the overhead of interpreted languages is not where performance of web apps suffers, in almost every instance.

    Errto, great reply and points well taken. However, as a web guy I am interested in hearing you unpack your comment about interpreted languages. My first language, back in the early 80's, was BASIC. But I didn't really feel "cool" until I bought a compiler and started compiling my stuff with some assembler screen routines (remember how slow the screen-writes were?!). I'm sure interpreted languages have come a long way,e.g., Perl, as has processing power, but I'm still curious about your statement and intent. Thanks.

    "Don't ever take a fence down until you know the reason it was put up." G. K. Chesterton

      Sure. Obviously compiled languages still beat out interpreted languages in terms of speed and memory consumption any day of the week. Of course, these days most compilers use a multi-phased approach that involves some kind of intermediate representation. The genius of technologies like JVML, .NET CLR, and Parrot (and their less widely known predecessors) is that this intermediate representation can act as a portable bytecode in itself. This is why you can run Java on PDA's but not Perl (at least not until the release of Ponie): Perl requires a full-fledged interpreter which is just too much overhead for a small system like that.

      But a web application is different. There you tend to have heftier CPUs and large bundles of RAM. If there is a CPU bottleneck on that kind of application, it will likely be because of intensive database queries or on-the-fly calculations, and not the interpreter. That said, if you were to write a web app in C or C++ I'm sure it would be much faster.

      The catch is, of course, that almost no one does that, because it's generally felt to be not worth the effort. They write web apps in Perl, Python, PHP, ASP, Java, ASP.NET, etc. The reason Perl does not suffer a major performance hit compared to Java and .NET merely because of a lack of compiled bytecode is that, assuming you're using mod_perl with either direct handlers or Apache::Registry scripts, the interpreter compiles and loads each module into memory only once. This one-time cost is higher for Perl because it has to compile the source code, but it's hugely different from doing it for every page hit.

      It's also possible that whoever told you this is conveniently ignoring the existince of mod_perl (and mod_python, etc) and presuming that all Perl web apps run as straight CGI, which is patently unfair.

        This is why you can run Java on PDA's but not Perl

        Actually, the first PDA I had Java on is also the first PDA I installed Perl on. The Sharp Zaurus 5500 ran perl just fine. It was a bit limited, in terms of modules available, but it worked for simple tasks.

        Linux, sci-fi, and Nat Torkington, all at Penguicon 3.0
        perl -e 'print(map(chr,(0x4a,0x41,0x50,0x48,0xa)))'

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://420607]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (5)
As of 2019-11-23 01:37 GMT
Find Nodes?
    Voting Booth?
    Strict and warnings: which comes first?

    Results (113 votes). Check out past polls.