8 ms·

Lisp is Sin (2006)

udzinari 16y ago
"Lisp is like the villainesses present in the Bond movies. It seduces you with its sheer beauty and its allure is irresistible. A fleeting encounter plays on your mind for a long,long time. However, it may not be the best choice if you're looking for a long term commitment. But in the short term, it sure is fun! In that way, Lisp is...sin. " Oh, is it? I think it is exactly the opposite.
shrikant 16y ago
4 years down the line, sriramk, any updates?
Luyt 16y ago
He mentions a lot of LISP dialects, but not Clojure. EDIT: Ah, there was no Clojure back then ;-)
jerf 16y ago
Assuming by Lisp we mean either "Common Lisp" or "what somebody would have called Lisp in 2006", there is now an exception to "All roads lead to Lisp" that has moved from total obscurity to all-language-geeks-should-know-about-this: Haskell. You can not take a 2006 Lisp and macro your way to purity. You could build a pure subset, but that would be a new language in every way that matters because you couldn't use non-pure libraries without a lot of wrapping. You can of course also start a new Lisp-like language with new primitives that do include immutability, but I would suggest that that shows Lisp moving forward by taking a feature from another heritage, which means you've no longer got all roads leading to Lisp/2006, you've got at least one leading away. If there's anything strange about Lisp, it is that it really was a local optimum posing as the global optimum for so long. We should end up with a few more local optima before all is said and done; there aren't enough yet.
- gaius 16y ago
  Not only Haskell: F#, OCaml, Erlang and Scala too. While Lispers were basking in the 50-year-old glow of being 30 years ahead once, all of these languages leapfrogged them and they don't even know it.
  - cageface 16y ago
    One killer feature remains exclusive to Lisp: macros. However, in languages as flexible as those you mention, with higher order functions and good type inference, you don't need macros as much as you might in less flexible languages. I'd love to see a serious evaluation of the cost/benefit of s-exprs and macros in real-world production code but I'm not sure how exactly how you'd measure this. My own cursory examination of the clojure-contrib library's use of macros, for example, suggested to me that many of them wouldn't be necessary in a language like Scala, but I'd love to see a more rigorous study.
    - gaius 16y ago
      One killer feature remains exclusive to Lisp: macros Lisp can't rest on its laurels here either: http://www.haskell.org/haskellwiki/Template_Haskell http://www.haskell.org/haskellwiki/Template_Haskell
- ohyes 16y ago
  The whole point of lisp is that it rolls around picking up new ideas. Haskell was originally implemented in lisp. Examples: Lexical scoping (ALGOL) The 'format' macro(I believe Fortran) The 'loop' macro (COBOL? Pascal? not sure?) Type systems ala Qi and Haskell (ML and typed lambda calculus influenced) Optional type declaration are probably to approximate C. You can implement prolog it... I believe lisp machines even had GC'd versions of C, Pascal, and other languages written for them. Personally, when I read "all roads lead to lisp," it is taken with tongue firmly in cheek. Lisp isn't really the 'best' language, it just ends up being able to subsume all of the ideas from them. In RPG terms, Lisp is the red mage. This is why I like it a lot; given a certain problem domain, you can approximate the global optima that is reached in another language.
  - zephyrfalcon 16y ago
    "The whole point of lisp is that it rolls around picking up new ideas." Kind of like the Katamari Damacy of programming languages... :-)
    - frou_dh 16y ago
      When I played that game I was ruining and picking up junky city debris! That sounds a scary language.
sriramk 16y ago
Wow, why did this get posted after so many years? It's a bit embarrassing to see my writing from back then. Its amateurish, a bit tacky and I sorely needed to edit it. As for my opinions now, I think classic Lisp is forever doomed to be a niche language. I think it's legacy will be contribution of ideas to mainstream languages. Having said that, Clojure is fascinating and could prove me wrong.
- mahmud 16y ago
  Actually, I clicked on the link thinking it was by another "Sriram Krishn*": http://www.cs.brown.edu/~sk/Publications/Papers/Published/ http://www.cs.brown.edu/~sk/Publications/Papers/Published/ I thought Dr. Krishnamurthi finally saw the Dark ;-)
