Hacker News Reader

Comment by jqm | Hacker News Reader

"100 year language..."

God I sure hope not. (Only if it's a lot easier to maintain than Perl 5 maybe...)

I have bad feelings about Perl after having to parse and cleanup a bunch of abominably written multi-thousand line pages full of regular expressions and all manner of cleverness. I mean, I actually hated Perl so badly I believed it was the worst invention ever. Then I saw a well written project and was easily able to understand and felt slightly less negative. So it's not entirely the language, but to this day seeing 'Perl' brings negative emotions to the surface. Something like PTSD I guess. It will probably take 100 years for that to go away and me to willingly look at anything called 'Perl'.

View on HN

Believe me, I've seen bad Perl[1]. Luckily I was already very familiar with Perl, so I was able to discern that the developer was just batty.

1: Global variables everywhere. Every function call did not pass arguments, but instead they assigned data to global variables in the immediately preceding lines, called the function, and then used those global variables. Copious use of SQL where every query was saved in a variable called $stmtA, $stmtB or $stmtC, depending on how many levels of sub-querying needed to be done in a loop. Obscure variable names in general. Zero comments. No use of modules, everything in one flat text file (for 5-10 or more flat text files), no code reuse. PHP used in the same project, to the same standard (one large sprawling multi-thousand line PHP file). This was an open source project, and to this day I wonder if possibly it was all a purposeful design decision, so they could charge for development requests.

Personally, I think a lot of the bad Perl code people have had to deal with relate back to three things.

a) Many of people writing the code were sysadmins that just needed to get a job done, and didn't have much real development experience.

b) Perl was also easy to get access to in cheap shared hosting environments, so it attracted other people without some development discipline.

c) Perl4 did not have objects, and scoping was limited to local(). Thus, lots of spaghetti code and global vars.

However, none of that would have gotten exposed to developers if their teams had decent interviewing techniques, or code review, etc.

All that to say that Perl 6 shouldn't have the same propensity for bad code to end up in a real project. Any more than any other language that is. I can certainly misuse regexps, lambas and other features and write some hard to maintain Python.

100 year language might be meant seriously by some people, but I meant it as something that has enough powerful concepts to stay relevant for a long time.

It harks back to Paul Graham's essay where he started off on Arclisp as a 100 year language and better designed lisp. Other priorities came up and it didn't really go anywhere besides maybe being used for this website. Hopefully Perl6 doesn't suffer a similar fate.

Reply on news.ycombinator.com