Ask HN: Best talks of 2018?
What's your favourite talks of 2018? It can be anything, programming, management, life, anything.
204 comments
"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...
James Mickens
https://www.usenix.org/conference/usenixsecurity18/presentat...
This is definitely the most hilarious one, James is a genius.
Added in Watch later yesterday. Absolutely fun and knowledgeable. You might also check his home page[1], contains good and important stuff like this one.
[1]. https://mickens.seas.harvard.edu/wisdom-james-mickens
[1]. https://mickens.seas.harvard.edu/wisdom-james-mickens
I understand why some criticizes the lack of depth of Mickens' presentation.
But, you got to admit that getting people to be interested in engineering ethics is remarquable.
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.youtube.com/watch?v=RjD1aLm4Thg
1. https://www.youtube.com/watch?v=RjD1aLm4Thg
Wow, just wow!
I've often felt that we (humanity) have pushed the boundaries of our knowledge right to some really hard lines to cross: relativity won't allow interstellar travel anytime soon, we are making progress in "soft AI" but "hard AI" is still insurmountable, even fusion seems as far as it's always been. Further "real" progress seems sometimes nearly impossible, or very arduous and slow at best.
Then this guy shows up, cuts a frog's leg, shines some weird lights on the wound... and the frog regenerates it! (frogs do not normally regenerate legs). This has been really astonishing to me. I hope this whole research area lives up to my excitement after listening to that talk, because really awesome things may come out of it.
I highly recommend this talk to literally anybody who has scientific curiosity en general!
I've often felt that we (humanity) have pushed the boundaries of our knowledge right to some really hard lines to cross: relativity won't allow interstellar travel anytime soon, we are making progress in "soft AI" but "hard AI" is still insurmountable, even fusion seems as far as it's always been. Further "real" progress seems sometimes nearly impossible, or very arduous and slow at best.
Then this guy shows up, cuts a frog's leg, shines some weird lights on the wound... and the frog regenerates it! (frogs do not normally regenerate legs). This has been really astonishing to me. I hope this whole research area lives up to my excitement after listening to that talk, because really awesome things may come out of it.
I highly recommend this talk to literally anybody who has scientific curiosity en general!
I definitely agree with you, this feels like REAL progress. I feel like this is a revolution in our understanding of how life as a collection of cells is able to function with such repeat ability and reliability. What is even more amazing is how this talk isn't even just going over our lack of understanding in this area, its saying hey everyone we just filled in this massive gap in our understanding, and look at what real things we can do with it.
It does feel like this research crosses a big line in science. Especially with the recent articles about how gene editing can cause weird defects that we don't understand, this shows we don't need to tinker at the lower levels when life already has the tools for higher level control.
It does feel like this research crosses a big line in science. Especially with the recent articles about how gene editing can cause weird defects that we don't understand, this shows we don't need to tinker at the lower levels when life already has the tools for higher level control.
+1000
Really cool talk / highly recommend! Some things you might learn / amazing facts:
- Children 7-11 can regrow fingertips
- Planarians (a kind of flatworm) are immortal
- If you teach a planarian to find "home", chop off its head and let it regrow its brain, it will still remember where home is
Note also that this was presented at NeurIPS so the talk also includes some discussion of non-neural information systems this kind of thing could inspire.
Really cool talk / highly recommend! Some things you might learn / amazing facts:
- Children 7-11 can regrow fingertips
- Planarians (a kind of flatworm) are immortal
- If you teach a planarian to find "home", chop off its head and let it regrow its brain, it will still remember where home is
Note also that this was presented at NeurIPS so the talk also includes some discussion of non-neural information systems this kind of thing could inspire.
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.
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.
Electron for living cells? (An honest attempt to make a joke)
It is important to note that this Michael Levin is at Tufts https://ase.tufts.edu/biology/faculty/levin/ and is NOT the Michael Levin that comes up first when you search for that name:
https://en.m.wikipedia.org/wiki/Michael_Levin
What an amazing talk. I do stream monitoring and have heard about planaria and have seen specimens. I did not know it is such an amazing creature. What a beautiful talk.
Whoa, this completely altered my point view regarding animal complexity. Natures scary.
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!
Oh boy, this is cool!
this is amazing talk - thanx for sharing
"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.
Another excellent talk by the creator of Clojure, and like the previous ones, relevant for all programmers.
I don’t like Rich’s appeal to human intuition and the physical world as justification for not using—and even disparaging—mathematical structures. His quote from memory was something like “There’s no such thing as a Maybe Sheep,” and that was aggravating to listen to. He then gives the simplest possible examples, and fails to convince me that his approach scales to the real world. At some point he starts talking about what a “person” is and what an “address” is and, somewhat in jest, he says something like “I know I know addresses are difficult this is just a simple example.” It’s precisely the difficult case that I want to see his “intuitive” view of programming actually work out.
Rich is a good speaker but I don’t find the line he toes to be agreeable.
Rich is a good speaker but I don’t find the line he toes to be agreeable.
He's a genius but I think he's getting bitter about how people are happily sticking with static strongly typed languages. At the end of the day he's trying to sell people on using Clojure, so of course he's going to rip on other languages.
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.
>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 about / be broken by. Like if all of a sudden some REST api no longer requires a specific HTTP header to be present in requests, then this change shouldn't break clients that have been including that formerly-required header all along.
Similarly, if you provide something to clients, and you add functionality to provide a response in all circumstances, not just some, then this should not break clients either.
This clearly is not true of `Maybe` / `Option[T]` and I think it's a pretty fair critique. Maybe we should be using Union types in these situations instead.
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 about / be broken by. Like if all of a sudden some REST api no longer requires a specific HTTP header to be present in requests, then this change shouldn't break clients that have been including that formerly-required header all along.
Similarly, if you provide something to clients, and you add functionality to provide a response in all circumstances, not just some, then this should not break clients either.
This clearly is not true of `Maybe` / `Option[T]` and I think it's a pretty fair critique. Maybe we should be using Union types in these situations instead.
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 straightforwardly because they flatten; maybe this is desirable in some cases but the rationale in Hickey's talk leaves me unconvinced. The only practical use case for union types I'm aware of is smoother interfacing to dynamically typed APIs; any nice examples for something beyond that?
Union Types don't compose straightforwardly because they flatten; maybe this is desirable in some cases but the rationale in Hickey's talk leaves me unconvinced. The only practical use case for union types I'm aware of is smoother interfacing to dynamically typed APIs; any nice examples for something beyond that?
> 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.
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.
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!
Yes, that was my fault, I overlooked "result," and I also appreciate the clarification.
I think the point remains that, while this is not a breaking change from a contractual viewpoint, most type systems would deem it incompatible.
I think the point remains that, while this is not a breaking change from a contractual viewpoint, most type systems would deem it incompatible.
I think you're kind of both agreeing. It would be nice if Maybe did work like he suggested, but in practice it's not that big a deal.
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 called as `a -> b`. And Rich must agree because Clojure itself does not support that!
I've learned that videos of his talks are just not worth my time.
I've learned that videos of his talks are just not worth my time.
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.
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.
> 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 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.)
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.)
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.
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 everything is an Object after all but I still would like to see a reasonable thing like Erlang's {:ok,x} | {:error, error} or OCaml's Some x | None. It is not an accident that many languages that like reliability implemented it like that.
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.
> 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 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:
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.)
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.)
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 Maybe generically, I guess my argument here becomes circular. (Begging the question maybe?)
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?)
> 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.
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.
[deleted]
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:
In this regard I really like OCaml:
let get_something = function
| Some x -> x
| None -> raise (Invalid_argument "Option.get")
I was surprised it was a seperate library in Clojure and doesn’t seem to be something that gets used much. Puts me off that it’s missing one of the most attaractive features of functional languages.
Because it would be just as illogical to allow a function `Vec a -> b` to be called as `a -> b`. And Rich must agree because Clojure itself does not support that!
Maybe Clojure's standard library just isn't that focused on vectors? Python stdlib doesn't support this as well, but NumPy does.
Maybe Clojure's standard library just isn't that focused on vectors? Python stdlib doesn't support this as well, but NumPy does.
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 into type theory to describe the very system he is trying to build.
Worse, he continued to implore his audience to spread FUD about type theory, claiming several times, "it is wrong!"
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 into type theory to describe the very system he is trying to build.
Worse, he continued to implore his audience to spread FUD about type theory, claiming several times, "it is wrong!"
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?
Well software engineering is the only engineering field that produces half baked unreliable crappy solutions continuously. Other fields cannot afford such attitude towards products. I think a simple (inferred) type system is pretty useful to increase correctness and it helps you to increase reliability (even though it does not avoid all of the mistakes you can make in software).
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 has taken the time to explain his thoughts very carefully, and his clear about what his experience is, and domains he is talking about. Whereas I see a lot of vague objections without specifics and that aren't backed up by experience.
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 has taken the time to explain his thoughts very carefully, and his clear about what his experience is, and domains he is talking about. Whereas I see a lot of vague objections without specifics and that aren't backed up by experience.
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.
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.
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...
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...
I haven't seen any of Rich's contributions to any major open source Haskell project. I can't really speak to his experiences with Haskell in proprietary code bases. Has he been a prolific Haskell contributor/hacker/user?
From his talk he hasn't convinced me that he understands Haskell's type system. Not only does he misunderstand the contract given by `Maybe a` but he conflates `Either a b` with logical disjunction which is definitely a false pretense. He builds the rest of his specious talk on these ideas and declares, "it [type theory] is wrong!"
He goes on to describe, in a haphazard and ignorant way, half of a type theory. As I understood it these additions to "spec" are basically a row-based polymorphic type system. Why does he refuse to acknowledge or leverage the decades of research on these type systems? Is he a language designer or a hack?
I can't even tell to be honest. He has some good ideas but I think this was one of his worst talks.
From his talk he hasn't convinced me that he understands Haskell's type system. Not only does he misunderstand the contract given by `Maybe a` but he conflates `Either a b` with logical disjunction which is definitely a false pretense. He builds the rest of his specious talk on these ideas and declares, "it [type theory] is wrong!"
He goes on to describe, in a haphazard and ignorant way, half of a type theory. As I understood it these additions to "spec" are basically a row-based polymorphic type system. Why does he refuse to acknowledge or leverage the decades of research on these type systems? Is he a language designer or a hack?
I can't even tell to be honest. He has some good ideas but I think this was one of his worst talks.
I think this comment is a bit too harsh, and I would rather we just discuss the points he makes, not his credibility. The man has decades of experience in software system development and architecture, and has built one of the most popular programming languages in the world, as well as Datomic. If that hasn't given him the right to give his opinion during the keynote of a conference for the language he built, then I don't know how much you want from him.
To apply your own standards, have you been a prolific Clojure contributor/hacker/user? Have you contributed to any major open source Clojure projects?
Can you actually say what about Maybe/Either he got wrong because it seems like he understands it perfectly well, speaking as a Scala developer.
To apply your own standards, have you been a prolific Clojure contributor/hacker/user? Have you contributed to any major open source Clojure projects?
Can you actually say what about Maybe/Either he got wrong because it seems like he understands it perfectly well, speaking as a Scala developer.
> 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 commercial project. It's a fine enough language. I wouldn't call myself an expert. And I haven't given a keynote address where I call out Clojure for getting things I don't understand completely wrong.
> Can you actually say what about Maybe/Either he got wrong because it seems like he understands it perfectly well, speaking as a Scala developer.
His point about Maybe was misguided at best. 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.
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, charitably, a "misnomer."
To his credit he says he's not bashing on type systems, only Maybe and Either. But he later contradicts himself in his conclusions. He goes on about reverse and how "the categoric definition of that is almost information free." And then, "you almost always want your return types to be dependent on their argument..." So basically, dependent types? But again, "you wouldn't need some icky category language to talk about that."
So again, I think he has some surface knowledge of type systems but I don't think he understands type systems. I'm only a beginner at this stuff and his errors were difficult to digest. I think if he wanted to put down Maybe and Either he should've come with a loaded weapon.
He's had better talks to be sure! I just don't think this one was very good. And in my estimation was one of the poorer talks this year.
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 commercial project. It's a fine enough language. I wouldn't call myself an expert. And I haven't given a keynote address where I call out Clojure for getting things I don't understand completely wrong.
> Can you actually say what about Maybe/Either he got wrong because it seems like he understands it perfectly well, speaking as a Scala developer.
His point about Maybe was misguided at best. 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.
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, charitably, a "misnomer."
To his credit he says he's not bashing on type systems, only Maybe and Either. But he later contradicts himself in his conclusions. He goes on about reverse and how "the categoric definition of that is almost information free." And then, "you almost always want your return types to be dependent on their argument..." So basically, dependent types? But again, "you wouldn't need some icky category language to talk about that."
So again, I think he has some surface knowledge of type systems but I don't think he understands type systems. I'm only a beginner at this stuff and his errors were difficult to digest. I think if he wanted to put down Maybe and Either he should've come with a loaded weapon.
He's had better talks to be sure! I just don't think this one was very good. And in my estimation was one of the poorer talks this year.
>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, charitably, a "misnomer."
I don't agree with Hickey, but isn't there a connection between Either as a basic sum type and logical disjunction via the curry-howard correspondence?
And wouldn't "forall a b. Either a b" be the bifunctor, since it has a product type/product category as it's domain, while the result "Either X Y" (where X and Y are concrete types, not type variables) has the semantics of logical disjunction ie. it represents a type that is of type X or type Y?
I don't agree with Hickey, but isn't there a connection between Either as a basic sum type and logical disjunction via the curry-howard correspondence?
And wouldn't "forall a b. Either a b" be the bifunctor, since it has a product type/product category as it's domain, while the result "Either X Y" (where X and Y are concrete types, not type variables) has the semantics of logical disjunction ie. it represents a type that is of type X or type Y?
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.
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.
> 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?
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.
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.
But protos and Haskell's type system solve different problems.
Perhaps, maybe, public apis like protos shouldn't encode requiredness of any piece of data (I actually fully agree with this).
But that says nothing about whether or not my private/internal method to act on a proto should care.
Another way of putting this is that requiredness ahiuslnt be defined across clients (as in a proto), but defining it within a context makes a lot of sense, and maybe/optional constructs can do that.
Or iow, other peopleay use your schema in interested and unexpected ways. Don't be overly controlling. Your code on the other hand is yours, and controlling it makes more sense. So the arguments that rely on proto-stuff don't really convince me.
(I work at Google with protos that still have required members).
Perhaps, maybe, public apis like protos shouldn't encode requiredness of any piece of data (I actually fully agree with this).
But that says nothing about whether or not my private/internal method to act on a proto should care.
Another way of putting this is that requiredness ahiuslnt be defined across clients (as in a proto), but defining it within a context makes a lot of sense, and maybe/optional constructs can do that.
Or iow, other peopleay use your schema in interested and unexpected ways. Don't be overly controlling. Your code on the other hand is yours, and controlling it makes more sense. So the arguments that rely on proto-stuff don't really convince me.
(I work at Google with protos that still have required members).
> But protos and Haskell's type system solve different problems.
That's pretty much my point. Hickey is very clear what domains he's talking about, which are similar to the domains that protos are used in -- long-lived, "open world" information systems with many pieces of code operating on the same data.
People saying "Rich Hickey doesn't understand type systems" are missing the point. He's making a specific argument backed up by experience, and they are making a vague one. I don't want to mischaracterize anyone, but often I see nothing more than "always use the strictest types possible because it catches bugs", which is naive.
I agree with your statement about private/internal methods. I would also say that is the "easy" problem. You can change those types whenever you want, so you don't really have to worry about modelling it incorrectly. What Hickey is talking about is situations where you're interfacing with systems you don't control, and you can't upgrade everything at once.
That's pretty much my point. Hickey is very clear what domains he's talking about, which are similar to the domains that protos are used in -- long-lived, "open world" information systems with many pieces of code operating on the same data.
People saying "Rich Hickey doesn't understand type systems" are missing the point. He's making a specific argument backed up by experience, and they are making a vague one. I don't want to mischaracterize anyone, but often I see nothing more than "always use the strictest types possible because it catches bugs", which is naive.
I agree with your statement about private/internal methods. I would also say that is the "easy" problem. You can change those types whenever you want, so you don't really have to worry about modelling it incorrectly. What Hickey is talking about is situations where you're interfacing with systems you don't control, and you can't upgrade everything at once.
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<MyActualClass> / 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.
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<MyActualClass> / 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.
[deleted]
I actually went ahead to learn haskell after one of his recent talks(my motivation was the vehement rejection from the haskell community..on reddit mostly) I haven't turned back since then. It's either he doesn't really understand how types are used or he's intentionally "bad-mouthing" types(which I don't think he's doing)
The second half, about his work on spec, is great.
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)
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)
Was about to suggest this myself. I see a few that didn't like this and I can see why, but I thought it was interesting to listen too. Always interesting to hear someone knowledgeable argue for something you don't think you agree with. It is also interesting since Rich is in the quite unique position of handling a functional language with dynamic types (a dying breed in the functional space imo).
I don't think Rich fully convinced me to change my mind, but he made me think about when and why Maybe is needed.
I think dynamic FP programming is actually doing quite well these days. Apart from Clojure & ClojureScript, there's Erlang and Elixir, and the Racket community, and in addition it's become popular to write FP code in Javascript using Ramda, immutable.js & etc - not to mention the FP nature of React.
Dying breed based on what? They're different compromises, there is nothing inherently superior about static types. It's more popular right now, because we're very much into rules at the moment; but I have a feeling that's peaking.
Typically, you need to move back and forth a number of times before it clicks. So you have all these people on the net fighting over which end of the spectrum is the Right one, and next month they're on opposite sides.
They're tools, hammers, screw drivers whatever; it doesn't make any kind of sense to identify with them. Unless your goal is to be a tool, I guess.
Typically, you need to move back and forth a number of times before it clicks. So you have all these people on the net fighting over which end of the spectrum is the Right one, and next month they're on opposite sides.
They're tools, hammers, screw drivers whatever; it doesn't make any kind of sense to identify with them. Unless your goal is to be a tool, I guess.
There is one advantage of formal specs in general that static types inherent: they can enforce a correctness policy on a design that works for all inputs with no runtime overhead. SPARK Ada eliminating entire classes of errors with mostly-automated analysis is one example. Rust blocking temporal and some concurrency errors without GC is another. I'll note they're both hard to eliminate with testing, too.
With that, comes the next benefit: less debugging and lower maintenance costs. It has to be balanced against annotation costs. Most projects claimed to come out ahead if it was just safety rather than full correctness. You can also generate tests and runtime checks from specs to get those benefits.
So, for high reliability with lower maintenance, there's definitely an advantage to knocking out entire classes of error. That leads to last advantage Ill mention: ability to warranty (market) and certify (regulators) your code free of those defects [if the checker worked]. The checkers are also tiny on some systems. Rarely fail. Inspires extra confidence.
With that, comes the next benefit: less debugging and lower maintenance costs. It has to be balanced against annotation costs. Most projects claimed to come out ahead if it was just safety rather than full correctness. You can also generate tests and runtime checks from specs to get those benefits.
So, for high reliability with lower maintenance, there's definitely an advantage to knocking out entire classes of error. That leads to last advantage Ill mention: ability to warranty (market) and certify (regulators) your code free of those defects [if the checker worked]. The checkers are also tiny on some systems. Rarely fail. Inspires extra confidence.
Sure, in return for bending code over backwards to fit rules you get guarantees; but pretending that is anything but a different compromise isn't helping. If Ada was all that, everyone would be using it; and that's not going to happen, because it's not a realistic approach to programming.
The academic approach doesn't look very constructive to me, never did. Once you have a language nailed down so hard that errors aren't possible, the complexity of dealing with it will be more or less the same as dealing with the errors in the first place.
I would much prefer a focus on more powerful tools that fit into the current "unsafe" ecosystem while offering a more gradual and flexible path to improved safety.
The academic approach doesn't look very constructive to me, never did. Once you have a language nailed down so hard that errors aren't possible, the complexity of dealing with it will be more or less the same as dealing with the errors in the first place.
I would much prefer a focus on more powerful tools that fit into the current "unsafe" ecosystem while offering a more gradual and flexible path to improved safety.
"If Ada was all that, everyone would be using it"
Argument for popularity = superiority. By your same logic, we shouldve stuck with COBOL for important apps since all the big businesses were using it. I have a feeling you dont write new apps in COBOL.
"the complexity of dealing with it will be more or less the same as dealing with the errors in the first place."
The best empirical comparison of C and Ada showed the opposite. All studies showed the safer languages had less defects with usually more productivity due to less rework later on. Evidence is against your claim so far.
"I would much prefer a focus on more powerful tools that fit into the current "unsafe" ecosystem while offering a more gradual and flexible path to improved safety."
Me too. Rust and Nim are taking that approach. People are finding both useful in production so far.
Argument for popularity = superiority. By your same logic, we shouldve stuck with COBOL for important apps since all the big businesses were using it. I have a feeling you dont write new apps in COBOL.
"the complexity of dealing with it will be more or less the same as dealing with the errors in the first place."
The best empirical comparison of C and Ada showed the opposite. All studies showed the safer languages had less defects with usually more productivity due to less rework later on. Evidence is against your claim so far.
"I would much prefer a focus on more powerful tools that fit into the current "unsafe" ecosystem while offering a more gradual and flexible path to improved safety."
Me too. Rust and Nim are taking that approach. People are finding both useful in production so far.
Wow wow chill out. It wasn't meant as a negative comment. I was just making the observation most new languages are staticly typed and that a lot of what you hear in the functional space is about types (type theory, dependant types, categories...) though this might be just what I've had infront of me recently. I retract my statement. I love the dynamic functional languages. Erlang and Clojure are amazing (now that I think about it elixir is a lot in the news, as I said my statement probably was wrong).
And as I said in my previous comment, I think Rich talk made some really interesting points.
And I don't consider clojure dying at all btw. In the field of data science especially it is thriving. I was tired ok... So... There...
Fundamentally changed how I think about modelling data
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://www.thestrangeloop.com/2018/git-from-the-ground-up.h...
From PyCon:
* Beyond Unit Tests: Taking Your Testing to the Next Level: https://www.youtube.com/watch?v=MYucYon2-lk
* Dataclasses: The code generator to end all code generator: https://www.youtube.com/watch?v=T-TwcmT6Rcw
* Automating Code Quality: https://www.youtube.com/watch?v=G1lDk_WKXvY
There are probably more I might add later as I remember them.
* 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://www.thestrangeloop.com/2018/git-from-the-ground-up.h...
From PyCon:
* Beyond Unit Tests: Taking Your Testing to the Next Level: https://www.youtube.com/watch?v=MYucYon2-lk
* Dataclasses: The code generator to end all code generator: https://www.youtube.com/watch?v=T-TwcmT6Rcw
* Automating Code Quality: https://www.youtube.com/watch?v=G1lDk_WKXvY
There are probably more I might add later as I remember them.
> "Beyond Unit Tests: Taking Your Testing to the Next Level"
+1 Very interesting. I will make sure to check the `Hypothesis` module.
+1 Very interesting. I will make sure to check the `Hypothesis` module.
"The Hard Parts of Open Source" by Evan Czaplicki https://www.youtube.com/watch?v=o_4EX4dPppA
"Design Microservice Architectures the Right Way" by Michael Bryzek [1]
Really good discussion on event-collaborative microservice systems that scale well for performance and maintenance as well as a good argument and use case for server and client code generation.
Definitely my favorite so far.
[1] https://www.infoq.com/presentations/microservices-arch-infra...
Really good discussion on event-collaborative microservice systems that scale well for performance and maintenance as well as a good argument and use case for server and client code generation.
Definitely my favorite so far.
[1] https://www.infoq.com/presentations/microservices-arch-infra...
Thanks for this, it's a great talk. I think the real point here has nothing to do with microservices; look at the leverage and flexibility they gain because everything is built data-first.
it's said microservice is phasing out to serverless?
I think more and more it's a case of people realizing there is no definitive "microservice" architecture. Because of that architects around the industry are now focusing on the flow of data and using whichever tools are best to get the right behavior in their business.
What was called microservices imo was just a higher level modularization of code to allow easier parallel development and maintenance/scaling, but since it needs a server that meant some boilerplate to initialize and keep the app running. A lot of people went about this in different ways which made things a bit chaotic to those new to the idea I think. The next logical step would be to remove that server code by running on a serverless architecture to focus on the functions that operate on data rather than having to maintain the initialization code and other boilerplate as well.
Among all of this advancement, an architect thinking the way Michael Bryzek does would have no problem using either approach since the focus is on the data and how data is used.
Still, server-based microservices are still very prominent, and I'd argue they are also much more platform agnostic if done right whereas (if I'm not mistaken) much of serverless is done in specific platforms causing you to be vendor-locked due to different deployment processes for each platform. I think research is being done to make platform-agnostic serverless deployments easier, but I haven't read much on it yet and am unaware of current advancements in that area.
What was called microservices imo was just a higher level modularization of code to allow easier parallel development and maintenance/scaling, but since it needs a server that meant some boilerplate to initialize and keep the app running. A lot of people went about this in different ways which made things a bit chaotic to those new to the idea I think. The next logical step would be to remove that server code by running on a serverless architecture to focus on the functions that operate on data rather than having to maintain the initialization code and other boilerplate as well.
Among all of this advancement, an architect thinking the way Michael Bryzek does would have no problem using either approach since the focus is on the data and how data is used.
Still, server-based microservices are still very prominent, and I'd argue they are also much more platform agnostic if done right whereas (if I'm not mistaken) much of serverless is done in specific platforms causing you to be vendor-locked due to different deployment processes for each platform. I think research is being done to make platform-agnostic serverless deployments easier, but I haven't read much on it yet and am unaware of current advancements in that area.
I was under that impression as well, that "Microservice" was now becoming too much boilerplate overhead, inconsistently defined within our industry, and easily misunderstood by those that implement them. Serverless architectures do solve these issues, however they are not a panacea.
From Deconstruct:
Nabil Hassein: Computing, Climate Change, and All Our Relationships https://www.deconstructconf.com/2018/nabil-hassein-computing...
Tom 7: Reverse emulating the NES to give it SUPER POWERS! https://www.youtube.com/watch?v=ar9WRwCiSr0
Nabil Hassein: Computing, Climate Change, and All Our Relationships https://www.deconstructconf.com/2018/nabil-hassein-computing...
Tom 7: Reverse emulating the NES to give it SUPER POWERS! https://www.youtube.com/watch?v=ar9WRwCiSr0
This. I was at Deconstruct too, and Nabil's talk got a standing ovation. It ran way over time, and I didn't notice. Tech people need to hear this. Tom's talk is also amazing in its own right.
Let's Program a Banjo Grammar was also one of my favorites. :D
https://www.deconstructconf.com/2018/ryan-herr-lets-program-...
Edit: I just looked at your username...that you, Ryan? :)
Let's Program a Banjo Grammar was also one of my favorites. :D
https://www.deconstructconf.com/2018/ryan-herr-lets-program-...
Edit: I just looked at your username...that you, Ryan? :)
Yep, that was me — thank you for the kind words!
Gary Bernhardt had a creative concept for selecting speakers. Half were invited, internet famous people like Tom 7 and Julia Evans. Half were people who'd never spoke at a conference before, like Nabil and I. For the call for proposals, we submitted 2 minute videos instead of abstracts. Gary invested a lot of time mentoring the new speakers, which I'm so grateful for!
In September, I did another, kind of similar talk at Strange Loop, called "Picasso, Geometry, Jupyter." https://www.youtube.com/watch?v=GYJ77F_8kq0
The topic and ideas were good, probably better than my Deconstruct talk. But my execution and presentation were uneven and unpolished, so I'd like to try it again at another conference. I'm submitting to PyCon — we'll see!
Gary Bernhardt had a creative concept for selecting speakers. Half were invited, internet famous people like Tom 7 and Julia Evans. Half were people who'd never spoke at a conference before, like Nabil and I. For the call for proposals, we submitted 2 minute videos instead of abstracts. Gary invested a lot of time mentoring the new speakers, which I'm so grateful for!
In September, I did another, kind of similar talk at Strange Loop, called "Picasso, Geometry, Jupyter." https://www.youtube.com/watch?v=GYJ77F_8kq0
The topic and ideas were good, probably better than my Deconstruct talk. But my execution and presentation were uneven and unpolished, so I'd like to try it again at another conference. I'm submitting to PyCon — we'll see!
Hey, that's great! Even if the execution wasn't up to your standards, I'm looking forward to watching! I heard from someone at the conference (maybe it was you even?) about how Gary curated the talks. I'm really glad he did that, because all around it was my favorite tech conference I've been to and I'll definitely be back. :)
Some of the better talks are yet to come
https://fahrplan.events.ccc.de/congress/2018/Fahrplan/index....
https://fahrplan.events.ccc.de/congress/2018/Fahrplan/index....
Do you know of anywhere to watch them live? I found this https://streaming.media.ccc.de/ but I'm not 100% sure it's what I want
That is probably the correct location for live streams. If it doesn't work, https://twitter.com/c3voc will know what's up.
The Streams will later be edited and uploaded to https://media.ccc.de/ where they will appear incrementally a few days (or sometimes even hours) after the talks are over. So it's usually not a problem to miss a talk.
The Streams will later be edited and uploaded to https://media.ccc.de/ where they will appear incrementally a few days (or sometimes even hours) after the talks are over. So it's usually not a problem to miss a talk.
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
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
Thanks, very interesting. He is right, the Rust borrow checker can not deal with arbitrary graphs and she added a memory management layer on top of the Rust one. However, you would have to do the same in C++. It is an interesting obervation. I spoke to Benedikt Meurer from the Google V8 team recently and he pointed out the same for Javascript Engines. If you do not have DAGs, Rust can‘t help you with safety. (at least it can not prevent use after free) I still like the whole ECS idea and it makes sense for me that using ECS in Rust will provide a performant and clean architecture.
[deleted]
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.
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.
Lessons Learned Implementing Common Lisp with LLVM
https://www.youtube.com/watch?v=mbdXeRBbgDM
https://www.youtube.com/watch?v=mbdXeRBbgDM
[deleted]
I wish he had time to do part 2 and part 3 of this.
This is next level hacking.
To do CAD program for synthetic biology Chemistry professor writes his own implementation of Common Lisp.
To do CAD program for synthetic biology Chemistry professor writes his own implementation of Common Lisp.
That was a great talk! Wish he had more time.
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
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.
A lot has to be accounted for his brain which is quite different from ours
https://news.ycombinator.com/item?id=14503404
https://news.ycombinator.com/item?id=14503404
nit: Honnold
Kristen Jacobs' talk on low level container networking at Kubecon 2018 in Seattle.
https://kccna18.sched.com/event/GrWx/container-networking-fr...
https://kccna18.sched.com/event/GrWx/container-networking-fr...
YouTube link for this talk: https://www.youtube.com/watch?v=6v_BDHIgOY8&index=255&list=P...
I 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 from the 60s and 70s.
Kevlin Henney - Procedural Programming: It's Back? It Never Went Away https://www.youtube.com/watch?v=otAcmD6XEEE
Kevlin Henney - Procedural Programming: It's Back? It Never Went Away https://www.youtube.com/watch?v=otAcmD6XEEE
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
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
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
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
Deviant Ollam seriously needs an award.
"Deep Learning to solve Challenging Problems" by Jeff Dean https://www.youtube.com/watch?v=3jzi3cvCde4
I'll watch Jeff Dean talk about pretty much anything, and his keynote "stump speeches" are more or less a greatest hits compilation of recent stuff from Google Brain.
I'll watch Jeff Dean talk about pretty much anything, and his keynote "stump speeches" are more or less a greatest hits compilation of recent stuff from Google Brain.
It's not a talk, but worth a mention. Joe Rogan interviews Matthew Walker, a Professor of Neuroscience and Psychology at the University of California, Berkeley, and Founder and Director of the Center for Human Sleep Science and author of the book "Why We Sleep: Unlocking the Power of Sleep and Dreams".
https://www.youtube.com/watch?v=pwaWilO_Pig
https://www.youtube.com/watch?v=pwaWilO_Pig
2018 LLVM Developers’ Meeting: C. Schafmeister “Lessons Learned Implementing Common Lisp with LLVM”
https://www.youtube.com/watch?v=mbdXeRBbgDM
https://www.youtube.com/watch?v=mbdXeRBbgDM
I really liked Paul Hill's "Failure is not an option: Building a culture of continuous improvement at NASA", the keynote from this year's DashCon: https://www.youtube.com/watch?v=XMkgk-7aIBc&index=16&list=PL...
It was really nice to see that the current Devops/SRE best practices are reflections of engineering/operations best practices in other fields
It was really nice to see that the current Devops/SRE best practices are reflections of engineering/operations best practices in other fields
Kelsey Hightower's talk on the "Path to Serverless".
https://youtu.be/oNa3xK2GFKY
https://youtu.be/oNa3xK2GFKY
I really enjoy Kelsey on all his talks. The most laid-back and funny presenter. All my initial Kubernetes knowledge was drawn from his lectures.
Really great talk! I think my favorite was his continuous emphasis on not being so vendor-favored. It's increasingly important to be reminded of this these days.
What bodies think about - by Michael Levin at NeurIPS 2018.
https://www.youtube.com/watch?v=RjD1aLm4Thg
I dont really know anything about biology, but this piqued my interest.One of the most interesting talks of 2018.
https://www.youtube.com/watch?v=RjD1aLm4Thg
I dont really know anything about biology, but this piqued my interest.One of the most interesting talks of 2018.
Seconded. Had no idea what it was going to be about and thought it might have been the most interesting talk I've ever seen.
Why Germany cannot and should not pay to save the Eurozone, by Yanis Varoufakis
(Video in English)
http://www.cesifo-group.de/de/ifoHome/events/seminars/Muench...
http://www.cesifo-group.de/de/ifoHome/events/seminars/Muench...
At around 15'40", Varoufakis says that Bretton Woods collapsed in 1971. I'm not enough of an economist/historian to understand this reference. Is he talking about the dollar going off of the gold standard? If so, why is he equating Bretton Woods with this arrangement (ie the dollar being on the gold standard?)
Edit: nm, found this from the US National Bureau of Economic Research: https://www.nber.org/chapters/c6876.pdf
Edit: nm, found this from the US National Bureau of Economic Research: https://www.nber.org/chapters/c6876.pdf
The Bretton Woods system was a predecessor of the Eurozone (Fixed exchange rate currency). Saying, that in order to have a healthy common monetary union you need to have a federal union first. Otherwise things crashes, as happened to bretton woods and as it’s happening on the eurozone
The Euro is not fixed to anything, but its value floats freely like any other currency. It is "fixed" to Eurozone members in the sense that they can't value/devalue it by themselves.
Comparing the Bretton Woods system to the Eurozone is not a direct comparison
Comparing the Bretton Woods system to the Eurozone is not a direct comparison
Fixed exchange rate meant as if all countries in Europe would have a fixed exchange rate between them (even if they would use different currencies). Hence the comparison eurozone-Bretton Woods
Direct link to the talk on YouTube (in English):
https://www.youtube.com/watch?v=QtrrN2uWUl8
https://www.youtube.com/watch?v=QtrrN2uWUl8
Any talk by Varoufakis is worth listening to.
He is a very controversial figure in both Greece and Europe as a whole.
Controversial in the very least. I also got the impression that he was quite anti-EU with his whole Greece rhetoric during the discussions about another Greek buyout. Maybe I got him wrong..?
How could he not be? The people he was negotiating with to try and save Greece were telling him - look, we know you’re right, but we’re going to completely ignore that fact and institute policy that completely fucks the worst off Greeks.
Here is an interview that explains his position a bit better than my paraphrasing: https://amp.theguardian.com/books/2017/mar/07/yanis-varoufak...
Here is an interview that explains his position a bit better than my paraphrasing: https://amp.theguardian.com/books/2017/mar/07/yanis-varoufak...
The guy is a jerk. He fucked up in an unprecedented way, his whole negotiation strategy was just a blackmail toward EU-Germany that eventually backfired. In the meantime all his proposals for reforming the public sector were laughable, like the idea of giving cameras to tourists to record tax evading shops.
He may be good at writing books or giving lectures but he was a complete disaster as minister of finance.
He may be good at writing books or giving lectures but he was a complete disaster as minister of finance.
Not sure about that. He was trying to get the best deal for Greece, Germany called his bluff and he was left holding the bag, but he had the right intentions. In retrospect he probably should have gone with the Grexit. The Germans would have capitulated, and, had they not, you’d still be better off.
Maybe downvoted because of the language, but the comment is accurate. The guy is a megalomaniac, who negotiated for Greece without ANY skin in the game.
Would not surprise me. It is my understanding that not a lot of people that actually understand how the EU works are pro EU at this point...
From the talk he appears everything but anti-EU. If you carefully listen to him, what he aims at is a federal-EU. He also justify the collapse of high-balance-deficit countries with the fact everyone is in the Eurozone. Therefore fuelling the borrow of capital that won’t be repaid, until bankruptcy.
For those who had the misfortune to suffer the consquences of his folly, he is not controversial at all. He is a conceited man-child with very bad manners. There's readily accessible, amble evidence for that by looking at photos of him in various settings, both formal and relaxed. The way he dresses and, more importantly, his body language make it quite plain. His writings and interviews attest to the same. BTW, and to do him full justice, his mathy book on game theory is not bad (though hardly a classic) so he may be somewhat competent as an academic economist.
The man is articulated but nothing of what he says brings anything to my mind. Maybe he's just too smart.. but I can't discern from overenginered pub talk.
Seems like English is not your first language ..?
He’s very articulate, and not only does he make a lot of sense, I’ve never seen him caught in a lie.
And I have no idea what makes you think it’s pub talk, I’m from the land of pubs (Ireland) and I’ve never heard anyone talk like he does in one.
He’s very articulate, and not only does he make a lot of sense, I’ve never seen him caught in a lie.
And I have no idea what makes you think it’s pub talk, I’m from the land of pubs (Ireland) and I’ve never heard anyone talk like he does in one.
what good does it do pointing that out, if it's even true? it's clear they meant articulate and public.
“Pub talk” is a thing, and “can’t discern from overengineered pub talk” makes sense.
“Can’t discern from overengineered public talk” is plausible, but it would be very unusual to phrase it that way.
It’s not really clear that he meant "public."
“Can’t discern from overengineered public talk” is plausible, but it would be very unusual to phrase it that way.
It’s not really clear that he meant "public."
I meant a never ending stream of sophisticated ideas and precise data that leads nowhere. I used to watch every interview of the guy[1] and .. I always left the video empty minded.
[1] he seemed to have human values and of course knowledge about the topic
[1] he seemed to have human values and of course knowledge about the topic
Ok, we're going down a rabbit hole here, but just to clarify, you meant "pub talk" as in the kind of conversation people have at a pub after a few beers? Or "public talk" as in a public speech, as nikofeyn suggested?
i can see "overengineered pub talk" as a specific critique instead of them meaning public. i am probably wrong there. but the point still stands as it's rude and not important to make a mention of their english, especially when it seems what they meant is one of two things, both of which make sense.
The 2018 Turing Award lecture, by John Hennessy (MIPS, Stanford, Alphabet) and David Patterson (Berkeley, RISC)
https://iscaconf.org/isca2018/turing_lecture.html
> Titled “A New Golden Age for Computer Architecture: Domain-Specific Hardware/Software Co-Design, Enhanced Security, Open Instruction Sets, and Agile Chip Development,” the talk covers recent developments and future directions in computer architecture. Hennessy and Patterson were recognized with the Turing Award for “pioneering a systematic, quantitative approach to the design and evaluation of computer architectures with enduring impact on the microprocessor industry.”
https://iscaconf.org/isca2018/turing_lecture.html
> Titled “A New Golden Age for Computer Architecture: Domain-Specific Hardware/Software Co-Design, Enhanced Security, Open Instruction Sets, and Agile Chip Development,” the talk covers recent developments and future directions in computer architecture. Hennessy and Patterson were recognized with the Turing Award for “pioneering a systematic, quantitative approach to the design and evaluation of computer architectures with enduring impact on the microprocessor industry.”
Not necessarily the best, but definitely one that should be watched "Escaping the Global Banking Cartel" by Andreas M. Antonopoulos https://www.youtube.com/watch?v=LgI0liAee4s
I thought Hillel Wayne's talk, Everything about distributed systems is terrible, was probably the best talk for the motivation behind why you should be using TLA+ to design systems:
https://www.youtube.com/watch?v=tfnldxWlOhM
https://www.youtube.com/watch?v=tfnldxWlOhM
A Serverless Journey: AWS Lambda Under the Hood
https://m.youtube.com/watch?v=QdzV04T_kec
https://m.youtube.com/watch?v=QdzV04T_kec
Eugenia Cheng: "The Art of Logic: How to Make Sense in a World that Doesn't"
https://www.youtube.com/watch?v=YHZKX0H6cUE
I saw an other version at Scala Exchange but that one requires registration [1] and it's seems to be almost the same talk.
It's very impressive summary of her latest book ("The Art Of Logic") about the importance of abstract logic in every day life and how abstraction can help us to understand each other (together with emotions).
[1]: https://skillsmatter.com/skillscasts/12089-keynote-conveying...
https://www.youtube.com/watch?v=YHZKX0H6cUE
I saw an other version at Scala Exchange but that one requires registration [1] and it's seems to be almost the same talk.
It's very impressive summary of her latest book ("The Art Of Logic") about the importance of abstract logic in every day life and how abstraction can help us to understand each other (together with emotions).
[1]: https://skillsmatter.com/skillscasts/12089-keynote-conveying...
The Best Way to Predict the Future is to Create It. But Is It Already Too Late? by Alan Kay
https://videocast.nih.gov/Summary.asp?Live=28442&bhcp=1
Kay begins at 4:00.
I love any talk with Joe Armstrong or Alan Kay in it.
Joe Armstrong - Keynote: The Forgotten Ideas in Computer Science - Code BEAM SF 2018
https://www.youtube.com/watch?v=-I_jE0l7sYQ
Joe Armstrong - Keynote: The Forgotten Ideas in Computer Science - Code BEAM SF 2018
https://www.youtube.com/watch?v=-I_jE0l7sYQ
I liked Erica Joy's keynote at Strange Loop a lot. https://www.youtube.com/watch?v=gi02tn3K2b4
One of my favourites was James Governor’s Sympathy for the DevRel. A call for people in tech to take better care of themselves.
https://devrel.net/dev-rel/sympathy-for-the-devrel
https://devrel.net/dev-rel/sympathy-for-the-devrel
“Be Human To Your Machines” — Scott Ganz at TedXSanFrancisco 2018.
https://youtu.be/Y6eNSf4br5Y
Emmy-winning TV comedy writer becomes award-winning AI conversation designer, frets about the dismissive way humans interact with computers and the corrosive social effects of badly-designed bots. Explains why conversation interfaces need to stick up for themselves and push back on bad behavior, for the good of human discourse.
https://youtu.be/Y6eNSf4br5Y
Emmy-winning TV comedy writer becomes award-winning AI conversation designer, frets about the dismissive way humans interact with computers and the corrosive social effects of badly-designed bots. Explains why conversation interfaces need to stick up for themselves and push back on bad behavior, for the good of human discourse.
"How to Win" by Daniel Gross[1]
It's an approach to living your life in a way that lets you be effective at accomplishing whatever you're after. Starting on something similar to a Mazlow's heirarchy(in that you must establish each level before going to the next one), you eventually find a way of not only living better and more effectively yourself, but finding how to expand that to your team and those around you. I didn't expect it to be good, but I liken it to Carnegie's "How to Win Friends and Influence People"- it gets to the core of the problem in the best way possible.
1. https://www.youtube.com/watch?v=LH1bewTg-P4
It's an approach to living your life in a way that lets you be effective at accomplishing whatever you're after. Starting on something similar to a Mazlow's heirarchy(in that you must establish each level before going to the next one), you eventually find a way of not only living better and more effectively yourself, but finding how to expand that to your team and those around you. I didn't expect it to be good, but I liken it to Carnegie's "How to Win Friends and Influence People"- it gets to the core of the problem in the best way possible.
1. https://www.youtube.com/watch?v=LH1bewTg-P4
Blockchains Are a Bad Idea (James Mickens)
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
https://www.youtube.com/watch?v=AnZ0uTOerUI
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
https://www.youtube.com/watch?v=AnZ0uTOerUI
A walk through of PDF's history and file format, check out Chas Emerick's 2018 Red Monk tech talk:
"Building 100 year systems in the shadow of PDF". https://www.youtube.com/watch?v=5EPn6plqkEs
"Building 100 year systems in the shadow of PDF". https://www.youtube.com/watch?v=5EPn6plqkEs
Jeff Vogel from Spiderweb Software gave an awesome retrospective on 24 years of creating old-school-style fantasy RPGs at GDC 2018:
"Failing to Fill: The Spiderweb Software Way" https://youtu.be/stxVBJem3Rs
"Failing to Fill: The Spiderweb Software Way" https://youtu.be/stxVBJem3Rs
It is not only about the content but the energy and how to present it.
They rock presenting great content in a great way.
---
Monica Dinculescu (https://github.com/notwaldorf)
PWA starter kit: build fast, scalable, modern apps with Web Components (Google I/O '18)
https://www.youtube.com/watch?v=we3lLo-UFtk
---
Kelsey Hightower (https://github.com/kelseyhightower/)
Keynote: Kubernetes and the Path to Serverless - Kelsey Hightower, Staff Developer Advocate, Google
https://www.youtube.com/watch?v=oNa3xK2GFKY
They rock presenting great content in a great way.
---
Monica Dinculescu (https://github.com/notwaldorf)
PWA starter kit: build fast, scalable, modern apps with Web Components (Google I/O '18)
https://www.youtube.com/watch?v=we3lLo-UFtk
---
Kelsey Hightower (https://github.com/kelseyhightower/)
Keynote: Kubernetes and the Path to Serverless - Kelsey Hightower, Staff Developer Advocate, Google
https://www.youtube.com/watch?v=oNa3xK2GFKY
I made a playlist of all the youtube links form this section: https://www.youtube.com/playlist?list=PLh6DLqe0B3ZCLi1bYvQrn...
Thank you
My favorite talk was called "Generations @ Work", presented at Red Hat Summit 2018.
It was about different generations in the workplace, what each grouping typically liked, disliked, was motivated by, and how they communicated differently.
I really liked it because of the content, but also because it was given by a small panel, I was a member of it. :)
Why did I propose such a talk? I usually submit technical talks to conferences, sometimes they are chosen. This year I did NOT have a technical talk selected by the Summit committee, but on a whim I had submitted this 'softball/managerial' title. It was the one that got me a ticket to Summit! You never know.
It was about different generations in the workplace, what each grouping typically liked, disliked, was motivated by, and how they communicated differently.
I really liked it because of the content, but also because it was given by a small panel, I was a member of it. :)
Why did I propose such a talk? I usually submit technical talks to conferences, sometimes they are chosen. This year I did NOT have a technical talk selected by the Summit committee, but on a whim I had submitted this 'softball/managerial' title. It was the one that got me a ticket to Summit! You never know.
AWS re:Invent 2018: Close Loops & Opening Minds: How to Take Control of Systems, Big & Small
https://youtu.be/O8xLxNje30M
https://youtu.be/O8xLxNje30M
I haven't seen the talk, but just from the title, a "taking control" talk related to AWS is kind of ironic.
I'll have to watch it though.
I'll have to watch it though.
This one struck a chord for me, related to trying to share your personal/health situation at work, not a topic that is talked about alot - https://ministryoftesting.com/dojo/lessons/i-have-a-secret-a...
I enjoyed Juan Benet’s Long Now talk about the permanent web http://longnow.org/seminars/02018/aug/06/long-term-info-stru...
Inside The Fake Science Factory from DefCon 26. First you'll laugh. And then you'll weep for humanity!
https://www.youtube.com/watch?v=ras_VYgA77Q
Also really dug Jeremy Rifkin's The Third Industrial Revolution: A Radical New Sharing Economy. Outlines the rollout of a possible new engineering platform consisting of free energy, satellite internet, and AI.
https://www.youtube.com/watch?v=QX3M8Ka9vUA
Keep the links coming, please. Terrific counter-programming for holiday down time ;)
https://www.youtube.com/watch?v=ras_VYgA77Q
Also really dug Jeremy Rifkin's The Third Industrial Revolution: A Radical New Sharing Economy. Outlines the rollout of a possible new engineering platform consisting of free energy, satellite internet, and AI.
https://www.youtube.com/watch?v=QX3M8Ka9vUA
Keep the links coming, please. Terrific counter-programming for holiday down time ;)
Dave Ackley's Retirement Talk https://www.youtube.com/watch?v=YtzKgTxtVH8
Joe Rogan has had an incredible year.
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
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
2018 is not over yet and CCC happening again next week usually delivers talks that place very high in my personal ranking.
The upcoming "chaos communication congress" always has a few gems https://fahrplan.events.ccc.de/congress/2018/Fahrplan/events...
I thought this was incredible: What's Next for Marketplace Startups https://www.youtube.com/watch?v=zl14Ty5-0Ko
Great explanation of this space and their views on augmenting existing regulated markets.
Great explanation of this space and their views on augmenting existing regulated markets.
[deleted]
Machine Learning for JS Developers : https://www.youtube.com/watch?v=_xm8ox1mmzE&frags=pl%2Cwn
[deleted]
Teaching kids to code at goto berlin: https://m.youtube.com/watch?v=patyK226zeE
I quite liked Johann Hari on Sam Harris's podcast on addiction, depression, etc. https://www.youtube.com/watch?v=msP0-NqRhZE
Sam Harris talks to leading AI theorist Eliezer Yudkowsky about why humanity will probably be killed off by AI (if not by something else first) https://youtu.be/AaNLX71Hl88
Most articles on Idlewords.com
joe rogan and jake the snake
Peter Thiel on Trump, Gawker, and Leaving Silicon Valley
https://www.youtube.com/watch?v=C0t5prZD57s&t
https://www.youtube.com/watch?v=C0t5prZD57s&t
Nothing can beat Charles Stress talk in my eyes: http://www.antipope.org/charlie/blog-static/2018/01/dude-you...
> Charles Stress
A pretty apt typo given what feeling many of his blog posts induce in readers :).
A pretty apt typo given what feeling many of his blog posts induce in readers :).
Shameless plug for my talk in haystack in April, which was a couple years of casual research rolled up. I really enjoyed giving the talk and I've had lots of great feedback, so thought I'd share it with y'all.
"Algorithmic extraction of keywords, concepts, and vocabularies."
Sorry only slides and no video: https://www.slideshare.net/MaxIrwin/haystack-2018-algorithmi...
"Algorithmic extraction of keywords, concepts, and vocabularies."
Sorry only slides and no video: https://www.slideshare.net/MaxIrwin/haystack-2018-algorithmi...
> only slides and no video
Please, people in this situation: learn how to make a screencast! A screencast is the most amazing piece of technology that most people don't know how to use. If you're on a Mac, you can do it already - QuickTime has a dead-simple screencast tool. If you're on Windows or Linux, you'll probably have to download some small piece of software, there are tons of good choices.
Then do a screencast of the actual talk along with the slides, and post that instead of just the bare slides.
Please, people in this situation: learn how to make a screencast! A screencast is the most amazing piece of technology that most people don't know how to use. If you're on a Mac, you can do it already - QuickTime has a dead-simple screencast tool. If you're on Windows or Linux, you'll probably have to download some small piece of software, there are tons of good choices.
Then do a screencast of the actual talk along with the slides, and post that instead of just the bare slides.
Hey and the next Haystacks CFP is open. You should submit a talk Max!
http://haystackconf.com
http://haystackconf.com
I am really proud of a talk I gave in March about my motivations for designing open source 3D printed robots:
https://youtu.be/V6HWLJqTASA
And this talk I gave about Starting a Business in Silicon Valley got a lot of traction on HN: https://youtu.be/V6HWLJqTASA
https://youtu.be/V6HWLJqTASA
And this talk I gave about Starting a Business in Silicon Valley got a lot of traction on HN: https://youtu.be/V6HWLJqTASA