Video

The List class is from BCL. I cannot create any methods in it.

They are not incredibly useful. Start from that point.

​@@zoran-horvat I beg to differ. For years I worked in languages that didn't support them, so we had to use sentinel or magic values to determine when data is not available or otherwise hasn't been set yet. That's a much bigger nightmare. Moving to tools which added null functionality improved that drastically! The concept of a null is so powerful!!! And made working with data and ensuring that I'm working with the right data so much easier! And the concept isn't even hard to grasp. One example... you have a method to query a database for user by ID... and go to retrieve user 123, but user ID 123 doesn't exist in the database, for whatever reason. Having that method intentionally return a null tells the calling code that there is no user 123; it doesn't exist. The other techniques I see used, either to throw an exception, or instantiate a blank "fake" user to avoid the null are both terrible ideas -- exceptions are slow and are intended to be "exceptional" when unpredictable things happen, and creating a blank object... well, you're working with data that isn't real and the calling code has to check for that too. Result<> objects don't solve this problem, because the database query actually is successful -- there is just no result that matches the specified criteria. A simple null return makes it all very easy without wasting any resources. And the Optional<> technique introduces a lot of extra boilerplate code that just isn't necessary. Most of the time when I see developers struggling with null exceptions, it's because they are trying to process data that they haven't initialized yet. So that exception is incredibly useful! It tells them that, hey, you forgot to do something somewhere else in your code. The current C# nullable reference type behavior encourages the practice of new()ing objects just to make the warnings go away or letting C# instantiate default objects for you that don't represent real data... so the code that would have thrown an exception using the "old" way if nulls were embraced, no longer throws those exceptions. So while, yes, it avoids the exception, that code is now working with fake data, and because no error is thrown, the developer isn't made aware of it. It happily proceeds down the happy path as if everything is perfect when it really isn't. This is a bigger problem than just fixing the exception. Exceptions tell you that you did something wrong and it needs to be addressed. But with the other technique, the code isn't even aware that there is a problem. When you do discover it, you have to backtrace to see where your object reference was assigned incorrectly. Very frustrating and time consuming. I'll take an exception over that every time. Many techniques for avoid nulls also abstract away the concept that reference-type objects are actually pointers and memory has to be allocated and CPU cycles are used to create that an object any time you instantiate or even declare one that isn't nullable. It makes developers much more careless about using those resources. And causes a lot of confusion about how reference types actually work. The majority of developers that I know that actually like C#'s nullable reference feature, I promise you, don't understand how objects actually work, and that modifying the contents of an object passed to a method actually modify the original object. The whole concept (and benefits) of reference objects is lost on them. And I believe that leads to more bugs than just taking the time to learn to work with nulls in the first place. I'd even go so far to say that anyone who doesn't like nulls, or doesn't understand nulls, shouldn't be using reference types at all, because if a null seems like an inconvenience, they don't get why objects can be so useful and so powerful. Structs are probably better for developers at that skill level. Techniques like what you show in this video make it much more difficult to determine whether you have required data missing, or if the data is actually an empty value. There is a big difference between the two, and hiding that for the sake of avoiding a few null checks and useful exceptions is kind of sad. Because of the null coalescing and the null conditional operator, dealing with nulls is really easy. The stuff you're doing in this and other videos is a lot more work than just learning how to use nulls properly in the first place. The code is longer, more complicated, and harder to read than anything I write which fully embraces the concept of a null.

LSP is not about classes but about types. So much about who should read the principle again. Regarding my video, I am not sure which timestamp in the video you are referring to. Before clarifying, be aware that assigning a list to a span without recreating the object makes the list a subtype of a span, quite formally. It is the same effect as what you would accomplish by defining a custom implicit cast operator without a direct subclass relationship. Any cast operation defines a subtype relationship, and implicit cast does that with full formality. Now with a lowered cynicism on your side and more seriousness, I would like to hear which timestamp in the video should cause concern.

The base class does not throw. Both classes are non-generic and therefore invariant.

Sometimes I use LanguageExt, mostly for Option and Result definitions. I regularly depend on language syntax alone, rather than third party libraries, because that is the only way I can preserve backward compatibility in the long run.

