Why is C# Evolving This Way?
Вставка
- Опубліковано 7 чер 2024
- C# 12 is here, introducing primary constructors and a few more new features to the language. But this latest version also continues the history of improvements and features added to the C# language and the .NET platform. Do you know that history? Do you know how C# became what it is today?
Two words: Functional programming. That thought underpins most of the evolution during the last twenty years. You don't believe me when I say that functional programming drives C# forward these days? Hear this, then! Hear the list of features added to C# since its version 2.
Generics (including covariance and contravariance, generic constraints, and covariant return types), extension methods and pattern matching, lambda expressions, expression-bodied methods, lambda types, records (and record structs), init-only setters and required properties, nullable references, null-conditional expressions, spans, ranges, expression trees, async streams, async/await.
How will you use these concepts if not in a functional design? But that leaves a screaming question unanswered: Why?
Why should we value functional design as equal to traditional object-oriented design? The reason is that the programming world has been changing through this entire evolutionary process of the C# programming language. We use C# to solve entirely different problems than at the beginning of .NET.
Watch this video and learn the primary motivation behind the latest features of C# and the principal methods of utilizing them in a modern design.
Thank you so much for watching! Please like, comment & share this video as it helps me a ton!! Don't forget to subscribe to my channel for more amazing videos and make sure to hit the bell icon to never miss any updates.🔥❤️
✅🔔 Become a patron ► / zoranhorvat
✅🔔 Subscribe ► / @zoran-horvat
⭐ Learn more from video courses:
Beginning Object-oriented Programming with C# ► codinghelmet.com/go/beginning...
⭐ Collections and Generics in C# ► codinghelmet.com/go/collectio...
⭐ Making Your C# Code More Object-oriented ► codinghelmet.com/go/making-yo...
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
⭐ CONNECT WITH ME 📱👨
🌐Become a patron ► / zoranhorvat
🌐Buy me a Coffee ► ko-fi.com/zoranhorvat
🗳 Pluralsight Courses ► codinghelmet.com/go/pluralsight
📸 Udemy Courses ► codinghelmet.com/go/udemy
📸 Join me on Twitter ► / zoranh75
🌐 Read my Articles ► codinghelmet.com/articles
📸 Join me on LinkedIn ► / zoran-horvat
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
👨 About Me 👨
Hi, I’m Zoran, I have more than 20 years of experience as a software developer, architect, team lead, and more. I have been programming in C# since its inception in the early 2000s. Since 2017 I have started publishing professional video courses at Pluralsight and Udemy and by this point, there are over 100 hours of the highest-quality videos you can watch on those platforms. On my UA-cam channel, you can find shorter video forms focused on clarifying practical issues in coding, design, and architecture of .NET applications.❤️
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
⚡️RIGHT NOTICE:
The Copyright Laws of the United States recognize a “fair use” of copyrighted content. Section 107 of the U.S. Copyright Act states: “Notwithstanding the provisions of sections 106 and 106A, the fair use of a copyrighted work, including such use by reproduction in copies or phono records or by any other means specified by that section, for purposes such as criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research, is not an infringement of copyright." This video and our UA-cam channel, in general, may contain certain copyrighted works that were not specifically authorized to be used by the copyright holder(s), but which we believe in good faith are protected by federal law and the Fair use doctrine for one or more of the reasons noted above.
#csharp #dotnet #functionalprogramming - Наука та технологія
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 ► ua-cam.com/video/HRLdcMil7Ec/v-deo.html
Boost Code Readability With Fluent Interface Design ► ua-cam.com/video/YgX71yANayY/v-deo.html
Clean Code Tip: Favor Method Chaining Over Nested Calls ► ua-cam.com/video/zWn0O0xzWMA/v-deo.html
"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!).
This is funny. First, I learned functional programming, then I switched to OOP, and now look, we are returning to functional programming.
Type of g is Func
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" ))
Excellent video. Kudos to you for going back over all the releases and putting in the research.
This is remarkable!
I enjoyed every bit of your presentation, good job.
Thanks Zoran, it' a pleasure to have a break from ordinary "duties" enjoying your quality contents.
Awesome video! Lots of confirmation for us FP proponents. Just discovered your channel, looking forward to your content.
truly amazing video, Animations kept simple but effective
Func
Fantastic presentation of both the overview and evolution. Thank you for your efforts.
Thanks for this video, I really love csharp and learning the functional way is my passion for the last few years.
I did C# since C# 2. But this video really enlighten me more and give the big picture of C#.. Thanks!
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...
Wonderful video, thank you!
we always learn with you Zoran 👍
Excellent and entertaining video
Excellent recap!
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.
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.
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'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. :)
I like the captions, I'm learning english and are very util 🙂
And again, a very good video
Java is also evolving toward functional data orient programming.
It even has pattern matching!
I think Scala, Kotlin, F#, and Clojure motivated
these improvements to C# & Java. Makes me happy !
The type of g is int -> int. I believe in C# it's Func
BTW, I noticed this path in C# years ago and I remember noting it to a colleague and I said "I wonder if we'll get sum types soon". Looks like C# isn't quite there yet.
C# is going in the direction of getting sum types soon, so it looks. The product types are easy and the new syntax is making them even easier.
Excellent
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.
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
Impressive speech.
@zoran-horvat I'm waiting for your programming course on this subject.
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.
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.
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 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
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.
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
I still remember when a main was no longer necessary. It was when I felt it.
It has it's place Zoran, but isn't always the best choice, particularly for UI design when you are databinding, etc.
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
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*.
"Func"
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
1:34 dynamic delegate?
Actually, a statically-typed delegate.
One language to rule them all! 😎
What is the intended purpose of records?
To model values.
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.
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.
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.
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.
g is Anonymous function?
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
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.
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.
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: ua-cam.com/video/Wp5iYQqHspg/v-deo.html
Time will come all language will be identical
C# sum types when?
Before end.
If you were blue you’d look like a tau. Neat 😅
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.
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?
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.
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.
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.
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.
Int
Nope.
@@zoran-horvat then it must be an object
@@beingmerciful It is a Fun delegate in C#.
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
Delegate
TLDR:
Zoran: Adopt functional or suffer OOP.
A tiny correction: Traditional OOP, not just any kind.