Can Lisp do What Perl Does Easily? | Hacker News Reader

Can Lisp do What Perl Does Easily?

groups.google.com

25 pointsomouse45 comments

Erik Naggum on why Perl sucks :D

Note the date. In 2000, Perl was, by far, the leading scripting language (and language for the web). I'm certain that if this rant were written today, it would target PHP, and possibly even Ruby and Python. Ironically, perhaps, modern Perl is more lisp-like than any other mainstream language (aside from JavaScript, in some ways), and so this article merely says, "Mainstream languages that come pretty close to Lisp are brain-damaged and you'd have to be a particular breed of crazy to use it for anything."

I love his rant. There are so many colorful expressions in it that even if you don't agree with what he says, you can enjoy how he says it.

Here's another my favorite, Erik on C++, from 1998: http://groups.google.com/group/comp.lang.lisp/msg/917737b7cc...

Awesome. He's convinced that using a language (C++ or Perl, depending on the rant in question) can cause damage to ones cognitive processes! He is a colorful one.

I'm pretty sure I'd feel dumber after having worked in PHP for the past six months on our new website, if that were true.

No, if you were succumbing to the trap he described about Perl, then you would feel smarter for having solved so many immediate problems.

"I actually think C++ is ideal only for programmers without any ethics."

This guy is a little bit extreme.

and so this article merely says, "Mainstream languages that come pretty close to Lisp are brain-damaged and you'd have to be a particular breed of crazy to use it for anything."

Wrong. This reddit comment nailed it: http://programming.reddit.com/info/2mm0n/comments/c2mo30

Erik's argument is that Perl incentivizes The Wrong Way, and disincentivizes The Right Way. It's not about coercion, it's about incentives. "it's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done." --jemfinch

"Wrong."

Very concise. And it's always good to back it up with the assertions of some random dude on Reddit.

The assertation is backed up by a quote from the original post by Naggum. I said "wrong" because you somehow missed that part of his post. He was not saying that Perl is wrong because it has some of Lisp's features. He was saying that it is wrong because it allows shitty work. In fact, it encourages it by making it harder to write good solutions.

Someone (Perl) can be beautiful (Lisp features), but that doesn't change the fact that they wear dirty clothing (ugly syntax) and they smell kind of funny (ugly solutions).

"The assertation is backed up by a quote from the original post by Naggum."

An ill-informed rant from a crank is not the same as "backed up".

"Someone (Perl) can be beautiful (Lisp features), but that doesn't change the fact that they wear dirty clothing (ugly syntax) and they smell kind of funny (ugly solutions)."

We all have our preferences.

While you can quote your favorite usenet crank from years ago, I can quote one of my favorites about Lisp (doesn't mean Lisp isn't a great language for many tasks...this quote just makes me laugh every time I read it):

"Lisp has all the visual appeal of oatmeal with fingernail clippings mixed in." --Larry Wall (larry@wall.org)

Smart people can disagree on many things. Programming languages are no different.

>An ill-informed rant from a crank is not the same as "backed up".

Omouse isn't (directly) asserting anything about perl. He's making assertions about Naggum's assertions. For that purpose, the ill-informed rant in question is an excellent source of corroboration.

> In 2000, Perl was, by far, the leading scripting language (and language for the web).

It still is (excepting PHP)

http://www.tiobe.com/tpci.htm

In what ways is Perl Lisp-like?

The more I learn Lisp, the less it seems like Perl at all.

Perhaps learning more Perl would solve that problem.

Perhaps you could give me a brief summary (a few sentences) about what you mean regarding Perl's similarly to Lisp. I may simply be paying attention to different things.

In the meantime, here are a few of the differences I've observed:

Perl flattens lists by default.

All subroutine parameters are passed via @_, resulting in an imperative-style parsing of variables at the beginning of every sub.

A perl program is a file of perl statements, a lisp program is a lisp list of expressions.

Perl has contexts.

