5 ms·
While I agree that Haskell is a great language and everyone should learn it because it's fun to play with it, I think solution to author's problems (and as a cu
by k_bx 13y ago
While I agree that Haskell is a great language and everyone should learn it because it's fun to play with it, I think solution to author's problems (and as a current evolution step) would be something like Kotlin.
It's Java-like language (no need to manage pointers), and it doesn't have null-pointer problem, but it's still high-level imperative OOP language.
While many people say that they're code in Haskell is easier to read, since it has this "side-effect-free" guarantees, for me it seemed as not true for some time recently. In Haskell, when your code gets complicated (and starts to have some patterns you want to omit in typing), you start writing Monads. And when you start writing monads, your code gets harder to read since you need not only consider the code, but also keep (>>=) operator (all of them, if you use multiple monads combined via transformers) in your head for every pair of lines. Your code can suddenly have something like global variables (dynamic scoping) hidden in monad (as with State monad), it's flow can be changed dramatically and different other surprises.
- ExpiredLink 13y agoThe Haskell hype is already over the top.
- mercurial 13y agoHaskell gives you referential transparency and immutability guarantees, something you'll never get in Kotlin. That said, I agree that Haskell code is typically dense, and suffers from readability problems.
- k_bx 13y agoYeah, I'm just saying that referential transparency and immutability often turn into a lie, since this code: https://gist.github.com/k-bx/594a415a06fdd0fc3841 https://gist.github.com/k-bx/594a415a06fdd0fc3841 could easily put 2 different values into `a` on each line. Of course, technically everything is still correct, and getA still returns same result for each call.
- mercurial 13y agoEr, but that's not the same 'a', it's two different bindings with the same name, and you should get: foo.hs:3:9: Warning: This binding for `a' shadows the existing binding bound at ... when you compile with -Wall.
- k_bx 13y agoYes. You're free to rename second a to b. The point I wanted to make is that it's the same getA, but anyone reading the code should understand that result binded to a and b will be different.
- mercurial 13y agoDepending on the monad. If you are in Reader and getA == ask, a and b will have the same value. If you are in IO and getA == getLine, a and b may be different.
- k_bx 13y agoThe whole point I was talking about is that as soon as you're in monad, referential transparency becomes a bit a "lie", and a <- getA, b <- getA becomes non just analogous to a = getA(); b = getA();, but even worse in "referential transparency" sense.
- chongli 13y agoReferential transparency is not a lie; getA is just a value. It could be substituted for its meaning without altering the program. For example, the following program: foo = do a <- getA putStrLn ("Hello, " ++ a ++ "!") where getA = do putStrLn "What is your name?" getLine Is equivalent to: bar = do a <- do putStrLn "What is your name?" getLine putStrLn ("Hello, " ++ a ++ "!")
- 13y ago
- happy_dino 13y agoJudging from the article, languages like C# or F# won't fit his bill. Why would a language which is so far behind C#/F# be a solution?
- k_bx 13y agoI don't understand why wouldn't F# fit. And C#, if I'm not mistaken, wouldn't fit because of null-pointer problem.