Somehow I always thought that this series had millions (or at least hundreds of thousands) of views just because everyone in my class watches it and knows it. They are such high-quality explanations too! I have even more appreciation now for the fact that you made this whole series just to help those of us struggling.
That's kind of a bummer to see how simple the language tries to be, then we see that in order to be efficient (or to work at all in a bunch of cases), you have to be really careful with very Haskell-specific things. That is what rebutted my colleague when we started our company.
It's like in C++ which discriminates between value, reference, and move semantics. If the programmer is unwary of this, the program may end full of dangling references, accidental copies, and whatnot. “There are only two kinds of languages: the ones people complain about and the ones nobody uses.” - Bjarne Stroustrup
Excellent series, thanks so much! Regarding your warning about `seq` at 8:49, I'm not sure exactly *what the risks are* and *what to do* about them? ➤ Risks → If I understand correctly, using `seq` might sometimes degrade performance (speed or RAM usage) because it messes with the compiler's assumptions. That's the only risk, right? Or is there also a risk of compilation or runtime errors? ➤ What to do → Should I use lazy code by default, and if I hit performance issues, first try to turn the compilation optimisations on (which may automatically make things stricter when needed), and if that's not enough, then try using strict code and see if that improves things?
For anyone looking for more videos on this topic I could recommend watching brilliant Bartosz's series on parallel and concurrent Haskell: th-cam.com/video/N6sOMGYsvFA/w-d-xo.html
![[#SHORTS CLIP] ใช้ของของตัวเองไปเลยสิคะ l ซานิเบาได้เบา l One Playground](http://i.ytimg.com/vi/Ea_mTywx2p4/mqdefault.jpg)
And as always, thunks for watching :3
Thanks a lot. You are a good teacher. You are clear, accurate, and explain a lot in a short time.
Thank you!
Somehow I always thought that this series had millions (or at least hundreds of thousands) of views just because everyone in my class watches it and knows it. They are such high-quality explanations too! I have even more appreciation now for the fact that you made this whole series just to help those of us struggling.
That's kind of a bummer to see how simple the language tries to be, then we see that in order to be efficient (or to work at all in a bunch of cases), you have to be really careful with very Haskell-specific things. That is what rebutted my colleague when we started our company.
It's like in C++ which discriminates between value, reference, and move semantics. If the programmer is unwary of this, the program may end full of dangling references, accidental copies, and whatnot.
“There are only two kinds of languages: the ones people complain about and the ones nobody uses.” - Bjarne Stroustrup
Excellent series, thanks so much! Regarding your warning about `seq` at 8:49, I'm not sure exactly *what the risks are* and *what to do* about them?
➤ Risks → If I understand correctly, using `seq` might sometimes degrade performance (speed or RAM usage) because it messes with the compiler's assumptions. That's the only risk, right? Or is there also a risk of compilation or runtime errors?
➤ What to do → Should I use lazy code by default, and if I hit performance issues, first try to turn the compilation optimisations on (which may automatically make things stricter when needed), and if that's not enough, then try using strict code and see if that improves things?
Excellent lectures, thank you.
Haskell is lazy, That just like us programmers, that's why we love haskell!
I wonder where all the discarded thunks end up 😢
For anyone looking for more videos on this topic I could recommend watching brilliant Bartosz's series on parallel and concurrent Haskell: th-cam.com/video/N6sOMGYsvFA/w-d-xo.html
Spectacular ❤️
Thank you so much!
Okay, so, very good video again.
Would be interesting to talk about whnf and nf