5 ms·

The Nature of Lisp (2006)

54 points by b-man 16y ago

pchristensen 16y ago
An oldie but goodie. This helped explain a lot of the often-praised features of Lisp and functional programming that had never made sense before.
- mace 16y ago
  Older post: http://news.ycombinator.com/item?id=127736 http://news.ycombinator.com/item?id=127736
- projectileboy 16y ago
  Ditto. Thanks to the RethinkDB guys for doing these all those years ago...
- eru 16y ago
  Yes. However keep in mind that Lisp has left the forefront of functional programming mostly to ML derived languages. Common Lisp isn't even very functional. Not much more than e.g. Python. Scheme is a bit more functional oriented.
  - samatman 16y ago
    Clojure, OTOH, is beautifully functional. Also, it is supported by NetBeans and Eclipse, so no SLIME needed.
    - eru 16y ago
      Yes, I forgot about Clojure.
  - ced 16y ago
    > Lisp has left the forefront of functional programming mostly to ML derived languages I'd be grateful if you could expand upon that statement. I'm a Lisper, and half the time I see one of these Haskell articles, I wonder if there really is a there there. For sure, functional programming can be a whole lot better than CL or Scheme, but I'd like to know if the difference is significant.
    - eru 16y ago
      Depends on what you want to achieve. If you leave out the dimension of static vs dynamic typing, you could get most of Haskell's benefits by making your Scheme pure, and confining side-effects. (Monads are one solution for this, but not the only one. Have a look at Functional reactive programming, or see how Clean uses linear typing.) You could probably hack most of the pureness stuff together with macros in an already existing Scheme. Purity by (strong) default makes it easier to combine your programs. Lazyness can help, too, but I am not completely sure whether you should make lazy the default. Chris Okasaki's "Purely Functional Data Structures" argues for needing both lazy and strict evaluation to guarantee asymptotic run times. Have a look at, say, Software Transactional Memory to see what purity can buy you. Combinatorial parsers are another interesting application in Haskell; however they should be easily implementable in Scheme, too. Please have a look at how http://www.cs.kent.ac.uk/people/staff/smk/redblack/rb.html http://www.cs.kent.ac.uk/people/staff/smk/redblack/rb.html uses the type system to statically guarantee the balance of red-black trees. Please pardon that I mostly talked about the `how' and not so much the `why'. I hope giving some examples might not totally be in vain.
  - pchristensen 16y ago
    I know. The article covers both (or did I mix it in with another of coffeemug's articles?). But coming from C# 2.0, Lisp's functional-supported-but-optional was still a big jump.
    - eru 16y ago
      Yes. Lisp is an acceptable functional language, and its communities also value functional approaches. (Whereas Python gives you almost the same support from the language, but much less from the communities and libraries. (My main grief is that dicts only have side-effecting operations.))
DrJokepu 16y ago
Commenting on the last paragraph: I honestly believe that one of the biggest obstacles for newcomers to Lisp is Emacs. Don't get me wrong, I love Emacs and it is truly the superior environment to do work in Lisp. However it has a bit of a steep learning curve just like Lisp itself and fighting two battles (one with Lisp and one with Emacs) is no easy task for someone coming from a Java / C# and Eclipse / Visual Studio background. I know because I've been there. That's why I decided to start work on an open source Visual Studio add-in to support for Common Lisp in Visual Studio itself. I think being able to do the first steps in a familiar environment would be a great help for newcomers. I wonder what you guys think of the idea?
- b-man 16y ago
  Did you ever tried Drscheme?
  - DrJokepu 16y ago
    Yes, DrScheme is awesome. However, I was specifically thinking of supporting Common Lisp, not Scheme as Scheme already has enough friendly tools for beginners.
    - b-man 16y ago
      How about cusp[1] then? It is an eclipse plugin. Never tried myself, but it could be a starting point. [1] http://sergeykolos.com/cusp/intro/ http://sergeykolos.com/cusp/intro/
      - DrJokepu 16y ago
        Yes, I've never seen that one before but it definitely looks promising. I'll have a look at it and see what it can do.
    - derefr 16y ago
      Why not just bootstrap knowledge of Common Lisp by learning Scheme first, then?
eru 16y ago
> After all, I was almost blinded by the infamous Lisp parentheses! Lisp's parenthesis seem to share their deterrence factor with Python's significant indentation. Most people who have used one of them for a while don't even notice them any longer. At least not as a problem. Interestingly, Haskell seems to be strange enough, that nobody fears its significant indentation.
- Xurinos 16y ago
  If it's any consolation, I do not like its line noise. I already work with perl. I wanted to step up towards beauty.
  - eru 16y ago
    Yes, Common Lisp is somewhat ugly. Scheme looks nicer.
    - Xurinos 16y ago
      I meant Haskell. :) Turns out CL is pretty light on the funny syntax, and the few places it is used are optional -- but nice.
      - eru 16y ago
        OK, I guess then I just have different preferences. I find Haskell much more bearable than CL in terms of beauty. Scheme is nice, too.
        Xurinos 16y ago
        I have heard similar opinions on Haskell. I am definitely attracted to the convenient function currying and composition, but I realized I could do similar in CL and make it look like whatever made sense to me. I find the ability to create my own look and feel to supercede accepting someone else's look and feel. I have no issues with Scheme, except that I have chosen to use CL over Scheme because it does feel like something of a batteries-included system. On the other hand, I was annoyed by what I felt was inconsistent syntax with Haskell revealed in Real World Haskell chapter 13 (unfortunately my only experience with it) when they showed this function definition: mkFuncRec :: String -> (Int -> Int) -> FuncRec vs this function definition: simplify :: (Num a) => SymbolicManip a -> SymbolicManip a The =>, previously used to instance types, confused me here (they never explained how this definition differed), and I was having a hard time keeping up with all the various times I needed to use each special symbol. Of course, I tolerated it through C++ and perl, so if I ever decided to try a project, I could probably get used to it.

