Real World Haskell(mmhaskell.com)
mmhaskell.com
Real World Haskell
https://mmhaskell.com/real-world
78 comments
I thought it was about the book and almost skipped the link. It would help to name it "Real World Haskell 2020" or something distinct.
Exactly. The book can't trademark the name in general use, but it's still crappy hygiene to reuse the exact name. This has to be taken as deliberately drafting the wake of the book, which I cannot respect. Nor can the authors feign ignorance. They decided to do this.
Think the author should pick new title. This is plain confusing.
I also thought it was about the book and almost skipped this until reading your comment.
Interesting. I've been programming in python for more than 4 years and I'd like to try something different.
I took a haskell class back in the day but just the basics, didn't even learn monads.
My goal is not to master the language itself but learn enough to make a better programner.
One thing that has been holding me back is the lack of real world examples. I get demotivated when only solving toy problems.
This looks like a great resource. I have heard a lot about Haskell From First Principles but there's too much stuff in there.
I took a haskell class back in the day but just the basics, didn't even learn monads.
My goal is not to master the language itself but learn enough to make a better programner.
One thing that has been holding me back is the lack of real world examples. I get demotivated when only solving toy problems.
This looks like a great resource. I have heard a lot about Haskell From First Principles but there's too much stuff in there.
To build some real world web applications check out IHP: https://ihp.digitallyinduced.com/
It's a truly batteries-included way to get started with building real world haskell web apps in minutes.
It's a truly batteries-included way to get started with building real world haskell web apps in minutes.
Wow, if that matures, ie gets some real world adopt by serious companies it would be the best thing around.
Much like using Rust and Haskell for web I'd much prefer deferring as much to something like Vue and the server APIs (no sever side rendering for that yet so I mostly just IRL use nuxt.js for toy projects). Something Servant (Haskell) does a clean job of. But you can never completely do away with static heavy lifting
This one takes a more modernized Rails or Elixir's Phoenix approach which is really interesting and looks highly usable.
Community size and quality is everything for real life software (something I remember Clojure had early on and now Rust has in spades, best of breed sort of libraries to choose from) so I hope it gets some adoption to see where it goes. I'll give it a shot to toy around with when I get some time.
Much like using Rust and Haskell for web I'd much prefer deferring as much to something like Vue and the server APIs (no sever side rendering for that yet so I mostly just IRL use nuxt.js for toy projects). Something Servant (Haskell) does a clean job of. But you can never completely do away with static heavy lifting
This one takes a more modernized Rails or Elixir's Phoenix approach which is really interesting and looks highly usable.
Community size and quality is everything for real life software (something I remember Clojure had early on and now Rust has in spades, best of breed sort of libraries to choose from) so I hope it gets some adoption to see where it goes. I'll give it a shot to toy around with when I get some time.
> Make sure you have good internet and can wait up to 30 minutes to complete the download [of version 16.10.2020]. We highly suggest to make sure your coffee machine is working before starting the update.
Wow!
Wow!
If you have good internet connection it's usually downloaded a lot faster. We have switched the nixpkgs version in that version, so a lot of tooling had to be redownloaded. E.g. in our getting started video we install it on a fresh empty macbook: https://www.youtube.com/watch?v=PLl9Sjq6Nzc&feature=youtu.be The full download there takes around 9 minutes on a slow home office internet connection (it's speed up in the video, but you can see the real-world time at the top right).
We mainly added the warning in that release because usually the update process is very smooth and takes only one minute, e.g. see this tweet: https://twitter.com/mittie/status/1322574176792825861
We mainly added the warning in that release because usually the update process is very smooth and takes only one minute, e.g. see this tweet: https://twitter.com/mittie/status/1322574176792825861
That's quite interesting. Thanks for mentioning it!
Step 1: install nix
hmm, no thanks
hmm, no thanks
We did a blog post a while ago sharing why we decided to use nix for all package management aspects of the framework. Take a look: https://ihp.digitallyinduced.com/blog/2020-07-22-why-ihp-is-...
From the blog post...
> Additionally Nix is very hard to install. This is a stumbling block for a lot of people. Especially when using certain macOS systems you cannot even install nix at all. Luckily most of the nix problems, like the macOS issues will be solved with time.
Great choice
> Additionally Nix is very hard to install. This is a stumbling block for a lot of people. Especially when using certain macOS systems you cannot even install nix at all. Luckily most of the nix problems, like the macOS issues will be solved with time.
Great choice
Install nix? Already done. What's the second step?
Why is installing nix any worse than installing some language-specific package manager?
Nix causes a visceral negative reaction in some people.
Why?
It's a complete end-to-end solution with an opinionated approach and unstructured documentation.
That is, the learning curve is very steep.
That said, for new projects I'm doing packaging and containerization in nix, because I don't have the time or mental energy to deal with half-assed solutions anymore.
That is, the learning curve is very steep.
That said, for new projects I'm doing packaging and containerization in nix, because I don't have the time or mental energy to deal with half-assed solutions anymore.
> I don't have the time or mental energy to deal with half-assed solutions anymore.
Exactly. I'd rather solve a problem in Nix then try some working, but half-baked alternative.
Exactly. I'd rather solve a problem in Nix then try some working, but half-baked alternative.
I looked at nix a while ago, concluded the versioning/chesumming is - a given sum should represent kind-of the same thing, but can mean really anything.
There was even a post on how to have a stable version for a tracking branch.
Now, I wouldn't mind, if it were explained exactly what guarantees the hashing provided, but there seemed to be pervasive misconception on what it provides.
There was even a post on how to have a stable version for a tracking branch.
Now, I wouldn't mind, if it were explained exactly what guarantees the hashing provided, but there seemed to be pervasive misconception on what it provides.
You might want to give a try to Elm. Most of the Haskell goodies but way simpler, except no type classes and too restrictive.
Not used Elm since early 2014 and heard it’s changed a bit since then.
Elm was a great Trojan horse. It limited feature set made it quick to learn and get familiar with the syntax.
When sufficiently proficient in Elm you then find yourself missing some of the features of Haskell i.e. higher kinder types. At that stage Purescript / Haskell is a natural transition as they feel familiar but with more functionality.
Elm was a great Trojan horse. It limited feature set made it quick to learn and get familiar with the syntax.
When sufficiently proficient in Elm you then find yourself missing some of the features of Haskell i.e. higher kinder types. At that stage Purescript / Haskell is a natural transition as they feel familiar but with more functionality.
Learning Haskell sideways is a good approach. There are so many usecases in JS as well and Typescript has made it all the better (but not nearly so restrictive).
Then PureScript also deserves a mention. It has several frameworks (some akin to the one built in in Elm). If you want to do this in Haskell (which is a lot harder) you may want to look at Miso.
+1 for Elm to learn Haskell. It is indeed way simpler, and has very friendly error messages. It lets you concentrate on grokking the basics: no side effects, pattern matching, recursion, currying.
After some time you start wondering why you have to type `List.map` and `Maybe.map` and `Set.map` when they all do the same thing. Then you'll be ready for some Haskell :)
After some time you start wondering why you have to type `List.map` and `Maybe.map` and `Set.map` when they all do the same thing. Then you'll be ready for some Haskell :)
Thanks for the suggestion. I've heard people suggesting Elm on reddit but in terms of learning materials there isn't much compared to haskell. But I think that shouldn't be much of a problem.
I know that Elm works great for front end but how is it for desktop and backend stuff?
I know that Elm works great for front end but how is it for desktop and backend stuff?
> I know that Elm works great for front end but how is it for desktop and backend stuff?
It isn't. It's explicitly designed as a purely web front-end language, that's its scope.
Of course, many Elm users like to run another ML-family language in the backend as well. Haskell's Servant backend library, the one used in this article, has a project to automatically generate Elm client code [1]. Elixir is popular as well.
But in general, I'd say that any backend framework that can provide an OpenAPI spec will work well, as you'll be able to auto-generate most if not all of the Elm client code (which is normally dull work and one of the main complaints about Elm).
[1] https://github.com/haskell-servant/servant-elm
It isn't. It's explicitly designed as a purely web front-end language, that's its scope.
Of course, many Elm users like to run another ML-family language in the backend as well. Haskell's Servant backend library, the one used in this article, has a project to automatically generate Elm client code [1]. Elixir is popular as well.
But in general, I'd say that any backend framework that can provide an OpenAPI spec will work well, as you'll be able to auto-generate most if not all of the Elm client code (which is normally dull work and one of the main complaints about Elm).
[1] https://github.com/haskell-servant/servant-elm
Yes, no desktop and backend. It might be possible to use Elm outside of web frontend, but probably wouldn't be much fun.
> in terms of learning materials there isn't much compared to haskell.
To whet your apetite, see https://elm-lang.org/
Then read through the excellent https://guide.elm-lang.org/ - not very long but absolutely enough to hit the ground running.
> in terms of learning materials there isn't much compared to haskell.
To whet your apetite, see https://elm-lang.org/
Then read through the excellent https://guide.elm-lang.org/ - not very long but absolutely enough to hit the ground running.
Agreed official elm guide is more than enough to get “started” with real world examples.
> One thing that has been holding me back is the lack of real world examples. I get demotivated when only solving toy problems.
I looked at haskell a few months ago and had a similar problem.
While I don't mind the toy problems, all those toy problems have something in common...
They can be easily solved with recursion. There are probably patterns to deal with other problems and this would have been more interesting to me.
I just had to think to myself: "If all you have is recursion every tutorial looks like a parser" ;)
I looked at haskell a few months ago and had a similar problem.
While I don't mind the toy problems, all those toy problems have something in common...
They can be easily solved with recursion. There are probably patterns to deal with other problems and this would have been more interesting to me.
I just had to think to myself: "If all you have is recursion every tutorial looks like a parser" ;)
Recursion is equivalent to iteration. You can solve any problem you like with it.
The problem with those tutorials is that they’re trying to do two things at once: 1) teach you Haskell and 2) advocate for Haskell.
I’m currently working as a full time assistant for one of the first year computer science courses at my university. This course is taught in a teaching dialect of Racket which does not allow mutation or side effects of any kind.
That doesn’t stop the profs from creating assignments with real world applicability such as graffiti stroke recognizers and decision tree learning algorithms. The key is that they’re not trying to make Racket look good, so the patterns of recursion can get pretty ugly at times.
The problem with those tutorials is that they’re trying to do two things at once: 1) teach you Haskell and 2) advocate for Haskell.
I’m currently working as a full time assistant for one of the first year computer science courses at my university. This course is taught in a teaching dialect of Racket which does not allow mutation or side effects of any kind.
That doesn’t stop the profs from creating assignments with real world applicability such as graffiti stroke recognizers and decision tree learning algorithms. The key is that they’re not trying to make Racket look good, so the patterns of recursion can get pretty ugly at times.
> Recursion is equivalent to iteration. You can solve any problem you like with it.
Maybe my comment was somehow badly written, because you (and the only other reply from chriswarbo) clearly misunderstood me.
I know that recursion is equivalent to iteration^^
My point was that some problems fit the one or the other better.
Look at fft for example. The algorithm is easy with recursion but hard with iteration. For other problems its the opposite.
Maybe my comment was somehow badly written, because you (and the only other reply from chriswarbo) clearly misunderstood me.
I know that recursion is equivalent to iteration^^
My point was that some problems fit the one or the other better.
Look at fft for example. The algorithm is easy with recursion but hard with iteration. For other problems its the opposite.
Which problems are hard to solve with recursion instead of iteration?
I found something like splitting a string into words not very intuitive...
Also the classical (recursive) fibonacci function everyone shows has accidental complexity of O(2^n). If you want a sane version it looks definitely more complicated than the iterative version.
I never saw a recursive version of bresenham's line plotting algorithm so this might be a good candidate as well ;)
Also the classical (recursive) fibonacci function everyone shows has accidental complexity of O(2^n). If you want a sane version it looks definitely more complicated than the iterative version.
I never saw a recursive version of bresenham's line plotting algorithm so this might be a good candidate as well ;)
I found something like splitting a string into words not very intuitive...
Just use a couple of accumulators (one for the current word, one for the list of completed words).
Also the classical (recursive) fibonacci function everyone shows has accidental complexity of O(2^n).
That's moving the goalposts. If you want a really fast fibonacci function then the classical iterative algorithm [which is O(n)] is not what you want either. Better to use matrix exponentiation which you can implement nicely with recursion using a divide-and-conquer approach similar to mergesort, giving you fibonacci with time O(log(n)).
I never saw a recursive version of bresenham's line plotting algorithm so this might be a good candidate as well ;)
There's nothing special about Bresenham's line algorithm that would make it particularly challenging to implement with recursion.
Just use a couple of accumulators (one for the current word, one for the list of completed words).
Also the classical (recursive) fibonacci function everyone shows has accidental complexity of O(2^n).
That's moving the goalposts. If you want a really fast fibonacci function then the classical iterative algorithm [which is O(n)] is not what you want either. Better to use matrix exponentiation which you can implement nicely with recursion using a divide-and-conquer approach similar to mergesort, giving you fibonacci with time O(log(n)).
I never saw a recursive version of bresenham's line plotting algorithm so this might be a good candidate as well ;)
There's nothing special about Bresenham's line algorithm that would make it particularly challenging to implement with recursion.
> splitting a string into words not very intuitive
It seems okay?
It seems okay?
split :: String -> [String]
split s = w s "" where
w [] "" = []
w [] a = [reverse a]
w (' ':ss) "" = w ss ""
w (' ':ss) a = reverse a : w ss ""
w (c:ss) a = w ss (c:a)
Yeah it's ok ;) Going back to my original comment this code is exactly what I meant with "patterns to deal with other problems". You clearly used a pattern (accumulator) with wich you are familiar.
Do you agree that most imperative programmers would not come up with this solution on their own, if you didn't teach them the "accumulator pattern"?
For me personally a tutorial with a lot code like that would be interesting.
Showing me another version of a recursive descent parser doesn't teach me anything, because I know how to write it (with recursion!!!) in an imperative language...
Do you agree that most imperative programmers would not come up with this solution on their own, if you didn't teach them the "accumulator pattern"?
For me personally a tutorial with a lot code like that would be interesting.
Showing me another version of a recursive descent parser doesn't teach me anything, because I know how to write it (with recursion!!!) in an imperative language...
> You clearly used a pattern (accumulator) with wich you are familiar.
No, I didn't, and please refrain from imputing thought processes without evidence. I didn't even think the word "accumulator" until I got to the last paragraph and needed a term to describe the second argument to w.
> Do you agree that most imperative programmers would not come up with this solution on their own
If we assume most imperative programmers are idiots as a special case of most people are idiots, sure. I'm not sure that's a good assumption or particularly relevant, though.
> Showing me another version of a recursive descent parser doesn't teach me anything
Ah, I think I misunderstood your point, then:
> > Which problems are hard to solve with recursion instead of iteration?
> I found something like splitting a string into words not very intuitive...
I assumed you meant that "splitting a string into words" was a example of a problem that was hard to solve with recursion (which I found rather puzzling, because as my example shows, it really isn't), rather than that it wasn't a good/intuitive example to illustrate recursion in the general case (which makes a quite a bit more sense, and I'm afraid I don't have a immediate solution to, sorry).
No, I didn't, and please refrain from imputing thought processes without evidence. I didn't even think the word "accumulator" until I got to the last paragraph and needed a term to describe the second argument to w.
> Do you agree that most imperative programmers would not come up with this solution on their own
If we assume most imperative programmers are idiots as a special case of most people are idiots, sure. I'm not sure that's a good assumption or particularly relevant, though.
> Showing me another version of a recursive descent parser doesn't teach me anything
Ah, I think I misunderstood your point, then:
> > Which problems are hard to solve with recursion instead of iteration?
> I found something like splitting a string into words not very intuitive...
I assumed you meant that "splitting a string into words" was a example of a problem that was hard to solve with recursion (which I found rather puzzling, because as my example shows, it really isn't), rather than that it wasn't a good/intuitive example to illustrate recursion in the general case (which makes a quite a bit more sense, and I'm afraid I don't have a immediate solution to, sorry).
> No, I didn't, and please refrain from imputing thought processes without evidence.
There where at least two other replies talking about accumulators. I call that pattern, like it or not.
Have you even heard of programming patterns?
> If we assume most imperative programmers are idiots as a special case of most people are idiots, sure.
The other reply from chongli seems to disagree with you ;)
Also suggesting that I'm stupid is no constructive style of argumentation.
> rather than that it wasn't a good/intuitive example to illustrate recursion
You are still misunderstanding me but a genius like you are should be able to figure that out.
I now understand what my teacher meant when he said:
"Haskell is a genius language but I don't like the community,"
There where at least two other replies talking about accumulators. I call that pattern, like it or not.
Have you even heard of programming patterns?
> If we assume most imperative programmers are idiots as a special case of most people are idiots, sure.
The other reply from chongli seems to disagree with you ;)
Also suggesting that I'm stupid is no constructive style of argumentation.
> rather than that it wasn't a good/intuitive example to illustrate recursion
You are still misunderstanding me but a genius like you are should be able to figure that out.
I now understand what my teacher meant when he said:
"Haskell is a genius language but I don't like the community,"
Hey, another Haskeller here!
> There where at least two other replies talking about accumulators. I call that pattern, like it or not.
It's true that you use this way of programming so often in functional languages that it earned itself a name, so that it's easier to talk about it. However calling it a 'pattern' feels weird (to me), even though it technically is one.
The equivalent of accumulators in imperative languages would be the 'pattern' of having some variables outside of the loop and mutating them from within the loop. Maybe you can appreciate that it feels weird calling this a 'pattern' — and now you can better understand how I feel about accumulators being called a pattern.
Skipping back to your original question: I write Haskell for living and teach two high-school classes in another functional language, and the only two 'patterns' regarding recursion I can think of are accumulators and mutual recursion. So, you know almost everything there is to know already! :-) [0]
Let me add that you use recursion very rarely in day-to-day programming; mostly you try to spare yourself writing the recursion explicitly and you instead use map, filter and foldr/foldl (sometimes called reduce) to do the recursion for you. Especially the folds are super-powerful (AFAIK you can write any recursive function using folds, should you wish to do so), and often under-appreciated.
> Haskell is a genius language but I don't like the community
IMHO the community around Haskell is (in general) great; the people are always eager to help. I'm a self-learned Haskeller and I couldn't have done it without the community. Come join us at r/haskell or the IRC and see for yourself :-)
[0]: Why do I say this? I remember my old days when I was learning Swift and encountered one new design pattern every day. Factory, Facade, ... I decided to get 'em all (why reinvent the wheel?), I was always anxious that I was coding something that could be better served by a ready-made design pattern. So I just wanted to let you know it's nothing like this with recursion, and that you can save yourself the anxiety (if you are anything like me).
> There where at least two other replies talking about accumulators. I call that pattern, like it or not.
It's true that you use this way of programming so often in functional languages that it earned itself a name, so that it's easier to talk about it. However calling it a 'pattern' feels weird (to me), even though it technically is one.
The equivalent of accumulators in imperative languages would be the 'pattern' of having some variables outside of the loop and mutating them from within the loop. Maybe you can appreciate that it feels weird calling this a 'pattern' — and now you can better understand how I feel about accumulators being called a pattern.
Skipping back to your original question: I write Haskell for living and teach two high-school classes in another functional language, and the only two 'patterns' regarding recursion I can think of are accumulators and mutual recursion. So, you know almost everything there is to know already! :-) [0]
Let me add that you use recursion very rarely in day-to-day programming; mostly you try to spare yourself writing the recursion explicitly and you instead use map, filter and foldr/foldl (sometimes called reduce) to do the recursion for you. Especially the folds are super-powerful (AFAIK you can write any recursive function using folds, should you wish to do so), and often under-appreciated.
> Haskell is a genius language but I don't like the community
IMHO the community around Haskell is (in general) great; the people are always eager to help. I'm a self-learned Haskeller and I couldn't have done it without the community. Come join us at r/haskell or the IRC and see for yourself :-)
[0]: Why do I say this? I remember my old days when I was learning Swift and encountered one new design pattern every day. Factory, Facade, ... I decided to get 'em all (why reinvent the wheel?), I was always anxious that I was coding something that could be better served by a ready-made design pattern. So I just wanted to let you know it's nothing like this with recursion, and that you can save yourself the anxiety (if you are anything like me).
Hey thanks for the nice reply. I know you can't generalize like that. There are probably a lot friendly Haskellers around ;)
I was just angry when I wrote my last comment, because I had to read this:
>> as a special case of most people are idiots
which is so low in multiple ways. It's also just wrong, because by definition most people have average intelligence. Even if you think this is true, a smart person would not use it as an argument^^
It's on my todo-list to dive a bit into haskell, when I find time.
I was just angry when I wrote my last comment, because I had to read this:
>> as a special case of most people are idiots
which is so low in multiple ways. It's also just wrong, because by definition most people have average intelligence. Even if you think this is true, a smart person would not use it as an argument^^
It's on my todo-list to dive a bit into haskell, when I find time.
> It's true that you use this way of programming so often in functional languages that it earned itself a name, so that it's easier to talk about it. However calling it a 'pattern' feels weird (to me), even though it technically is one.
> The equivalent of accumulators in imperative languages would be the 'pattern' of having some variables outside of the loop and mutating them from within the loop. Maybe you can appreciate that it feels weird calling this a 'pattern' — and now you can better understand how I feel about accumulators being called a pattern.
That's a fair point, actually. I read "patterns" as "design patterns" a la the book of same name, based on the implied^Wlater stated title "accumulator pattern", but I agree it does fit a weaker notion of "pattern" such as "less-than-maximally-entropic (aka compressible in the information-theoretic sense) feature of code".
> The equivalent of accumulators in imperative languages would be the 'pattern' of having some variables outside of the loop and mutating them from within the loop. Maybe you can appreciate that it feels weird calling this a 'pattern' — and now you can better understand how I feel about accumulators being called a pattern.
That's a fair point, actually. I read "patterns" as "design patterns" a la the book of same name, based on the implied^Wlater stated title "accumulator pattern", but I agree it does fit a weaker notion of "pattern" such as "less-than-maximally-entropic (aka compressible in the information-theoretic sense) feature of code".
Do you agree that most imperative programmers would not come up with this solution on their own, if you didn't teach them the "accumulator pattern"?
Background: I’m currently working as a full time assistant for the first year computer science course at my university. We have around 1800 people enrolled in the class including over 1000 first year CS students. Many of our first years were exposed to imperative programming in high school, either at home or with a high school CS class.
The course we teach is based on the book HTDP and uses a purely functional teaching dialect of Racket. Many of our students struggle to figure out how to use the different recursion patterns such as accumulative recursion and mutual recursion.
I’m not the GP but I will answer your question anyway: yes, I agree that most imperative programmers would not come up with that solution. I have witnessed it myself first hand.
Where I disagree is with any implication or suggestion that they should, given no prior functional programming experience. Accumulative recursion is a standard pattern in functional programming but if you’re an imperative programmer you may not have ever needed to learn it. Therefore, I think it would be unreasonable to expect you to come up with it on the fly.
Background: I’m currently working as a full time assistant for the first year computer science course at my university. We have around 1800 people enrolled in the class including over 1000 first year CS students. Many of our first years were exposed to imperative programming in high school, either at home or with a high school CS class.
The course we teach is based on the book HTDP and uses a purely functional teaching dialect of Racket. Many of our students struggle to figure out how to use the different recursion patterns such as accumulative recursion and mutual recursion.
I’m not the GP but I will answer your question anyway: yes, I agree that most imperative programmers would not come up with that solution. I have witnessed it myself first hand.
Where I disagree is with any implication or suggestion that they should, given no prior functional programming experience. Accumulative recursion is a standard pattern in functional programming but if you’re an imperative programmer you may not have ever needed to learn it. Therefore, I think it would be unreasonable to expect you to come up with it on the fly.
> While I don't mind the toy problems, all those toy problems have something in common...
> They can be easily solved with recursion.
As a sibling mentions, recursion is pretty much required in pure functional programming. There is no notion of time or sequencing: everything we write is a definition. If we don't call another function, then our program will finish; if we don't use recursion (either directly, indirectly via functions like `map`, or via a chain of mutually-recursive definitions) then our program's behaviour will be fixed by the structure of our code (e.g. the number of calls we write). That's fine for simple calculations, but most useful programs depend on the structure of their data (e.g. processing lines in a file, etc.); that requires recursion, since we can't hard-code the right number of calls ahead of time.
> They can be easily solved with recursion.
As a sibling mentions, recursion is pretty much required in pure functional programming. There is no notion of time or sequencing: everything we write is a definition. If we don't call another function, then our program will finish; if we don't use recursion (either directly, indirectly via functions like `map`, or via a chain of mutually-recursive definitions) then our program's behaviour will be fixed by the structure of our code (e.g. the number of calls we write). That's fine for simple calculations, but most useful programs depend on the structure of their data (e.g. processing lines in a file, etc.); that requires recursion, since we can't hard-code the right number of calls ahead of time.
General recursion is equivalent to goto. It is nicer when recursion can be wrapped up in a higher level combinator (map, fold, etc.) or other even higher level abstraction. That's one thing the array languages (APL, J, etc.) got right.
> General recursion is equivalent to goto.
Yes, but goto requires a whole bunch of machinery in order to make any sense. It (a) needs a notion of time/sequencing, (b) needs a notion of statement and (c) needs a notion of labelling.
(a) and (b) are often taken as given in imperative programming languages (e.g. C, assembly, etc.), but Haskell has none of them. It's hard to ascribe any meaning to "goto" in Haskell; other than some embedded language like ST or something.
> It is nicer when recursion can be wrapped up in a higher level combinator (map, fold, etc.) or other even higher level abstraction.
I agree, but I was counting those as (indirect) recursion for the purposes of explaining the parent's observation.
Yes, but goto requires a whole bunch of machinery in order to make any sense. It (a) needs a notion of time/sequencing, (b) needs a notion of statement and (c) needs a notion of labelling.
(a) and (b) are often taken as given in imperative programming languages (e.g. C, assembly, etc.), but Haskell has none of them. It's hard to ascribe any meaning to "goto" in Haskell; other than some embedded language like ST or something.
> It is nicer when recursion can be wrapped up in a higher level combinator (map, fold, etc.) or other even higher level abstraction.
I agree, but I was counting those as (indirect) recursion for the purposes of explaining the parent's observation.
I wrote a blog post some time ago on writing a small URL shortener in Haskell at http://www.wjwh.eu/posts/2019-11-01-haskell-shorturls.html. Still a toy example, but more "real world" than recursion exercises :)
In my brief experience of going through the Haskell examples, I am awestruck by the power that Haskell enables yet scared by the huge type level complexity underlying the libraries that enable it.
Just to query a database the example used half a dozen langauge extensions. I could probably learn the base Haskell langauge but that's not enough it seems for real world usage.
Now these langauge extensions ofcourse reduce the boilerplate and enable a nicer syntax but they dramatically increase the cost of using Haskell in production.
My understanding of the ecosystem is that there is a divide between people who want to use Simple Haskell concepts and others that want to advance the state of the start for every library.
https://www.simplehaskell.org/
Just to query a database the example used half a dozen langauge extensions. I could probably learn the base Haskell langauge but that's not enough it seems for real world usage.
Now these langauge extensions ofcourse reduce the boilerplate and enable a nicer syntax but they dramatically increase the cost of using Haskell in production.
My understanding of the ecosystem is that there is a divide between people who want to use Simple Haskell concepts and others that want to advance the state of the start for every library.
https://www.simplehaskell.org/
I worked with Haskell for awhile but never had it fully 'click'. That being said, I think that once someone is fully comfortable with algebraic data types, category theory, and functional programming, most of these extensions and fancy constructs become pretty shallow and easy to understand.
(Would appreciate if any bonafide haskellers care to comment)
(Would appreciate if any bonafide haskellers care to comment)
Cat theory isn’t needed at all. It just gives you another smell test for recognizing you maybe designed an api nicely. (Aka: oh cool, my api code has some nice mathematical / logical property, maybe it’s not just mud on the wall)
Agree. You don’t need to know category theory to use Haskell or the libraries.
Know category theory or being aware of it just gives you a deeper understanding of the way things work.
I don’t know category theory but aware of it. The way I look at it is c style languages you have design patterns. These are loosely designed patterns with no formal definitions. That makes it hard to reason about or test things.
In category theory you have mathematical laws. Laws are far stronger than a loosely typed designed patterns so using these laws it’s far easier to reason about code.
Know category theory or being aware of it just gives you a deeper understanding of the way things work.
I don’t know category theory but aware of it. The way I look at it is c style languages you have design patterns. These are loosely designed patterns with no formal definitions. That makes it hard to reason about or test things.
In category theory you have mathematical laws. Laws are far stronger than a loosely typed designed patterns so using these laws it’s far easier to reason about code.
Also piping in to say you don't need to understand category theory to successfully write production Haskell. It's interesting to learn and does help solidify understanding of some concepts, but by no means required.
Highly agree that most common extensions are pretty shallow and easy to understand. The tricky ones are usually enabled because some library told you to, or you've genuinely leveled up and recognize where to use them yourself.
Highly agree that most common extensions are pretty shallow and easy to understand. The tricky ones are usually enabled because some library told you to, or you've genuinely leveled up and recognize where to use them yourself.
[deleted]
I'm not convinced that arguing that "think[ing] day-to-day tasks like running a web app are difficult or impossible in Haskell! ... isn't true!" is well-served by a series that introduces (in the first post!) Persist and Template Haskell and then has
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE QuasiQuotes #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# LANGUAGE RecordWildCards #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE OverloadedStrings #-}
PTH.share [PTH.mkPersist PTH.sqlSettings, PTH.mkMigrate "migrateAll"] [PTH.persistLowerCase|
User sql=users
name Text
email Text
age Int
occupation Text
UniqueEmail email
deriving Show Read
|]
Python web app tutorials routinely introduce MongoDB/pymongo, Flask, at-annotations for routing, and follow that up with 2-5 `from __future__ import` statements. These are pretty much exactly analogous to the steps in the current series. The only difference is that the Haskell standards change less frequently, so more "from __future__" imports (LANGUAGE pragmas) are required. (Note that the latest Haskell is from 2010, while the latest Python is from 31 days ago; see how many future imports you need to get a modern Python web app to work with a ten year old Python release)
This is not evidence that day-to-day tasks like running a web app are difficult or impossible in Python.
This is not evidence that day-to-day tasks like running a web app are difficult or impossible in Python.
Sure. But you're begging the question that those are somehow evidence for an argument that Python is easy. I disagree that they would be, especially for a novice, or one who already has a familiar and comfortable workflow in a different language. I think such a user would think "wait, this is what they think is easy entry-level practical programming? Riiiight."
This code relies on GHC and GHC specific extensions. The mentioned pragmas are not defined by the 2010 standard.
The lastest GHC release is from August 8th of this year.
The lastest GHC release is from August 8th of this year.
> The mentioned pragmas are not defined by the 2010 standard.
That's exactly the point. GHC supports the most recent Haskell version it supports, and implements some extensions to the standard language, which can all be enabled or disabled using compiler directives (LANGUAGE pragmas). These are analogous to Python future import statements, which are compiler directive saying that a particular module should be compiled using syntax or semantics that is not part of the current version of Python the language.
Once in a blue moon, the Haskell standard changes, and certain features that you used pragmas for (e.g. PatternGuards, EmptyDataDecls, RelaxedPolyRec) will no longer require them. This depends on the standard, not the latest GHC release. Unlike Python, core Haskell changes slowly and conservatively, so you should not be surprised that the average Haskell code uses pragmas more frequently than Python uses future imports.
That's exactly the point. GHC supports the most recent Haskell version it supports, and implements some extensions to the standard language, which can all be enabled or disabled using compiler directives (LANGUAGE pragmas). These are analogous to Python future import statements, which are compiler directive saying that a particular module should be compiled using syntax or semantics that is not part of the current version of Python the language.
Once in a blue moon, the Haskell standard changes, and certain features that you used pragmas for (e.g. PatternGuards, EmptyDataDecls, RelaxedPolyRec) will no longer require them. This depends on the standard, not the latest GHC release. Unlike Python, core Haskell changes slowly and conservatively, so you should not be surprised that the average Haskell code uses pragmas more frequently than Python uses future imports.
You do recall that your initial thesis was "A lot of people think day-to-day tasks like running a web app are difficult or impossible in Haskell! But of course this isn't true!"? Right?
For people who want to dig more, here are some free resources about learning Haskell:
https://github.com/allenleein/knowledge-base/tree/gh-pages/%...
https://github.com/allenleein/knowledge-base/tree/gh-pages/%...
This is a good way of getting your feet wet: https://haskell-via-sokoban.nomeata.de/
Also, the unfortunately now de-funded, but still resource bearing https://qfpl.io/projects/professional-fp-courses.html.
In the real of paid resources, I found this one most useful:
https://haskellbook.com
https://haskellbook.com
I like how this website gives an overview first on what to expect. I wish more articles shared here would do this.
Can anyone share where’s haskell used
Like what companies are using haskell
Github are using it https://github.com/github/semantic
Facebook and many others.
Immediately confronted by 9 compiler extension directives, major turnoff to this interested newbie. Is this considered normal and acceptable?
I think this is considered normal for real world Haskell usage.
Most libraries and even frameworks like ihp that try to be favor ease of use rely on these language extensions. You can ofcourse place these directives once in the cabal file, but there's no getting around to learning what they do.
Most libraries and even frameworks like ihp that try to be favor ease of use rely on these language extensions. You can ofcourse place these directives once in the cabal file, but there's no getting around to learning what they do.
With GHC2021, you may soon be able to simply put that instead, and it will imply enabling all those individually.
https://www.reddit.com/r/haskell/comments/je1t82/does_the_id...
https://www.reddit.com/r/haskell/comments/je1t82/does_the_id...
It comes with the territory for a fast moving language with new extensions like -XDerivingVia[1] -XLinearTypes[2], more often than not backed by a publication where its interaction with other features is considered. Some extensions are purely syntactic and are quickly understood -XLambdaCase[3] -XBlockArguments[4] -XMultiWayIf[5]. The compiler will suggest missing extensions. There is enough to hs98 for a lifetime of study (see work of Graham Hutton[6] and Jeremy Gibbons[7])
[1] https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/deri...
[2] https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/line...
[3] https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/lamb...
[4] https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/bloc...
[5] https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/mult...
[6] https://twitter.com/haskellhutt
[7] https://twitter.com/jer_gib
[1] https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/deri...
[2] https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/line...
[3] https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/lamb...
[4] https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/bloc...
[5] https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/mult...
[6] https://twitter.com/haskellhutt
[7] https://twitter.com/jer_gib
Why a turnoff? "Extension" just means "language feature that is thoroughly well-specified, well-tested and widely used but hasn't made it into the language standard (partly because there hasn't been one for ten years)".
Yes. They're normal here, and you can consider them about as significant as an import statement, some context when reading the code, but nothing crazy.
The extensions are very well vetted, and new versions of the language standard can be summed up as "enable extensions a, b, c by default." Plus library changes, of course.
The extensions are very well vetted, and new versions of the language standard can be summed up as "enable extensions a, b, c by default." Plus library changes, of course.
Are you looking at production code or pedagogical examples? For the former, it's totally normally to use compiler-specific features. If you are scared off by that, you'd be better served reading a book that introduces things little by little.
Ugh, why do we need to spread the world with highly dubious libraries like Esquilito and Servant...
What makes those two libraries, in particular, "highly dubious"?
- Persistent: tries to support way to many kinds of databases, ends up being lowest common demoninator dumb about all of them.
---- Just use PostgreSQL simple
- Esquilito, not comprehensive. I vaguely remember let through some bad SQL too
---- Use Beam
- Servant: the type level stuff is poorly executed nerd skateboarding. It either should be:
---- less type level and more simple-stupid
---- Use data kinds so the type level is less "un-kinded" and catch a lot of mistakes before they become horrible term-level errors.
---- Just use PostgreSQL simple
- Esquilito, not comprehensive. I vaguely remember let through some bad SQL too
---- Use Beam
- Servant: the type level stuff is poorly executed nerd skateboarding. It either should be:
---- less type level and more simple-stupid
---- Use data kinds so the type level is less "un-kinded" and catch a lot of mistakes before they become horrible term-level errors.
As a huge fan of Servant, have you got a replacement I should check out?
No ...but
I use github.com/obsidiansystems/obelisk/ at work (I work at the place that makes it). It does it's own thing for user-visible routes (for frontend and backend because automatic prerendering). It does a different thing for requests and live queries all of which are over websockets for simplicity.
Our routes stuff should be pulled out as a generic dual parsing-prettyprinting library (it and https://hackage.haskell.org/package/tomland are the same basic ideal, just need to remove the concrete HTTP / TOML specifics to get to the commonality).
I once started throwing together like servant but using data kinds in https://github.com/ericson2314/matrix-client
I use github.com/obsidiansystems/obelisk/ at work (I work at the place that makes it). It does it's own thing for user-visible routes (for frontend and backend because automatic prerendering). It does a different thing for requests and live queries all of which are over websockets for simplicity.
Our routes stuff should be pulled out as a generic dual parsing-prettyprinting library (it and https://hackage.haskell.org/package/tomland are the same basic ideal, just need to remove the concrete HTTP / TOML specifics to get to the commonality).
I once started throwing together like servant but using data kinds in https://github.com/ericson2314/matrix-client