I've been inspired to continue my studies tonight. The ripple effect when people of different perspectives come together is very real. A complex system is surely interlinked & there is always a conflict between reusability/modularity & coupling but I suppose I have a passion for decoupling as much as possible with the least amount of mental overhead. If domain modelling was a solved problem accountant's would no longer be in business. As long as the tiles continue to shift under our feet & there is nuance & change, there will be additional rules to apply, & so on & so forth. This talk was really enlightening for me. Thank you for highlighting some of my doubts & intuitions. I feel like you have stook a good balance of surface & depth & you've defo earned a sub.
One of the beautiful things about F# is that is allows you to switch from a functional-first, robust way of modeling your domain down to a high-performance mode when necessary. The pragmatism of F# is what keeps me excited. I've never run into a performance issue that I was not able to solve with F#. Yes, you may have to move from a immutable, functional-first approach to a more procedural design but you only need to do that for the performance critical pieces of your code. Other languages are more dogmatic or do not give you the level of control that you need to achieve high-performance. F# allows you to stay high-level if you want but also drop down to near C-levels of performance when you need to.
The guy on the Fast F# channel has an interesting take on this. For the itnernals of performance critical functions he's prepared to fall back on mutable imperative techniques if necessary, so long as the API remains functional.
@@tullochgorum6323 This comment made me laugh so hard, you were referring his own video's back to him. The commenter is FastF#, but I am glad more people are interested in performant F#
A fantastic episode, thanks to all three of you! Being able to "dumb things down", and even repeatedly, is in my opinion one of the most important capabilities of a great teacher. When I came to the secondary school, we got this physics teacher. We were completely new and knew noone. Older students said "this dude is a complete menace, you're all so screwed". On the contrary, this guy happened to be one of if not THE best teacher I have ever had. He was really strict and demanding BUT he was always, and Imean ALWAYS willing and able to explain things or parts of things we did not understand in more basic or simple terms. I'll never forget him for the rest of my life. After him we got a different teacher, the "this is what's written in the book so that's how it is, just use the formulas from there" type and it destroyed my love for physics.
Kudos to getting this interview. I would not have even considered F# if I hadn't watched some of Scott's videos, and I often recommended those videos to programmers interested in FP--no matter what the language or stack.
Interesting discussion guys, thanks for uploading. I think my favourite idea from the video, which I believe was also mentioned in another video with Don Syme is this idea of leveraging the type system of F# (or really any language with a strict type system) to model the business domain in a way that is easy to demonstrate to colleagues/stakeholders to allow them to give their input, while also getting the benefit of improving the error checking at compile time and thus reducing the amount of tests that need to be written. This is not something I had considered before. I found this channel recently because of the talk with John de Goes (I'm a jr scala dev) and have been enjoying all the videos since because of the all great guests you've had on such as Scott, and also the fact that when you guys are discussing an idea, you are not afraid to push back and always challenge each other's ideas which is great to see. Keep it up 💪
Ody and Scott briefly discussed FP in enterprise or FAANG, and I have a different experience working with startups in a developing nation. Yes, the business value of FP is not just in its performance or language features. The major benefit is it attracts high-performing tech leads and ICs who are familiar with concepts like functional/reactive domain modelling, actor models, effect systems, etc. and they can iterate and refactor the product very quickly. However, these teams command high salaries and require long candidate searches (even more so in my country), and these might burn through startup capital quicker than finding product-market fit. I've seen a few companies "strategically" migrate their FP codebase to C#, Java or Javascript to decrease labor costs, increase their hiring pool, and buy time for the product to gain traction. The obvious solution to increase the supply of developers would be to improve education and acceptance of FP in our industry, but sadly we're far off from that and I suspect some markets from developing nations experience similar challenges.
Here's a thoughtful vlog on F# performance from the Fast F# channel: th-cam.com/video/EIBRoNEpg6c/w-d-xo.html. He uses F# for performance critical simulation software that outperforms their competition. He points out that you can achieve most of the speed of C but with far fewer LOC. And of course your app should be more reliable too. So the question is - are you prepared to make a much larger investment in developers to achieve that final 20% of efficiency or performance? Or do you you accept a modest performance cost to enjoy significantly faster development and lower maintenance costs?
Register to win:
Domain Modeling Made Functional (by Scott Wlaschin)
Leave a thoughtful comment and we will pick three winners.
I commented for the algorithms but I don't need the book. I already own a couple of copies 😊.
@@FastFSharp Thanks 😀
@@FastFSharp Thank you for encouraging us to continue. It means a lot.
Keep the videos coming!
I've been inspired to continue my studies tonight.
The ripple effect when people of different perspectives come together is very real.
A complex system is surely interlinked & there is always a conflict between reusability/modularity & coupling but I suppose I have a passion for decoupling as much as possible with the least amount of mental overhead.
If domain modelling was a solved problem accountant's would no longer be in business. As long as the tiles continue to shift under our feet & there is nuance & change, there will be additional rules to apply, & so on & so forth.
This talk was really enlightening for me. Thank you for highlighting some of my doubts & intuitions. I feel like you have stook a good balance of surface & depth & you've defo earned a sub.
Love seeing Scott Wlaschin!
Yeah me too 😁
I have just started with F# for Fun and Profit. It is really awesome, thanks Scott Wlaschin :)
Scott Wlaschin has become somewhat of a legend all his talks are excellent and also entertaining and funny.
I haven't read the book yet, but I have watched Scott Wlaschin talk on Railway oriented programming. One of the best. :)
One of the beautiful things about F# is that is allows you to switch from a functional-first, robust way of modeling your domain down to a high-performance mode when necessary. The pragmatism of F# is what keeps me excited. I've never run into a performance issue that I was not able to solve with F#. Yes, you may have to move from a immutable, functional-first approach to a more procedural design but you only need to do that for the performance critical pieces of your code.
Other languages are more dogmatic or do not give you the level of control that you need to achieve high-performance. F# allows you to stay high-level if you want but also drop down to near C-levels of performance when you need to.
The guy on the Fast F# channel has an interesting take on this. For the itnernals of performance critical functions he's prepared to fall back on mutable imperative techniques if necessary, so long as the API remains functional.
@@tullochgorum6323 This comment made me laugh so hard, you were referring his own video's back to him. The commenter is FastF#, but I am glad more people are interested in performant F#
@@CrIMeFiBeR So it is - guess I shouldn't post late at night!
A fantastic episode, thanks to all three of you!
Being able to "dumb things down", and even repeatedly, is in my opinion one of the most important capabilities of a great teacher. When I came to the secondary school, we got this physics teacher. We were completely new and knew noone. Older students said "this dude is a complete menace, you're all so screwed". On the contrary, this guy happened to be one of if not THE best teacher I have ever had. He was really strict and demanding BUT he was always, and Imean ALWAYS willing and able to explain things or parts of things we did not understand in more basic or simple terms.
I'll never forget him for the rest of my life.
After him we got a different teacher, the "this is what's written in the book so that's how it is, just use the formulas from there" type and it destroyed my love for physics.
Kindly drop your Twitter Handle or Email, So we can reach you Thanks
@@techconception Hi, I already have the book, so no need to send one to me :) Thanks!!
This channel is amazing. Please keep producing content like this.
Kudos to getting this interview. I would not have even considered F# if I hadn't watched some of Scott's videos, and I often recommended those videos to programmers interested in FP--no matter what the language or stack.
Interesting discussion guys, thanks for uploading. I think my favourite idea from the video, which I believe was also mentioned in another video with Don Syme is this idea of leveraging the type system of F# (or really any language with a strict type system) to model the business domain in a way that is easy to demonstrate to colleagues/stakeholders to allow them to give their input, while also getting the benefit of improving the error checking at compile time and thus reducing the amount of tests that need to be written. This is not something I had considered before.
I found this channel recently because of the talk with John de Goes (I'm a jr scala dev) and have been enjoying all the videos since because of the all great guests you've had on such as Scott, and also the fact that when you guys are discussing an idea, you are not afraid to push back and always challenge each other's ideas which is great to see. Keep it up 💪
Kindly drop your Twitter Handle or Email
anonbridger
Fantastic talk!
I already have a copy of the book, but I just wanted to congratulate you on making a great video (and acquiring a new subscriber 🙂).
42:01 Is the one that hurts the most and can only be learned the hard way lol
Ody and Scott briefly discussed FP in enterprise or FAANG, and I have a different experience working with startups in a developing nation. Yes, the business value of FP is not just in its performance or language features. The major benefit is it attracts high-performing tech leads and ICs who are familiar with concepts like functional/reactive domain modelling, actor models, effect systems, etc. and they can iterate and refactor the product very quickly.
However, these teams command high salaries and require long candidate searches (even more so in my country), and these might burn through startup capital quicker than finding product-market fit. I've seen a few companies "strategically" migrate their FP codebase to C#, Java or Javascript to decrease labor costs, increase their hiring pool, and buy time for the product to gain traction. The obvious solution to increase the supply of developers would be to improve education and acceptance of FP in our industry, but sadly we're far off from that and I suspect some markets from developing nations experience similar challenges.
Kindly drop your Twitter Handle or Email
Book looks interesting to read. I don't know F#, but I am interested to learn more about DDD and functional programming.
Here's a thoughtful vlog on F# performance from the Fast F# channel: th-cam.com/video/EIBRoNEpg6c/w-d-xo.html. He uses F# for performance critical simulation software that outperforms their competition. He points out that you can achieve most of the speed of C but with far fewer LOC. And of course your app should be more reliable too. So the question is - are you prepared to make a much larger investment in developers to achieve that final 20% of efficiency or performance? Or do you you accept a modest performance cost to enjoy significantly faster development and lower maintenance costs?