fexl 16y ago
I programmed in Lisp back in 1985 and liked it a lot. Today I consider it too imperative for my tastes, and also too heavyweight. So lately I've been embedding a little interpreter for my Fexl language ( http://fexl.com http://fexl.com ) into my systems written in Perl. That way I can opportunistically use a pure functional language for script-like purposes such as dynamic web sites and report generation, without committing to rewriting my entire system in another language. The Fexl interpreter is tiny and only has 7 grammar rules, so it's really easy to deploy in very focused areas of the system. It's going well so far in testing. I suspect that over time I will migrate an increasing amount of system logic out of Perl and into Fexl, so eventually all that remains in Perl is the Fexl interpreter itself. Then I'll swap that out for my interpreter written in C and be done with Perl. Don't get me wrong -- I've been using Perl for 12 years and I know how to write disciplined code in it, so I am grateful to Perl. But I find the pure functional approach to be liberating, making many tasks seem almost effortless. In fact, I've even been applying the functional concepts to my Perl code itself, with great reward. For example, when I'm parsing text, I don't use the usual destructive position pointer. Instead, I use a functional representation of the text, with head, tail, prefix, suffix, and such. It's liberating. Another example: when I use my key-value maps with automatic hierarchical structuring by disjoint prefix, I no longer use a destructive "put" operation to change entries. Instead, the "put" operation in effect returns a brand new key-value map with just that one entry changed. It's amazing how efficient this is because of structure sharing, and it also adds much clarity to the code and avoids a lot of thorny implementation issues (especially because I actually need a super-efficient "virtual copy" of large key-value maps for what I'm doing.) So my main points here are: 1. You can deploy a small embedded interpreter for a purely functional language, inside a system written in any language (yes, even Perl). You don't have to rewrite your entire system in a "pure" language all in one fell swoop, or ever. You can just systematically migrate more logic into the functional side, completely at your leisure, in an evolutionary fashion. 2. You can apply functional concepts and techniques to code written in any language (yes, even Perl). That works even if you don't go as far as using an embedded interpreter. I am finding both of these techniques to be highly rewarding, and the most exciting thing I've done since I started programming in 1975.
- Imbue 16y ago

Lisp is Sin (2006)

"Lisp is like the villainesses present in the Bond movies. It seduces you with its sheer beauty and its allure is irresistible. A fleeting encounter plays on your mind for a long,long time. However, it may not be the best choice if you're looking for a long term commitment. But in the short term, it sure is fun! In that way, Lisp is...sin. " Oh, is it? I think it is exactly the opposite.

shrikant 16y ago

4 years down the line, sriramk, any updates?

Luyt 16y ago

He mentions a lot of LISP dialects, but not Clojure. EDIT: Ah, there was no Clojure back then ;-)

jerf 16y ago

Assuming by Lisp we mean either "Common Lisp" or "what somebody would have called Lisp in 2006", there is now an exception to "All roads lead to Lisp" that has moved from total obscurity to all-language-geeks-should-know-about-this: Haskell. You can not take a 2006 Lisp and macro your way to purity. You could build a pure subset, but that would be a new language in every way that matters because you couldn't use non-pure libraries without a lot of wrapping. You can of course also start a new Lisp-like language with new primitives that do include immutability, but I would suggest that that shows Lisp moving forward by taking a feature from another heritage, which means you've no longer got all roads leading to Lisp/2006, you've got at least one leading away. If there's anything strange about Lisp, it is that it really was a local optimum posing as the global optimum for so long. We should end up with a few more local optima before all is said and done; there aren't enough yet.

gaius 16y ago
Not only Haskell: F#, OCaml, Erlang and Scala too. While Lispers were basking in the 50-year-old glow of being 30 years ahead once, all of these languages leapfrogged them and they don't even know it.
- cageface 16y ago
  One killer feature remains exclusive to Lisp: macros. However, in languages as flexible as those you mention, with higher order functions and good type inference, you don't need macros as much as you might in less flexible languages. I'd love to see a serious evaluation of the cost/benefit of s-exprs and macros in real-world production code but I'm not sure how exactly how you'd measure this. My own cursory examination of the clojure-contrib library's use of macros, for example, suggested to me that many of them wouldn't be necessary in a language like Scala, but I'd love to see a more rigorous study.
  - gaius 16y ago
    One killer feature remains exclusive to Lisp: macros Lisp can't rest on its laurels here either: http://www.haskell.org/haskellwiki/Template_Haskell http://www.haskell.org/haskellwiki/Template_Haskell