54 points by b-man 16y ago

An oldie but goodie. This helped explain a lot of the often-praised features of Lisp and functional programming that had never made sense before.

mace 16y ago
Older post: http://news.ycombinator.com/item?id=127736 http://news.ycombinator.com/item?id=127736
projectileboy 16y ago
Ditto. Thanks to the RethinkDB guys for doing these all those years ago...
eru 16y ago
Yes. However keep in mind that Lisp has left the forefront of functional programming mostly to ML derived languages. Common Lisp isn't even very functional. Not much more than e.g. Python. Scheme is a bit more functional oriented.
- samatman 16y ago
  Clojure, OTOH, is beautifully functional. Also, it is supported by NetBeans and Eclipse, so no SLIME needed.
  - eru 16y ago
    Yes, I forgot about Clojure.
- ced 16y ago
  > Lisp has left the forefront of functional programming mostly to ML derived languages I'd be grateful if you could expand upon that statement. I'm a Lisper, and half the time I see one of these Haskell articles, I wonder if there really is a there there. For sure, functional programming can be a whole lot better than CL or Scheme, but I'd like to know if the difference is significant.
  - eru 16y ago
    Depends on what you want to achieve. If you leave out the dimension of static vs dynamic typing, you could get most of Haskell's benefits by making your Scheme pure, and confining side-effects. (Monads are one solution for this, but not the only one. Have a look at Functional reactive programming, or see how Clean uses linear typing.) You could probably hack most of the pureness stuff together with macros in an already existing Scheme. Purity by (strong) default makes it easier to combine your programs. Lazyness can help, too, but I am not completely sure whether you should make lazy the default. Chris Okasaki's "Purely Functional Data Structures" argues for needing both lazy and strict evaluation to guarantee asymptotic run times. Have a look at, say, Software Transactional Memory to see what purity can buy you. Combinatorial parsers are another interesting application in Haskell; however they should be easily implementable in Scheme, too. Please have a look at how http://www.cs.kent.ac.uk/people/staff/smk/redblack/rb.html http://www.cs.kent.ac.uk/people/staff/smk/redblack/rb.html uses the type system to statically guarantee the balance of red-black trees. Please pardon that I mostly talked about the `how' and not so much the `why'. I hope giving some examples might not totally be in vain.
