hpr-knowledge-base/hpr_transcripts/hpr3558.txt

Episode: 3558
Title: HPR3558: How I'm learning Haskell
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3558/hpr3558.mp3
Transcribed: 2025-10-25 01:23:12

---

This is Hacker Public Radio Episode 3558 for Wednesday, the 23rd of March 2022.
Today's show is entitled, How I'm Learning Haskell.
It is part of the series Haskell.
It is hosted by Tukuturo Toe and is about 23 minutes long.
It carries a clean flag.
The summary is Tukuturo Toe talks about how she is learning Haskell.
Hello!
This is Tukuturo Toe and you are listening to the Hacker Public Radio.
In today's episode, I'll talk about how I started learning Haskell.
So, I had learned a bunch of different kinds of languages before,
started with the basic and then branched out to the Java and VP.net.J.I.P.
and so on.
There's a long list of languages, and I have...
Well, maybe I have learned one or two of those properly,
other others I have some idea how they are used, and I have written small programs,
but I probably wouldn't say that I really know those languages.
But anyway, I had programmed for quite a while.
So, of course, I heard about Haskell and how it's really different and difficult
and how you need superpowers to write it.
So, obviously I wanted to try my hand at that.
First I skimmed in the net.
There's quite a big amount of Haskell tutorials there,
but the one that really caught my attention is how to learn Haskell by Chris Allen.
I would link to this in the show notes, of course,
and that's not a tutorial in itself,
but it's a collection of tutorials linked to the different tutorials and resources.
And from there I got to the CIS194 by friend Jorge.
This is a university lecture that starts from the very basics and pulls from there.
It's a really good place to start learning Haskell.
So, I did that for a while, and then I stopped,
and then I had a half a year break, I think,
side again, and got a little bit farther and stopped.
So, I repeated that a couple of times.
I was learning things, certainly, that is a good tutorial,
but I didn't really know how to apply pieces.
I know how to operate with the list and how to do calculations
and how to write your own records and things like that,
but I didn't even know how to apply pieces together.
At the same time, I was skimming through the learning Haskell for great good.
So, that is a often recommended book.
It is pretty good, but for some reason it didn't work for me.
I don't really put my finger on why it didn't work for me,
but I read that for a while and then stopped.
But I still use that now and then,
when I have to check some syntax that I don't often use,
for example, cards, for some reason,
this is a thing that I haven't properly memorized yet.
At this point, I started having a hate idea of how things work.
So, of course, I wanted to write a game, because why not?
And, instead of starting from the scratch,
I found a project called Lampjaha,
that is a library for writing Rockwell-like games,
and it's written in Haskell,
and it was really neat.
It was easy to get started with,
and start doing your own modifications,
and it's written as a library.
So, you can just take library and then the example project
and start modifying,
modifying that you don't have to touch to the library at all.
It's quite a lot of itself,
like I was just writing configuration files
with the fancy syntax.
And, like I said, I got it up and running,
and I think I made a couple versions of my game,
but the codebase was far too big for me.
So, I couldn't really understand again
how everything fit together,
and there were a lot of concepts that I didn't understand,
and that made reading the code quite hard.
But, so, I kept it for a while and then gave up.
But, I realized that writing games is fun,
so I wanted to write more,
and I wanted to write something a lot smaller,
something that wouldn't be so big.
So, I wrote a river exploration game.
This is based on a desert stream,
nearby our house,
and I'll keep it often playing there.
And, one winter,
we went there and see what's explaining how desert,
all these cold stages
and obstacles,
and what not there that needs to overcome to find the cold.
So, I got an idea that this sounds like a great game.
I wrote that,
and I scaled down a lot,
like it was running in a console,
so it only had a textual input and output.
And, it was turn-based,
so the game was telling that this is the situation
you are currently in,
and here's the options you can do,
one, two, three,
and then to play it selects an option,
and then the game proceeds to the next turn.
And,
and that's that one actually I finished.
Sadly, I have lost the source code for that.
I thought I had that to do that,
but apparently I don't have.
And, that was probably my first complete
Haskell program that did something useful.
And, here I learned how to think,
how to put things together,
like in a sense of overall structure of the program,
how you structure the program in a way
that you have the interactions
with the outside world,
in this case the screen and the keyboard,
one part of the program,
and then you try to keep that part of the program
as small and as possible.
And, then you have the another part of the program
that is actually logic of the program,
the thing that tells you when it receives input,
that how things proceeds.
And, that's the picker part of the program,
and that's the part that I enjoy writing most, actually.
So, after that, I started writing a yet another program,
this is the deep space one,
this is actually a web-based game.
And, I don't like writing user interfaces.
For some reason, I never got a hang on,
hang on how to design user interface
in any program, programming language.
So, here I used to do a shortcut,
and because it's a web-based program,
I could write the hospital part of the program
to have just an interface that you can connect to.
And, then I wrote the actual user interface with the element,
and that is just sending messages and queries
to the server and server response that is the situation.
And, that is really good match for the hospital in my experience,
because then you have this thin layer
that interacts with the SSL web server
and connects to the database,
and then you have this part layer
to all the computations and calculations,
and see what happens
when a player does something.
What is the next result?
And then, the thin layer is responsible
of storing the new data into database
and sending messages back to the client.
And, that one is written on top of years old,
years old is a library or web server.
I guess web server is the...
Okay, it's a library for writing web-based programs with hospital.
And, that was really easy to start with.
Like, there's a simple example project
that shows basics of things like authentication,
authorization, connecting to the database,
putting stuff on the...
as an outputting stuff, as an HTML.
And, I could just take that one
and start modifying it,
just adding it little things
and making this simple hello world program.
So, I'll only crawl the watch to a game.
And, this is probably where the piece is finally started falling in place to me.
Yeah, I started to really see
the big picture of the hospital.
How to structure that program?
How to do things?
And, if you are familiar with the
hexagonal architecture,
or I think it's sometimes called onion architecture,
this is the same thing.
So, sometimes it's even called ports and adapters, I think.
Anyway, the idea is that you have a team crust
or surface layer that is used to connect.
The outside world to your program.
And, then you have the inside
that is charge of doing the actual business,
business of the program.
And, that outside layer,
does the interactions with the user
and screen and database and lotmap.
You have other systems, maybe.
And, that inside is the part that does the actual calculations.
And, this inside part is never, ever connecting to these outside systems.
They are separated from it.
Anyway, after this one,
I mean, actually, this is where I am currently.
I'm still working on that game and trying to learn more things about hospital.
Because, the language is so...
There are so many libraries.
And, there are so many fascinating ideas.
And, so many different ways of doing things.
Like, when you start looking solution to some problem,
you often end up finding multiple solutions.
And, when you pick one of those solutions,
then that narrows down some future solutions.
That affect on what kind of choices you can do in the future.
So, sometimes it's tricky to figure out what this is and what approaches you want to apply on any program.
But, I haven't stopped learning.
I currently am working on writing more programs.
And, I'm reading books and blog posts.
I mean, this is what I have been doing alongside of this.
This is a list of some interesting books in the show notes.
But, I don't even call them true here too.
So, this is some books are for specific subjects.
Some are for more program approach.
And, this is a design alphabetical order.
This is not in the order I read because I couldn't figure out in which order I read them.
This is an algorithm-driven design by Sandi McIe.
And, this probably isn't a book that you should start with.
These things how you apply algebra to design your programs.
It's a fascinating subject, but that's probably something that you should not start with.
There's an optics by example, by Chris Fenner.
This is super good book of Atlantis and optics in general.
It's related to how you query and modify immutable nested data in Haskell.
And, I would read this before that I would have practically read the book,
because this is more hands-on practical use.
But, this isn't something you should start with, probably.
But, as soon as you start having a nested data,
you have a data that has multiple levels and structure,
and you start reading and modifying that,
then this book is good to pick up.
Because, this social tools how to do that in a pleasant way, let's say.
Production Haskell by Matt Persons, Parsons Story.
And, thinking with type level programming in Haskell, again, by Sandi McIe.
This is a bit more advanced concept maybe.
This talks about how you can move some computations from the, let's say, how do I go?
From the execution, you can move some computations from the execution time of the program
into the compilation time of the program.
This is something that I'm not particularly good at.
But, the idea is that you can express in a pipe level things about your data that you're processing.
And, for example, say that this function that operates with lists,
expects lists to have at least two items in it.
Otherwise, it cannot do the, whatever it is.
For example, it could be a function that takes two first items from the list
and does some operations with them, and then returns some value.
And, that, of course, cannot be done on a list that doesn't have those two items on it.
So, you can express these things on a pipe level in a compilation time.
So, in a compilation time, the compiler will actually check that if this thing expects list of two items
and this place is calling it, but this place that is calling cannot guarantee that there's at least two items.
This is a compilation error.
So, you push some of those checks into the compilation time.
And, that is something I would like to learn, but I haven't gotten around my head yet.
Then, there's a, what I wish I knew when learning Haskell.
It's even dear.
And, this is really cool.
When you're starting, this, like the name suggests,
would be a good thing to skim through.
And then, it's a select document.
And then, after skimming it through, then read it again and start digesting what has been said.
Because there's a lot of interesting stuff and useful stuff in that book or document itself.
It's a video that circulates in the net.
And, then there's a, of course, blocks that I read when I'm trying to learn more things about Haskell.
And, I'll put the links on the show notes to this.
There's this planet Haskell that's an aggregation of various blocks that talk about Haskell.
And, there's a, there's an interesting stuff.
There's a stuff like very, very basic things.
Then, there's very advanced things.
There's a mixture of everything there.
That, that is worth checking out.
And, Monday morning Haskell and Lexi Lambda are two other blocks that I actively follow.
And, of course, there's plenty of videos in there.
YouTube and other three in the other video services.
There's a conference talks, there's hobbies talking about the projects, there's a teaching and so on.
So, when I feel like watching a video, I just search randomly Haskell videos and try to find something that looks interesting and start watching it.
And, if it's relevant to my interest, then I watch it.
And, if it not, I just discard it because there's so many videos out there and there's, of course, varying quality.
And, the thing that I have problem with videos is that it's hard to follow for me.
Because, with book, it's easy.
You can read the same sentence or same chapter or paragraph multiple times and take your time and let the things sink in.
But, with the video, it's a steady stream coming at the same page.
Of course, you can rewind it, but then you are then like finding the exact correct spot.
It might be a bit tricky and then it feels jumpy and everything.
But, I especially enjoy conference talks.
They are interesting to watch.
So, that's basically my approach to learning Haskell.
So, lots of tinkering with the code, a little bit of reading, a little bit of watching videos.
And, the thing is that it's easy to do things and you know how to do it also.
But, with Haskell, the language and how you approach programming is so quite different from other mainstream languages.
So, if you have learned, say, C sharp and you are really good at it and then you start learning Haskell.
It might actually be harder to learn Haskell in that point than if you were starting from the scratch you and the Haskell where you first put on language to learn.
But, then of course, if you were later on going to learn a C sharp, then it would be so different.
So, then the learning of the C sharp would be hard.
So, learning, unlearning, the previous learning, learned concept is hard.
And, because Haskell is so different, there's quite a bit of unlearning to do.
And, learning on the other hand, it's just about willingness to suck at something until you learn to suck at it anymore.
When you're learning a new thing, it's going to be hard, of course.
You're not going to just pick a book really through and be an expert Haskell programming.
I mean, you could have, if you are exceptionally good at it and stuff, but most likely you won't be.
So, then people learn differently, of course.
Some people like reading, some people like watching videos, some people like listening to the podcast.
But, practice is something that everyone needs.
And, it's better to write 10 small programs and finish them to write one huge program and never finish it.
So, just picking up some interesting things, interesting problems, it could be a review of any game.
It could be a just a program that gives you a random quotes every morning as you look on your computer.
And, just pick something, write it, and you learn a little bit and then you rinse and repeat that.
Try to write different kinds of programs, some that works on the console, some that works on the web, some that have a graphical user in the face.
And, practice is something you will need.
You cannot get good at programming, just listening to some random woman talking about how they learned Haskell.
You have to do the work yourself.
And, while Haskell is different, you really don't need a magic degree to write Haskell.
And, you don't need to know category theory.
And, you don't need any superpowers.
You just need practice and more practice and even more practice.
And, that's the new that learning is about, at least for me.
I can read a bunch of books, but I don't really learn those things before I try those in some program and figure out how the pieces fit together.
So, if you have any questions, comments or feedback.
If you want to tell us how you learned Haskell or what your approach was and of general anything about Haskell, you will trigger your own episode.
And, you can reach me via email or at www.fetiversandtutor.atek.lgbd.
You have been listening to Hacker Public Radio at HackerPublicRadio.org.
Today's show was contributed by a HBR listener like yourself.
If you ever thought of recording a podcast and click on our contribute link to find out how easy it leads.
Hosting for HBR has been kindly provided by an onsthost.com, the internet archive and our things.net.
On this otherwise status, today's show is released under Creative Commons, Attribution 4.0 International License.