Slides are published here: www.slideshare.net/paulszulc/maintainable-software-architecture-in-haskell-with-polysemy Source code created for this presentation under github.com/EncodePanda/maintainable-software-architecture-in-haskell This should be also blog post (once I learn how to write properly in English :) )
Python is lovely for small scripts / apps, but once an app grows to a moderate size, the dynamic typing makes it easier for bugs to sneak in and makes it harder to reason about the code. Generally, with statically typed languages, you find more mistakes at compile time that you would not encounter until runtime in a dynamically typed language (or, not encounter at all until a user stumbles on it) Python: Easier to get things done, easier to introduce bugs Haskell: Harder to get things done, harder to introduce bugs Also, since python is an interpreted language, it's relatively slow. You might not care about that initially, but you can end up in a rough spot if you develop a large python application and then your performance starts hurting.
@@komosaq I think the intention is to somehow achieve "Haskell: easy to get stuff done, hard to introduce bugs". I don't know if we can get there, or how, but hopefully it's possible.
@@komosaq Thats true if you understand Haskell's static type errors, and Haskell terminology... Julia (Lisp?) with its various macro compilers & functional inlining fixes some of Python's performance issues. We need to move away from editing code by directly editing text, we need to edit programs by running queries (like JQuery or paredit*) on the code-data that automatically handle all the cases that affect callers and callees. In naive editing of functinal programs if you figure out you should have been using X instead of Y with duck/structural typing and dynamic late binding of everything you can change all your callers with one change, but in static you may have to change all of your callers...
Incredible speaker, incredible talk. I'm blown away!
Pawel is amazing, as he always is
Slides are published here: www.slideshare.net/paulszulc/maintainable-software-architecture-in-haskell-with-polysemy
Source code created for this presentation under github.com/EncodePanda/maintainable-software-architecture-in-haskell
This should be also blog post (once I learn how to write properly in English :) )
Paweł is great giving talks! Excellent, thank you!
This is a fantastic talk. Thank you!
All his talks are amazing!
This is amazing! Pawel is such a great speaker
Great talk!
great talk
slides: www.slideshare.net/paulszulc/maintainable-software-architecture-in-haskell-with-polysemy
Maybe I'm missing something but the major selling point of this is that "It's as easy as doing it in python", so why not just use python?
Python is lovely for small scripts / apps, but once an app grows to a moderate size, the dynamic typing makes it easier for bugs to sneak in and makes it harder to reason about the code.
Generally, with statically typed languages, you find more mistakes at compile time that you would not encounter until runtime in a dynamically typed language (or, not encounter at all until a user stumbles on it)
Python: Easier to get things done, easier to introduce bugs
Haskell: Harder to get things done, harder to introduce bugs
Also, since python is an interpreted language, it's relatively slow. You might not care about that initially, but you can end up in a rough spot if you develop a large python application and then your performance starts hurting.
@@komosaq I think the intention is to somehow achieve "Haskell: easy to get stuff done, hard to introduce bugs". I don't know if we can get there, or how, but hopefully it's possible.
@@komosaq Thats true if you understand Haskell's static type errors, and Haskell terminology... Julia (Lisp?) with its various macro compilers & functional inlining fixes some of Python's performance issues. We need to move away from editing code by directly editing text, we need to edit programs by running queries (like JQuery or paredit*) on the code-data that automatically handle all the cases that affect callers and callees. In naive editing of functinal programs if you figure out you should have been using X instead of Y with duck/structural typing and dynamic late binding of everything you can change all your callers with one change, but in static you may have to change all of your callers...
cringe