- pchristensen 16y ago
  I know. The article covers both (or did I mix it in with another of coffeemug's articles?). But coming from C# 2.0, Lisp's functional-supported-but-optional was still a big jump.
  - eru 16y ago
    Yes. Lisp is an acceptable functional language, and its communities also value functional approaches. (Whereas Python gives you almost the same support from the language, but much less from the communities and libraries. (My main grief is that dicts only have side-effecting operations.))

DrJokepu 16y ago

Commenting on the last paragraph: I honestly believe that one of the biggest obstacles for newcomers to Lisp is Emacs. Don't get me wrong, I love Emacs and it is truly the superior environment to do work in Lisp. However it has a bit of a steep learning curve just like Lisp itself and fighting two battles (one with Lisp and one with Emacs) is no easy task for someone coming from a Java / C# and Eclipse / Visual Studio background. I know because I've been there. That's why I decided to start work on an open source Visual Studio add-in to support for Common Lisp in Visual Studio itself. I think being able to do the first steps in a familiar environment would be a great help for newcomers. I wonder what you guys think of the idea?

b-man 16y ago
Did you ever tried Drscheme?
- DrJokepu 16y ago
  Yes, DrScheme is awesome. However, I was specifically thinking of supporting Common Lisp, not Scheme as Scheme already has enough friendly tools for beginners.
  - b-man 16y ago
    How about cusp[1] then? It is an eclipse plugin. Never tried myself, but it could be a starting point. [1] http://sergeykolos.com/cusp/intro/ http://sergeykolos.com/cusp/intro/
    - DrJokepu 16y ago
      Yes, I've never seen that one before but it definitely looks promising. I'll have a look at it and see what it can do.
  - derefr 16y ago
    Why not just bootstrap knowledge of Common Lisp by learning Scheme first, then?

eru 16y ago

> After all, I was almost blinded by the infamous Lisp parentheses! Lisp's parenthesis seem to share their deterrence factor with Python's significant indentation. Most people who have used one of them for a while don't even notice them any longer. At least not as a problem. Interestingly, Haskell seems to be strange enough, that nobody fears its significant indentation.

Xurinos 16y ago
If it's any consolation, I do not like its line noise. I already work with perl. I wanted to step up towards beauty.
- eru 16y ago
  Yes, Common Lisp is somewhat ugly. Scheme looks nicer.
  - Xurinos 16y ago
    I meant Haskell. :) Turns out CL is pretty light on the funny syntax, and the few places it is used are optional -- but nice.
    - eru 16y ago
      OK, I guess then I just have different preferences. I find Haskell much more bearable than CL in terms of beauty. Scheme is nice, too.
      - Xurinos 16y ago
        I have heard similar opinions on Haskell. I am definitely attracted to the convenient function currying and composition, but I realized I could do similar in CL and make it look like whatever made sense to me. I find the ability to create my own look and feel to supercede accepting someone else's look and feel. I have no issues with Scheme, except that I have chosen to use CL over Scheme because it does feel like something of a batteries-included system. On the other hand, I was annoyed by what I felt was inconsistent syntax with Haskell revealed in Real World Haskell chapter 13 (unfortunately my only experience with it) when they showed this function definition: mkFuncRec :: String -> (Int -> Int) -> FuncRec vs this function definition: simplify :: (Num a) => SymbolicManip a -> SymbolicManip a The =>, previously used to instance types, confused me here (they never explained how this definition differed), and I was having a hard time keeping up with all the various times I needed to use each special symbol. Of course, I tolerated it through C++ and perl, so if I ever decided to try a project, I could probably get used to it.