Oversight: Assignments in C# are also expressions, which can be useful in some cases. "If it has an assignment, it is probably a statement" is therefore completely false. More correct would be: if it has a *declaration*, it is probably a statement. I say probably, because variables can be declared in expressions with the `out` and `is` and `switch` keywords.
This is what ive been doing for some time: cherry picking FP concepts and applying them tl my C# projects. The results have been simpler code and easier testability. In particular i focus on: immutability, impureheim sandwich, unions + pattern matching (with Dunet). I encourage everyone to try it.
Lambdas are not fundamental to FP, but *closures* are. It's the idea of extending the lifetime of a value by capturing it within a function. You can fully emulate OOP with closures over mutable variables, and you can emulate closures with OOP. In fact, the C# compiler compiles lambdas that capture data into classes with the captured values as fields and the code as a method. But yeah, the syntax details do not matter.
It always bothers me that OOP and FP are treated like opposite concepts that are mutually exclusive. The data are objects, the services that perform operations on them are objects, and they might all be immutable and stateless, and makes it not any less functional/object-oriented.
Great talk but what a noisy place. I saw a few other NDC Oslo 2024 talks, and they were nearly the same and noisy. They do not appear to have been very organized this year, Oslo.
No, because then the type is tightly coupled with console. Imagine that you have the function and next you have to support storing to file. Add a new function to each type to handle that? No. Add a new function to some module which pattern matches the cases.
@@fsharpfan No more tightly coupled than the current solutions switch. You're either writing a new subclass or a new case statement. I'm a huge fp fan, this did not sell it well imo.
The issue here is not FP vs OO. The issue is C# is getting so complicated that when looking at someone else's code, you often can't see what's written, even though it's obvious. They are destroying C# by complexity. The beauty of C is that, the language doesn't change and that's the main feature of it. C# is in danger of being destroyed by these shysters who think following every useless trend is cool.
Hard disagree. It gives loads of tools and you can choose what you do in your organisation. Nothing is forced upon you but C# provides a crazy amount of functionality.
no DI, and functional arguments are good just for these kind of presentations, imagine not having DI and you passing every single service, repository to each and individual function in production application, it's a joke, functional programming is really good, but not the way it is explained here
you know that's how many other languages work? Go, Rust, Elixir etc - DI containers are even consider as antipattern. It's not a joke, just different approach. And in practice, if you do it right, it's way less of a hassle than you think. Have you heard about Vertical Slice Architecture? That's basically what do in functional world - no repositories, no services, so nothing to pass.
@@Qrzychu92 Vertical Slice Architecture isn't tied to either FP or OOP-it works with both approaches. You can have repositories, services, and even Dependency Injection if they fit your design. The core idea of vertical slices is about grouping everything necessary to execute a use case as cohesively as possible. It's less about rejecting specific patterns like repositories or DI and more about ensuring each feature is self-contained, avoiding unnecessary layers. So, whether you use DI/Repositories/Services or not, the focus remains on organizing code by feature, not enforcing a strict patter
@@jackpioneer3566 the main idea of VSA (at least according to Jimmy Bogard), is to have a slice where all the code you need is there. No services, no nothing,full code duplication, just procedural, make it work. Then refactor the code smells away. If you do that enough times, you will end up with clean architecture and DDD inside of your slice. You are right, it doesn't matter if it's FP or OOP. It's just with FP that the natural way to start, in OOP you are trained into thinking "I need a repository and a service", even though it's a single line when using EF Core directly
Great talk. This is exactly how I'm writing code today after doing c# my whole career since dotnet 1.0
Can you please recommend your favorite books on this topic? Thx )
Oversight: Assignments in C# are also expressions, which can be useful in some cases. "If it has an assignment, it is probably a statement" is therefore completely false. More correct would be: if it has a *declaration*, it is probably a statement. I say probably, because variables can be declared in expressions with the `out` and `is` and `switch` keywords.
This is what ive been doing for some time: cherry picking FP concepts and applying them tl my C# projects. The results have been simpler code and easier testability.
In particular i focus on: immutability, impureheim sandwich, unions + pattern matching (with Dunet).
I encourage everyone to try it.
Lambdas are not fundamental to FP, but *closures* are. It's the idea of extending the lifetime of a value by capturing it within a function. You can fully emulate OOP with closures over mutable variables, and you can emulate closures with OOP. In fact, the C# compiler compiles lambdas that capture data into classes with the captured values as fields and the code as a method. But yeah, the syntax details do not matter.
We can already do curried functions in C#
var add = (int n1) => (int n2) => n1 + n2;
var add10 = add(10);
var x = add10(10); // 20
getting an error on the first line:
error CS0815: Cannot assign lambda expression to an implicitly-typed variable
It always bothers me that OOP and FP are treated like opposite concepts that are mutually exclusive. The data are objects, the services that perform operations on them are objects, and they might all be immutable and stateless, and makes it not any less functional/object-oriented.
Great talk but what a noisy place. I saw a few other NDC Oslo 2024 talks, and they were nearly the same and noisy. They do not appear to have been very organized this year, Oslo.
Isn't the 'obvious' solution to have every `ContactMethod` have a method that knows how to consume its data and print to the console?
No, because then the type is tightly coupled with console. Imagine that you have the function and next you have to support storing to file. Add a new function to each type to handle that? No. Add a new function to some module which pattern matches the cases.
@@fsharpfan No more tightly coupled than the current solutions switch. You're either writing a new subclass or a new case statement.
I'm a huge fp fan, this did not sell it well imo.
The issue here is not FP vs OO. The issue is C# is getting so complicated that when looking at someone else's code, you often can't see what's written, even though it's obvious. They are destroying C# by complexity. The beauty of C is that, the language doesn't change and that's the main feature of it. C# is in danger of being destroyed by these shysters who think following every useless trend is cool.
Hard disagree. It gives loads of tools and you can choose what you do in your organisation. Nothing is forced upon you but C# provides a crazy amount of functionality.
no DI, and functional arguments are good just for these kind of presentations, imagine not having DI and you passing every single service, repository to each and individual function in production application, it's a joke, functional programming is really good, but not the way it is explained here
you know that's how many other languages work? Go, Rust, Elixir etc - DI containers are even consider as antipattern. It's not a joke, just different approach. And in practice, if you do it right, it's way less of a hassle than you think.
Have you heard about Vertical Slice Architecture? That's basically what do in functional world - no repositories, no services, so nothing to pass.
@@Qrzychu92 Vertical Slice Architecture isn't tied to either FP or OOP-it works with both approaches. You can have repositories, services, and even Dependency Injection if they fit your design. The core idea of vertical slices is about grouping everything necessary to execute a use case as cohesively as possible. It's less about rejecting specific patterns like repositories or DI and more about ensuring each feature is self-contained, avoiding unnecessary layers. So, whether you use DI/Repositories/Services or not, the focus remains on organizing code by feature, not enforcing a strict patter
@@jackpioneer3566 the main idea of VSA (at least according to Jimmy Bogard), is to have a slice where all the code you need is there. No services, no nothing,full code duplication, just procedural, make it work. Then refactor the code smells away. If you do that enough times, you will end up with clean architecture and DDD inside of your slice.
You are right, it doesn't matter if it's FP or OOP. It's just with FP that the natural way to start, in OOP you are trained into thinking "I need a repository and a service", even though it's a single line when using EF Core directly