3 ms·
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 variable
by 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 agoSorry, didn't mean to imply it was a feature unique to CL.
- enigmo 14y agoType-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...