Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Failure of Lisp? A Reply To Brandon Werner

danweinreb.org

Post reply on HN
Print view View original

21–30 of 53 posts

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

#21

Post by orib »

lallysingh wrote: post #15
PieSquared wrote: post #12

Earlier quoted context omitted.

The lisp macro system can more or less be done at compile time, yes, but that's not the problem with other languages. The format of lisp makes it especially easy to do macros - code is data! Here's an example. Take, for example, this class declaration: (defclass dog (animal) ((size :accessor dog-size) (name :accessor dog-name :init-form "Fido"))) How do you make that into data? Easy. Just quote it: '(defclass dog (an…

Or: 1. Allow a factory for Class. 2. Make Method contain the full body contents as a list of statements, and give them a factory as well. Then it's a matter of reasonable constructor syntax.

And a whole lot of "wait, what tree does this code map to again?"

With lisp, there's no difficulty mapping:

   int main(int x) {foo()}
to

  Method m = new Method(return:=new Type(int),
                        args  := new ArgList(
                                  new Arg(new Type(int),
                                          new Name("x"))),
                        body  := new Block(
.... I'm sure you get the point....

The syntax tree is apparent from the syntax.

  (+ 1 2 (* 3 4))
Maps to:

  '(+ 1 2 (* 3 4))

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

#22

Post by blasdel »

brlewis wrote: post #8
jlouis wrote: post #2

Lisp (any lisp, be it lisp-1 or lisp-2) are currently fighting a fight on multiple fronts. From one side, each iteration of Python or Ruby gains new ground as they incorporate more and more lisp-concepts, while being "Visually friendly" (ie, with common syntax). They also have the ability to lure many more users from, say Java or C#. On the other side, you have any language with type theory governing the language des…

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 sense. In Haskell you can also use supercompilation to resolve as much of the graph as possible at run time. No need for macros.

Don't think that other language communities want the warts from your language, just because you are so enthusiastic about them.

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

#23

Post by blasdel »

silentbicycle wrote: post #20
kylec wrote: 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 wish ML used s-expressions. Also, you might like this presentation, "The Swine Before Perl" by Shriram Krishnamurthi (of PLT). It's a great thing to show people who wonder how you could think Lisp has a good syntax: http://www.cs.brown.edu/~sk/Publications/Talks/SwineBeforePe... (Also: SK's book is great.)

ML and it's successors do not want for s-exprs.

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.

Use composition like a real FPer. Learn that there's so much more to data than lists + atoms.

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

#24

Post by blasdel »

prospero wrote: post #10
kylec wrote: 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…

Clarity and unambiguity aren't necessarily the same things. The human brain can handle huge amounts of ambiguity, and our spoken languages reflect this. A programming language is meant to be a bridge between our ambiguous thoughts and the unambiguous calculations of a computer. S-expressions constrain the format of the programmer's dialog with the computer, making it simple and monotonic. For some people this will ad…

Bravo! People tend to boggle when I decry Lisp as being hopelessly low-level.

Sometimes ambiguity can be free, allowing indifference to how the machine works, without obscuring it at all. A good example is classical Hindley-Milner type inference (the algorithm that adds type annotations to plain System F code): it is fairly easy to construct oddball statements where annotating the types is undecidable or would cause resource exhaustion. But it turns out that for the known examples, it would be either impossible to decide the types in any form, or it would take O(c^n) bytes to enumerate the annotations.

So effectively there is no downside to the ambiguity -- the ambiguous statements are already infeasible for other reasons. Everybody Wins!

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

#25

Post by gruseom »

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 need it to run both on the server and in the browser, under different circumstances). The point isn't that I needed, say, Lisp macros to do this. The point is that I was able to do it pretty easily. As a working programmer, I'm surprised by how often something that feels like it'll be scary and hard turns out to be pretty easy in CL. In fact I often spend more time worrying about it than I do coding it (which makes me wonder how long it will take before certain habits that come from experience in less productive environments die off).

This isn't the sort of thing you can really analyze on the level of language features. I find that a lot of the discourse around language comparison is the activity of researchers and hobbyists (for want of a better term) who aren't immediately concerned with building major systems. They like to explore many different things and the programming tasks they take on tend to be conducive to that - coding exercises and such. That's great, but not the same perspective as when you throw yourself into making one big system over months or years. To the first sort of person, the various Lisps and startup annoyances and incompatibilities constitute a huge barrier, enough to say "why bother" and move on. To me they were an investment that paid off relatively quickly and has since produced big gains. (I mean technically. We'll see if they cross over economically.)

Lisp isn't going to have a major resurgence on language grounds alone. It's too old for that, and too suboptimal for blog posts. What would, though, make a big difference is seeing more successful products made with it. That may sound odd as there have been few so far, but that's where I think the untapped potential of Lisp is. And if that ever happens, an ecosystem might develop that has fewer of the dysfunctional aspects of the past. Successful companies that use Lisp would fund open source development, and so on.

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

#26

Post by jlouis »

brlewis wrote: post #8
jlouis wrote: post #2

Lisp (any lisp, be it lisp-1 or lisp-2) are currently fighting a fight on multiple fronts. From one side, each iteration of Python or Ruby gains new ground as they incorporate more and more lisp-concepts, while being "Visually friendly" (ie, with common syntax). They also have the ability to lure many more users from, say Java or C#. On the other side, you have any language with type theory governing the language des…

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 undesirable things with it. Perhaps the advantage of a macro is perceived to be so small compared to e.g., function composition and higher order functions, that it is left out of the language.

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

#27

Post by silentbicycle »

blasdel wrote: post #23
silentbicycle wrote: post #20

Earlier quoted context omitted.

I agree. I wish ML used s-expressions. Also, you might like this presentation, "The Swine Before Perl" by Shriram Krishnamurthi (of PLT). It's a great thing to show people who wonder how you could think Lisp has a good syntax: http://www.cs.brown.edu/~sk/Publications/Talks/SwineBeforePe... (Also: SK's book is great.)

ML and it's successors do not want for s-exprs. 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. Use composition like a real FPer. Learn that there's so much more to data than lists + atoms.

> 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.)

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

#28

Post by jlouis »

silentbicycle wrote: post #27
blasdel wrote: post #23

Earlier quoted context omitted.

ML and it's successors do not want for s-exprs. 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. Use composition like a real FPer. Learn that there's so much more to data than lists + atoms.

> 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 a CLOS object or a DEFSTRUCT (I think, my CL-fu is definitely not that good).

As for the composition, lisps are lacking (nice) currying which is one of the basic building blocks when constructing combinator-libraries.

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

#30

Post by 13ren »

"the community is judgmental and unfriendly to newcomers and thorny and un-inspiring."

Brandon's reply agrees with this criticism, because "I have heard this same criticism from other people than you, and at this point I assume it must really be true."

The comments here focus on lisp. Lisp isn't the problem.

Post reply on HN