161–170 of 205 posts
I rather enjoyed RustConf 2018's Closing Keynote, "Using Rust For Game Development" by Catherine West: https://www.youtube.com/watch?v=aKLntZcp27M I learned about the ECS pattern and got to see some Rust refactoring in action. Previous HN discussion here: https://news.ycombinator.com/item?id=17977906
Deviant Ollam - The Hotel Room Gourmet https://youtu.be/qtFV73wpEAw Also not 2018 but his elevator with Howard Payne talk: https://youtu.be/oHf1vD5_b5I (1h version) https://youtu.be/ZUvGfuLlZus (2h version) And the search for the perfect door: https://youtu.be/4YYvBLAF4T8
Earlier quoted context omitted.
The sad thing is that Rich Hickey had some very good videos when Clojure was a new thing back in 2008–2009. Unfortunately, I've disagreed vehemently with most of his talks since then. In this case, it's completely illogical that a function `Maybe a -> b` should be callable as if it were a function `a -> b`. Do you want to know how I know? Because it would be just as illogical to allow a function `Vec a -> b` to be ca…
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…
Fundamentally because it would require you to conjure up a value of type b from nowhere when the Maybe a is Nothing. If we view the function type as implication this would not be valid logically without some way of introducing that value of type b.
You could imagine some function from Nothing -> b that could rescue us. But since it only handles one case of the Maybe type, it is partial (meaning it could give undefined as an answer). There is basically two total functions that we could change it to:
* Maybe a -> b in which case we are back where we started.
* Unit -> b which essentially is just b, which can be summed up as meaning we need some kind of default value to be available at all times.
Now this is only "illogical" because we don't postulate a value of type b to be used as this default.
> It's like saying (+) works on integers, but not on 3
No, it's like saying (+) must work on all integers AND a special value nil that is not like any other integers, but somehow included in them and all other data types. We can't do anything with this nil value since it doesn't carry any data, so in the case of (+) we would essentially have to treat it as an identity element.
This is good though, since (+) has 0 as an identity element, so we can just treat nil as a 0 when we encounter (+). However, when we want to define multiplication we still need to treat nil as an identity element (since it still doesnt carry any data), except the identity element for multiplication is 1. This would be repeated for every new function that deals with integers.
So by mashing together Maybe and Integer we have managed to get a frankenstein data type with an extra element nil which sometimes means 0 and sometimes means 1.
Why not just decompose them into Maybe and Integer and supply the default argument with a simple convertion function like fromMaybe?
(FWIW, I actually agree with Hickey that using Maybe in api design is problematic and I've encountered what he's talking about. But while that might be an argument for where he wants to take Clojure, it's not an argument for dismissing type theory the way he does.)
Joe Rogan interviews Dr. Andrew Weil https://youtu.be/WjYYdMNUXF8
Joe Rogan interviews Elon Musk https://youtu.be/ycPr5-27vSI
Joe Rogan interviews James Hetfield https://youtu.be/5O6QPTawR14
Earlier quoted context omitted.
The sad thing is that Rich Hickey had some very good videos when Clojure was a new thing back in 2008–2009. Unfortunately, I've disagreed vehemently with most of his talks since then. In this case, it's completely illogical that a function `Maybe a -> b` should be callable as if it were a function `a -> b`. Do you want to know how I know? Because it would be just as illogical to allow a function `Vec a -> b` to be ca…
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…
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 change, you just write a wrapper function that produces the correct result for Nothing and delegates to the existing function for Some(a) and you're done without breaking existing clients.
(Now, I suppose, if you're u had something like Scala implicits available, having an implicit a -> Maybe a conversion might sometimes be useful, though it does make code less clear.)
Earlier 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…
> Why is it illogical to say that a Maybe a -> b should be callable as if it were a -> b? Fundamentally because it would require you to conjure up a value of type b from nowhere when the Maybe a is Nothing. If we view the function type as implication this would not be valid logically without some way of introducing that value of type b. You could imagine some function from Nothing -> b that could rescue us. But since…
https://www.youtube.com/watch?v=15RTC22Z2xI
I find almost all from GOTO 2018 very insightful.
https://www.youtube.com/results?search_query=goto+2018
esp ones listed below.
GOTO 2018 • The Do's and Don'ts of Error Handling • Joe Armstrong
https://www.youtube.com/watch?v=TTM_b7EJg5E
GOTO 2018 • Pragmatic Event-Driven Microservices • Allard Buijze
https://www.youtube.com/watch?v=vSd_0zGxsIU
GOTO 2018 • Why Business Cases are Toxic • Chris Matts
https://www.youtube.com/watch?v=KvOcjmpPQCc
GOTO 2018 • Unconditional Code • Michael Feathers
Earlier quoted context omitted.
> Why is it illogical to say that a Maybe a -> b should be callable as if it were a -> b? Fundamentally because it would require you to conjure up a value of type b from nowhere when the Maybe a is Nothing. If we view the function type as implication this would not be valid logically without some way of introducing that value of type b. You could imagine some function from Nothing -> b that could rescue us. But since…
You got it backwards. These problems arise when you want to use an (a -> b) function as (Maybe a -> b), not vice versa.
Recent but great talk posted here, What Bodies Think About: Bioelectric Computation Outside the Nervous System [1] by Prof. Michael Levin. He talks about how long term low energy electrical networks between all cells in living organisms shape how the organism grows. I think what he talks about will be the future of medicine as it allows for an amazing degree of high level control over how animals grow. 1. https://www…
Blown away. To me the following(rephrased) stood out: We are currently good at manipulating molecules and cells(machine code/hardware level) but if we understand the algorithms(software level) which control the large scale form and function - it would bring in radical change. Hardware/software distinction in biology is a very interesting take and we all know what device independence can do.
Earlier quoted context omitted.
> Why is it illogical to say that a Maybe a -> b should be callable as if it were a -> b? Fundamentally because it would require you to conjure up a value of type b from nowhere when the Maybe a is Nothing. If we view the function type as implication this would not be valid logically without some way of introducing that value of type b. You could imagine some function from Nothing -> b that could rescue us. But since…
You got it backwards. These problems arise when you want to use an (a -> b) function as (Maybe a -> b), not vice versa.
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 Maybe generically, I guess my argument here becomes circular. (Begging the question maybe?)