Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Best talks of 2018?

news.ycombinator.com

Post reply on HN
Print view View original

181–190 of 205 posts

Re: Ask HN: Best talks of 2018?

#181

Post by geokon »

ttiurani wrote: post #20

"Maybe Not" by Rich Hickey: https://www.youtube.com/watch?v=YR5WdGrpoug Another excellent talk by the creator of Clojure, and like the previous ones, relevant for all programmers.

Are the things he illustrates already implemented in Clojure? I'm kinda new to Clojure and I see there is deps.edn and there is clojure.spec, but have they come together into the system he describes? Or is that still "in the works"?

I was left a little vague on how it'd work in the end. I guess your program would specify what spec/input-output it expects from a library's API and then the library git history is traversed till you hit the last "version"/hash that matches the spec you require. Then we can just get rid of version numbers entirely and I guess you would just get a warning when a library made a breaking change and your dependency is stuck on an old version/hash in the git tree

Am I understanding that right? I get that the new way of development he describes would prevent breaking changes entirely (though it honestly sounds messy with lots of legacy stuff floating around)

Re: Ask HN: Best talks of 2018?

#182

Post by gr__or »

patrec wrote: post #177
gavinpc wrote: post #153

Earlier quoted context omitted.

> When have you ever had to unnecessarily break API compatibility because something you thought was an Option[T] result turned out to be really a T, always? That would be a breaking change. And should be, if you're into that sort of thing. The objection is to the opposite case: What was a T is now an Option[T]. I don't know Scala specifically, but that's a breaking change in every typechecked language I know. Rich is…

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!

Re: Ask HN: Best talks of 2018?

#183

Post by IshKebab »

dethos wrote: post #130
IshKebab wrote: post #127

Earlier quoted context omitted.

Watched 20 minutes of it. Fairly amusing but if you know anything about machine learning you won't learn anything.

You should watch the whole thing.

Eh I feel like a talk should tell you one thing that only the speaker knows in the first 20 minutes.

Re: Ask HN: Best talks of 2018?

#184

Post by Aeolun »

vishnu_ks wrote: post #157
Aeolun wrote: post #145

Earlier quoted context omitted.

I don’t think listening to someone so foolhardy would impress me very much.

I think you missed the point. Alex Honnold didn't woke up one day morning and decided to climb El Cap in the afternoon. He has been preparing for the climb for almost 7 years. He memorized each and every step he would make during the climb. He even abandoned his first solo attempt because the conditions didn't seem to be right. It was never a do or die situation. He wore the same set of clothes throughout the practic…

I mean, it’s amazing, don’t get me wrong. I just feel like doing it served no purpose and needlessly put him at risk.

To be honest, I thought this was a guy with a wife and children (there was a story earlier about him doing a free solo), since he’s single I guess his life is his own.

Re: Ask HN: Best talks of 2018?

#185

Post by chubot »

maxhallinan wrote: post #160
chubot wrote: post #43

Earlier quoted context omitted.

Are you sure that he doesn't understand it, or is it possible that you haven't worked with the same scale of systems he has? Here's my response to his talk, which I found insightful: https://lobste.rs/s/zdvg9y/maybe_not_rich_hickey#c_povjwe Also, I think your comment suffers from the problem here, where you invoke "type theory" without any elaboration: https://lobste.rs/s/zdvg9y/maybe_not_rich_hickey#c_ioeyob Rich ha…

You're right: there isn't much substance in my comment. I just meant to qualify the parent comment by saying that not everyone found this to be a "Best talk of 2018". A lot of good arguments for both sides were made in other places and it felt a bit obnoxious to reopen the argument here, where it's off topic. I should have simply stated that this is a controversial talk instead of adding my two cents. Here's my under…

If that was your intention, simply saying "I didn't find this talk useful" would suffice. It's not necessary to say that "Rich Hickey doesn't understand type theory".

I would say that "X doesn't understand type theory" is becoming a common form of "middlebrow dismissal" [1], which is discouraged on HN.

And that's exactly the scenario you described in proto3 - now every field could be encoded as a Maybe.

No, in protobufs, the presence of fields is checked at runtime, not compile time. So it's closer to a Clojure map (where every field is optional) than a Haskell Maybe.

This is true even though Google is using statically typed languages (C++ and Java). It would be true even if Google were using OCaml or Haskell, because you can't recompile and deploy every binary in your service at once (think dozens or even hundreds of different server binaries/batch jobs, some of which haven't been redeployed in 6-18 months.) This is an extreme case of what Hickey is talking about, but it demonstrates its truth.

I don't find any relationship between types and anything I understand as "runtime behavior".

Look up the concept of "type erasure", which occurs in many languages, including Haskell as I understand it. Or to be more concrete, compare how C++ does downcasting with how Java does it. Or look at how Java implements generics / parameterized types.

[1] http://www.byrnehobart.com/blog/why-are-middlebrow-dismissal...

Re: Ask HN: Best talks of 2018?

#186

Post by agentultra »

