?

Log in

No account? Create an account

The Perils of Perl, Do we need to take away your keyboard?

« previous entry | next entry »
May. 6th, 2007 | 09:08 pm

I love this stuff:

http://avatraxiom.livejournal.com/58084.html

... and frankly I am not going to be as eloquent as Chromatic:

http://use.perl.org/~chromatic/journal/33191?from=rss

Yes, PERL MADE ME WRITE BAD CODE.

The concept that a language makes you write bad code, or difficult code to maintain, is just bizarre.

Ok, if the programming language required you to only use i, l, and 1, as variables I might buy it... but for some reason, which I can clearly articulate over dinner if you are buying, I don't really see perl as the limiting reason.

Perl does not prevent you from setting up coding standards, writing good comments, or structuring the layout of ideas such that someone else can not follow what you did. Nor does it require your program to dump core to stdout and print "redrum, redrum".

That would be a nifty easter egg though.

MySQL could use a few more...

And if I had any artistic skills what so ever this post would have a 1950's style horror cartoon with big "Beware of Perl" title, but I don't and when I went looking in Google Images for the pictures I got lost in a link feast of nifty comic art.

Link | Leave a comment |

Comments {13}

NBarnes

(no subject)

from: nbarnes
date: May. 7th, 2007 04:24 am (UTC)
Link

75% of the differences between C and Ruby is that Ruby forces you to do about 50% of what you should have been doing in C all along. The other 50% of what you should have been doing all along Ruby still doesn't force you to do. *coughCOMMENTScough*

Most of the rest of the differences are syntax streamlining, which is wonderful, but irrelevant to the point.

Reply | Thread

Dreamer of the Day

(no subject)

from: iamo
date: May. 7th, 2007 05:52 am (UTC)
Link

I don't know, I find even the most well structured Perl code (say, for example, LiveJournal's) to be difficult to read. But I'm not as good with the code reading in general as a lot of other coders are. When I buy a book on coding, I read the text and not the examples. I still find it more difficult than other languages though.

C would be my most readable by far. Everything is so plain and linear.

Reply | Thread

Brian "Krow" Aker

(no subject)

from: krow
date: May. 7th, 2007 06:47 am (UTC)
Link

I've seen a lot of C code which made heavy usage of function pointers that turned out hard to read.

Was it the fault of the language?

No, more like it was not very well documented how the function pointers got set.

Reply | Parent | Thread

Dreamer of the Day

(no subject)

from: iamo
date: May. 7th, 2007 07:49 am (UTC)
Link

Obviously there are degrees of readability within any language, including C. But it is, imo, a fair bit more complicated than a perfectly relativistic scale.

I think there are different ways of thinking about code and different languages lend themselves to those different ways of thinking.

For example, I find functional languages like Haskell and Lisp to be downright unlegible, but there are clearly people who find them the easiest to read.

Add in to the mix that certain problem domains will probably attract certain types of thinkers, and I think that it's definitely fair to say that certain languages will tend to have poor readability to certain tasks in general. Exceptions abound as with anything, of course.

Reply | Parent | Thread

Christy

Readable C

from: spristy
date: May. 7th, 2007 02:09 pm (UTC)
Link

I distinctly remember looking at someone's C code where they had named a variable momentaryLapseOfReason.

I asked the guy what that was all about, and if I remember correctly, it was because the variable was used as a tokenizer or parser or whatever, and sometimes it didn't parse the tokens just right, even if there was nothing wrong with the input, so that was what the variable was named.
After this, I find Perl quite readable.

Oddly, despite being a Java developer who can write C under duress, I find C++ to be cryptic most of the time.

Reply | Parent | Thread

Brian "Krow" Aker

Re: Readable C

from: krow
date: May. 7th, 2007 04:14 pm (UTC)
Link

Now I have to wonder if that person was me... since a decade or so ago I was very likely to name a variable with its problem if I was debugging several problems... (an odd habit that has gone the way of the do do with more unit testing).

Reply | Parent | Thread

Christy

Re: Readable C

from: spristy
date: May. 9th, 2007 05:53 pm (UTC)
Link

Wonder no more!

It was Geomorphology code, of course. It read in comma-delimited files as I recall. It was a rather unsettling variable name at the time.

Reply | Parent | Thread

Brian "Krow" Aker

Re: Readable C

from: krow
date: May. 9th, 2007 08:43 pm (UTC)
Link

Oh.. that was when we reverse engineered ARC/INFO files for some project. Whenever that variable had data in it, an ASSERT would be set and the program would bail.

Reply | Parent | Thread

Roy Corey

My take on this.

from: xerhino
date: May. 7th, 2007 02:13 pm (UTC)
Link

I'm sad to say I mostly agree. Sad because I've been writing perl for probably 10 years, off and on, and I'm in love with it. Perl is the flexible and curvaceous mistress of the coder and sysadmin, but for large, complex projects it feels unwieldy. Even the perl greats like Randall Schwartz have code that takes me way too long to figure out even when I already know what it does. That's mitigated by adherence to standards like the "perl best practices" advice by Damion Conway, but too few people actually code to any standard. Sloppy code is, many times, avoidable and not the real issue. I think the author states that perl is good for a lot of scripts and system administration.

When programs become large and complex, however, even good style can't keep up with good consistent, logical, built in object orientation. OOP in perl feels like OOP in C. It can be done and it's not super complex, but it isn't natural either. Perl OOP articles have sections on how to trick perl into doing what you want such as making object internals private: you create inside out classes and anonymous hashes or you scramble the names of the internal variables outside of the class namespace so no one can find them. Yikes! I think my epiphany came when I was writing (attempting to write) an object oriented asynchronous event handler. I had some abstract classes thought out and started to code them and thought "Jeez, this would be easier in C++". At that point I dusted off a Python book that had been sitting unread for too long and started in on it. I hear good things about Ruby too, so that's next.

May I ask: when you aren't coding in lower level languages like C or C++ what scripting language(s) do you use?

Reply | Thread

Roy Corey

Re: My take on this.

from: xerhino
date: May. 7th, 2007 02:45 pm (UTC)
Link

Before anyone misinterprets that. I still use perl all the time. I just came to my own conclusion that perl isn't right for everything. In my case it's big OOP stuff.

Reply | Parent | Thread

Brian "Krow" Aker

Re: My take on this.

from: krow
date: May. 7th, 2007 05:34 pm (UTC)
Link

I find perl OOP works pretty well, and I have tried to keep large perl projects on track by using OOP concepts (even when I write C code, it is fairly OOP like).

Reply | Parent | Thread

Brian "Krow" Aker

Re: My take on this.

from: krow
date: May. 7th, 2007 04:05 pm (UTC)
Link

For scripting I do 90% perl, an odd bash shell script here and there, and Python if I need a specific library or two.

I tend to use languages based on what libraries are around.

Reply | Parent | Thread

Max

(no subject)

from: avatraxiom
date: Jul. 24th, 2007 06:08 am (UTC)
Link

You might be interested in the response thread on chromatic's post, and also my two responses elsewhere, which are also somewhat clarifying. We had some interesting conversations, myself and a few folks who blog on use.perl.

And for reference, Bugzilla currently isn't moving away from Perl, although it was an extremely enlightening research process.

-Max

Reply | Thread