Learning Haskell: Let's Code a Command Line Tool
HTML-код
- Опубликовано: 5 фев 2025
- Thanks for watching! If you enjoyed this video and want to see more videos like it, subscribe. Comment below with any questions you have or suggestions for future content.
Get the Code: gist.github.co...
FP in JavaScript Playlist: • Functional Programming...
Download GHCI: www.haskell.or...
Installing Hasking in 5 Steps (if the link above is unclear): wiki.haskell.o...
Learn You a Haskell for Great Good: learnyouahaskel...
Thank you for this very useful video!
Thank you for a concise and real-world introduction to Haskell. of course The code can be more functional, but I think it is better to be more lig ht on that regard and let people got familiar with the syntax . I'm the kind of Person that needs to understand every bit of an abstraction to be able to focus on the problem, so your video helped me a lot to understand some other haskell code. I 'm a J s developer really convinced of FP benefits. keep up the good work
You're welcome :) thanks for the feedback
Do you have your vim dot files available?
Monad bindings make all this stuff a million times easier to read and run faster in most cases than do blocks, which are indeed the gateway drug to monads and cofunctors :D
Excellent. Thank you.
Don't use the black background.
The problem with this, as an example program, is that it looks like a QBasic program. Read a string, store it in a value. Do something to the string, print that to the screen.
A user who reads about the glory of functional programming and monad burritos is going to wonder why anyone is getting excited about line by line input/out put.
I'm of the opinion that people generally fail to stick with Haskell because they try to learn the syntax, language structure, and FP all at once.
My aim with an example like this is to introduce Haskell syntax and some of the language features (do notation, pattern matching, compilation, etc) with the assumption that the viewer already wants to learn Haskell -- whatever their reason for choosing it as a language may be.
Mind you, a "Why FP" video using Haskell instead of JS could fill a void on my channel. If that's what you're hinting at? :)
I agree that you can easily overload someone learning Haskell, or any other language, by putting too many concepts at once. How we handle this, however, is fairly non-trivial. I think care has to be taken when chopping things up.
I think there are possibly two general approaches to a language based on the audience. Are they familiar with programming in another language? If they are not, then you have to start on a very basic level - but if they are, I think you need to show why you would want to know this language and it is the latter that I think really is missing in regards to Haskell.
After I finished the entire book, LYaHFaGG, I still didn't really see the point. Every program example looked nothing more like a Qbasic program which had some terse notion as a way to combine multi-line statements into one plus the ability to run functions on non-trivial data types, which has been around forever through the C++ style of creating objects and then operator overloading.
For example, if you ask someone why learn/write C, you almost always get the same answer, it is very fast. Why learn Haskell? That's the question I would like to see addressed more as it isn't obvious at all in the books I read. I am considering which book to read next, if you had a recommendation it would be appreciated. I am thinking either real world haskell or the haskell book.
Awesome points. I see what you're getting at now.
Honestly.. Haskell offers a strict environment for learning FP, buts you'll be hard-pressed to find practical uses for the language in the real world.
If you're looking for "real world FP," you'd probably enjoy picking up something like Clojure or F#.
If you're more of a Frontend dev (doesn't sound like it, based on the mention of C++, but still...) then writing functional JS is really phenomenal compared to more imperative approaches. Elm (basically Frontend Haskell) and Clojurescript are also worthwhile options.
The real selling points of FP come down to a different approach to complexity management and dealing with parallelism. FP uses function composition instead of encapsulation to manage complexity. And the use of immutable data with pure functions means that there is no shared, mutable state in the majority of the program. So things can run in parallel without race conditions.
I am not a front-end developer, I code mainly as I like to code. The last actual work I did in coding was a long time ago in Fortran 90 (academic research in Physics).
I am not sure though I would agree that functional style programming only has benefits in regards to what you cite. I am not saying it doesn't have benefits there ( I don't have the experience to comment) but just that it may have benefit in general just to coding but you have to look at things from the point of view of what are the data classes vs what are the steps you need to do (imperative).
In your code for example, that addAll function can be implemented as a fold which jumps out if you think of it as either some kind of list / Monoid. The repeated put and get can also be implemented directly vs sequential line by line as you basically have a list of IO's which you want to bind and then map over and Haskell will readily traverse that list.
If that point is understood, that you need to look at the classes of the data I think it could have the same kind of obvious benefit as it really apparent when you first see things like arrays and loops vs get x1, get x2, get x3 etc. . I think people get too weirded out because the classes in Haskell have odd names (Monoid, Monad) and there is so much nonsense about them. It isn't like the concept of an object which has a map method is harder to understand than a linked list, it is obviously much easier than data structures like a binary heap.
Now maybe it might be thought that if you introduce someone to Haskell and you end up looking at applicative functors, monoids and monads that people might freak out. However people learning other languages at one point went through all of that when they first had to get up to speed on arrays, objects, pointers etc. . Plus even if you don't get it right away, the point at least is made that you can basically do simple operations on complex structures easily *when* the language has the abstractions.
Just look at how Haskell can add up all the elements in a tree in just a few lines of code vs what it takes to define and do that in C. Yes on some level it can be harder to understand when you first see it, but that is no different than anything else. When you first see arrays it looks odd, especially if you don't have a math/physics background. But when you see how fast an array can reduce lines of repeated code it becomes obvious that is something you *have* to understand.
I agree. Yes, a fold/reduce is certainly at the heart of functional programming (check out transducers if you haven't yet and want to see some very cool stuff in that area).
Based on your initial comments, I got the impression I would need to sell you on the practical utility of FP. But you are absolutely right in that there are also stylistic benefits -- FP is declarative, which can make for shorter (often times clearer) code.
So, if I understand your last comment correctly, I would agree that FP offers a better way of working with data transformation.
It is consistently possible (and I would suggest preferable) to write a program with a functional core that transforms the relevant data that is wrapped in a small layer of side-effecting code that performs I/O. When it comes to a pure FP language (Haskell), the Monad tricks are required to create these side effects. In other languages, it's very easy to create side-effects, so the benefits come from having the discipline to limit impure code to a small, intentional section of the codebase.
Am I understanding your points correctly?