I'm so impressed with the way in which you speak, carefully and obviously with love for your craft. Reminds me a lot of my first programming teacher in high school. I found your channel just a few days ago and I have been going through all of your videos. There's so much C# fluff on TH-cam, it's disappointing that you don't have more views.
Thank you, Zoran! It's like "a breath of fresh air" in common programmer's duties which often are driven as "there's no time to explain - pin this feature on the side" ))
I like to explain delegates as objects that represent a piece of code that is not declared in a class. They're objects in the end. Just done on a different way...
Well, what is next for C#? F# got some pipelining feature for functional expressions. Is that the next important feature for functional programming in C# if it is realized?
I'd really like to see the pipe operator, but that is not likely to happen. But I do expect discriminated unions any time soon. That would be a tiny tweak to the existing syntax.
I adopted records. It's actually a great way to create custom formats and settings using the newer JSON capabilities. Functional Programing actually makes Object Oriented Programing easier. It allows you to simplify many different tasks.
just a tip…delegate and anonymous methods (lambdas) execution instructions are put in the heap, thus requiring garbage collection; however, local and regular methods are put on the stack (no GC). i spoke to the team lead of the MS .CLR team, and he knows this and has no plans to fix this.
Great content as usual, I have been using FP in c# for the past 10 years, I swear people love the functional features and the simplicity they bring to the design and readability, we just have to hide the fact those concepts stem from FP, then everyone is happy weirdly, language-ext helped me switch to FP constructs whole heartedly and made me a better programmer, I think the FP cult is the issue, we have to agree the FP ecosystem is full of purists and non-helpful people helping people to switch, f# is better in that regard, and content creators like you are oasis in the desert :), well done.
I'm primarily a Java dev, but there's a parallel story there in what the problems we're solving now vs then. Java originally was meant to run on an unknown device and securely load new classes from the network, from 3rd parties. OOP and VMs are good for that kind of thing, problem is, that's not what people do now. Now we know exactly which linux container we're running in, using AOT compilation because in practice the code isn't dynamic and in serverless you don't benefit from a jitting VM. Under these constraints things like exhaustive switches make more sense than polymorphism. Applications also do far more I/O than in years past so blocking threads becomes more problematic, which favors a more FP style.
Most popular programming languages these days evolve in very similar directions. The strong separation between imperative and functional programming languages is long gone. Imperative first languages are introducing more functional parts and functional languages are adopting imperative parts. From the most popular languages I believe it's really just C that does not really evolve. And that's also fine, because the quality of C is that it's super simple and low level. Even C++ has lambdas these days. It's not like Rust, but you got the point. But Java and C# are special ones for each other, because they have always been very similar and continued adopting each others things, although with the nuance that C# is a bit more diverse with syntax, which is why some people say C# is better while others say that C# has too many features. :)
one problem i found with primary constructors is this not being allowed… public class MyId : MyId(typeof(T) {} public class MyId(Type theType) { Type id=theType} Because the first class has no PC, it won’t let me pass to the base PC. big bug for me, but you can do it with regular constructors.
C# seems to be getting more heavily Functional inclined. I remember in your Pluralsight course asking for records in C# long way back, you got your wish.
u should do a video explaining implementation of X-Plicit Architecture (Herbert Gracia [sp?])to achieve modern isolation of abstraction and implementation, dependency inversion, and thus enabling flexibility for the enterprise future capabilities.
The primary trait of the anemic domain model is that behavior is implemented at the calling site. With functional types, behavior is still implemented in its own place, and used from the calling site. Therefore, the caller doesn't notice any difference between a full-blown class with methods defined on it, and a functional type with a separate definition of functions that apply to it
Nice enthusiastic video! Though, it looks like you totally forget to mention ValueTuples? :( They really share the same concept as structs and records in that they represent value semantics. It's also good to mention how C# shares history with F#, which is based on OCaml. So that's really another important source of functional coding influence.
I notice that I have a hard time getting out of that old pure OOP paradigm, especially around combining data and behavior. I still consider the "anemic model" an anti-pattern, although you might argue that separating data from behavior doesn't necessarily result in an anemic model as long as the behavior is still a part of your domain model and not of client services. What is your view on the "anemic model" for c# and are there still valid use cases for traditional OOP styled classes?
There are many valid users of more-or-less pure OO models even today, so as many uses fit functional modeling better. The distinction is in what you need to add later, i.e. how should you extend the model: by adding more types, or by adding more functions. OO will struggle with the latter, but FP will struggle with the former kind of a problem.
@@zoran-horvatin my experience OO almost exclusively fails when the "type" of a thing seems to change as its characteristics change dynamically. A simple example is a negative account balance cannot be permitted but must become a Debt. Things are things but how they should be classified changes. A model that dynamically assigns allowable behaviours is more true to reality.
@@m4inline That is why we have object composition - that same which we use in functional modeling with types. On the example of account statuses, both object -oriented and functional models are equally plausible.
I love the functional evolution of C#. It still feels OOP enough, but I can weave in functional behaviour easily. And I don't have to build 2-line long type definitions anymore.
@@Akronymus_ Functional languages may be good for some scenarios, but they are way too difficult to use when building things like games and apps. You're not free to build things. The language imposes insane requirements.
@@gavinw77 You can write OOP/procedural in F#. I specifically said that even for OOP F# is better than c#. So, yes, f# is a functional first language, but it also is not a functional only language. So I still stand by what I wrote.
Another beautifully explained video! I really like your approach to showing how new features of the language can benefit our day-to-day work through functional patterns. My biggest issue with modern c# is the fact it is becoming cluttered with multiple ways to accomplish the same thing as they "need" to be retro compatible. This situation even impacts readability as they have to come with workaround for syntax for new features
I don't like C#'s style, but I do love smashing together structural and functional programming together in interesting ways, so you had me in the first minute
Nice presentation, and you make some compelling points, with which I agree. So why not just use F# then, if we want to stay in the Microsoft environment? or a purely functional language, like Haskell, for instance?
Not many programmers could do that. I know of companies that run one team in F# and a dozen teams in C#. On the other hand, C# is a good choice for solving so many practical problems. I deeply believe that the best language is the one which offers a clean version of all three paradigms, rather than being excellent in just one of them.
@@obinnaokafor6252 Quite incorrect in my experience. My team used F# on several very large, high-scalability projects. It was a breeze of fresh air. And all developers had less bugs, and covered more business edge cases on the first pass. Problem with F# is that not many developers want to learn it. It's OOP and FP capabilities are much more aligned for todays apps
For me in the case if F# I believe it's really the different syntax that has always made me prefer C#, I am really just more used to the C family language syntax. However, I have played bit with F# too and recently explored documentation about it, just out of fascination and I totally see the value of it, because it's basically an implementation of OCaml, a language which strongly influenced Rust. In a certain sense you can say Rust is a bit like OCaml written with C like syntax. And I am totally into Rust these now. I am aiming to make Rust to be just is important in my life as C# is, although I have profesionally been on C# since almost 20 years ago almost as old as it is, so that is still a big difference to overcome.
I write 90% of my code in C# 7 then I use a mixture of everything else, mostly generic with default implementation. I don’t use record their confusing to me
Where do I start? It's a nice video showcasing all the new FP features of c# but there's nothing wrong with writing code the "old" way because applications have not changed since the days we did Win32 and MFC. It's still the same, get some data from a SQL database, display some buttons and dialogs type code we have been writing since 20 years ago. The picture you show at 11:25 gave me a chuckle. We write FP because we transform data? Data transformation has existed since the dawn of the programming age, it's not a reason to do FP over procedural. FPs only advantage is that it is nice and logical. It doesnt produce less bugs, or prevent developers from using it improperly. Records? You have a video explaining why it's being used wrong. Primary constructors? Lots of videos why it's being used incorrectly. Async/await.. lets not even go there. The real problem with programming is that we are giving shiny new objects.. and we use it wrong. That's why your channel exists to tell us we are doing it wrong.
You have made a couple of miscalculations there. The applications _did_ change over the last decade - the tasks we solve today have changed dramatically. Mads Torgersen has debated over that, explaining the most flagrant change that has happened in recent years: the need to transform the data created by some other team/application. That is why so much stress is being put on separating the data definition (tuples, records) from behavior (extension methods, pattern matching, switch expressions). Software today is structured way differently than software ten years ago.
I realised that "ontology" as a concept is at the root of OOP and that OOA cannot always reflect reality. What can always reflect reality is the notion that all "things" are behaviours.
@@zoran-horvat Both imperative and OO are error-prone and should be used as less as possible. F# is also multi paradigm, but is functional first. It's bad enough to work in an ecosystem that still uses exceptions, null or mutability as default behavior.
No, I have no idea what covariance is. I've read it a few times over the years. And it has never made any sense to me, or at least, any sense it makes is soon forgotten.
type of g is function(int)->int, no idea how to spell that out :D Edit: I deleted "like a delegate" only to be shown I was actually intuitively right. A good sign for the C# language.
Thank you very insightful video! Totally agree that OO has been overhyped and seperating data and logic is much cleaner in many projects. I still regularly find coders that believe more objects is more better. Most of the time (especially in services) you just want to run a series of functions on an input to transform it into an output. That works better by having them separate. Easier to reuse portions that way than having it all mixed together in classes.
Zoran, is it me, or all this languages "changes" tracking would be obsolete for software development in 2-5 years... I mean, all of this is nothing more than changes in how we code, but LLM-s are much more suited to track this. It seams evolution is running in circles in code and new features to more efficiently do the same things. These tedious types of work seems as if just made for automation of something that LLMs are. There would be need for programmers, but maybe 10% of todays, so this career would be less payed and less desirable. Do you agree, or do you think LLM-s can't and would not do versioning, refactoring and 90% of all programmers work?
I've been listening to this song since 1990s. I don't see how that could happen. Think for yourself: if you wanted to pay for software to get done, and eventually you got it, then what would happen in-between? What magic would make it for you?
@@zoran-horvat I'm looking at things from my position of junior dotnet developer, as an employee. It seams to me that supply and demand of jobs will not be in my favor, adding to LLMs. I'm not saying there would not be need for coders, but I'm saying there would not be as much need for MOST of the coders (lost of unemployed coders). You disagree with my statement?
@@niksatan I agree that demand for coders will diminish, but it always did. We should be software engineers, not coders, and in that sense AI is not even remotely going to substitute us in its present form.
@@zoran-horvat Zoran thank you for your words, yes, I am in fear of things to come, job-wise. I've invested a lot into learning these things, but sometimes it seams that other jobs are more payed and more in demand than software. But you are right, I should strive to look at my work more as a software engineering, and less as coding. Hope chatgpt-5,6 won't be a better engineer than me, as it is already better coder than me.
@@niksatan I feel your pain. One can't help but feel inadequate when LLMs continue to improve in ways we can't replicate. But on the other hand, coding is such a chore. Do it enough and you grow tired of the struggle.
Personally i love it, i Really dislike all the paradigm cults, there really is such a thing as the right tool for the job. With C# i can write OOP for classes and hierarchies of objects, write FP for the interactions and use procedural code to interface with low level systems. What's there not to love?!
There is a lot of pain when you learning all those nice features of modern c# and then in 2023 you are switched to a project with ASP WebForms, .net framework 4.6.2 and Visual Basic. After this I want to shoot myself.
I even can't launch it. And no one in the company can help me. I don't know how many programmers thinking about suicide but I am obviously one of them😢
I've been there and I think there are far worse frameworks you could be stuck working in, I'm thinking vb6, classic asp... but in all honesty what would it take just to rewrite the app in something newer? It may be worth considering imo.
Though I’ve programmed functionally in the distant past I had no idea I was doing so. The first language I wrote anything useful in was Z80 machine code and the program was an assembler. Seeing that a byte could be code or data a useful insight for a novice. Then my brother wrote a menu system where instead of the if-else and switch logic I would write, he stored the address of the function to call along with the menu item and the equivalent of just method.Invoke() from a key press. The menu items were stored as doubly-linked lists and he had the same method.Invoke() approach for navigating the menu. No need for logic, the path was in the data. But it wasn’t until C# started including functional programming concepts that the penny dropped. Extension methods I’m glad to see early in the history because that was a clue for me. Ps edit, some disambiguation is needed re definition of functional.
Do you think C# is generally heading toward a major overhaul? Or that M$ is going to create a completely new language based on C#? The goal being a simplification of the language and elimination of all the unnecessary syntax. My reasoning is that C# generally is getting more and more things with every version (I find most of it unnecessary) and that the learning curve for a beginner C# programmer today is getting steeper and steeper. The language is literally getting stuffed with 75% unnecessary things and 25% useful things with an obvious heading toward functional programming. Sometimes I find it chaotic, seeing that the new stuff is rarely used and that there is even an opposition towards using them. I have a hard time introducing new C# syntax in the application because it is "complicated", "we don't understand it", "I find it stu..." etc. Although I try to explain some of the advances, I too have to agree that the language is getting filled with literally everything and people (general programming population) are less willing to learn the new stuff.
Imho the learning curve always stays the same for c#, but it only gets longer over time. Almost everything that was valid c# years ago is still valid today. Maybe not best practice, but you can always learn that yourself. It's not like it's required to learn about every single intricacy of possible syntax sugar before you can even get started programming in c#. You still write your first hello world application mostly the same way you did when c# came to be. The only real change was top level program.cs in that regard. And everything else still works like it did years ago, but you can do things more efficiently or concise if you want to. That YOU don't need every new feature or find them necessary is entirely irrelevant (even if that sounds abrasive). It is that way by design since every developer, including people from MSFT, have different needs from the language and those needs may or may not be addressed by the language team eventually. Opinions on features is always a thing to be taken with a grain of salt imo since nowadays its trendy to have the "only my opinion is valid" mentality, especially on social media. The language is also not 'obviously headed' towards functional programming but it borrows what is useful, otherwise Option would already be a thing. Having trouble introducing new language features at your workplace is also more of a social problem because stagnation is easy. In general, I find your post to be overly generalizing and you treat personal experiences as a general truth, which I know for a fact none of my colleagues would reciprocate. I agree that some features might miss the mark (like primary constructors on classes) but they will be improved upon eventually. But most features are deliberate opt ins or conveniences/shortcuts on existing ways of programming in C#, rarely is there a feature that 'raises the bar' on what you NEED to know to learn and use C#
I have been following up from .net core 3.1 with less chaos and hardness from syntatic changes, which most time is helping codes to read/write better. I just don't use what i don't understand, either but that cannot be an excuse to blame their effort to make a language upto date.
Records are not that powerful without the logic in primary constructor, no elegant way to validate constructor args. Same about PC for regular classes.
@@VoroninPavel Absolutely not. That is as if you had a hundred definitions of a string and a dozen definitions of an int inside a project. Try to keep this idea at the back of your mind for some time and you will see how many concepts will become easier to grasp: There is no validation in records.
@@zoran-horvatbut it's what one does to avoid primitive obsession. Sometimes string is indeed just a value - sequence of characters and nothing more, records also can be values, but not always. In his book Domain Model Made Functional Scott mentions the same issue for F# and offers several approaches. How are we going to ensure value validity across the call chain if validation is not the part of construction? Just by convention to use dedicated construction functions? Well, at least today we can enforce this with source analyzers.
Primary constructors, as implemented in C# 12, are a failure. First, they spread initialization over the whole class. Since you save lines, it seems you have avoided boilerplate, but in terms of text, the real savings are not so great, and we loose code locality. You have to read the whole class to understand how it is created. Second, is very easy to start a class with primary constructors… to realize later that you need to do more in the constructor. Moving then to a traditional constructor is a real pain in the neck.
@@ianmarteens That is not the problem. The problems begin when you don't see the point of primary constructors and then, instead of thinking "it must be my fault", you confidently say it's their fault. I hope I have clarified it now, and that you will take your time to understand what that feature is, and what its intended use is.
@@zoran-horvat I've been coding for 20 years and I admit I am stuck in my ways a little bit. I'll be trying to use some of these practices in my next project at work
@@edgeofsanitysevensix Maybe in the future. The short story is that FP and immutable design make testing much simpler because all the system under test has to tell you, it tells via the return value.
@@cyberpunkspike It is the trait of good syntax when a guess ends up correct. For example, in previous versions of C#, the answer would be a compile time error - that would ruin all the magic.
"Most of programming day is - here's my JSON, give me your JSON, thanks for the JSON." 😆 YUP!
I love how you speak about C# with such passion in your voice, like it is an epic adventure (it really is though!).
I'm so impressed with the way in which you speak, carefully and obviously with love for your craft. Reminds me a lot of my first programming teacher in high school.
I found your channel just a few days ago and I have been going through all of your videos. There's so much C# fluff on TH-cam, it's disappointing that you don't have more views.
Excellent video. Kudos to you for going back over all the releases and putting in the research.
Type of g is Func
My first thought was int => int but maybe my brain has gone too functional over the years.
my dumb ass went "a delegate" haha
Thank you, Zoran! It's like "a breath of fresh air" in common programmer's duties which often are driven as "there's no time to explain - pin this feature on the side" ))
I meant "it is" = "all you videos" ))
The quality of these videos is just outstanding.
This is funny. First, I learned functional programming, then I switched to OOP, and now look, we are returning to functional programming.
Fantastic presentation of both the overview and evolution. Thank you for your efforts.
truly amazing video, Animations kept simple but effective
Thanks Zoran, it' a pleasure to have a break from ordinary "duties" enjoying your quality contents.
I did C# since C# 2. But this video really enlighten me more and give the big picture of C#.. Thanks!
This is remarkable!
I enjoyed every bit of your presentation, good job.
Func
Great video as usual Zoran! The type of "g" is Func
Yes, it is!
I like to explain delegates as objects that represent a piece of code that is not declared in a class. They're objects in the end. Just done on a different way...
Before C# 3, C# was basically a carbon copy of Java. After C# 3 in my opinion, C# become something else... Something greater. Great video.
Agreed. It used to be Microsoft Java, but it has gone in a functional directions, more so with DUs on the was.
Awesome video! Lots of confirmation for us FP proponents. Just discovered your channel, looking forward to your content.
Thanks for this video, I really love csharp and learning the functional way is my passion for the last few years.
Well, what is next for C#? F# got some pipelining feature for functional expressions. Is that the next important feature for functional programming in C# if it is realized?
I'd really like to see the pipe operator, but that is not likely to happen. But I do expect discriminated unions any time soon. That would be a tiny tweak to the existing syntax.
The type of g is Func because it takes an int as input and returns an int as result in functional describes as int -> int
I adopted records. It's actually a great way to create custom formats and settings using the newer JSON capabilities. Functional Programing actually makes Object Oriented Programing easier. It allows you to simplify many different tasks.
Very good video, also, g is a Func
just a tip…delegate and anonymous methods (lambdas) execution instructions are put in the heap, thus requiring garbage collection; however, local and regular methods are put on the stack (no GC). i spoke to the team lead of the MS .CLR team, and he knows this and has no plans to fix this.
Great content as usual, I have been using FP in c# for the past 10 years, I swear people love the functional features and the simplicity they bring to the design and readability, we just have to hide the fact those concepts stem from FP, then everyone is happy weirdly, language-ext helped me switch to FP constructs whole heartedly and made me a better programmer, I think the FP cult is the issue, we have to agree the FP ecosystem is full of purists and non-helpful people helping people to switch, f# is better in that regard, and content creators like you are oasis in the desert :), well done.
I'm primarily a Java dev, but there's a parallel story there in what the problems we're solving now vs then. Java originally was meant to run on an unknown device and securely load new classes from the network, from 3rd parties. OOP and VMs are good for that kind of thing, problem is, that's not what people do now.
Now we know exactly which linux container we're running in, using AOT compilation because in practice the code isn't dynamic and in serverless you don't benefit from a jitting VM. Under these constraints things like exhaustive switches make more sense than polymorphism. Applications also do far more I/O than in years past so blocking threads becomes more problematic, which favors a more FP style.
The same processes we are witnessing in .NET.
Most popular programming languages these days evolve in very similar directions. The strong separation between imperative and functional programming languages is long gone. Imperative first languages are introducing more functional parts and functional languages are adopting imperative parts.
From the most popular languages I believe it's really just C that does not really evolve. And that's also fine, because the quality of C is that it's super simple and low level.
Even C++ has lambdas these days. It's not like Rust, but you got the point.
But Java and C# are special ones for each other, because they have always been very similar and continued adopting each others things, although with the nuance that C# is a bit more diverse with syntax, which is why some people say C# is better while others say that C# has too many features. :)
one problem i found with primary constructors is this not being allowed…
public class MyId : MyId(typeof(T) {}
public class MyId(Type theType) { Type id=theType}
Because the first class has no PC, it won’t let me pass to the base PC. big bug for me, but you can do it with regular constructors.
Excellent and entertaining video
we always learn with you Zoran 👍
C# seems to be getting more heavily Functional inclined. I remember in your Pluralsight course asking for records in C# long way back, you got your wish.
u should do a video explaining implementation of X-Plicit Architecture (Herbert Gracia [sp?])to achieve modern isolation of abstraction and implementation, dependency inversion, and thus enabling flexibility for the enterprise future capabilities.
Excellent recap!
@zoran-horvat I'm waiting for your programming course on this subject.
Wonderful video, thank you!
For "separation between the data and behavior", can the data only objects be "anemic domain model"?
The primary trait of the anemic domain model is that behavior is implemented at the calling site. With functional types, behavior is still implemented in its own place, and used from the calling site.
Therefore, the caller doesn't notice any difference between a full-blown class with methods defined on it, and a functional type with a separate definition of functions that apply to it
Nice enthusiastic video! Though, it looks like you totally forget to mention ValueTuples? :(
They really share the same concept as structs and records in that they represent value semantics.
It's also good to mention how C# shares history with F#, which is based on OCaml. So that's really another important source of functional coding influence.
Good idea, I will add them for the next presentation. I will hold this talk again.
1:34 dynamic delegate?
Actually, a statically-typed delegate.
Become a patron ► www.patreon.com/zoranhorvat
Enroll video course *Beginning Object-Oriented Programming with C#* ► codinghelmet.com/go/beginning-oop-with-csharp
Watch other related videos:
Avoid Returning Null From Methods ► th-cam.com/video/HRLdcMil7Ec/w-d-xo.html
Boost Code Readability With Fluent Interface Design ► th-cam.com/video/YgX71yANayY/w-d-xo.html
Clean Code Tip: Favor Method Chaining Over Nested Calls ► th-cam.com/video/zWn0O0xzWMA/w-d-xo.html
I notice that I have a hard time getting out of that old pure OOP paradigm, especially around combining data and behavior. I still consider the "anemic model" an anti-pattern, although you might argue that separating data from behavior doesn't necessarily result in an anemic model as long as the behavior is still a part of your domain model and not of client services.
What is your view on the "anemic model" for c# and are there still valid use cases for traditional OOP styled classes?
There are many valid users of more-or-less pure OO models even today, so as many uses fit functional modeling better. The distinction is in what you need to add later, i.e. how should you extend the model: by adding more types, or by adding more functions. OO will struggle with the latter, but FP will struggle with the former kind of a problem.
@@zoran-horvatin my experience OO almost exclusively fails when the "type" of a thing seems to change as its characteristics change dynamically. A simple example is a negative account balance cannot be permitted but must become a Debt. Things are things but how they should be classified changes. A model that dynamically assigns allowable behaviours is more true to reality.
@@m4inline That is why we have object composition - that same which we use in functional modeling with types. On the example of account statuses, both object -oriented and functional models are equally plausible.
I like the captions, I'm learning english and are very util 🙂
I love the functional evolution of C#. It still feels OOP enough, but I can weave in functional behaviour easily. And I don't have to build 2-line long type definitions anymore.
IMO even with the evolution into a more FP language, F# is a plain better language. (even for OOP code)
@@Akronymus_Nonsense. No one uses f#. lol
@@obinnaokafor6252 Well, I do. And I stand by what I said.
@@Akronymus_ Functional languages may be good for some scenarios, but they are way too difficult to use when building things like games and apps. You're not free to build things. The language imposes insane requirements.
@@gavinw77 You can write OOP/procedural in F#. I specifically said that even for OOP F# is better than c#.
So, yes, f# is a functional first language, but it also is not a functional only language.
So I still stand by what I wrote.
Impressive speech.
Another beautifully explained video! I really like your approach to showing how new features of the language can benefit our day-to-day work through functional patterns. My biggest issue with modern c# is the fact it is becoming cluttered with multiple ways to accomplish the same thing as they "need" to be retro compatible. This situation even impacts readability as they have to come with workaround for syntax for new features
I don't like C#'s style, but I do love smashing together structural and functional programming together in interesting ways, so you had me in the first minute
Nice presentation, and you make some compelling points, with which I agree. So why not just use F# then, if we want to stay in the Microsoft environment? or a purely functional language, like Haskell, for instance?
Not many programmers could do that. I know of companies that run one team in F# and a dozen teams in C#.
On the other hand, C# is a good choice for solving so many practical problems. I deeply believe that the best language is the one which offers a clean version of all three paradigms, rather than being excellent in just one of them.
f# is for hobbyists - those who do not have any meaningful application solutions to build
@@obinnaokafor6252
Quite incorrect in my experience. My team used F# on several very large, high-scalability projects. It was a breeze of fresh air. And all developers had less bugs, and covered more business edge cases on the first pass.
Problem with F# is that not many developers want to learn it. It's OOP and FP capabilities are much more aligned for todays apps
For me in the case if F# I believe it's really the different syntax that has always made me prefer C#, I am really just more used to the C family language syntax.
However, I have played bit with F# too and recently explored documentation about it, just out of fascination and I totally see the value of it, because it's basically an implementation of OCaml, a language which strongly influenced Rust.
In a certain sense you can say Rust is a bit like OCaml written with C like syntax.
And I am totally into Rust these now. I am aiming to make Rust to be just is important in my life as C# is, although I have profesionally been on C# since almost 20 years ago almost as old as it is, so that is still a big difference to overcome.
@@TapetBart Yet you are here commenting on an amazing video on C#. f# folks are really funny. lol
Excellent
I still remember when a main was no longer necessary. It was when I felt it.
How long until we have F# in C# syntax?
I mean when all of F# is finally part of C#
It will never be the case. The coding patterns in two languages are different.
@@abj136 f# is not a serious language
g is Anonymous function?
It has it's place Zoran, but isn't always the best choice, particularly for UI design when you are databinding, etc.
And again, a very good video
What is the intended purpose of records?
To model values.
11:59 The question is "how did we get here?"
Well, it started with a gleam in Dennis Ritchie's eye back in the 70's with _int (*ip)(int);_
;-)
u left out ref structs, but did mention span so i guess it’s ok. lol
I write 90% of my code in C# 7 then I use a mixture of everything else, mostly generic with default implementation. I don’t use record their confusing to me
Where do I start? It's a nice video showcasing all the new FP features of c# but there's nothing wrong with writing code the "old" way because applications have not changed since the days we did Win32 and MFC. It's still the same, get some data from a SQL database, display some buttons and dialogs type code we have been writing since 20 years ago. The picture you show at 11:25 gave me a chuckle. We write FP because we transform data? Data transformation has existed since the dawn of the programming age, it's not a reason to do FP over procedural. FPs only advantage is that it is nice and logical. It doesnt produce less bugs, or prevent developers from using it improperly. Records? You have a video explaining why it's being used wrong. Primary constructors? Lots of videos why it's being used incorrectly. Async/await.. lets not even go there. The real problem with programming is that we are giving shiny new objects.. and we use it wrong. That's why your channel exists to tell us we are doing it wrong.
You have made a couple of miscalculations there. The applications _did_ change over the last decade - the tasks we solve today have changed dramatically.
Mads Torgersen has debated over that, explaining the most flagrant change that has happened in recent years: the need to transform the data created by some other team/application. That is why so much stress is being put on separating the data definition (tuples, records) from behavior (extension methods, pattern matching, switch expressions).
Software today is structured way differently than software ten years ago.
Languages evolve. Those developers who cannot accept this are not good
As in every technical or scientific field, those who do not keep up with the progress are left behind. Nobody cares.
Func. Do I win a void*?
Exactly. Here is your void*.
I realised that "ontology" as a concept is at the root of OOP and that OOA cannot always reflect reality. What can always reflect reality is the notion that all "things" are behaviours.
Neither of the two can capture everything. That is why we combine them in modeling.
But if C# goes more and more functional, why still use it? Why not switch to F#?
Because C# also supports imperative and object-oriented natively.
@@zoran-horvat Both imperative and OO are error-prone and should be used as less as possible. F# is also multi paradigm, but is functional first. It's bad enough to work in an ecosystem that still uses exceptions, null or mutability as default behavior.
@@MarkusBurrer They also have their role in programming. Have you ever seen a non-imperative sorting algorithm?
"Func"
No, I have no idea what covariance is. I've read it a few times over the years. And it has never made any sense to me, or at least, any sense it makes is soon forgotten.
Try this one: th-cam.com/video/Wp5iYQqHspg/w-d-xo.html
type of g is function(int)->int, no idea how to spell that out :D
Edit: I deleted "like a delegate" only to be shown I was actually intuitively right. A good sign for the C# language.
Correct.
Thank you very insightful video! Totally agree that OO has been overhyped and seperating data and logic is much cleaner in many projects. I still regularly find coders that believe more objects is more better. Most of the time (especially in services) you just want to run a series of functions on an input to transform it into an output. That works better by having them separate. Easier to reuse portions that way than having it all mixed together in classes.
Zoran, is it me, or all this languages "changes" tracking would be obsolete for software development in 2-5 years... I mean, all of this is nothing more than changes in how we code, but LLM-s are much more suited to track this. It seams evolution is running in circles in code and new features to more efficiently do the same things. These tedious types of work seems as if just made for automation of something that LLMs are. There would be need for programmers, but maybe 10% of todays, so this career would be less payed and less desirable. Do you agree, or do you think LLM-s can't and would not do versioning, refactoring and 90% of all programmers work?
I've been listening to this song since 1990s. I don't see how that could happen. Think for yourself: if you wanted to pay for software to get done, and eventually you got it, then what would happen in-between? What magic would make it for you?
@@zoran-horvat I'm looking at things from my position of junior dotnet developer, as an employee. It seams to me that supply and demand of jobs will not be in my favor, adding to LLMs. I'm not saying there would not be need for coders, but I'm saying there would not be as much need for MOST of the coders (lost of unemployed coders). You disagree with my statement?
@@niksatan I agree that demand for coders will diminish, but it always did. We should be software engineers, not coders, and in that sense AI is not even remotely going to substitute us in its present form.
@@zoran-horvat Zoran thank you for your words, yes, I am in fear of things to come, job-wise. I've invested a lot into learning these things, but sometimes it seams that other jobs are more payed and more in demand than software. But you are right, I should strive to look at my work more as a software engineering, and less as coding. Hope chatgpt-5,6 won't be a better engineer than me, as it is already better coder than me.
@@niksatan I feel your pain. One can't help but feel inadequate when LLMs continue to improve in ways we can't replicate. But on the other hand, coding is such a chore. Do it enough and you grow tired of the struggle.
Personally i love it, i Really dislike all the paradigm cults, there really is such a thing as the right tool for the job.
With C# i can write OOP for classes and hierarchies of objects, write FP for the interactions and use procedural code to interface with low level systems. What's there not to love?!
Precisely.
C# sum types when?
Before end.
There is a lot of pain when you learning all those nice features of modern c# and then in 2023 you are switched to a project with ASP WebForms, .net framework 4.6.2 and Visual Basic. After this I want to shoot myself.
I feel for you. Recently I saw my 2005 or something C# project. I wanted to cry.
I even can't launch it. And no one in the company can help me. I don't know how many programmers thinking about suicide but I am obviously one of them😢
I've been there and I think there are far worse frameworks you could be stuck working in, I'm thinking vb6, classic asp... but in all honesty what would it take just to rewrite the app in something newer? It may be worth considering imo.
@@jeremychristman1515 My point is that programming is changing, and will change. Programmers are changing it, hence they remain.
Time will come all language will be identical
TLDR:
Zoran: Adopt functional or suffer OOP.
A tiny correction: Traditional OOP, not just any kind.
Though I’ve programmed functionally in the distant past I had no idea I was doing so. The first language I wrote anything useful in was Z80 machine code and the program was an assembler. Seeing that a byte could be code or data a useful insight for a novice. Then my brother wrote a menu system where instead of the if-else and switch logic I would write, he stored the address of the function to call along with the menu item and the equivalent of just method.Invoke() from a key press. The menu items were stored as doubly-linked lists and he had the same method.Invoke() approach for navigating the menu. No need for logic, the path was in the data. But it wasn’t until C# started including functional programming concepts that the penny dropped. Extension methods I’m glad to see early in the history because that was a clue for me.
Ps edit, some disambiguation is needed re definition of functional.
A very nice retrospective.
One language to rule them all! 😎
If you were blue you’d look like a tau. Neat 😅
Do you think C# is generally heading toward a major overhaul? Or that M$ is going to create a completely new language based on C#? The goal being a simplification of the language and elimination of all the unnecessary syntax.
My reasoning is that C# generally is getting more and more things with every version (I find most of it unnecessary) and that the learning curve for a beginner C# programmer today is getting steeper and steeper.
The language is literally getting stuffed with 75% unnecessary things and 25% useful things with an obvious heading toward functional programming. Sometimes I find it chaotic, seeing that the new stuff is rarely used and that there is even an opposition towards using them. I have a hard time introducing new C# syntax in the application because it is "complicated", "we don't understand it", "I find it stu..." etc. Although I try to explain some of the advances, I too have to agree that the language is getting filled with literally everything and people (general programming population) are less willing to learn the new stuff.
Imho the learning curve always stays the same for c#, but it only gets longer over time.
Almost everything that was valid c# years ago is still valid today. Maybe not best practice, but you can always learn that yourself.
It's not like it's required to learn about every single intricacy of possible syntax sugar before you can even get started programming in c#.
You still write your first hello world application mostly the same way you did when c# came to be.
The only real change was top level program.cs in that regard.
And everything else still works like it did years ago, but you can do things more efficiently or concise if you want to.
That YOU don't need every new feature or find them necessary is entirely irrelevant (even if that sounds abrasive).
It is that way by design since every developer, including people from MSFT, have different needs from the language and those needs may or may not be addressed by the language team eventually. Opinions on features is always a thing to be taken with a grain of salt imo since nowadays its trendy to have the "only my opinion is valid" mentality, especially on social media. The language is also not 'obviously headed' towards functional programming but it borrows what is useful, otherwise Option would already be a thing.
Having trouble introducing new language features at your workplace is also more of a social problem because stagnation is easy.
In general, I find your post to be overly generalizing and you treat personal experiences as a general truth, which I know for a fact none of my colleagues would reciprocate.
I agree that some features might miss the mark (like primary constructors on classes) but they will be improved upon eventually. But most features are deliberate opt ins or conveniences/shortcuts on existing ways of programming in C#, rarely is there a feature that 'raises the bar' on what you NEED to know to learn and use C#
I have been following up from .net core 3.1 with less chaos and hardness from syntatic changes, which most time is helping codes to read/write better. I just don't use what i don't understand, either but that cannot be an excuse to blame their effort to make a language upto date.
var g = (int x) => x * x;
its a delegate -> Func
Records are not that powerful without the logic in primary constructor, no elegant way to validate constructor args. Same about PC for regular classes.
Records should not contain validation, because they are just values: A value's validity changes by the context in which it is used.
@@zoran-horvatdifferent context -> different type
@@VoroninPavel Absolutely not. That is as if you had a hundred definitions of a string and a dozen definitions of an int inside a project.
Try to keep this idea at the back of your mind for some time and you will see how many concepts will become easier to grasp: There is no validation in records.
@@zoran-horvatbut it's what one does to avoid primitive obsession. Sometimes string is indeed just a value - sequence of characters and nothing more, records also can be values, but not always. In his book Domain Model Made Functional Scott mentions the same issue for F# and offers several approaches.
How are we going to ensure value validity across the call chain if validation is not the part of construction? Just by convention to use dedicated construction functions? Well, at least today we can enforce this with source analyzers.
covariance and contravariance can bite you in the bum too, if you don’t understand them.
Primary constructors, as implemented in C# 12, are a failure. First, they spread initialization over the whole class. Since you save lines, it seems you have avoided boilerplate, but in terms of text, the real savings are not so great, and we loose code locality. You have to read the whole class to understand how it is created. Second, is very easy to start a class with primary constructors… to realize later that you need to do more in the constructor. Moving then to a traditional constructor is a real pain in the neck.
That is not the intended use of primary constructors. The intended use, as I see it, is as in records, where none of the bad things you listed happen.
@@zoran-horvat records are fine. But primary constructors in C# 12 can be used as I said.
@@ianmarteens So can reflection. Is it a failure?
@@zoran-horvat sorry, can’t see your point. Not blaming you, it must be my fault. Have a nice day.
@@ianmarteens That is not the problem. The problems begin when you don't see the point of primary constructors and then, instead of thinking "it must be my fault", you confidently say it's their fault. I hope I have clarified it now, and that you will take your time to understand what that feature is, and what its intended use is.
Multicast Delegate
Nope.
I feel like if I don't use a functional pattern you will find me and kill me 😢
Oh, no, I wouldn't mutate you. Maybe ask for your murdered copy?
@@zoran-horvat I've been coding for 20 years and I admit I am stuck in my ways a little bit. I'll be trying to use some of these practices in my next project at work
@@edgeofsanitysevensix Give them a chance - they are worth it.
@@zoran-horvat can you cover functional programming and how (if at all) it affects unit testing?
@@edgeofsanitysevensix Maybe in the future. The short story is that FP and immutable design make testing much simpler because all the system under test has to tell you, it tells via the return value.
Just stealing from F# lol
Does that mean that F# is now left without those features?
@@zoran-horvat no my point is F# has a lot of good stuff and it's being added now to C#
@@flogginga_dead_horse4022 could name such features?
@@obinnaokafor6252 pattern matching originally, records , more too but just a quick reply
Int
Nope.
@@zoran-horvat then it must be an object
@@beingmerciful It is a Fun delegate in C#.
Delegate
I guessed Func correctly.
@@cyberpunkspike It is the trait of good syntax when a guess ends up correct. For example, in previous versions of C#, the answer would be a compile time error - that would ruin all the magic.