That video is explaining the evolution of the C# syntax over the last 15 years. That video is not dedicated specifically to elevates types, but it includes many topics and a mention of some of the types from this short video, all put in the perspective of modern programming in C#.

I very much like your channel. Lots of good FP information. I don't use C#, but I still like the information and the view to language progression.

It can be the function (Comparison delegate), and that was the last line added in the demo. It is common in .NET to include an overload, so to accept both the IComparer and Comparison, to suit every caller. Java supports that natively, as you can assign a lambda to an interface variable, but in .NET we still have to write both methods.

Adapter would have to change the type, i.e. adapt one type to another.

Greater or equal is common in programming because it preserves order. Greater than reverses the order. It is relevant when the algorithm applies to reference types. Why have one algorithm for ints and a different one for references if both do the same thing? Applying a two-argument function to N arguments is the functional fold operator.

I'm using your example in the video. Using a function or a series of functions does not mean that you're coding in a functional style. All logic in both styles happens in functions. Functional means no mutations on an original data structure and no side effects. All examples you've given are technically functional approaches. In the example you've given, order has no meaning and no consequence. You're evaluating 2 sides at one time. 1 Always wins. They're value types. Your question for value and reference types, I already answered with IComparable. Any type, value or reference, that implements IComparable can be used by the existing library functions that use the interface. This is why I said write for the specific and move towards the generic. The fold function is also known as reduce, which is why I said Reduce.

That happens, yes.

Which line of code is that?

@@zoran-horvat Sorry... I was not talking directly to you. I meant the general "you", as in the person that wrote whatever code I'm reading. I prefer the first line in the Car example because it's clearer (to me). I don't have to think or look something up, it's just clear from the start. Hope that clears things up... sorry for the confusion.

Incompatibility of delegates is not an inconvenience - it is intentional. The same situation is with classes. Their objects are not assignable to each other even when the two classes have the same shape.

@zoran-horvat That's more or less ok, depending on point of view. There have been quite interesting discussions with C# team about this, but that's another point Unreadability of type signatures is quite a problem. As is currying. It's quite hard to do it in functional way. If I wanted functions to be partially applied that's where type signature unreadability gets problematic. Discriminated unions and exhaustive pattern matching would be great additions to C#. But I fear that may drive C# into F# territory with some bad trade-offs in readability and semantics to keep backwards compatibility.

That is what makes it a good joke, I guess.

Some sequences throw when you try to iterate them twice. For example, streams do not support multiple iterations in general, and so a sequence deserialized from a stream would throw.

@@zoran-horvat was thinking more in the lines of the following code (see found variable): public IEnumerable<DiscountApplication> GetDiscountAmounts(Money price, DiscountContext context) { var found = false; foreach (var discount in _primary.GetDiscountAmounts(price, context)) { found = true; yield return discount; } if (found) yield break; foreach (var discount in _alternate.GetDiscountAmounts(price, context)) { yield return discount; } }

Delegate types exist outside enclosing classes, and they are functions.

Functional programming can be excellent, but this is unreadable. The delegates hide the structure of the actual functions and when it's this nested it's a nightmare. Without putting words in Zoran's mouth, I think that he's showing the power of containing state within expressions rather than classes. But going between 5 layers of functions and their abstract representations as delegates seems a bit much to me when we're literally just filtering a collection.

C# will hardly advance further in readability, unfortunately.

Viewability and listenability are the future, so don't care.

I like the way you formulated it.

That's it :) Now, the reason! The reason is that one function knows the data source and another function knows the phrase. Neither should depend on other's data, so the delegate arithmetic comes to the picture. It is the direct inverse of traditional dependency injection in OOP.

@@zoran-horvat I have to admit Zoran, it took me longer than I care to admit to work out what I was seeing. Clearly you are a very talented and experienced developer, but the delegates hide so much that it's extremely hard for me to read without seeing their definitions. As always, thanks for the video as I have learned lots. I didn't even realise that functions could be extended. It's also very interesting to see how state can be entirely contained within functions.

@@1992jamo I told you it is going to be difficult :) But those things you have seen in the end, that is the important lesson. Give it some time, and you will see that it will change the way you look at the functions and delegates, not only in C# but in any language.

True, they won't. It takes a lot of experience and even more formal knowledge to start to appreciate functional designs.

I had a senior recently not understand the curried function I'd written. That one surprised me.

