I don't follow it. This is the crux of the article:
> and there is nothing you can do in Haskell that is not data. No logic can be written in Haskell outside of data.
Is he talking about Lisp?
> the often dreaded Haskell monads are really just side effects represented as data.
Nah
> Typeclasses are data ...
Really?
> ... that define certain behaviour, yes, but this behaviour, like all behaviour in Haskell, is merely a rule, a declaration, a law, which states how one piece of data is transformed into another. This is also what functions are.
Yes. Functions. Not data.
Also some bad code in the example:
getNumOfReplacement :: String -> Maybe Char
getNumOfReplacement word
| first_char =='{' && third_char == '}' = Just second_char
| otherwise = Nothing
where first_char = head word
second_char = word !! 1
third_char = word !! 2
getNumOfReplacement' :: String -> Maybe Char
getNumOfReplacement' ('{':x:'}':_) = Just x
getNumOfReplacement' _ = Nothing
> The above algorithm could also be written in a pretty similar way in many other languages, even some non-functional ones. What makes Haskell different however is that this is the only way in which you can do it.
Weird claim! There's loads of ways to do it.
> It forces you to yes, learn some mathematical concepts, but on a more fundamental level to reason about your code only in terms of data and transformations between it.
In terms of data and transformations between it. Not in terms of data and data. Because not everything's data.
To drive home the point that not everything is data and there's more than one way of doing things: there is a known technique for promoting code into data called the free monad & interpreter pattern [1]. You write a bit of boilerplate, which then lets you write business logic functions, which - rather than returning business logic answers - returns something like an AST of the business logic itself. Then you can put that business-logic-AST into different interpreters to execute the same logic in different ways.
2 comments
[ 3.3 ms ] story [ 19.1 ms ] thread> and there is nothing you can do in Haskell that is not data. No logic can be written in Haskell outside of data.
Is he talking about Lisp?
> the often dreaded Haskell monads are really just side effects represented as data.
Nah
> Typeclasses are data ...
Really?
> ... that define certain behaviour, yes, but this behaviour, like all behaviour in Haskell, is merely a rule, a declaration, a law, which states how one piece of data is transformed into another. This is also what functions are.
Yes. Functions. Not data.
Also some bad code in the example:
Verbose and crashy (for inputs "", "{", "{x", ...). Here's better: > The above algorithm could also be written in a pretty similar way in many other languages, even some non-functional ones. What makes Haskell different however is that this is the only way in which you can do it.Weird claim! There's loads of ways to do it.
> It forces you to yes, learn some mathematical concepts, but on a more fundamental level to reason about your code only in terms of data and transformations between it.
In terms of data and transformations between it. Not in terms of data and data. Because not everything's data.
To drive home the point that not everything is data and there's more than one way of doing things: there is a known technique for promoting code into data called the free monad & interpreter pattern [1]. You write a bit of boilerplate, which then lets you write business logic functions, which - rather than returning business logic answers - returns something like an AST of the business logic itself. Then you can put that business-logic-AST into different interpreters to execute the same logic in different ways.
[1] https://www.tweag.io/blog/2018-02-05-free-monads/