4 ms·

I enjoyed the read, but I borked at your suggestion that not being purely functional, and the language barking at you if you break that convention stops you lea

by richo 14y ago

I enjoyed the read, but I borked at your suggestion that not being purely functional, and the language barking at you if you break that convention stops you learning functional programming. Take most Lisps (I'll assume scheme, because it's what I'm most familiar with), which give you more than enough side-effecty rope to hang yourself with should you so desire- but you won't get far unless you're coding functionally.

cageface 14y ago
All kinds of large Lisp codebases are written in an imperative style. There's no reason it's any more difficult to write that kind of code in Lisp than it is in any imperative language.
Peaker 14y ago
I haven't seen much functional code in elisp, which is the Lisp I most commonly read. Some Common Lisp code I saw was also very imperative. Scheme seems to be a more functional language, but I don't really see why people consider other Lisps any more functional than say, Python.
- lispm 14y ago
  Common Lisp is a multi-paradigm language. The standard supports imperative, functional and object-oriented programming styles. It even tries to mix them. The Common Lisp Object System for example uses Generic Functions, and not the more usual message passing mechanism. The language is also traditionally extended by other paradigms: rule-based, logical, actors, agents, concurrent, ... Still Common Lisp uses mechanisms of functional programming widely. It supports lexical binding, many library functions are higher-order functions, etc. There are also some programs which are written in a very functional style and most implementations support tail call optimizations to further make a functional style useful. Common Lisp does not enforce a particular programming paradigm. As a start all three supported would be used by a programmer. He or she might even add some more, if necessary.
  - Peaker 14y ago
    Lexical binding, higher-order functions, etc are very common in Python, for example. Except for TCO which is not widely supported in Python, and problematic if support is not guaranteed, Python seems to be just as functional as CL. Nobody cites Python as a functional language, yet people mostly cite CL as a functional language.
    - lispm 14y ago
      Functional Programming is discouraged in Python. See the various statements by its Benevolent Dictator starting here: http://www.artima.com/weblogs/viewpost.jsp?thread=98196 http://www.artima.com/weblogs/viewpost.jsp?thread=98196 then here: http://python-history.blogspot.de/2009/04/origins-of-pythons-functional-features.html http://python-history.blogspot.de/2009/04/origins-of-pythons...
      - Peaker 14y ago
        So more a matter of the atmosphere around the language than the language itself. Intrinsically, Python and CL seem just as fit for functional programming (with semi-legitimate reliance on TCO being a slight benefit for CL's side).
agentultra 14y ago
Sometimes you need side-effects. The world is far from pure. I think Common Lisp gives you exactly the tools you need and gets out of your way. Dynamic variables (a very specific term in CL) are simply awesome. You need side-effects when you're dealing with I/O -- sockets, files, shells, etc. I prefer languages that make it as painless as possible when I need it. Purity, IMO, is over-rated. You can write pure FP code in C++, Java, or CL if you wanted to. It doesn't matter whether you can write imperative code with side-effects and doesn't make those languages any less useful. This purity thing that the Haskell-zealots are on about just stinks of bullish*t and it's not good for you. That being said, Haskell does do some neat things and there is a lot to learn from it. It's type-inference lets it do some neat things like parallel maps and so forth. It also shows us that laziness is not always a good default. I'm not hating on Haskell but anyone who drools over its, "purity," is not saying much at all. Purity is not an attribute that wins you any battles.
- riffraff 14y ago
  > Dynamic variables (a very specific term in CL) are simply awesome. I may be wrong but I think the name is rather common outside CL too (assuming you refer to "variables with dynamic scope rather than lexical"). E.g. as we are talking of scala http://www.scala-lang.org/api/current/scala/util/DynamicVariable.html http://www.scala-lang.org/api/current/scala/util/DynamicVari...
  - agentultra 14y ago
    Sorry, didn't mean to imply it was a feature unique to CL.
- enigmo 14y ago
  Type-inference doesn't provide anything related to parallel maps, though Haskell's type system can verify that they're safe. Switching an arbitrary loop to a parallel one in C#, Scala, Java, whatever, is certainly a crapshoot. The real benefit to purity and laziness (imo) is the STM. The type system (and pure functions) allow rerunning transactions arbitrarily without worry about side effects, and laziness by default minimizes lock contention by deferring most code execution outside of the transaction block. Joe Duffy has a pretty good writeup a few years ago outlining the difficulty of writing an STM for languages without such guarantees, it's definitely worth a read: http://www.bluebytesoftware.com/blog/2010/01/03/ABriefRetrospectiveOnTransactionalMemory.aspx http://www.bluebytesoftware.com/blog/2010/01/03/ABriefRetros...

by richo 14y ago

cageface 14y ago

All kinds of large Lisp codebases are written in an imperative style. There's no reason it's any more difficult to write that kind of code in Lisp than it is in any imperative language.

Peaker 14y ago

I haven't seen much functional code in elisp, which is the Lisp I most commonly read. Some Common Lisp code I saw was also very imperative. Scheme seems to be a more functional language, but I don't really see why people consider other Lisps any more functional than say, Python.

lispm 14y ago
Common Lisp is a multi-paradigm language. The standard supports imperative, functional and object-oriented programming styles. It even tries to mix them. The Common Lisp Object System for example uses Generic Functions, and not the more usual message passing mechanism. The language is also traditionally extended by other paradigms: rule-based, logical, actors, agents, concurrent, ... Still Common Lisp uses mechanisms of functional programming widely. It supports lexical binding, many library functions are higher-order functions, etc. There are also some programs which are written in a very functional style and most implementations support tail call optimizations to further make a functional style useful. Common Lisp does not enforce a particular programming paradigm. As a start all three supported would be used by a programmer. He or she might even add some more, if necessary.
- Peaker 14y ago
  Lexical binding, higher-order functions, etc are very common in Python, for example. Except for TCO which is not widely supported in Python, and problematic if support is not guaranteed, Python seems to be just as functional as CL. Nobody cites Python as a functional language, yet people mostly cite CL as a functional language.
  - lispm 14y ago
    Functional Programming is discouraged in Python. See the various statements by its Benevolent Dictator starting here: http://www.artima.com/weblogs/viewpost.jsp?thread=98196 http://www.artima.com/weblogs/viewpost.jsp?thread=98196 then here: http://python-history.blogspot.de/2009/04/origins-of-pythons-functional-features.html http://python-history.blogspot.de/2009/04/origins-of-pythons...
    - Peaker 14y ago
      So more a matter of the atmosphere around the language than the language itself. Intrinsically, Python and CL seem just as fit for functional programming (with semi-legitimate reliance on TCO being a slight benefit for CL's side).

agentultra 14y ago

Sometimes you need side-effects. The world is far from pure. I think Common Lisp gives you exactly the tools you need and gets out of your way. Dynamic variables (a very specific term in CL) are simply awesome. You need side-effects when you're dealing with I/O -- sockets, files, shells, etc. I prefer languages that make it as painless as possible when I need it. Purity, IMO, is over-rated. You can write pure FP code in C++, Java, or CL if you wanted to. It doesn't matter whether you can write imperative code with side-effects and doesn't make those languages any less useful. This purity thing that the Haskell-zealots are on about just stinks of bullish*t and it's not good for you. That being said, Haskell does do some neat things and there is a lot to learn from it. It's type-inference lets it do some neat things like parallel maps and so forth. It also shows us that laziness is not always a good default. I'm not hating on Haskell but anyone who drools over its, "purity," is not saying much at all. Purity is not an attribute that wins you any battles.

riffraff 14y ago
> Dynamic variables (a very specific term in CL) are simply awesome. I may be wrong but I think the name is rather common outside CL too (assuming you refer to "variables with dynamic scope rather than lexical"). E.g. as we are talking of scala http://www.scala-lang.org/api/current/scala/util/DynamicVariable.html http://www.scala-lang.org/api/current/scala/util/DynamicVari...
- agentultra 14y ago
  Sorry, didn't mean to imply it was a feature unique to CL.
enigmo 14y ago
Type-inference doesn't provide anything related to parallel maps, though Haskell's type system can verify that they're safe. Switching an arbitrary loop to a parallel one in C#, Scala, Java, whatever, is certainly a crapshoot. The real benefit to purity and laziness (imo) is the STM. The type system (and pure functions) allow rerunning transactions arbitrarily without worry about side effects, and laziness by default minimizes lock contention by deferring most code execution outside of the transaction block. Joe Duffy has a pretty good writeup a few years ago outlining the difficulty of writing an STM for languages without such guarantees, it's definitely worth a read: http://www.bluebytesoftware.com/blog/2010/01/03/ABriefRetrospectiveOnTransactionalMemory.aspx http://www.bluebytesoftware.com/blog/2010/01/03/ABriefRetros...