On Mon, Jul 19, 2010 at 10:20 PM, Mark Engelberg <mark.engelb...@gmail.com>wrote:
> > I think stateful things are too hard to do in Haskell, and they are an > important part of most real-world programs. Clojure's blend of > persistent data structures with a variety of reference-type objects > that can contain them feels much more pragmatic to me. Also, I'm just > happier working in a dynamically-typed language. > > As a side note, years ago, I wanted to write something in Haskell that > worked like Clojure's memoize (which is implemented in a half-dozen or > so lines of code in Clojure's core), and asked about it on the Haskell > mailing list. I was pointed to a PhD dissertation on the topic of how > to write memoize in Haskell. All I could think was, "Do I really want > to be using a language where memoize is a PhD-level topic?" > > I wasn't going to reply to this, as this isn't the place to do language advocacy. But this comment has made it to the top of both reddit/programming and hacker news, so some sort of response is needed. First of all, it's not that hard to write a memoize function in Haskell. Either recognize that because you're updating state, you need to be in a monad (I'd recommend Control.Monad.State), or use unsafePerformIO. But the real error you committed is one that Clojure newbies make as well, and very much does apply to Clojure. You confused *a* solution to the problem with the problem itself. Memoization is the *solution*- what's the problem? The problem is that you have this value that is very expensive to compute, that you may not need at all, and that you only want to compute once if you do need it. This is a job for lazy evaluation- especially in Haskell where everything is lazily evaluated anyways. Memoization is, in fact, just one way to implement lazy evaluation in languages that are not lazily evaluated. Lazy values are useful in a lot of situations other than lazy lists (aka seqs). Second of all, this is a problem Clojure faces as well! Maybe not around memoization, but definitely around other issues. For example, consider the following: how do you implement a doubly linked list efficiently in Clojure? The answer is: you don't. But a doubly linked list is a solution, not a problem. The problem is that you need a data structure where it is cheap to both add and remove elements from both ends. The proper solution in Clojure is to implement one or another (applicative, lazy) dequeue. But in this case it's very easy for a programmer new to functional languages and Clojure to confuse this solution with this problem- doubly linked lists are the solution for that problem in everything from Cobol and Pascal to Java, C#, Ruby, and Python. "What? You want me to either accept a huge speed and memory hit, drop to Java, or go read some weird book I've never heard of written in yet another programming language nobody uses (ML) just to implement a doubly linked list in Clojure? What sort of stupid language is this?" Here's to hoping that newbies to Clojure don't adopt the same attitude to Clojure you adopted to Haskell. Brian -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
