Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Re: Perl advocacy, CGI/ModPerl vs ASP/JSP

by Matts (Deacon)
on Jun 17, 2002 at 14:47 UTC ( #175085=note: print w/ replies, xml ) Need Help??


in reply to Perl advocacy, CGI/ModPerl vs ASP/JSP

  1. The sigils are ugly in my opinion (arguments that they help you figure out the type of a variable fall down with references and slices). So I'd avoid arguing against that one if I were you.
  2. Perl has warts. The whole $self as first argument thing is one, but there are many others.
  3. But, despite the warts, Perl has CPAN. I'm afraid CPAN kills arguments about other languages stone dead. I've tried really hard to move to other languages (C, Java, Ruby) because I don't like Perl's warts, but none of those languages have the simple elegance of CPAN.
  4. Speed issues tend to evaporate when put under real tests. Slashdot gets a lot of hits and runs perl. Other sites get a lot of hits and run JSP, others ASP. In the end it all comes down to good design and network architectures.
  5. Did I mention perl has CPAN?
  6. Java is fundamentally not immune to security problems. That's the most naive thing I've ever heard a developer say. What about cross site scripting bugs? What about SQL injection bugs? No matter what language you're programming in, when you're working on the web you always *always* check your user input. Perl's taint mode makes it hard to avoid doing that, but it still doesn't alleviate security issues.

That's probably not exactly everything you wanted to hear. It's not so much an advocacy argument - the best thing about Perl is CPAN (and sometimes the worst thing about Perl is CPAN, but that's a whole other node).

Update: wedman reminded me of perldoc. That's such an awesome tool I can't rave enough. Show me another language that has as good and as easy to find docs as perl when you're working on the command line.


Comment on Re: Perl advocacy, CGI/ModPerl vs ASP/JSP
Download Code
Re: Re: Perl advocacy, CGI/ModPerl vs ASP/JSP
by wedman (Sexton) on Jun 17, 2002 at 16:15 UTC
  • Slashdot gets a lot of hits and runs perl. <...> In the end it all comes down to good design and network architectures.
  • Doesn't Slashdot have a big fat load balancing system in place? The speed issue was dealt with by throwing more hardware at the problem. So, like you said, it comes down to design and achitecture. I suppose somebody could code a website using Q-BASIC on several heavy duty machines behind a load balancing system, but that's probably not good design.

    To me, I find Perl very fast and easy to develop with. Not only is CPAN sweet, but PerlDoc rocks as well. I use references constantly when I code, and PerlDoc is always there when I need a hint.

      Slashdot actually used to be fast, and back then it ran out of Malda's appartment. (I have a userid in the 2000's). It requires a big fat pipe because it uses it. It requires load balancing because it gets enough traffic to need a big fat pipe.
      They describe the machines that power the site here. I wouldn't call 10 Intel boxes a big fat system. They probably cost less than one Sun box.
        More importantly, if it is a problem that can be solved by throwing more computers at, then you have a linear growth scalability. If you have a bad implentation, like bad algorithims, you could end up with an exponential growth, which cannot be fixed by throwing more computers at it. Perl can obviously support good programming and linearly scalable systems.
Re: Re: Perl advocacy, CGI/ModPerl vs ASP/JSP
by BUU (Prior) on Jun 17, 2002 at 23:04 UTC
    Sigils are *not* ugly! They are useful to show the type of values. Your contention that they "fall down with references" is mildly 'true', but not for the most part. Even if its a reference to a hash, you still know its one value, a scalar value, thus fufilling the point of the sigil. And more over, if you see "%$foo" then you know $foo is hash reference. And you can easily determine what type it is, merely by using the 'ref' function. I love sigils, they also help to make the code visually distinctive, you can always tell what is a variable and what is a keyword, and allowing interpolation is just a ++
      I'm afraid I can't agree. There are just so many cases where the sigils aren't enough to disambiguate clearly in people's brains. And references are the main cause of this. But also look at slices. Here's a hash slice:
      @foo{ qw(a b c) } = qw(x y z);
      Now what does the @ have to do with the variable? The correct answer is absolutely nothing. The sigils in perl are used to denote the type of the operation, NOT the type of the variable. Because the slice above operates on a list it uses the @ to denote a list. But damn, is it ever confusing.

      To take it further, you say ref($var) is enough, but how do you do that while coding? You can't - you can only run ref() at runtime. So sigils aren't serving their purpose there. Also now let's suppose ref($var) returns nothing, so what does $var->(); do? It possibly executes a function! But ref() told you nothing, and the $ told you nothing. (yes, I'm aware strict will catch that, but what if the purpose is to run a function? Then you have to have strict refs off for that section of code).

      Now take it a step further. What about $var->{entry}. Most people these days are doing OO (aren't they?) so what does the $ tell us this time? Nothing, because the type of $var->{entry} is totally and utterly opaque to the naked eye.

      Extreme example time. How do you do a hash slice of a hashref belonging to an object implemented as a blessed hashref? (did you parse that? It's hard to read, but it's even harder to figure out without severe experimentation how to do it). The solution is the totally inelegant:

      @{$var->{entry}}{qw(a b c)} = qw(x y z);
      So now what part of the above defines the fact that it's a hashref? The answer is the openning curly bracket just before the first qw. Nope, sigils were pretty useless once again.

      OK, rant over. Sigils really aren't all they're worked up to be. They have a purpose, which was fine for perl 4, but I think when perl 5 came along it all but made them useless.

        Well, i wont dispute with you on the basis of hashslices and so forth. Theyre just ugly. (i could point out that it may be the *programmer's* job to avoid ugliness...). But the rest of my arguements i feel still prove true. For your $x->{blah} $x a var blessed into a class (or atleast you hope it is), and {blah} is a hashkey contained by $x, which means it follows all the normal rules of such hashkeys, a scalar value. Now if you had done say, @$x->{blah} then we would know that {blah} is a hash-key to a array reference. (mm..i think that works) Same with say, $x->method; Theres an $x->, which means that $x is again blessed into a class, and method doesnt have any sigils, so its a function. You can tell $x isnt say, a coderef, b/c you call those like $x->(); no method name.
        There is a difference though between whether there is a sigil, and what it's used to denote. (In Ruby they denote scope.)

        Makeshifts last the longest.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (14)
As of 2014-10-21 16:43 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (106 votes), past polls