ohyes 16y ago
The whole point of lisp is that it rolls around picking up new ideas. Haskell was originally implemented in lisp. Examples: Lexical scoping (ALGOL) The 'format' macro(I believe Fortran) The 'loop' macro (COBOL? Pascal? not sure?) Type systems ala Qi and Haskell (ML and typed lambda calculus influenced) Optional type declaration are probably to approximate C. You can implement prolog it... I believe lisp machines even had GC'd versions of C, Pascal, and other languages written for them. Personally, when I read "all roads lead to lisp," it is taken with tongue firmly in cheek. Lisp isn't really the 'best' language, it just ends up being able to subsume all of the ideas from them. In RPG terms, Lisp is the red mage. This is why I like it a lot; given a certain problem domain, you can approximate the global optima that is reached in another language.
- zephyrfalcon 16y ago
  "The whole point of lisp is that it rolls around picking up new ideas." Kind of like the Katamari Damacy of programming languages... :-)
  - frou_dh 16y ago
    When I played that game I was ruining and picking up junky city debris! That sounds a scary language.

sriramk 16y ago

Wow, why did this get posted after so many years? It's a bit embarrassing to see my writing from back then. Its amateurish, a bit tacky and I sorely needed to edit it. As for my opinions now, I think classic Lisp is forever doomed to be a niche language. I think it's legacy will be contribution of ideas to mainstream languages. Having said that, Clojure is fascinating and could prove me wrong.

mahmud 16y ago
Actually, I clicked on the link thinking it was by another "Sriram Krishn*": http://www.cs.brown.edu/~sk/Publications/Papers/Published/ http://www.cs.brown.edu/~sk/Publications/Papers/Published/ I thought Dr. Krishnamurthi finally saw the Dark ;-)

fexl 16y ago

I programmed in Lisp back in 1985 and liked it a lot. Today I consider it too imperative for my tastes, and also too heavyweight. So lately I've been embedding a little interpreter for my Fexl language ( http://fexl.com http://fexl.com ) into my systems written in Perl. That way I can opportunistically use a pure functional language for script-like purposes such as dynamic web sites and report generation, without committing to rewriting my entire system in another language. The Fexl interpreter is tiny and only has 7 grammar rules, so it's really easy to deploy in very focused areas of the system. It's going well so far in testing. I suspect that over time I will migrate an increasing amount of system logic out of Perl and into Fexl, so eventually all that remains in Perl is the Fexl interpreter itself. Then I'll swap that out for my interpreter written in C and be done with Perl. Don't get me wrong -- I've been using Perl for 12 years and I know how to write disciplined code in it, so I am grateful to Perl. But I find the pure functional approach to be liberating, making many tasks seem almost effortless. In fact, I've even been applying the functional concepts to my Perl code itself, with great reward. For example, when I'm parsing text, I don't use the usual destructive position pointer. Instead, I use a functional representation of the text, with head, tail, prefix, suffix, and such. It's liberating. Another example: when I use my key-value maps with automatic hierarchical structuring by disjoint prefix, I no longer use a destructive "put" operation to change entries. Instead, the "put" operation in effect returns a brand new key-value map with just that one entry changed. It's amazing how efficient this is because of structure sharing, and it also adds much clarity to the code and avoids a lot of thorny implementation issues (especially because I actually need a super-efficient "virtual copy" of large key-value maps for what I'm doing.) So my main points here are: 1. You can deploy a small embedded interpreter for a purely functional language, inside a system written in any language (yes, even Perl). You don't have to rewrite your entire system in a "pure" language all in one fell swoop, or ever. You can just systematically migrate more logic into the functional side, completely at your leisure, in an evolutionary fashion. 2. You can apply functional concepts and techniques to code written in any language (yes, even Perl). That works even if you don't go as far as using an embedded interpreter. I am finding both of these techniques to be highly rewarding, and the most exciting thing I've done since I started programming in 1975.

Imbue 16y ago