Live data from Hacker News

The Failure of Lisp? A Reply To Brandon Werner

danweinreb.org

41–50 of 53 posts

Re: The Failure of Lisp? A Reply To Brandon Werner

#41
post #38

Earlier quoted context omitted.

People tend to boggle when I decry Lisp as being hopelessly low-level. Intriguing. I'm not really convinced by your example though. In the spirit of conciseness is power[1], can you provide a short program that should be formally expressible in a good enough language, but isn't concisely in Lisp? Or maybe your definition of low-level is different from mine? [1] That's the PG version, of course.

I don't buy that concision is power. This borders on a tautology, but expressiveness is power. Concision is part of that (a big part, even), but it's not everything. My only problem with Lisp is that it's exactly the sum of its parts - no more, no less. Everything decomposes into self-similar pieces, which decompose into other pieces, and on and on, turtles almost all the way down. This is wonderfully elegant, but al…

>I don't buy that concision is power. This borders on a tautology, but expressiveness is power. Concision is part of that (a big part, even), but it's not everything.

Yeah, I completely agree. I was going to write about it, but then figured it wasn't relevant to the question.

I'd love to discuss these old PG essays one day.

Re: The Failure of Lisp? A Reply To Brandon Werner

#42
post #25

Such a respectful reply. To judge by his writing, Weinreb is a genuinely nice man. I'm glad that he has taken on a (semi-) public role as Lisp advocate. I'm a recent (last 3 years) adopter of Common Lisp who works in it every day. To me Lisp is hardly a failure, it's a secret weapon. For example, a couple of weeks ago I had occasion to take a complex chunk of CL code and make it compile into Javascript as well (I nee…

Thank you for the kind words!

I don't think that Brandon Werner said that Lisp was a failure as a language. As I read it, he's saying that Lisp has failed to capture a lot of new users, get very popular, and so on.

I agree with you that a lot of the really big advantages of Lisp show up better in large systems than in small coding exercises.

There have actually been lots of successful products made with Lisp. People just don't say so, sometimes because Lisp is unpopular and sometimes because it's just not important. InspireData is a great product, but there's no need for anyone to know what language it's in: in fact, it's in the LispWorks implementation of Common Lisp.

For links to success stories, see my survey paper at http://common-lisp.net/~dlw/LispSurvey.html and see the "Success Stories" section.

Re: The Failure of Lisp? A Reply To Brandon Werner

#43
post #38

Earlier quoted context omitted.

People tend to boggle when I decry Lisp as being hopelessly low-level. Intriguing. I'm not really convinced by your example though. In the spirit of conciseness is power[1], can you provide a short program that should be formally expressible in a good enough language, but isn't concisely in Lisp? Or maybe your definition of low-level is different from mine? [1] That's the PG version, of course.

I don't buy that concision is power. This borders on a tautology, but expressiveness is power. Concision is part of that (a big part, even), but it's not everything. My only problem with Lisp is that it's exactly the sum of its parts - no more, no less. Everything decomposes into self-similar pieces, which decompose into other pieces, and on and on, turtles almost all the way down. This is wonderfully elegant, but al…

I'd like to understand what you mean. Is there a way you could provide an illustrative example?

Re: The Failure of Lisp? A Reply To Brandon Werner

#44
post #28

Earlier quoted context omitted.

> They force an inappropriate fundamental data type on everything, and are only of benefit if you want to fiddle with the insides of extant functions. Please explain. (And I know composition, etc. I also use Haskell and Forth.)

I think what is meant is that the list is the primary data structure for everything in lisps. Fortunately, it is not the only data structure in lisps. I dislike constructs where eg. a graph edge is built as: '(GRAPH-EDGE ) whereas in ML you would write type edge = { source: Vertex.t; target: Vertex.t } which is not a list, but an entirely different representation. In Common Lisp the representation could of course be…

It's true that earlier Lisp dialects had trouble. But in Common Lisp, you can do currying just fine. At work (ITA Software), it's part of our standard utility library.

Re: The Failure of Lisp? A Reply To Brandon Werner

#45
post #3

Earlier quoted context omitted.

While I hear many people complaining about the "awkward" and "hard-to-read" syntax, it's rare to hear someone compliment the syntax of lisp. I am a big fan of the Lisp syntax because it's so simple and consistent - probably a relic of its roots in lambda calculus. Not having to worry about operator precedence is a huge bonus in itself - I don't know why on one hand people cling to PEMDAS, logic, assignment, etc havin…

I agree - I think the other strength of it is that macros are less messy then a language with infix operators/functions. There is something nice about a language (lisp) that doesn't look like anything else, in an artistic sense (not sure if that counts for much). I think when most people complain about the parens, they are really complaining about the endless ))))))) at the end of an expression.

In practice, it's just not a problem, because your interactive development environment takes care of it for you. I think the idea that anyone should be expected to program by using something with the power of Microsoft Notepad is an obsolete view. GNU Emacs with Lisp mode makes it very easy to work with the parentheses.

