วีดีโอ

haskell sucks

this is so cool

damn..... even the title is declarative.

type signatures are an anti-pattern. just use inference.

I can barely understand simpler code that does things step by step, I don't want to make it harder for myself

so python is just dumb haskell?

No

The sentence "Haskell doesn't even feature variables" deals immense psychic damage to most programmers

lol monads

Wow. That's an absolutely beautiful video. I'm starting to understand it - especially with the aid of those fantastic function / higher-order function (HOF) diagrams. One comment, however: there appears to be a minor typo in the "Wrapping up" diagram at around 07:36. I think that the output of the filter HOF should possibly have the type [a]. Having just subscribed to your channel, I'm going to watch more of your Haskell videos in my quest to understand functional programming with TypeScript (of all things - possibly with the aid of the fp-ts library). Thank you.

Awesome video! Hope your channel blows up

2:49 foo needs a function of one argument (type a), it's not a plus function of 2 arguments (x, y).

def closest(target, points, dist): distances = ((dist(target, p), p) for p in points) _, closest_point = min(distances, key=lambda i: i[0]) return closest_point

Bro I have been coding in Python since highschool and it took me a while to understand that example at the end of the video.

Sometimes you really wish you had some structural typing 🙂

oh man heartbroken you didnt continue this series

wow, great video

COME BAAAACK

I instantly fell in love with Rust after learning how to write it in a functional-like way. Now I really want to learn more.

4:09 > _"UTH, Haskell lists look like this"_ wait, this looks (syntax) & sound (name) like lisp lists.

stop saying that is a very complicated topic because it isn't

Any tutorial about vizualisation in the new perspective section? looks sophisticated.

There is *lots* of overhead in the for loop you showed to begin with, specifically on the programmer's side! Compare: int factorial(int n) { int product=1; for (int factor=1; factor<=n; factor++) product*=factor; return product; } factorial :: Int -> Int factorial n = product [1..n] Why should the programmer repeatedly explain to the compiler how to iterate through numbers every time they want to handle any sort of sequence? It's even done with the full expectation the compiler will recognize the pattern and discard those details, in order to perform optimization like using CPU flags, unrolling, vectorization etc; which means there's another load of overhead on the compiler's side. And then you still have to elaborate for some of those, like #pragma omp reduction (* : product).

На питоне можно однострочные написать тоже 😂

Continuation when? :p

Confusing apply with map is pretty bad for learning. Map is specific to list and really shouldn't be used over fmap but I get why you're taking about it. But recursion isn't something that's ever really used outside of library implementations. You should really be teaching people things like fold because they're just going to get hung up on recursion not being efficient or something Overall tackling it from this angle makes haskell seem no different to any other language. Nothing here is special really

Tail call recursion is not slower

amazing series

Nice try Big Haskell corporate slave

Arguments and parameters are different things. The function declaration (not applying or execution) uses parameters, not arguments.

Wow! Just amazing. Incredible video, highly detailed and well explaining, while still remaining very short and concise. Great job!

Amazing videos

Great video :D

And I don't even need to memory allocate in my brain to learn this - Haskell has it built in!

Great video :D

Haskell is like driving a jet fighter on the road. It's cool and advanced af but its practical usage is low.

Thank you. I've been thinking of starting Haskell for many years, and this video series serves as a concise and accessible introduction!

Wait, isn't there a massive crashing bug in the factorial code? If i call "factorial (-1)" it will infinitely recurse and never stop. How is this an acceptable coding feature? Surely, the function domain should be limited to unsigned integers (Z+) rather than all Integers?

Still just does a for loop under the hood

Nah watch this: import closestPoint from 'closest-point'; let res = closestPoint(point, target);

Here is a version in rust that doesnt clone anything, so should be very fast. It also accounts for the case where the list of points might be emtpy. fn closest<'a>(points: &'a [Point], target: &Point) -> Option<&'a Point> { points.into_iter().min_by_key(|p| distance(&p, target)) }

Haskell is so bad, don't learn it :(

Thanks so much. Please keep doing more ❤

looking forward for next episodes! thank you for your content 🎉

This video is so starkly different from the conclusions I've come to in my work experience that it was a little jarring. Great video and I can understand how one would arrive at using recursion more, but based on my work experience I try to avoid recursion at all costs. I have found that recursion tends to tie knots in my code that only get worse over time. I find iterators and their associated for loops to be much more intuitive, and even figured out how to handle trees without recursion by instead building tree-based iterators.

I'm just starting my journey at Odin Project, at 56yo At the moment my focus is on the basics, but this is very interesting. Hope to see more like this. Thanks!

Hope all is well, wondering for the continuation of the series :)

oh, like rust iterators! haskell sounds pretty cool

as someone who mainly uses rust and has used lisps, i recognize a lot of similarity. type variables are like rust's generics, guards are like lisp if