So, basically, it moved error handling from being explicit to being implicit. If now an error occurs, it skips over the remaining code, and allows errors to be handled in a specific section at the end of the function... sounds familiar.
Neat Talk - but i didn't get the conclusion - i get that "Math helps us solve complex problems". But how ?? Is it indication that i should model the flow of data or control like a math transformation ??? can someone help me understand it ??
The ideas in the talk come from a branch of mathematics called Category Theory. Specifically, I'm looking at the idea of building functors in Go. There are limitations to doing this in a language like Go, but nonetheless I think that there is a lot you can learn from understanding Category Theory, even if you have to implement them differently than you would do in, say, Haskell. There is an excellent, comprehensive (but challenging) course on Category Theory from Bartosz Milewski: th-cam.com/video/I8LbkfSSR58/w-d-xo.html
... there are other branches of mathematics that can be useful to help you understand how your code works. General Algebra (or Universal Algebra) gives some basic building blocks that are directly applicable to code. The best example of this is monoids (e.g., see this blog post: blog.axosoft.com/monoids-practical-category-theory/). If you want to go further, Constructive Type Theory and Homotopy Type Theory will show you how to reason about increasingly complex structures. It's debatable how much these will help *understand* anything, but maybe I just need to spend more time on them :-)
Is there anything more than a rough analogy between "type lifting" in the sense of this talk and "type lifting" as used in natural language semantics? I don't think the terminology is a coincidence, particularly when combined with the exhortation to think like a mathematician,.
I’m not familiar with ‘type lifting’ in natural language semantics. I’m not familiar with much in natural language semantics. The terminology I used comes from Category Theory. Do you have any good starting points for type lifting in natural language semantics?
Too bad they didn't add try catch. There are still unknown errors that can occur in go. fmt.Sprintf("%v", arg) can return a nil value and a nil value can be assigned to a string. You cannot check if string == nil.
One of the best talk i have ever heard. Awesome presentation skills! Very enjoyable!
I realize it's kinda randomly asking but does anyone know a good website to watch newly released tv shows online ?
@Alvaro Chaim i dunno I watch on Flixportal. just search on google after it:) -chance
@Chance Kaiser thank you, I signed up and it seems like a nice service :) Appreciate it !!
@Alvaro Chaim you are welcome :D
This was just wonderful.
So, basically, it moved error handling from being explicit to being implicit. If now an error occurs, it skips over the remaining code, and allows errors to be handled in a specific section at the end of the function... sounds familiar.
You really got me here... Where does this happen too? Not ironic tho, really a question
@@wofebr try...catch blocks. Java.
rewatching this talk after studying haskell/monads and it's so much more enlightening
This was an incredibly insightful talk
Unique talk John you made me laugh, which is very rare !
Absolutely the best! Maybe the best (tech) talk I've ever saw!
Just wrote some really beautiful code based off the info in this talk. Long live John Cinnamond. Long live Golang.
Nice! Just took a funcional approach to handling erros, with a kind of Maybe monad.
That rick roll, though!
Mr. Sahab lol!
yup :-)
Neat Talk - but i didn't get the conclusion - i get that "Math helps us solve complex problems". But how ?? Is it indication that i should model the flow of data or control like a math transformation ??? can someone help me understand it ??
The ideas in the talk come from a branch of mathematics called Category Theory. Specifically, I'm looking at the idea of building functors in Go. There are limitations to doing this in a language like Go, but nonetheless I think that there is a lot you can learn from understanding Category Theory, even if you have to implement them differently than you would do in, say, Haskell. There is an excellent, comprehensive (but challenging) course on Category Theory from Bartosz Milewski: th-cam.com/video/I8LbkfSSR58/w-d-xo.html
... there are other branches of mathematics that can be useful to help you understand how your code works. General Algebra (or Universal Algebra) gives some basic building blocks that are directly applicable to code. The best example of this is monoids (e.g., see this blog post: blog.axosoft.com/monoids-practical-category-theory/). If you want to go further, Constructive Type Theory and Homotopy Type Theory will show you how to reason about increasingly complex structures. It's debatable how much these will help *understand* anything, but maybe I just need to spend more time on them :-)
Is there anything more than a rough analogy between "type lifting" in the sense of this talk and "type lifting" as used in natural language semantics? I don't think the terminology is a coincidence, particularly when combined with the exhortation to think like a mathematician,.
I’m not familiar with ‘type lifting’ in natural language semantics. I’m not familiar with much in natural language semantics. The terminology I used comes from Category Theory. Do you have any good starting points for type lifting in natural language semantics?
excellent talk. Thanks.
Watching the talk, this seems a lot like trying to add Option types to Go
Interesting talk now that Go has generics. 😄
Not yet...
Aaand that's a monad...
Nice talk 👍 The know-how he dropped is gold. Pro tip: learn haskell to get this knowledge for free 🤤
Knowledge is never free but, yes, Haskell is with learning.
Too bad they didn't add try catch. There are still unknown errors that can occur in go. fmt.Sprintf("%v", arg) can return a nil value and a nil value can be assigned to a string. You cannot check if string == nil.
Ewww. This would be soo annoying to come across in a big project.