The Failure of Lisp? A Reply To Brandon Werner • Hacker News Board

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

#51

Post by silentbicycle » Sun, Sep 21, 2008, 2:32 PM UTC

dlweinreb wrote: post #48

silentbicycle wrote: post #19

Earlier quoted context omitted.

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 do…

> We definitely need the equivalent of a CPAN for Lisp

Agreed! I like the Eggs repository for Chicken (http://chicken.wiki.br/Eggs%20Unlimited%203), but individual Scheme implementations just aren't compatible enough for such things to really benefit them all -- I'm pretty sure the lack of a module system in the core for R5RS is to blame. There's one in R6RS, but I hope it's not too little, too late.

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

#52

Post by silentbicycle » Sun, Sep 21, 2008, 2:39 PM UTC

dlweinreb wrote: post #47

blasdel wrote: post #22

Earlier quoted context omitted.

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?

Besides the Glasgow Haskell Compiler (which probably doesn't count, for your purposes, but it's a good example of a large and complex program), the best example is probably Darcs (http://darcs.net/), a distributed version control system with a powerful patch composition system.

There are further answers from the Haskell wiki here: http://haskell.org/haskellwiki/Haskell_in_practice

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

#53

Post by jlouis » Sun, Sep 21, 2008, 3:55 PM UTC

dlweinreb wrote: post #46

jlouis wrote: post #26

Earlier quoted context omitted.

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 extreme…

I weren't clear enough, sorry.

Yes, it is extremely hard to add lisp-style macros to C or Java because they have no s-expression structure you can work on. And they do not want an s-expression structure because it is too alien for those programmers. Thus, they perceive that macros are not worth the effort.

I think macros are left out of so many languages because people do not know how to incorporate them while retaining other desirable properties of the language (type safety for instance).

Also, macros are not the only way to build ORM systems. Python does the same with metaclassing as an example. But we can agree on that trying to map it into a statically typed language with reflection/AOP as Java did is doomed to fail I think ;)

I am not trying to say that macros are useless. I am trying to say that some languages leave them out on purpose. Many problems on which macros look nice can be solved with a little extra thought on representation. But then again, many can not.

I see the discussion of macros/no-macros a bit like the discussion on static/dynamic typing. With static typing, we know we are leaving some valid programs outside the gates of the static world. But we think that this loss is negligible compared to the benefits a static check gives us. Yet, some people oppose this viewpoint and wants the valid programs as well, because they perceive the benefits of the static typing to the negligible. Both approaches are valid, but it currently looks like it is hard to get all of the cake in one munch.