~~

Reading lots on Haskell recently I’m beginning to feel like it’s very cool from the CS point of view, but too overcomplicated from the practical one. And all attempts to prove otherwise, as far as I think of them, have failed.

I mean, you can definitely write a useful Haskell application but isn’t the cost too high? Isn’t after all its type system too restrictful? Doesn’t messing with ErrorT IO seem to be much ado about nothing?

Yes, it’s cool when you can reason about your programs in almost mathematical sense. It’s great that you can model the domain with types. It’s nice to have lazy pure code… But when you come to side-effects, stateful computation, error handling, &c simultaneously… Well it starts to feel wrong. Just wrong.

All these are just my thoughts based on short time of learning it. Maybe I’m just too stupid. Maybe I will have this “a-ha!” with Haskell sometime so everything will seem natural to me. But maybe Haskell is just too overcomplicated for actual programming.

It feels like Haskell is actually like maths. Mathematics is all very consistent, you can reason about anything there, you can prove theorems, but when things get complicated they get REALLY complicated. And there is no shortcuts or something like that. And as even tensors don’t fit in my head really well, Haskell may not too.

Think of it like having a programmer to study algebraic geometry for example. Though Haskell seems to be lots easier.

To better understand State monad I have derived it step by step from do notation to it’s constructor form. So to keep the result I post it here.
This is executable Haskell. Save as haskell file & try to run execState tickN 5 for every tickN.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

module StRed where
import Control.Monad.State
 
{-- Just for reference.
-- | A parameterizable state monad where /s/ is the type of the state
-- to carry and /a/ is the type of the /return value/.
newtype State s a = State { runState :: s -> (a, s) }
 
instance Monad (State s) where
    return a = State $ \s -> (a, s)
    m >>= k  = State $ \s -> let
        (a, s') = runState m s
        in runState (k a) s'
 
instance MonadState s (State s) where
    get   = State $ \s -> (s, s)
    put s = State $ \_ -> ((), s)
--}
 
-- This monad is able to add one to its internal state.
tick :: State Int Int
tick = do n <- get
          put (n+1)
          return n
 
-- What follows is a derivation of this monad into its normal form.
-- Please note, that this derivation doesn't respect Haskell's order of evaluation.
tick1 :: State Int Int
tick1 = get >>= (\n -> put (n+1) >>= (\_ -> return n))
tick2 = (State (\s -> (s,s))) >>=
              (\n -> (State (\_ -> ((), (n+1)))) >>=
                  (\_ -> (State (\p -> (n, p)))))
tick3 = (State (\s -> (s,s))) >>=
              (\n -> (State (\q -> let
                  (a, q') = runState (State (\_ -> ((), (n+1)))) q
                  in runState ((\_ -> (State (\p -> (n, p)))) a) q')))
tick4 = (State (\s -> (s,s))) >>=
              (\n -> (State (\q -> let
                  (a, q') = ((), (n+1))
                  in (n, q'))))
tick5 = (State (\s -> (s,s))) >>=
              (\n -> (State (\_ -> (n, n+1))))
tick6 = State (\p -> let
              (a, p') = runState (State (\s -> (s, s))) p
              in runState ((\n -> (State (\_ -> (n, n+1)))) a) p')
tick7 = State (\p -> let
              (a, p') = (p, p)
              in (a, a+1))
tick8 = State (\p -> (p, p+1))
 
-- So, here you are. This monad contains function which returns current state,
-- and changes internal state by adding one. Exactly what we supposed.
-- Now, when you run it with execState it's easy to see how it works.
a = execState tick8 3
a1 = snd (runState tick8 3)
a2 = snd ((\p -> (p, p+1)) 3)
a3 = snd (3, 4)
a4 = 4
 
-- In fact, I think this monad is easy to write in tick8 form right from the beginning =)

Hope this would help someone.

Working through a few tutorials and books on Haskell I think I’m starting to feel that it’s all very good until it comes to Stateful Fucking Computations.

Well, I know that I do not know Haskell. And I know that I cannot wrap may head around all of its concepts right now (Monad Transformers? Arrows for god’s sake?). But on the other hand I see how it becomes, well, almost explosionary more compilcated as you start adding Stateful Fucking Stuff. Monad + Monad + Monad Transformer + Another one… And if you just have missed somehow that you will need, e.g. ST + IO + Error, and have just implemented smth without Error… Well welcome to ErrorT rewriting of great bunch of you functions. And it doesn’t seem to be always easy.

And of course I still have troubles with types. X :: A b c d WTF? Don’t yet clearly understand the difference between type, newtype & data. Well data is for algebraic datatypes. But type and newtype do somewhat confuse me.

And actually, writing an interpreter seems to be much harder (Parsec, State, IO through most of the program, Error throwing anywhere) than writing a compiler (Parsec -> Tree, work on the tree in a purely functional manner, generate code in a purely functional matter, you will only have to handle errors somehow in a good way. But I think it’s not that hard to do this w/o using monads here, actually. And IO only for Input once & Output once, all in main :: IO ()).

Frankly, Scheme seems to be MUCH easier to grasp. But after all, that’s one of the points why I actually did start to grok Haskell.

Good luck me.