@@Robert-yw5ms Currying requires a wider view on functions to understand. A litmus test is for someone to answer why F# functions have no parentheses around arguments.

​@@zoran-horvat Do i have to know the mathematical background also, to get very good at funktional programming?

@@UwuseSawase You should have a clear understanding of mappings and functions. That is primarily algebra, rather than mathematical analysis, for example.

I don't know...

This is the regular coding pattern when designing pure functional code. It is not common to see this kind of code mixed together with OOP design.

Watch again. This is literally the single point you should understand, and once you do...

@@zoran-horvat There’s many C# features used here that I’m not familiar with. What means “b!”? What do delegates do in this context? Also I constantly lost track of definitions and had to scrub back and forth through the video to get what you were referencing. And the final point of difficulty is not understanding WHY all this indirection would exist. I can do this same function without all these.

@@abj136 Can you?

@@abj136 The "b!" is easy enough to explain. "!" is the null forgiving operator. If you're using nullable reference types, you use "?" to designate that a variable or return type can be null. His Create() functions return things like "BookType?" (this was shown in a recent video he did - Master the Design of Functional Types in C#). So his "a" and "b" variables could potentially be null if the creation logic failed. However, since this is a demo, he knows that those are not going to be null, and doesn't want warning squiggles distracting from what he's talking about. So he uses the "!" operator to say, "I definitely know that these are not null, even if the analysis logic says they might be, so don't show me any warnings about them." Basically, they're not related to the topic he's trying to explain, just part of the general C# syntax.

This particular detail is hard. But once you clarify it, you'll be looking at functions in an entirely new way!

Me too. But I love Zoran’s presentation style and I keep repeating videos until things start to click. I don’t converse like this with my fellow developers so I’m just a bit rusty and Zoran sets an excellent standard to rise to.

There are a couple reasons for this: 1. He moves quickly in his demos. I ⏸️ and ⏪ all the time to clarify details that he might gloss over. I prefer this now as I don't need to sit thru mind numbing tedious explanations. 2. He focuses strictly on the topic, so if something he does is unclear (say with the bare Func signatures), it's mostly on you to figure it out. 3. He's now skipping over refactorings like Func -> BookFilter etc., because that's now understandably hidden behind Patreon. I've come to love Zoran's style as he speaks to you like a young child but does not treat you as one--you must come prepared with knowledge of c#, because he focuses on the abstractions which is where the real learning happens. Just keep watching and it'll click!

@@d2pgoon86 I think point 3 is the most important. Especially since the delegates hide parameters.

I am a beginner developer (well, I did that 20 years ago as a hobby in school) and I went through Zoran's tutorials on Udemy to refresh and update my knowledge. They were phenomenal and easy to understand. Most of the stuff here on YT is too advanced for me but I could not find better source of C# knowledge on the internet than Zoran!

That makes sense. Currying is closely related to dependency injection, in the sense that it applies to scenarios where one party provides dependencies and other party provides parameters.

My practical experience says me to not care about UI LOGIC so much. UIs are rewritten each 5 years.

It is not a mess, but yes, F# syntax is streamlined.

I've barely dabbled with f#, so this is a genuine question: is the type inference really powerful enough to work out what all the types here would be without being told?

@@Robert-yw5ms Almost always yes, but the implementation of the compiler must change. The type resolution might sometimes need to wait until the time it is used. In the meanwhile, the compiler might go along with rough guesses. As a last resort, F# settles down with a guess, such as always assuming some numeric type is int unless proven otherwise. I am not the best source for questions regarding the F# compilation process, I must say that, too.

@@Robert-yw5ms Hmm, in this case, you'd probably want to define the input types. let filter (dataSource: Async<BookType seq>) (phrase: string) = async { let! bookTypes = dataSource return bookTypes |> Seq.filter (fun bookType -> bookType.Title.Contains(phrase, StringComparison.InvariantCultureIgnoreCase)) } The return type would just be deduced, no need to specify it. We usually create a function to be able to "map" an Async, so without the computation expression: let filter (dataSource: Async<BookType seq>) (phrase: string) = dataSource |> Async.map (Seq.filter (fun bookType -> bookType.Title.Contains(phrase, StringComparison.InvariantCultureIgnoreCase))