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

151–160 of 205 posts

Re: Ask HN: Best talks of 2018?

#151

Post by navinsylvester »

aeleos wrote: post #81

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.

Re: Ask HN: Best talks of 2018?

#152

Post by nadagast »

gnuvince wrote: post #134
maxhallinan wrote: post #37

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…

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 someone who really enjoys type systems, including haskell.

Re: Ask HN: Best talks of 2018?

#153

Post by gavinpc »

patrec wrote: post #91
joshlemer wrote: post #65

Earlier quoted context omitted.

>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 He spent many minutes motivating it. If you support some functionality to a client (as a library, or a service, or more abstractly), and then later want to relax the constraints that you require from those clients, this should be an acceptable change that they shouldn't have to worry a…

His argument for spurious API breakage is strictly logically correct, but seems practically dubious to me. 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? Maybe I'm wrong and someone will post some convincing examples, but I currently don't see this as a problem that needs solving. Union Types don't compose stra…

> 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 arguing that it shouldn't be. But it could be possible even in typed languages through union types. For example, you can do this in TypeScript by changing T to T | undefined, which is a superset of T.

Re: Ask HN: Best talks of 2018?

#154

Post by outside1234 »

Aeolun wrote: post #145
krispbyte wrote: post #84

Earlier quoted context omitted.

To other people not getting what free solo is, it means climbing a cliff without ropes.

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

It’s dumb as rocks, agreed.

But it’s the massive prep they do and skills they have that make it genius

Re: Ask HN: Best talks of 2018?

#156

Post by myth_drannon »

aeleos wrote: post #81

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…

Just mind blown. Stopped watching talks because I feel that the information delivery is lacking comparing to a book or a good blog post, but this one is just so mind expanding!

Re: Ask HN: Best talks of 2018?

#157

Post by vishnu_ks »

Aeolun wrote: post #145
krispbyte wrote: post #84

Earlier quoted context omitted.

To other people not getting what free solo is, it means climbing a cliff without ropes.

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 practice sessions and the climb. Everything was done to minimize the risk. For me Alex Honnold's solo is an example of what a Human can achieve with the right amount of practice and preparation.

Re: Ask HN: Best talks of 2018?

#158

Post by bfung »

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.

After having code reviewed a lot of Haskell code and managing library dependencies, his talk makes a TON of sense.

Some refactorings of code are basically just relaxation of requirements or tightening of return values - and Maybe is littered everywhere / changed everywhere. It just makes the the code hard to read and a lot of busy work - but to no real value.

This is the same in Java code. Too many Optional / Nullable everywhere. Unit tests littered everywhere to deal with Optionals. But no real functionality change or new information for future maintainers. Just extra cruft.

spec seems to be work picked up where Optional / Maybe has left off.

Re: Ask HN: Best talks of 2018?

#160

Post by maxhallinan »

chubot wrote: post #43
maxhallinan wrote: post #37

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.

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 understanding of one of your points: required fields in a data serialization format place an onerous burden on consumers. So in proto3, every field is optional, and this permits each consumer to define whats required for its own context.

Unfortunately, I can't find any connection between the dilemma at Google and the suitability of the Maybe type. You say this:

>The issue is that the shape/schema of data is an idea that can be reused across multiple contexts, while optional/required is context-specific. They are two separate things conflated by type systems when you use constructs like Maybe.

I agree - the value of a field might be a hard dependency for one consumer and irrelevant to a second consumer. But Maybe has nothing to do with this. If the next version of protobuf adds a Maybe type, it would not obligate consumers to require fields that they treat as optional. It would just be another way to encode the optionality, not optionality as a dependency but optionality of existence. A required input could still be encoded as a Maybe because the system can't guarantee it's existence. So Maybe is simply an encoding for a value that isn't guaranteed to exist. And that's exactly the scenario you described in proto3 - now every field could be encoded as a Maybe.

A second point that stuck out to me:

>I didn’t understand “the map is not the territory” until I had been programming for awhile. Type systems are a map of runtime behavior. They are useful up to that point. Runtime behavior is the territory; it’s how you make something happen in the world, and it’s what you ultimately care about. A lot of the arguments I see below in this thread seemingly forget that.

Your worldview here is very different from my own, and perhaps while this difference exists, there won't be much mutual understanding. I don't find any relationship between types and anything I understand as "runtime behavior". Types are logical propositions. The relationship between programs and types is that programs are proofs of those propositions. Runtime does not enter into the picture. That's why constraint solvers work without running the program.

Post reply on HN