Perl is worse! (was: Python is Wierd!)

[Richard Jones]

[Steve Lamb]
> On Fri, 28 Jul 2000 11:17:31 +1000, Anthony Baxter <anthony at interlink.com.au>
> wrote:
> >Euw! No, the "oh, I know what you want that to be, I'll change it for you" i
> s
> >my #1 all-time perl hate. 
> 
>     Why?  Has it ever messed up?  It does exactly what you tell it to unlike
> the babysitting languages that barf with "Oh, you don't know what you're doin
> g
> so I won't let you do it."  
> 
>     Before you answer know the difference between it messing up and /you/, as
> the programmer, messing up.  
> 
> [snip]
> 
> >Particularly when combined with magic linenoise - use the wrong bit of
> >linenoise, and suddenly your large complex datastructure is an int. Yaaay.
> 
>     The above example applies here.  Once you know what is going on it is all
> fairly straight forward.  BTW, your large, complex datastructure isn't an int
> .
> There is no int unless you use int(), just like in Python, or try to stuff it
> into someplace that expects something that could be called an int, in which
> case it is your fault as a programmer, not the languages, and has nothing to
> do with the symbols.

  Uh, no, your large complex data structure can easily converted into an int 
(or just the last element in the structure if the situation is slightly 
different) if it's referred to in a scalar context accidentally (in some cases 
by getting the line-noise wrong). Yes, that would be the programmer's fault - 
but the point here is that Perl's an overly complex language that allows too 
much freedom to fuck up a complex program dealing with complex data structures.

  Programming is about being explicit in telling the computer what you want it 
to do. When a subtle variation in your code radically changes the outcome, 
that's annoying as hell to a programmer. And the problem being identified here 
is that Perl has hundreds of these subtle variations built in that radically 
change the outcome of a program - not to mention not being obvious in some 
cases like:

    $a = \($x, $y, $z);

 ... you'd think that was equivalent to:

    @a = ($x, $y, $z);
    $a = \@a;

 .... or,

    $a = [$x, $y, $z];

 ... but it isn't, it's really:

    $a = (\$x, \$y, \$z);

... which is _of course_ equivalent to:

    $a = \$z;

... and the killer being that it's different to:

    @a = \($x, $y, $z);
    $a = scalar(@a);

... as one would perhaps expect (yes, scalar behaves differently in different 
contexts!).

   Yeah, that's a good language at work there.

   I've now got 2 years of experience in developing Perl _applications_ using 
complex Object Oriented (hah! OO! hah!) data structures. I'm leaving this job 
now in frustration and working in a Python development house. The killer is 
that I'm interviewing a lot of programmers trying to hire a new Perl 
application developer - and I'm rapidly forming the opinion that they're a very 
very rare breed (if they exist at all). That is, people who say they can write 
Perl applications and can actually understand some of the issues in 
manipulating complex data structures in Perl and not just writing 100-500 line 
CGI scripts. That's not application writing kiddies, that's just hacking shit 
together and calling it a program. And code re-use isn't just copying the first 
fucking half of the script to the next one you write. I honestly believe that 
Perl is creating a very dangerous breed of undisciplined programmers, and I'm 
worried.

   And Perl OO. Hah! There's maybe ... what, 0.000001% of the total Perl 
population who have ever written a class package? And maybe 0.01% of them who 
can do anything beyond bless $data, $class; where $class only has functions? 
That is, they've read Conway's book and knew more than a tenth of it before 
reading it?


        Richard