I made a playlist of all the youtube links form this section: https://www.youtube.com/playlist?list=PLh6DLqe0B3ZCLi1bYvQrn...
Thank you
Ask HN: Best talks of 2018?
201–205 of 205 posts
Re: Ask HN: Best talks of 2018?
#202I really liked this talk about the history of programming and how so many ideas we consider recent or modern are in fact much older than many of us realise. Watching this talk merely amplifies the feeling that the programming profession is in a perpetual loop - discarding or forgetting ideas or concepts, then re-discovering them anew. What's also striking is how rich and varied were the programming ideas that emerged…
Although a bit repetitive from one talk to the next, Kevlin Henney's talks are of great quality, both in content and form.
If you're interested in a deep analysis on software development behaviours, through patterns either at the code or organisational level, his talks are gold.
I particularly enjoyed his take on management analysis, it resonates with a lot of "failure" situations that I had experienced in my previous job:
Kevlin Henney - Agility != Speed https://youtu.be/kmFcNyZrUNM
Re: Ask HN: Best talks of 2018?
#203Earlier quoted context omitted.
Why is it illogical to say that a Maybe a -> b should be callable as if it were a -> b? His point is that Maybe a should be composed of all the values of a, plus one more value, nil. A value of type a is a member of the set (nil + a). Why should having a more specific value reduce the things you can do with it? It breaks composition, fundamentally. It's like saying (+) works on integers, but not on 3. I'm saying this…
> His point is that Maybe a should be composed of all the values of a, plus one more value, nil No, that's a simple union type. There are very good reasons for Maybe to be different than unions (Maybe can nest meaningfully, simple unions can't.) Maybe Maybe a is valid, and often useful, type. Of course, if you have a function of type a -> b and find out you need a more general Maybe a -> b, instead of a breaking chan…
I agree that there are reasons for Maybe a to be a different type from (a | nil) but there are also good reasons to prefer (a | nil). Like most things, it's a set of tradeoffs. What I appreciated about this talk was that he went into the benefits of thinking about types in this way. It's (relatively) common to see the benefits of Maybe a explained, but more rare to see the benefits of full union types explained.
Re: Ask HN: Best talks of 2018?
#204Earlier quoted context omitted.
Why is it illogical to say that a Maybe a -> b should be callable as if it were a -> b? His point is that Maybe a should be composed of all the values of a, plus one more value, nil. A value of type a is a member of the set (nil + a). Why should having a more specific value reduce the things you can do with it? It breaks composition, fundamentally. It's like saying (+) works on integers, but not on 3. I'm saying this…
My problem is that I don't know when to expect nil from a call because in Java null is part of every type and you can happily receive a null from anything, the compiler won't give you a warning. In OCaml I know what to expect because Some x | None is super simple to reason about. I can never receive a null a nil or other things that somehow satisfy the type requirements. Clojure is great with untyped programming ever…
Yes, the default of a lot of languages, (Java, C, etc) where nil is implicitly a member of every other type is a bad default. But that's a separate question.
Re: Ask HN: Best talks of 2018?
#205Earlier quoted context omitted.
You got it backwards. These problems arise when you want to use an (a -> b) function as (Maybe a -> b), not vice versa.
Yeah, you're right, I got confused when interpreting the parent comment. Thanks for pointing it out! I guess I overlooked it because the other way is so logically trivial, since it basically boils down to A -> B => (A || Nothing) -> B, which is just an or-introduction. So if you wanna implement Maybe generically the "work" lies on the other side. But since Hickey's argument sort of is that we shouldn't implement Mayb…
> I guess I overlooked it because the other way is so logically trivial, since it basically boils down
Yeah, that's (part of) Hickey's point. That the "best" type systems fail this test, and require manual programmer work to solve this problem. Again, I'm saying this as someone who really appreciates Haskell.