3 ms·

> This has always been my problem with Haskell; it is beautiful, but it is useless for hacking. Don't confuse a lack of experience and skill with an advanced t

> This has always been my problem with Haskell; it is beautiful, but it is useless for hacking. Don't confuse a lack of experience and skill with an advanced tool's (Haskell in this case) lack of practical value. It's one thing to say "Haskell takes a long time to become useful for the average person" and another to say "Haskell is useless for hacking (as in quick prototyping as I understand from your article)". I, for one, can produce quick mock-ups and prototypes way faster in Haskell than in any other language I know; and I consider myself an advanced user of Ruby and Python. You need to, of course, absorb and internalize a large number of use cases and concepts in Haskell before you get to this point, but it is quite extraordinary once you're there. High expressiveness, modeling to fit the domain even for small, one-off tasks (thanks to algebraic data types) and many other elegant aspects all become second nature and really really fast once you're expert enough. dons' slides come to mind as a presentation on a related topic if anyone's interested[1]. [1]: http://donsbot.files.wordpress.com/2009/01/semicolon.pdf http://donsbot.files.wordpress.com/2009/01/semicolon.pdf

TylerE 15y ago
But that is I think OP's point, Haskell forces you to "model", versus something like scheme or python where you can just sling dicts around. Haskell absolutely forces you to do a non-trivial amount of thinking up front, which is counter-productive when you're trying to throw something together in 10 minutes.
- DanWaterworth 15y ago
  You can sling dicts around in Haskell too if you want to. The reason people don't is that the alternative is easier.
  - jayferd 15y ago
    +100. That's one of the things I love about Haskell - it makes the "right" things easy and the "wrong" things hard.
  - TylerE 15y ago
    But, if I remember correctly, the haskell map is typed, isn't it? In python you can mix the types of both keys and values in a single dict freely.
    - jrockway 15y ago
      You can easily define your own type that is "everything". But how useful is a dict in python with keys and values of varying types? I've certainly never used one.
      - TylerE 15y ago
        It's very useful. Use it like you'd use a bare object in Javascript, as a freeform data container to hold whatever properties you need. A bit like a key-value NoSQL store, actually.
        jrockway 15y ago
        Values, yes, but keys?
        TylerE 15y ago
        Sure, why not. I mean, I can't offhand of a time that I've really used mixed keys, but I also can't come with any compelling reason why it's a bad idea. Ad-hoc data comes up all the time.
    - deleted 15y ago
      [deleted]
    - DanWaterworth 15y ago
      It's possible in Haskell: {-# LANGUAGE ExistentialQuantification #-} import Data.Maybe import Data.Typeable import Data.Dynamic import Data.Map (Map) import qualified Data.Map as M data Orderable = forall a. (Ord a, Typeable a) => Orderable a instance Eq Orderable where (Orderable a) == (Orderable b) = case cast b of Just b' -> a == b' Nothing -> False instance Ord Orderable where (Orderable a) < (Orderable b) = case typeOf a `compare` typeOf b of GT -> False LT -> True EQ -> a == fromJust (cast b) a > b = b < a a <= b = not (a > b) a >= b = not (a < b) toOrd :: (Ord a, Typeable a) => a -> Orderable toOrd = Orderable fromOrd :: (Ord a, Typeable a) => Orderable -> Maybe a fromOrd (Orderable a) = cast a m1 = M.empty m2 = M.insert (toOrd "hello world") (toDyn (4 :: Int)) m1 m3 = M.insert (toOrd True) (toDyn "foo") m2 m4 = M.insert (toOrd (5 :: Int)) (toDyn False) m3 main = print ((fromJust (fromDynamic (fromJust (M.lookup (toOrd "hello world") m4)))) :: Int)
  - stcredzero 15y ago
    You can sling dicts around in Haskell too if you want to. The reason people don't is that the alternative is easier. This is extraordinary if it is true -- it would mean something in Haskell has succeeded in making the designed/intended "right way" in a programming language the "easy way." I'm not so sure finding the right way to design a language/environment is right for a sole design focus anymore. A programming language/environment should be designed to unify and leverage the power of a community, in a way that elevates it above the level of "pop culture." (Where a pop culture is defined as one where the rate of change far outstrips the growth of actual value/knowledge.)

TylerE 15y ago

But that is I think OP's point, Haskell forces you to "model", versus something like scheme or python where you can just sling dicts around. Haskell absolutely forces you to do a non-trivial amount of thinking up front, which is counter-productive when you're trying to throw something together in 10 minutes.

DanWaterworth 15y ago
You can sling dicts around in Haskell too if you want to. The reason people don't is that the alternative is easier.
- jayferd 15y ago
  +100. That's one of the things I love about Haskell - it makes the "right" things easy and the "wrong" things hard.
- TylerE 15y ago
  But, if I remember correctly, the haskell map is typed, isn't it? In python you can mix the types of both keys and values in a single dict freely.
  - jrockway 15y ago
    You can easily define your own type that is "everything". But how useful is a dict in python with keys and values of varying types? I've certainly never used one.
    - TylerE 15y ago
      It's very useful. Use it like you'd use a bare object in Javascript, as a freeform data container to hold whatever properties you need. A bit like a key-value NoSQL store, actually.
      - jrockway 15y ago
        Values, yes, but keys?
        TylerE 15y ago
        Sure, why not. I mean, I can't offhand of a time that I've really used mixed keys, but I also can't come with any compelling reason why it's a bad idea. Ad-hoc data comes up all the time.
  - deleted 15y ago
    [deleted]
  - DanWaterworth 15y ago
    It's possible in Haskell: {-# LANGUAGE ExistentialQuantification #-} import Data.Maybe import Data.Typeable import Data.Dynamic import Data.Map (Map) import qualified Data.Map as M data Orderable = forall a. (Ord a, Typeable a) => Orderable a instance Eq Orderable where (Orderable a) == (Orderable b) = case cast b of Just b' -> a == b' Nothing -> False instance Ord Orderable where (Orderable a) < (Orderable b) = case typeOf a `compare` typeOf b of GT -> False LT -> True EQ -> a == fromJust (cast b) a > b = b < a a <= b = not (a > b) a >= b = not (a < b) toOrd :: (Ord a, Typeable a) => a -> Orderable toOrd = Orderable fromOrd :: (Ord a, Typeable a) => Orderable -> Maybe a fromOrd (Orderable a) = cast a m1 = M.empty m2 = M.insert (toOrd "hello world") (toDyn (4 :: Int)) m1 m3 = M.insert (toOrd True) (toDyn "foo") m2 m4 = M.insert (toOrd (5 :: Int)) (toDyn False) m3 main = print ((fromJust (fromDynamic (fromJust (M.lookup (toOrd "hello world") m4)))) :: Int)
- stcredzero 15y ago
  You can sling dicts around in Haskell too if you want to. The reason people don't is that the alternative is easier. This is extraordinary if it is true -- it would mean something in Haskell has succeeded in making the designed/intended "right way" in a programming language the "easy way." I'm not so sure finding the right way to design a language/environment is right for a sole design focus anymore. A programming language/environment should be designed to unify and leverage the power of a community, in a way that elevates it above the level of "pop culture." (Where a pop culture is defined as one where the rate of change far outstrips the growth of actual value/knowledge.)