Meanwhile, we have no "dangling else" problem. Also, we have no need to memorize C's 15 levels of operator precedence, so when you see an expression, you never have to puzzle over how the items are grouped. In simple cases of C expressions, of course, it's easy, but it can get complicated. See "Java Puzzlers" by Josh Bloch and Neal Gafter to see how C/Java-style syntax can get you into trouble and fool you. There are pros and cons to each approach (C/Java and Lisp). I've used all of them extensively, and I prefer the Lisp way.

Re: The Failure of Lisp? A Reply To Brandon Werner

#46
post #26
post #8

Earlier quoted context omitted.

Lisp will have played its major part when other languages have real macro systems.

Macros are a double edged sword. Their advantages also drags in some disadvantages. If they were only advantageous, they would have flown into mainstream languages long ago(in the full Lisp-sense where the macro is a lisp program). But they have not. This can be due to multiple reasons: their disadvantages outweigh the advantages or that the effort of getting them into the language simply drags so many other undesira…

I disagree about that. It's very, very hard to add Lisp-style macros to something like C or Java. The best attempt to do it for Java is Jonathan Bachrach's Java Syntactic Extender, but as far as I know nobody has built any software with it. It's just too hard to use.

Until you have read a clear description (e.g. Seibel) or had some experience, it's hard to see what macros are really all about.

Lisp macros are extremely important, powerful, and beneficial. Space does not permit me to go into the full explanation; see Peter Siebel's book and the great lecture he gave at Google, available on the web.

Macros allowed us to add object-oriented programming to Common Lisp. CLOS (the Common Lisp Object System) fits in very smoothly into the Common Lisp language, with a nice, clear syntax and very powerful semantics. At work, we have built an object-relational mapping system that, similarly, would be impractical (ugly and verbose to the point of unusability) without macros.

Re: The Failure of Lisp? A Reply To Brandon Werner

#47
post #22
post #8

Earlier quoted context omitted.

Lisp will have played its major part when other languages have real macro systems.

Other languages don't necessarily need 'real macro systems' Lisp does, not just because it is so hopelessly low-level (for FP), but also because once you're using s-exprs it's hard to restrain anyone from mogrifying functions. In a suitable language like Haskell where all functions are composed, using functional composition for everything instead of low-level fiddling with "statements as data" makes a shit-ton of sen…

By the way (this is a serious question), what software products have been produced that were written in Haskell?

Re: The Failure of Lisp? A Reply To Brandon Werner

#48

I don't know CL, but from the subset of scheme that i know, i cant imagine how can this language fail. It just feels too good and the code is so beautiful. I could say for certain that scheme has made me into a better programmer.

Common Lisp and (especially!) Scheme are really elegant languages, sure, but there's really something to be said for being able to install the one clear Python implementation* and getting a huge standard library with lots of documentation and a large community, upfront, versus trying to figure out whether you should set up SBCL or CLISP or PLT or Chicken or ..., then finding there are several libraries for what you'r…

Yes, lisp.org needs to be (and will be) vastly improved. We definitely need the equivalent of a CPAN for Lisp, and several of us are working on producing such a thing. You're quite about marketing!

As for multiple implementations: CPython, Jython, IronPython, Stackless Python, PyPy. What editor do you use? Gnu Emacs with Slime; or, some of the commercial Lisp implementations come with IDE's; and there's work being done ("curl") to make Eclipse work well with Common Lisp. Java has several IDE's, such as IntelliJ and Eclipse. For Python, what I'm told by the Python experts I know is that they just don't use any IDE.

But much of what you're saying above is very much to the point. The comments on my blog posting go into these issues more.

Re: The Failure of Lisp? A Reply To Brandon Werner

#49

Lisp's biggest problem is the simple fact that most other languages already ship with most nonwindows boxes. _Successful_Lisp_ is a good book (amongst others), but what do you type the code into? Until today, I hadn't heard of SBCL. I've been fiddling in e-lisp, which is a tragedy of its own sorts. The only mention of SBCL in "google:lisp linux" is an ad. I don't think I'm the only one still afraid of a $5k entrance…

Soon, lisp.org will be redone to make it easy to find good free Lisp implementations. Meanwhile, check out my survey paper at http://common-lisp.net/~dlw/LispSurvey.html.

Re: The Failure of Lisp? A Reply To Brandon Werner

#50

Earlier quoted context omitted.

I agree - I think the other strength of it is that macros are less messy then a language with infix operators/functions. There is something nice about a language (lisp) that doesn't look like anything else, in an artistic sense (not sure if that counts for much). I think when most people complain about the parens, they are really complaining about the endless ))))))) at the end of an expression.

In practice, it's just not a problem, because your interactive development environment takes care of it for you. I think the idea that anyone should be expected to program by using something with the power of Microsoft Notepad is an obsolete view. GNU Emacs with Lisp mode makes it very easy to work with the parentheses. Meanwhile, we have no "dangling else" problem. Also, we have no need to memorize C's 15 levels of…

I agree that it's not a problem, but for newcomers all that parenthesis accumulation is quite problematic. I speak out of my personal experience: I've abandoned lisp even before learning something about macros because I couln't stand the parenthesis. I gave a second chance to Lisp some time ago, years after my first attempt. I've walked through Seibel's book entirely and know I love Lisp, but the parenthesis give a really bad first impression, they only make sense after you get to know the language better.
Post reply on HN