Domain modelling in object-oriented and functional programming, based on C# and F# - Marcin Kern

[@islandman9619]

Good presentation, though I'm surprised you didn't show measures in F#. We switched all our development from C# to F# about 4 years ago and it's been absolutely fantastic. Less code, more robust, easier project organization, faster development, better readability and (as you say) domain code can be discussed with SME's. I used imperative languages, including C#, for about 20 years before F#. It feels like I've been released from prison. Cheers mate!

[@Daniel_Zhu_a6f]

I think, the problem with OOP is not that it does not model real life objects, quite the contrary. The problem is that real world is very messy and complex with a lot of hidden state and irreversible non-conserving processes, while math is much simpler.

[@killymxi]

When someone is trying to sell me a language comparing it to a yesterday alternative - I feel cheated. A talk that tries to do best in either language would make a better impression.

[@MarcinKern]

I'm sorry you feel this way mate. What do you think would make biggest change / impact? What did you miss the most?

[@killymxi]

@@MarcinKern It's 2022, we have multiple flavors of records and tuples in C# for a long time already. - readonly record struct would be the way to introduce nominal value types; - I would not let a list of 1 or 2 engines pass a code review - you can use an (empty) interface to imitate a union type. Hybrid engine can be a record of two engines. Total LOC numbers are going to be comparable. There is a current best representation of any modeling concept in either language. You can do a better job putting them side by side without picking favorites. That way it would be a more useful talk for C# users as well. Your argumentation for F# will have to be shifted according to current realities. - F# comes with better defaults, with C# you have to know how to do it right; - Main thing you lose without union types in C# is the totality check when doing pattern matching; - there are no traits-like or headers-like separation of type from its methods in C# and there is a limit of what things can be moved into extension methods currently.

[@mehdi-vl5nn]

is this ddd?

[@obinnaokafor6252]

Kindly use modern C# features to model your domain

[@Qrzychu92]

what features do you have in mind? Nullable references? Because even with records, the code would be mostly the same. One thing is that you could argue that you can use read-only colelctions in C#., but that's the pitch of the talk, that in F# it's easier, because you get all that out of the box.

[@obinnaokafor6252]

@@Qrzychu92 with positional records, you do not need constructors. And required properties make it even better for domain modelling.

[@Qrzychu92]

@@obinnaokafor6252 but then you have to put validation somewhere else. Still, discriminated unions are better for modeling the domain, and that's the point of this talk. Sprinkling syntactic sugar won't fix the bigger issues presented here

[@MarcinKern]

Thanks @obinnaokafor6252, I appreciate that. I will add modern syntax to the talk (I do love records actually), although I agree with @Qrzychu92 here, that it won't change much.

[@obinnaokafor6252]

@@Qrzychu92 DU is important. But you seem to be modelling your C# domain from the purview of an f# developer. Use most of the modern C# features will make the code more succient and those are important features - not syntactic sprinkling. Notwithstanding, having DU in C# would be great.

[@eugenforascu2134]

You could model a Vehicle with 2 props ElectricEngine and GasolineEngine and that would enforce both type safety on engines and engine count, but clealy the type system in F# is more advanced so we'll have to wait for union types in c# or fight other devs/architects to be able to use f# :)

[@MarcinKern]

I would be reluctant to do that, because electric vehicle would use only 1 of those props, while 2nd would be null, which is a whole bucket of misunderstandings. Fighting for F# with other devs/architects might be fun, but it certainly is difficult 😅

[@VerifiedNobody]

Ok, you designed the domain, but you I'm not sold untill you show that in use. In c#, a json or a data entry wpf form is directly mappable to the class, whatever you swiped under the rug as complexities of oops will rear its head in the additional layer you need in F# for parsing and handling the validation errors and formatting them to user friendly errors. I came here for learning F#, and got nerd sniped with half baked C# code.

[@veer66]

This sounds like a good talk, but I can't read the code. Maybe I need to buy a new TV.

[@UristMcFarmer]

*Heavy sigh*...can anyone point me towards any F# developers who actually know C# and as such can present a _coherent_ comparison between the two? I've been watching F# videos on and off for the last few days and this is just another man who doesn't know how to OOP or C# telling me I should F# because C#, as a language, isn't defensive enough.

[@WalterVos]

Do you need a comparison, truly? I've seen a few, and they don't do much for me either. I haven't stuck with F#, but I've completed "F# from the ground up" on Udemy (might be elsewhere, too), and that was quite enlightening.

[@YngvinLion]

Watching videos like this one is like watching a TV shop, where people cannot do simple things, like opening a jar or drinking water. Every time somebody tries to convince me "F# > C#", they must use ad absurdum junior-level C# code & architecture, comparing to super phun thyme F# (which for me looks like C# written without abstractions as well as without OOP principles and I think the issue with the presenters, who cannot properly explain why is it so and how to deal with that). Why to not show at least PoC proj written both C# and F# by people, who know each of this tech and to show examplpes of IRL-like tickets or benchmarks? Why it's always "rEaL wOrLd ExAmPle" with some damn cars-engines/animals-cats-dogs/student-teacher/etc? Show us how you deal with 10000 req/min, show how you deal with logging/exceptions handling, validation, how you deal with comlpex queries that at least have subqueries/joins/unions of more than 3 tables, how you deal with middleware... There are so many things to show, but as always, me watchiing a proj with 2 simple endpoints, listening how the guy passes the engines using List in the signature.

[@bdaniel7]

Wait? No Diesel or LPG engine?.... tsk tsk tsk...