joel_ms wrote: post #179
agentultra wrote: post #172

Earlier quoted context omitted.

> I think this comment is a bit too harsh, and I would rather we just discuss the points he makes, not his credibility. I was trying to address the points he made but parent appealed to his authority which I haven't found convincing. > To apply your own standards, have you been a prolific Clojure contributor/hacker/user? Have you contributed to any major open source Clojure projects? I have been a user on a commercia…

>His point about `Either a b` was perhaps further from the mark. It is not a data type that represent logical disjunction. That's what the logical connective, disjunction, is for. Haskell doesn't have union types to my knowledge. Either is not a connective. It's a BiFunctor. His point that it's not "associative" or "communtative" or what-have-you simply doesn't make sense. In fact he calls Either "malarky" or, charit…

Yes, there is a connection. Which makes it all the more strange: Either does correspond as you say which means it has the same properties as the connective. In the correspondence the functor arrow is implication and a pair of functions ‘a -> b’ and ‘b -> a’ is logical equivalence. Using these we can trivially demonstrate the equivalence of Either to the associativity laws using an isomorphism.

That’s what makes his talk strange. He talks about types as sets and seems to expect Either to correspond to set union? If he understood type theory then he’d understand that we use isomorphism and not equality.

You can express type equality in set theory and that is useful and makes sense.

But it doesn’t make sense in his argument.

Malarky? Come on. Doesn’t have associativity? Weird.

Re: Ask HN: Best talks of 2018?

#187

Post by seventhtiger »

brodo wrote: post #136
faitswulff wrote: post #55

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

This one is one of my favorites of the year too. ECS seems like a pattern which can also be used in other contexts then games. I‘m currently writing a simulation tool and I am considering switching to ECS.

Simulations and games are highly integrated and iterative. Having every process be done in frames or steps makes the preservation of information for the next step/frame really important. Systems are also tightly coupled and not easily separated.

That's why I like ECS. I also like the EC part to just be a table I can query, and the S system should be very tight and the dependencies should be used explicitly. That way you go around some thing like dynamic ordering of the update function based on object pools and other nonsense.

Re: Ask HN: Best talks of 2018?

#188

Post by vishnu_ks »

Aeolun wrote: post #184
vishnu_ks wrote: post #157

Earlier quoted context omitted.

I think you missed the point. Alex Honnold didn't woke up one day morning and decided to climb El Cap in the afternoon. He has been preparing for the climb for almost 7 years. He memorized each and every step he would make during the climb. He even abandoned his first solo attempt because the conditions didn't seem to be right. It was never a do or die situation. He wore the same set of clothes throughout the practic…

I mean, it’s amazing, don’t get me wrong. I just feel like doing it served no purpose and needlessly put him at risk. To be honest, I thought this was a guy with a wife and children (there was a story earlier about him doing a free solo), since he’s single I guess his life is his own.

Probably this might help you understand why Alex does this.

https://news.ycombinator.com/item?id=14503404

Re: Ask HN: Best talks of 2018?

#189

Post by agentultra »

ajss wrote: post #174
agentultra wrote: post #172

Earlier quoted context omitted.

> I think this comment is a bit too harsh, and I would rather we just discuss the points he makes, not his credibility. I was trying to address the points he made but parent appealed to his authority which I haven't found convincing. > To apply your own standards, have you been a prolific Clojure contributor/hacker/user? Have you contributed to any major open source Clojure projects? I have been a user on a commercia…

> The function `a -> Maybe a` is a different function than `a -> a`. Despite his intuition that the latter provides a stronger guarantee and shouldn't break code, callers may be expecting the Functor instance that the `Maybe` provides and therefore is a breaking change. I don't really follow that. How can it be a breaking change? Can you give an example?

If you're building a parser, you may use: http://hackage.haskell.org/package/parsec-3.1.13.0/docs/Text...

Where your downstream parsers match on `Nothing` and assume the stream hasn't been consumed in order to try an alternative parser or provide a default.

If you change an equation to use `option` instead you have a completely different parser with different semantics.

I was thinking of a case where I use your function in a combinator that depends on the Functor and Monoid instances provided by the `Maybe` type. If you change your function to return only the `a` and it doesn't provide those instances then you've changed the contract and have broken my code. And I suspect it should be easy to prove the equations are not equivalent.

Re: Ask HN: Best talks of 2018?

#190

Post by vitaminCPP »

sn9 wrote: post #106

Some of my favorite talks from Strange Loop: * Contracts For Getting More Programs Less Wrong: https://www.thestrangeloop.com/2018/contracts-for-getting-mo... * "It's Just Matrix Multiplication": Notation for Weaving: https://www.thestrangeloop.com/2018/its-just-matrix-multipli... * Hackett: a metaprogrammable Haskell: https://www.thestrangeloop.com/2018/hackett-a-metaprogrammab... * Git from the Ground Up: https://w…

> "Beyond Unit Tests: Taking Your Testing to the Next Level"

+1 Very interesting. I will make sure to check the `Hypothesis` module.

Post reply on HN