Your talks, books and blog bring the joy back to programming. This is a great example. You bring these transformation concepts humorously over in layman's terms with brilliant justifications. Captivating, and so many ah-ha moments! Thanks for sharing and bringing us all up to date. btw - I'm in the 50+ club and have been in the business for sometime ;-)
The comment he makes at 38:10 sum up perfectly and concisely why what we call "Computer Science" is just not a science at all. And how easy it would be to make it into one. And at 39:22 he shows exactly who we should throw away our PHP frameworks as use Middleware instead. This is solid gold - even if you don't use an FP language.
at 7:22 the code is as Fowler says, a thin DB wrapper (class or script). But as you pull data belonging to different Entity classes (if you're using an ORM) and then put them into objects etc, can we say It is object oriented OR is the data simply being stuffed into objects to iterate over and do your business logic so it's merely data oriented?
This is almost exactly the same conclusion I have come to. Would be great to see concrete examples as theory is always theory, but trying to replicate the ideas in code is not as straightforward as just understanding the theory and easily deriving solutions from it.
8:22 "An apple goes into this tunnel, it turns into a banana, so it's an apple to banana function. [...] If you've played with a Brio wooden railway set you know how this works." Um... 🤔 sure, that's exactly how I remember it working 😅.
Even though I do share the same opinion of the author, I think that this talk is a bit biased since the author uses very simple and linear cases for the FP side and rather complex (real , from his past) examples for the tradicional so called "OO". It's possible to make code "bad" (let's say highly coupled, since it is my understanding of the author main concern), with both approaches. Also, the notion that the DDD guys have about hiding persistence, in my opinion, may not be adequate because it will create issues sooner or later ; for example concurrency: either there are inconsistencies or to much contention. For me, DDD is about the bounded context, not so much about the "shared language". My natural languge is not english, so the business guys do not generally use our terms, since we program in english (which we will because mixing languages: business + the programming language own terms like "class", "if", "for", ...)
Your talks, books and blog bring the joy back to programming. This is a great example. You bring these transformation concepts humorously over in layman's terms with brilliant justifications. Captivating, and so many ah-ha moments! Thanks for sharing and bringing us all up to date. btw - I'm in the 50+ club and have been in the business for sometime ;-)
Wow! This presenter is amazing; watched this before bed and stayed interested the entire length of the video.
The title was perfect, because this was exactly what I was looking for! 😂
The comment he makes at 38:10 sum up perfectly and concisely why what we call "Computer Science" is just not a science at all. And how easy it would be to make it into one.
And at 39:22 he shows exactly who we should throw away our PHP frameworks as use Middleware instead.
This is solid gold - even if you don't use an FP language.
As usual excellent presentation!
at 7:22 the code is as Fowler says, a thin DB wrapper (class or script). But as you pull data belonging to different Entity classes (if you're using an ORM) and then put them into objects etc, can we say It is object oriented OR is the data simply being stuffed into objects to iterate over and do your business logic so it's merely data oriented?
Excellent talk and understated
Good talk! It will be great to see code example(gist) of any transaction script implementation
I think you forgot LaunchMissilesAsync
This is almost exactly the same conclusion I have come to. Would be great to see concrete examples as theory is always theory, but trying to replicate the ideas in code is not as straightforward as just understanding the theory and easily deriving solutions from it.
Get his DDD book - it works through practical examples.
8:22 "An apple goes into this tunnel, it turns into a banana, so it's an apple to banana function. [...] If you've played with a Brio wooden railway set you know how this works."
Um... 🤔 sure, that's exactly how I remember it working 😅.
Functional Core Imperative Shell
anyone please share link
another amazing talk !!
Awesome talk
Great talk indeed. I look at my recent purchases and incidentally I bought his book 3 weeks ago. Makes me want to start reading that
Even though I do share the same opinion of the author, I think that this talk is a bit biased since the author uses very simple and linear cases for the FP side and rather complex (real , from his past) examples for the tradicional so called "OO".
It's possible to make code "bad" (let's say highly coupled, since it is my understanding of the author main concern), with both approaches.
Also, the notion that the DDD guys have about hiding persistence, in my opinion, may not be adequate because it will create issues sooner or later ; for example concurrency: either there are inconsistencies or to much contention. For me, DDD is about the bounded context, not so much about the "shared language". My natural languge is not english, so the business guys do not generally use our terms, since we program in english (which we will because mixing languages: business + the programming language own terms like "class", "if", "for", ...)
goat!
If your railway tunnels transform entities that pass through them then there's something seriously wrong
Starting premise for a fantasy/horror film????
Lacks decent examples.