(edit) Also, Lisp reserves almost no characters. I can use square-bracket as a symbol name if I want.

"Perl flattens lists by default."

Perl has several data types. You can get all the unflattened goodness you want by passing array refs. We do it all the time in our code. It's merely syntax.

"All subroutine parameters are passed via @_, resulting in an imperative-style parsing of variables at the beginning of every sub."

Likewise, pass an array ref, and you don't fiddle with parsing @_. TMTOWTDI.

(Note that I'm not suggesting passing array refs for everyone or all subroutines...it's just a somewhat lispy way of thinking. In OO development, a more "imperative-style" is appropriate, and we use that too.)

"A perl program is a file of perl statements, a lisp program is a lisp list of expressions."

OK. Wonderful. Nonetheless, you have first-class functions in Perl. Currying is possible (and not terribly ugly) in Perl. Closures exist in Perl.

Macros do not, yet, exist in Perl 5. But they exist in Perl 6. That's the only significant gap I'm aware of (where "significant" means, "a concept that cannot be replicated in the language without huge, long-winded, hacks"). Syntax is arbitrary, and smart people can disagree on what good syntax looks like. Power is a bit more tangible, and on the power continuum Perl holds up just fine.

"Perl has contexts."

So? Merely syntax.

"Also, Lisp reserves almost no characters. I can use square-bracket as a symbol name if I want."

Again, so?

I'm talking about power, you're talking about implementation and syntax preferences. You may feel that the beauty of Lisp is in the details, and that's wonderful. I think Lisp is nifty, too. But, there is also beauty in speed of development, and nothing is faster to develop than already written code. Perl has the largest collection of free pre-written functionality of any modern language in CPAN. It also happens that for my problem domain (system administration automation) Perl is effectively already a nearly ideal DSL.

For me, built-in grep and map and file tests and operations and regular expressions and taint mode and efficient hash tables and native Unicode and cheap enough concurrency and lots and lots of libraries are all killer features and Perl has all of them. Sure, Lisp has a better map, by some definition of better, and I can pull in a regex library and probably a POSIX file library. Erlang has better concurrency by all definitions. Other languages are strong in other areas. But nothing has them all...except Perl.

The nice thing is that we can both use our favorite languages for anything we want. I will never come over to your house and force you to write (or read!) Perl code. I promise.

I do think folks are missing out on some interesting ideas by closing their eyes and going "neener neener neener neener" with fingers in their ears every time someone mentions Perl, but that's no business of mine.

I'm mostly trying to figure out what the essential qualities of Perl are such that you consider it more lisplike than any other language. I have in fact been trying to avoid making value judgments about either language (though I have complained about Perl in the past, and I understand the original author makes some absurd criticisms).

So: I have specified a few things that, to me, seem remarkably different from Lisp. In some cases, such features are more cumbersome or less flexible. In others, such as the reserved characters, there is no clear winner.

That Common Lisp has few if any reserved characters gives me lots of freedom to change how my program looks. In my example above, I could remap 'funcall' to '&' and the result would look almost just like Perl. It means, though, that I have to be really careful not to do anything stupid lest my program be unreadable. Perl, in contrast, has built-in meanings for all sorts of punctuation. This often saves a lot of typing, and allows many ideas to be expressed succinctly without any extraneous configuration So Lisp is more flexible in a sense, but it's not immediately clear that this makes Lisp more powerful.

What I'm interested in, is how much different it is to program in lisp as compared to perl. The symbols thing seems minor in principle. But in practice, when coding in Lisp I find this flexibility leads to a completely different way of thinking. It's way too early for me to say whether one is better than the other, but the difference is remarkable.

merely syntax

