Live data from Hacker News

Not Lisp again (2009)

funcall.blogspot.com

21–30 of 276 posts

Re: Not Lisp again (2009)

#21
post #14

Yeah, but it's goddamned ugly and unreadable. It considers repetition to be a design feature . If you're going to sell people on the benefits of functional programming, I think you should really be pushing more for SML or Haskell or something like that.

That's a pretty subjective opinion... I don't have much trouble with lisp but Haskell makes my eyes bleed. Of course I'm not a Haskell programmer, so it stands to reason that those who are find its syntax enjoyable.

To each their own...

Re: Not Lisp again (2009)

#22
post #14

Yeah, but it's goddamned ugly and unreadable. It considers repetition to be a design feature . If you're going to sell people on the benefits of functional programming, I think you should really be pushing more for SML or Haskell or something like that.

[deleted]

Re: Not Lisp again (2009)

#23

The objections the author had way back in the day are no longer the objections programmers of mainstream languages have to Lisp today. Today the objections I hear are more along the lines of: 1 - All those parenthesis. (Still a top objection) 2 - Lisp doesn't look like or work like what I'm used to. 3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages. 4 - There aren't nearly a…

Yeah, back when I tried Common Lisp #3 was a stumbling block. I hear Clojure solves that problem pretty well, maybe because it's a little more mainstream than other lisps and also because my understanding is it's pretty easy to work with existing Java libs from Clojure.

Re: Not Lisp again (2009)

#24

The objections the author had way back in the day are no longer the objections programmers of mainstream languages have to Lisp today. Today the objections I hear are more along the lines of: 1 - All those parenthesis. (Still a top objection) 2 - Lisp doesn't look like or work like what I'm used to. 3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages. 4 - There aren't nearly a…

You left out a rather glaring objection:

7 - Lisp has a tendency to lure programmers up the river of insanity [0] due to the sheer power of macros (particularly reader macros). This can leave the rest of the team (or any successors) struggling with a mountain of technical debt. Overall, I think the power of Lisp makes it difficult for a community to organize without a BDFL to keep everyone on the same page.

[0] http://tvtropes.org/pmwiki/pmwiki.php/Main/RiverOfInsanity

Re: Not Lisp again (2009)

#25

The objections the author had way back in the day are no longer the objections programmers of mainstream languages have to Lisp today. Today the objections I hear are more along the lines of: 1 - All those parenthesis. (Still a top objection) 2 - Lisp doesn't look like or work like what I'm used to. 3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages. 4 - There aren't nearly a…

1) You can become familiar with the parentheses. One might say, "all that white space" about Python, but that doesn't make Python any less powerful a language.

2) It does not look like what you're used to, but it certainly can work like you're used to since it is a multiparadigm language. Of course, programming Lisp like you program C or Python loses a lot of the power.

3) As a Lisp programmer, this is my biggest gripe.

4-5) True. If you aren't a contractor/freelancer that can choose your tools, Lisp is a hard sell.

6) Lisp is ancient. That said, the rest of the programming world has yet to catch up to the some of the concepts in Lisp like conditions or CLOS. Many of the "advances" in the new shiny languages have been in Lisp for decades.

Re: Not Lisp again (2009)

#26

I'm having trouble understanding why the derivative example was so impressive to the author. Can someone explain? It seems trivial to do in any language where functions are first class citizens.

Probably hadn't thought of passing a subroutine address to a routine in z80 machine language he was familiar with?

Re: Not Lisp again (2009)

#27

The objections the author had way back in the day are no longer the objections programmers of mainstream languages have to Lisp today. Today the objections I hear are more along the lines of: 1 - All those parenthesis. (Still a top objection) 2 - Lisp doesn't look like or work like what I'm used to. 3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages. 4 - There aren't nearly a…

Learning lisp or functional programming is more of a conceptual experience than a practical one.

That is not to say it is not practical to learn lisp, but the state of the programming world as it is today makes it so that it is less practical to learn lisp than it is to learn about say something like java.

Re: Not Lisp again (2009)

#28

I'm having trouble understanding why the derivative example was so impressive to the author. Can someone explain? It seems trivial to do in any language where functions are first class citizens.

> I'm having trouble understanding why the derivative example was so impressive to the author.

Says someone 35 years later. :)

Probably every (commonly found) derivative example, and the majority of languages with first class functions all come from this example.

MIT introducing Scheme and those two professors writing SICP are a large part of the reason for the current functional programming landscape. Without them I believe they'd still be as niche as APL.

Re: Not Lisp again (2009)

#30
post #14

Yeah, but it's goddamned ugly and unreadable. It considers repetition to be a design feature . If you're going to sell people on the benefits of functional programming, I think you should really be pushing more for SML or Haskell or something like that.

Unreadable? Personally, I think that Lisp has the clearest possible syntax - because it basically doesn't have any. It's just straight ASTs - something that I have to visualize myself in other languages wich have more syntax sugar.

Lisp has the minimal syntax for lists:

    (a b c d)
where other languages require separating commas, but Haskell has minimal syntax for function application:

     f x y z
with no parenthesis needed. (Technically, this is a triple application ((f x) y) z, masked by the convention of application being a left-associative binary operator.)
Post reply on HN