|
|
|
|
|
by ArchReaper
2313 days ago
|
|
As a non-Haskell-er, this article is impossible to follow. I have tried to learn Haskell a few times, always unsuccessfully. Haskell code is filled with so many Haskell-specific things. I realize the goal isn't to be an 'easy' language, but jeez. Aside from the horrendous variable naming, I'm having trouble understanding what the author actually accomplished, and why it's necessary for a tool like this to exist in the first place. Can anyone translate the problem into a more simplified, non-Haskell-specific version? > jonk :: (a -> b) -> ((a -> Int) -> Int) -> ((b -> Int) -> Int) I have no idea what this line means. To me, it looks like he wants to write a transformer that matches a specific signature, and he uses a tool that tells him which functions can fit the 'hole' he has in the code, based on types. If I'm correct (I'm assuming I'm not), how is this different than intellisense in an IDE that tells you a list of type-valid functions/variables? Why is this a necessary part of the Haskell coding process? My first instinct is that this demonstrates a problem with the language, if something like this is necessary. Appreciate anyone that tries to explain. I know most of my assumptions are probably wrong. |
|
I suspect that people wanting to learn Haskell actually want to learn a statically typed functional programming language. And if you also want that language suitable to everyday problems, the kind of things you are dealing with at work, then Haskell is probably not the best one to start with.
I love how Scott Wlaschin presents statically typed functional programming languages as straightforward and pragmatic solutions to everyday problems:
https://www.youtube.com/watch?v=PLFl95c-IiU
https://pragprog.com/book/swdddf/domain-modeling-made-functi...
Once you're comfortable with that (and the way it is presented here really isn't very complex) then Haskell becomes a lot easier to understand.
But Haskell is very distracting because it is much more expressive and complex than than ML dialects for example, so it will be a big learning curve before someone is comfortable reading someone else's Haskell code. For other statically typed functional programming languages (f.i. OCaml/ReasonML, F#, Elm) that is not the case.