6 ms·

Hi Daniel, It's weird you mention that, I was just chatting to a colleague the other day on this topic, and I rooted out this old article which I loved: www.s

Hi Daniel, It's weird you mention that, I was just chatting to a colleague the other day on this topic, and I rooted out this old article which I loved: www.slideshare.net/ScottWlaschin/ddd-with-fsharptypesystemlondonndc2013 I was lucky enough to work on a big F# project a while ago and really enjoyed the experience, it was the first time I'd done any functional programming in a professional context and I miss it now that I'm doing more JavaScript and Node.js! Thanks for the kind words on the article, much appreciated!

DanielBMarkham 9y ago
Hey Dave, No problem. There was a ton of good stuff in there! I saved it to refer back to it later. :) As a tech coach, I teach good programming skills, which mostly ends up being TDD and other good coding skills for OOP folks. But I've become a huge pure FP fan over the past decade, learning it all on my own just by struggling through it. So as a coach, I'm seeing more and more of these microservice train wrecks. I'm also seeing a ton of people who don't understand microservices come online and bitch about how they don't work. Wlaschin's book goes into building a pure FP system from the top-down -- something I never considered doing (I've never coached or worked in a large pure FP shop). Of course, if you build it out that way, it really doesn't matter how you splice up the code or where it goes. You can do monolith, serverless, microservices, whatever. I liked the process described in the book a lot. It describes to me how you can have 50 people and 100 microservices and make it all work. (Although everything you point out is still an issue, many of the pure FP techniques mitigate them.) Feels a lot like BDUF, though, which kinda bugs me. I sat down with Uncle Bob last month and spend a week showing him F#. TDD didn't seem to work that well, but maybe I missed it. There's just nothing to test in simple transforms, and you want to keep using simple transforms as much as you can. I think we need to evolve a TDD-like process for growing systems in pure FP from the ground-up. I'll probably cogitate on this for a few years and end up writing something. If you know of any good resources, please send them my way!
- bajablast 9y ago
  Personally I have learned that TDD and unit tests are only useful in OOP settings that have side effects and have mutated state overtime. But with a more FP approach all you need to do is verify the feature works since you know that state can't change the output. I kind of also feel that TDD has a kind of cult like following, especially with the Rails crowd

DanielBMarkham 9y ago

Hey Dave, No problem. There was a ton of good stuff in there! I saved it to refer back to it later. :) As a tech coach, I teach good programming skills, which mostly ends up being TDD and other good coding skills for OOP folks. But I've become a huge pure FP fan over the past decade, learning it all on my own just by struggling through it. So as a coach, I'm seeing more and more of these microservice train wrecks. I'm also seeing a ton of people who don't understand microservices come online and bitch about how they don't work. Wlaschin's book goes into building a pure FP system from the top-down -- something I never considered doing (I've never coached or worked in a large pure FP shop). Of course, if you build it out that way, it really doesn't matter how you splice up the code or where it goes. You can do monolith, serverless, microservices, whatever. I liked the process described in the book a lot. It describes to me how you can have 50 people and 100 microservices and make it all work. (Although everything you point out is still an issue, many of the pure FP techniques mitigate them.) Feels a lot like BDUF, though, which kinda bugs me. I sat down with Uncle Bob last month and spend a week showing him F#. TDD didn't seem to work that well, but maybe I missed it. There's just nothing to test in simple transforms, and you want to keep using simple transforms as much as you can. I think we need to evolve a TDD-like process for growing systems in pure FP from the ground-up. I'll probably cogitate on this for a few years and end up writing something. If you know of any good resources, please send them my way!

bajablast 9y ago
Personally I have learned that TDD and unit tests are only useful in OOP settings that have side effects and have mutated state overtime. But with a more FP approach all you need to do is verify the feature works since you know that state can't change the output. I kind of also feel that TDD has a kind of cult like following, especially with the Rails crowd