Comment by drblast | Hacker News Reader

Comment by drblast | Hacker News Reader

Lisp is my happiness language, and everything else isn't. So for me there are really two types.

Every language that's not Lisp, while obviously inferior, usually has some domain-specific use.

I do get a huge kick out of C and assembly when I get the chance to do something low-level. It's a lot of fun to get in there and make something totally non-portable that runs 1000 times faster than the equivalent C++ program.

Getting small things done quickly used to mean Perl, but recently I've started to use Lisp for short scripts because Perl's built-in data structures are so poorly implemented. Last week I was playing around with parsing huge volumes of U.S. census data, which should have been Perl's bread and butter, but ten lines into the Perl script I missed map and nested lists so I switched to Lisp and was done in short order.

I've done a few things with Python, but nearly every design decision they made early on rubs me the wrong way.

I like Javascript for the same reasons I love Lisp. I have a feeling I'd really like Haskell if I could find the time to learn it fully.

And then there are the languages I consider to be abominations, like C++ and Java. Still, they have some great IDE's and libraries which make up for the language in some cases. I haven't gotten around to C# or F# yet. I don't know if I want to.

There are so few honestly awful programming languages. I have been forced to use a few, including Visual Basic for Applications, Matlab script, and a few other proprietary domain-specific languages that I've long since forgotten.

So three languages? Pssh. Learn as many as you can, enough to complete a useful project or two in each. After you do that, you'll realize that Lisp is the best by far and you've wasted most of your time. But at least you'll KNOW.

How did you miss map when Perl has it? Also, when you say Perl's builtin data structures are poorly implemented, are you referring to the necessity of refs to do lists of lists and other nested structures or something else?

Perl doesn't have it. It has an imitation. Since perl can't do lists of lists (you have to use what it calls "refs") if I do something like:

my @list2 = map { ($_ . '', $_ += 0) } @list;

I wont get a nice list of pairs but just one flat list. This is a silly limitation to have to think about when you're used to proper high level functional languages.

  >>Perl doesn't have it. It has an imitation. Since perl can't do lists of lists (you have to use what it calls "refs") if I do something like: my $l = map { ($_ . '', $_ += 0) } @list;    I wont get a nice list of pairs but just one flat list. This is a silly limitation to have to think about when you're used to proper high level functional languages.

Well, you won't get a flat list either since you're calling map in a scalar context :) I don't see how the necessity of doing

  my @l = map { [$_ . "", $_ + 0] } @list;

rather than

  my @l = map { ($_ . "", $_ + 0) } @list;

is a problem with map rather than a problem with Perl's arrays and lists only being able to contain scalars.

Rats, you caught me before the edit. I thought I got away with it. Perl is actually (unintuitive) a strongly typed language, which is what caught me.

>I don't see how the necessity of doing...

Because I'm used to being able to have lists of lists and now I have to deal with "refs" everywhere. In creating, in getting the values. The given example doesn't highlight it, but imagine in instead of the simple anonymous function given there the call to map called a function that returns a list? I have to remember to turn that into a "ref" or change the function to look at context and return a "ref" itself. I may not own the function in question.

The point is that these are all artificial problems that the programmer shouldn't have to give any thought to. You don't have to in Python. Not in Ruby. Not in Lisp. The only language I have to deal with this kind of limitation I can't think of off the top of my head is C (even C++ can handle lists of lists).

>>The point is that these are all artificial problems that the programmer shouldn't have to give any thought to.

Yeah, the references of Perl sucks. Just has to be learned.

The Perl feature is that it is flexible. You'll get more library and language capabilities with CPAN than using anything else I know of.

The disadvantage is that you have to learn quite a bit of extra stuff. It is the natural language inspiration shining through (not a mathematically elegant and minimal notation, exactly :-).

I don't have three languages anymore; just now I only do Perl. This is a choice I made, because it is fun.

