Do I really want to be using a language where memoize is a PhD-level topic?

The original poster obviously enjoys learning new things: he posts on the Clojure mailing list, and hints that he has learned bits and pieces of Haskell. That places him early in the adoption curve. But when you want a language to get things done (one you can "use"), work from a comfort zone - start with a steady base, and branch out to unfamiliar topics. Some people are comfortable finding and reading academic papers as part of their workflow, and others aren't. That's their preference.

Other parts of your time should be spent the opposite way: start at the unfamiliar, and make it familiar. But it's not pragmatic to always work like this.

If not, your "conclusion that Haskell's differences are what throw people off" is incorrect.

I don't think the author of the email is "stereotyping the Haskellers as a bunch of ivory tower PhDs", he's relating a story that's actually true of finding out that a basic technique he wanted to implement was most easily implemented by following the technique in a PhD thesis.

  Everyone, please refrain from language wars. Haskell is a tremendously
  ambitious and inspiring language, for which I have the highest
  respect. There is zero point in bashing it (or its users) in this
  forum.

    import Data.Array
    
    f :: Integer -> Integer
    f n = sum [0..n]
    
    largeNumber = round 2e6 :: Integer
    
    memo_f :: Array Integer Integer
    memo_f = listArray (0,largeNumber) [ (f n) | n <- [0..largeNumber] ] 
    
    
    main = do
        putStrLn (show (memo_f!largeNumber))     -- slow
        putStrLn (show (memo_f!(largeNumber-1))) -- slow
        putStrLn (show (memo_f!(largeNumber)))   -- fast
        putStrLn (show (memo_f!(largeNumber-1))) -- fast
        putStrLn (show (memo_f!(largeNumber-2))) -- slow
        putStrLn (show (memo_f!(largeNumber-3))) -- slow
        putStrLn (show (memo_f!(largeNumber)))   -- fast
        putStrLn (show (memo_f!(largeNumber-2))) -- fast
        putStrLn (show (memo_f!(largeNumber-4))) -- slow
        putStrLn (show (memo_f!(largeNumber-5))) -- slow

So it isn't intuitive to you that an empty object and array should both evaluate to true, but neither are equal to true, the empty array is equal to false, and the empty object is neither equal to true _or_ false?

Yes and no. As with many other things, there's a tradeoff between Haskell's purity and referential transparency and side-effecting constructs such as storing stuff in a local cache, which is what memoization does. You can't litter printfs or cache calls throughout your pure functions either, "for some reason". It makes sense that's it's a pain to do in a (non-IO/state) haskell function, because those are very much about mixing side-effects into the code.

A better solution would probably be to integrate memoization at the runtime level, with some compiler hints maybe. That way it becomes an implementation detail not an imperative side-effect, and the world is pure again.

Anyway yeah, if you can't bear with Haskell's constraints you can just use something else, such as MLs (in order not to give up static type safety). Whoop the fucking do.

You see, I would love to love Haskell but in practice the language just always turns out to be an overly intellectual exercise. Real world programs need to manage state, preferably in a very controlled way, but the bottom line is that they need to do that in some obvious and easy way.

It doesn't help if you explain me that you really don't need to explicitly store state anywhere, that you can just use monads to carry it over from computation to computation. Monads are an interesting abstraction per se but I don't want to use such heavy-weight artillery to make a mere assignment, to write a pointer to memory. I want my language to put some effort in protecting myself from the hazards of unintended concurrency but when I want to do it, the language must obey.

That said, Clojure is just perfect. For now, Clojure is my Blub.

This isn't "smart people showing off about how clever they can be", it's people giving names to things that they use everyday.

The problem people have with monads is that the word "Monad" does not describe something they're used to dealing with. A computer programmer is used to concrete things like lists, trees, functions, compilers; things you could hold in your hand (or at least draw on a whiteboard), poke at, and observe.

Monads can't be understood in this way, because they are not anything concrete; "Monad" is a word to describe concrete things that, individually, are all very different. It's like explaining the concept of "Green" to someone by showing them an apple, a tennis ball, and some grass clippings. They will never understand "Green", because you can't understand what Green is by seeing three examples of them. Green is a color, not some sort of weird tennis-ball-apple-grass-clipping hybrid.

Monads are the same way. List is a Monad. Reader is a Monad. State is a Monad. But when you look at these things and try to generalize, you might not see the parts that are the same, because the parts that are the same that make them all monads are hard to see.

I think the hard part is that you hear about what defines a monad ("return" and "bind" or "return", "fmap", and "join"), and don't see how some dual or triple like that helps you write computer programs. Each set of functions is so different from the other sets that the fact that they are all called "return" and "bind" doesn't seem to matter. And that's exactly right; at some level, it doesn't matter.

You use a List as a monad to combine computations that return multiple values, and you use Cont to write your programs in a continuation-passing style. Very different. Nothing similar at all, really. On the concrete level.

The similarity does matter at a higher level, though; noticing similarities means you can write parts of your program in advance, and just tweak those parts for each specific case.

An example is liftM2; it abstracts away the tedium of using a calling a two-arg function with monad-like semantics. If there were no similarities between List and Maybe, you'd have to write something like this:

   liftList2 f xs ys = concat $ (\x ->
                                 concat $ (\y -> [f x y])
                                          `map` ys)
                                 `map` xs

   -- this doesn't compile; I want to use more descriptive words than the Data.Maybe API does :)
   liftMaybe2 f x y = if has x then extract x -> \x'
                          if has y then extract y -> \y'
                                           makeMaybe f x' y'
                          else Nothing
                      else Nothing

   liftList2 (,) [1,2] [3,4]      ==> [(1,3),(1,4),(2,3),(2,4)]
   liftList2 (,) [] [1..infinity] ==> []

   liftMaybe2 (,) (Just 10) (Just 20)     ==> Just (10, 20)
   liftMaybe2 (,) Nothing (Just "oh hai") ==> Nothing

These seem very similar. There is the same sort of nesting in both structures, we seem to be saying the same thing twice in both functions. We seem to be applying functions to values "inside" each of these things.

Maybe we can abstract those things away somehow, and make the two functions look a little more similar:

    newList x = [x]
    fmapList xs f = f `map` xs --
    joinList xs = concat xs

    liftList2 f xs ys = joinList $ fmapList xs $ \x ->
                        joinList $ fmapList ys $ \y ->
                        newList $ f x y
    -- hey, the code looks nicer already!

    newMaybe x = Just x
    fmapMaybe Nothing _ = Nothing
    fmapMaybe (Just x) f = Just $ f x
    joinMaybe Nothing = Nothing
    joinMaybe (Just x) = x

    liftMaybe2 f x y = joinMaybe $ fmapMaybe x $ \x' ->
                       joinMaybe $ fmapMaybe y $ \y' ->
                       newMaybe $ f x' y'

    class Monad m where
        new :: a -> m a
        fmap :: m a -> (a -> b) -> m b
        join :: m (m a) -> m a

    instance Monad [] where -- haskell98 spells List as []
        new  = newList
        fmap = fmapList
        join = joinList

    instance Monad Maybe where
        new  = newMaybe
        fmap = fmapMaybe
        join = joinMaybe

    liftM2 f x y = join $ fmap x $ \x' ->
                   join $ fmap y $ \y' ->
                   new $ f x' y'

"

On Mon, Jul 19, 2010 at 4:34 PM, Jared <tri...@gmail.com> wrote: > I am curious; for the people with Haskell experience why did you decide to use Clojure? I am asking this because Haskell and Clojure seem to solve similar types of problems. When would you want to use Haskell instead of Clojure and visa-versa?

[Mark Engelberg replies]

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?" "