Perl is full of syntax. There's syntax for everything, personally I think it's one of Perl's strengths. Lisp, in contrast, (usually) has very little syntax. It's orthogonal and consistent. (limited and static, if you'd prefer more negative connotations)

Some people do better memorizing huge number of details, others do better learning core rules and applying them to each case. In my first year of music theory, my professor took the "few core rules, consistently applied" approach to teaching voice-leading and almost everyone hated it. The first day of class next semester, my new professor handed out a voice-leading review sheet that was, front-and-back, covered with rules about what to do in a given context. Most people seemed to prefer it that way.

"I'm mostly trying to figure out what the essential qualities of Perl are such that you consider it more lisplike than any other language."

Not any other language. Merely any other mainstream language aside from possibly JavaScript (which is very nearly Scheme with C-style syntax).

It actually doesn't sound like we disagree on much other than what makes a language Lisp-like. ;-)

I'm primarily concerned with the "blub" and "power continuum" concepts that pg came up with. Any language lower on the power continuum is blub, and if you're only familiar with blub you can't see why a language higher up is more powerful. My basic assertion is that Perl has much more room below it on the power continuum than above it, with pretty much just Lisp (and other macro-capable functional languages) being clearly above it. Perl 6 introduces macros, so the picture changes a little bit come Christmas (or whenever the first Perl 6 is released).

And, I agree that syntax is a huge gaping difference between Lisp and Perl. But Lisp is hugely different from all other mainstream languages in that regard, as well, so it has to be canceled out, as far as I'm concerned. So, once syntax as a difference in removed, all you have is "what concepts can you implement readily in this language", and Perl has pretty much everything except macros. Most other mainstream languages are missing some number of others.

http://www.paulgraham.com/icad.html

Scroll down to Appendix: Power.

The Perl solution is close to the Lisp solution in terms of brevity. The solution in other languages tend to be longer or the problem can't be solved at all.

Choice quote:

"In the rivalry between Perl and Python, the claim of the Python hackers seems to be that that Python is a more elegant alternative to Perl, but what this case shows is that power is the ultimate elegance: the Perl program is simpler (has fewer elements), even if the syntax is a bit uglier."

Defining a function is only the first step. Generally, one defines a function so that it can be called. With perl, you have to use an extra symbol to specify that you're calling a function, where Python infers it if you put a parameter list. Common Lisp lets you do it either way.

Here's a hypothetical Python:

    mana=foo(100)
    mana(-10)
    mana(-15)

Here's Perl:

    $mana=foo(100);
    &$mana(-10);
    &$mana(-15);

Common Lisp:

    (setf mana (foo 100))
    (funcall mana -10)
    (funcall mana -15)

Also Common Lisp:

    (setf (symbol-function 'mana) (foo 100))
    (mana -10)
    (mana -15)

For Web stuff, I pretty much exclusively program in Perl and JavaScript when left on my own. I like both a lot. I really don't get the anti-Perl reputation as portrayed in this article, although as noted it is really old. Maybe it's just my Perl code, but I can pick up code from 10 years ago and understand it fine, and my Perl code never seems to gets out of hand as described in this rant. You always have wonder with rants what the author was actually doing...

I don't think any particular language causes brain damage like some more strongly-opinioned people would say. But some make it easier to write nutty code. It doesn't mean everybody writes nutty code.

Just like how being surrounded by junk food predisposes you to poor dietary habits and possibly in consequence, heart problems, it's not impossible to eat healthy and stay fit.

Shunning the environment/language/tool is understandable, but equating it to the root of the problem always involves some exaggeration. The NASA code released not long ago had GOTOs in it and I don't think it costed lives.

The author of that rant is a purist. He believes that if everyone would slow down, learn Lisp values and implement them in their code, so that eventually they, and perhaps more importantly the next generation will be far better able to focus on essential difficulties rather than incidental ones.

His argument is that perl programmers are all busy solving immediate problems that would have never been problems to begin with if everyone had been using Lisp the way it was meant to be used. And they're often not solving problems in Lisp-fashion.

The only concrete assertions I see there are that regular expressions are error-prone (fine, if you really think so, don't use them), and that data in Perl aren't s-expressions (I'm assuming that's what he's ranting about when he's implying that all Perl is good for is massaging input formats).

So pretty weak: CPAN is the supreme, far-and-away, no-other-reason-or-language-comes-close (at least in 2000) to use Perl.

Yes CPAN is perl's best kept secret. There's still nothing to touch it.

These ranters never actually show you any perl code that is particularly ugly and compare it against some lisp/python/ruby code that solves the problem more cleanly.

I'm sure that there are areas where other languages' solutions are much cleaner than an equivalent perl one, but can anybody actually show us one? Especially a lisp one.

pg wrote a few in an essay. (And, unremarkably, though I'm going to remark on it anyway, Perl stands up as well as any other mainstream language to the onslaught. Perl 6 does even better, though I think one of the biggest side effects of Perl 6 is going to be a huge influx of Haskell coders because of Pugs.)

And when will be Perl 6 ready?

The day before Arc comes out.

Heh, that's a good one :D

Possibly by Christmas. Many of us are already using it with Pugs.

Wow not a single example!

Wow - I use a lisp, but this argument is awful. Saying you can really quickly whip up something that works in Perl is an overwhelming recommendation. That the subsequent code in unmaintainable is a relatively tiny disadvantage.

From the linked-to post: "...the language rewards idiotic behavior... you can commit any dirty hack in a few minutes in perl, but you can't write an elegant, maintainabale program..." Sound familiar? That's the mating call of statically typed language programmer and the top-down 'software architect'. That's bad. And I'll admit, Scheme's libraries (I use Scheme) are in practice somewhat statically typed and fussy, which sucks.

I've never used Perl - maybe I should. BTW, is Ruby really just as good for quick 'duct tape' work and hacks? My very limited experience with Ruby made me think it was good, but not extraordinarily handy.

He sounds a tad disgruntled about his past jobs. He didn't answer the question "can lisp do what perl does easily?" because the answer is no: http://weitz.de/cl-ppcre/

the unemployed programmer had a problem. "I know", said the programmer, "I'll just learn perl." the unemployed programmer now had two problems.

One of the best programming quotes. Ever.

It was better the first couple hundred times I heard it.

Jamie Zawinski's from 1997 is the most famous in modern times:

"Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems."

But, it dates back even further to a "D. Tilbrook" from before 1988:

"Whenever faced with a problem, some people say `Lets use AWK.' Now, they have two problems."

There's an XML variant that had quite a lot of popularity in the early 00's.

It's funny because they're all accurate. XML is an ugly beast, regular expressions can be amazingly obfuscated. I don't know about AWK, but I'm guessing that it's as ugly as Perl.

AWK is no where near as complicated as perl. It'll probably take someone 1/2 hour to figure it out.

Brian Kernighan created Awk. And who are you again?

You've misunderstood the fundamental UNIX nature of these quotes. They are said by people who use the tools in question regularly. jwz doesn't avoid regular expressions for everything (he'd be a fool to do so, and he's no fool)...he's merely pointing out that regexes can be misused, and often are. Likewise Awk.

By cloistering yourself into Lisp, and nothing but, you're missing out on years of aggregate wisdom from some of the smartest people in computing. Lisp is one of those really valuable pieces of wisdom. But it is not the only one, or even the most important. Deny yourself the rest of the history of computing, and you are doomed to reimplement it...and you'll almost certainly do it poorly.

This applies more to lisp than perl. More likely to be unemployed if you only know lisp. Not many companies use lisp. A lot of them use perl (though this is changing to ruby and python).

'Maintainability' is the last refuge of the fussy language.

The date should really be noted in the title of the post.

Why?

Because the ranter was pissed that his favorite language was not very viable commercially, and a language he strongly dislikes was the most popular language on the web, with many job opportunities. Bitterness colors his logic.

Two reasons: First, everything has context and time is often a big part of it. Setting that context up for people is helpful. Second, this site is entitled Hacker News and this is not News. While people will argue old things should still be included, and that's fine, I think old things should at least be marked as such by putting the year of publication next to them.

Reply on news.ycombinator.com