191–200 of 205 posts
"Q: Why Do Keynote Speakers Keep Suggesting That Improving Security Is Possible? A: Because Keynote Speakers Make Bad Life Decisions and Are Poor Role Models" James Mickens https://www.usenix.org/conference/usenixsecurity18/presentat...
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
Jonathon Blow had a really interesting but subtle response to this talk: https://www.youtube.com/watch?v=4t1K66dMhWk&feature=youtu.be
Earlier quoted context omitted.
Nope, it's not the opposite case, I was just to lazy to spell it out. Which way around it is depends on whether it's a return value or parameter. Covariant vs contravariant. If it's a parameter an API change from T to Option[T] shouldn't break (you require less), whereas with a return type it's from Option[T] to T (you promise more).
To be fair the "result"-part in "something you thought was an Option[T] result turned out to be really a T" makes it sound like you were speaking of the return-type to me as well. I appreciate the elboration though!
I think the point remains that, while this is not a breaking change from a contractual viewpoint, most type systems would deem it incompatible.
Alex Hannold's Ted Talk on how he free soloed El Cap. https://www.youtube.com/watch?v=6iM6M_7wBMc Another favorite one of mine was Jimmy Chin talking about how they shot Free Solo. https://www.youtube.com/watch?v=Oq_vvnxZ6I0
Thanks for the links. I enjoy climbing. Alex Honnold is one of a kind. Absolutely stunning what he does.
Earlier quoted context omitted.
I thought this was one of the notably bad talks this year. The whole premise that a function of Maybe a should be a function of a without an API change is neither intuitive to me nor really justified by Hickey. Different things are different. It's sad to see someone build such a wall around himself when faced by something (type theory) that he doesn't understand.
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…
In this regard I really like OCaml:
let get_something = function
| Some x -> x
| None -> raise (Invalid_argument "Option.get")
"Q: Why Do Keynote Speakers Keep Suggesting That Improving Security Is Possible? A: Because Keynote Speakers Make Bad Life Decisions and Are Poor Role Models" James Mickens https://www.usenix.org/conference/usenixsecurity18/presentat...
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…
I think Rich does not like Some x | None because he does not like simple pattern matching too much. This is why Clojure does not have a first class pattern matching syntax (you can emulate, and there is a library and it is just X amount of lines, etc. but still). In this regard I really like OCaml: let get_something = function | Some x -> x | None -> raise (Invalid_argument "Option.get") This is very simple to unders…
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…
Earlier quoted context omitted.
I agree. Further his exposition on `Either a b` was built on a lack of understanding of BiFunctors. The icing on the cake was his description of his own planned type theory. What he described was, as I could decipher from his completely ignorant ravings, a row-based polymorphic type system. However he passes off his insights as novel rather than acknowledging (or leveraging) the decades of research that have gone int…
Well, in his defense, type theory is supposed to make software engineering simpler, not more difficult. So if even he doesn't understand it, then how can we expect a random programmer to?