(I consider going functional again, next. Or, if the Android competition don't work out, maybe Objective C.)

>Yeah, the references of Perl sucks. Just has to be learned.

But this is part of the larger point: it doesn't have to be learned. Just use something else that doesn't have this frustrating design flaw.

>The Perl feature is that it is flexible.

As opposed to, say, Lisp? CLOS, the most powerful OO system in existence [1] and it was initially just a library on the language. When people say things like this about perl they're usually talking from '98 or so when perl was the most flexible game in town. A lot has changed since then.

>You'll get more library and language capabilities with CPAN than using anything else I know of.

Java has more libraries, hands down. I'd say most common programming languages cover every use case that 99% of programmers will encounter, so CPAN/Java libs are only the only hope for a small amount of people in a very small amount of situations.

>It is the natural language inspiration shining through

You mean the English inspiration shining through. A lot of the ambiguity problems we have in real life (faithfully replicated in perl for us!) are a bigger problem in English than, say, German.

>This is a choice I made, because it is fun.

To each his own. I would try out some of the more advanced languages though. Lisp has some really cool things like the condition system [2], with Haskell you can easily play with infinite sequences, an incredible type system, etc.

>Or, if the Android competition don't work out, maybe Objective C

I would advise learning Smalltalk first and playing with that. It's a purer implementation of what you'll be doing with Objective C so it will help you learn good behaviors when you are ready to do some iOS programming. The Smalltalk image is also a fascinating concept.

[1] If you disagree, point me to one that is more powerful. And the way I'm judging power is by how many patterns I have to know to use it. In CLOS I don't even have to override a function and then call the base version, I can just use :before/:after methods.

[2] This is probably Lisp's nicest feature that hasn't yet been copied by mainstream languages. Which is a shame, software would be a lot more robust if it used this kind of system as opposed to the crippled exception system we use today.

>>[flexible] As opposed to, say, Lisp?

Nothing compares to Lisp there, really. Perl is probably closest of the modern ones. But I talked about those I know.

CL was a favorite when I studied, but has gone the way of my German and French... I don't know it anymore. :-(

Pity it lost out in the market place. Today, CL has too bad library support, afaik.

[Edit: I don't know much about the Perl 6 macro system, but it seems harder to use than CL macros. Hard to make it as neat, for a roughly Algol-like language like Perl.]

>>CLOS, the most powerful OO system in existence

It was more or less copied in Perl's Moose.

I wrote "You'll get more library and language capabilities with CPAN than using anything else I know of."

And got the counter example "Java".

Afaik, you don't get language extensions like a new OO system in Java...?

So after comparing with CL for flexibility -- you compare amount of libraries with a system language, with roughly half the development speed (and a lot more pain) compared to scripting languages and Lisp...?

>>You mean the English inspiration shining through.

Oh, please... that was irrelevant bashing.

I take your point re Smalltalk, I've only read about the language.

Edit: Fixed syntax, clarity.

>Perl is probably closest of the modern ones. But I talked about those I know.

I'm not convinced. :)

>Pity it lost out in the market place.

The games not over yet. Clojure has been coming on strong lately.

>Afaik, you don't get language extensions like a new OO system in Java...?

You're running into a "good is the enemy of the great" issue here. Perl probably has Moose because the "OO" it comes with it is awful. Java actually has a pretty workable OO system right out of the box, so no one is willing to go to the trouble to put something even better on when they could just write more code with what they have. I'll give you that modifying the language is easier in perl if you need to.

>So after comparing with CL for flexibility -- you compare amount of libraries with a system language, with roughly half the development speed (and a lot more pain) compared to scripting languages and Lisp...?

The point of that example was purely to counter the oft claimed "CPAN has more libraries than any other language!". It's not true, though the libraries it has might be easier to find than some.

>Oh, please... that was irrelevant bashing.

I just get tired of hearing about Larry's supposed linguist credentials. Perl has English behavior and it's amusing to me that a supposed linguist would pick language features that cause the most misunderstandings in real life! Why on earth would I want my programming language to be as prone to misunderstanding as spoken language? That's the exact opposite of what I actually want.

>>You're running into a "good is the enemy of the great" issue here.

Perl, as opposed to e.g. Java, has a tradition of being extensible; Moose is not the only example.

Common Lisp wasn't OO in the first silver book either.

>>counter the oft claimed "CPAN has more libraries than any other language!". It's not true, though the libraries it has might be easier to find than some.

Not what I wrote; I wrote "The Perl feature is that it is flexible. You'll get more library and language capabilities with CPAN than using anything else I know of."

You needed to go to Lisp (which sadly isn't really commercial today) for flexibility -- and Java for libraries. (And as you note -- I'm willing to believe there is more open source for Java, but finding it...?)

Re linguists -- you need to give exact examples of your claims for me to understand what you talk about. Compare with e.g. German, as you claimed there were some difference?

Etc.

    > In CLOS I don't even have to override
    > a function and then call the base version,
    > I can just use :before/:after methods.

that is possible in Perl, too, with method modifiers: http://search.cpan.org/~drolsky/Moose-1.19/lib/Moose/Manual/...

in fact, Moose took many ideas from CLOS (and Smalltalk, Ruby, Perl 6, ...)

you write:

    > When people say things like this about
    > perl they're usually talking from '98 or so
    > when perl was the most flexible game in
    > town. A lot has changed since then.

true, but don't forget Perl itself has changed a lot, too.

Yea, as I said, Moose looks pretty good. And I realize perl has changed itself. Today it looks like the biggest issue with perl5 is you need a page long preamble [1] to get a relatively modern language.

[1] Use statements to bring in the right libraries, turn off bad defaults, turn on needed features, etc. Stuff that is the default behavior in today's languages.

I agree with much of what you've said but every language is not inferior to Lisp. I would say Haskell is on par (in some ways superior).

The way I rate the power of a language is based on how many "patterns" you need when using it. For example, I find Smalltalk an extremely powerful language but it does have one weakness: dispatching on more than one type requires a pattern (e.g. double dispatch, visitor, etc.). CLOS doesn't have this limitation. But Lisp does have a pattern that Haskell doesn't have: delayed evaluation. Every time you need it you have to reach for a closure or a macro and each of these have design side effects (e.g. macros can't be used as first class functions). Haskell doesn't have this problem because delayed evaluation is how the language works by default.

Clojure has some lazy stuff but I agree that Haskell is better in some ways but Haskell has no cool makro-system.

It comes down to static vs. dynamic.

Haskell has a cool macro system : template haskell. So it comes down to typing.

When I said every language is inferior to Lisp, I meant that in the most tongue-in-cheek way possible :-)

Reply on news.ycombinator.com