Great view on programming languages, THX! Somehow APL will always feel like write-only programming. "We will make reading insanely hard because nobody likes reading other developer's code..."
@@leinh4245 Everything in the expression is a direct transfer from the thinking behind it: "it is equal if and only if the other object is a point and that other point is equal to this point."
I wish I could see this a little earlier.. This is an awesome demonstration of neat code. A code that looks beautiful at same time little hard to understand which serves the purpose of abstraction. I really love it.❤️
This is literally the first time I've watched a programming speech where the guy speaking ACTUALLY had a personality and a sense of humor. Thank you Bill Wagner for not being dry, and for showing that not all programmers have the same personality.
I used to do mapping/lookup logic similar to 41:50 with Dictionaries; where what you check against is the key, and the result you want is the value. 🙈 Which is runtime-configurable, but obviously way slower to execute. Nice to know about this compact switch syntax.
You might be surprised how fast Dictionaries are. I've found that a Dictionary is quicker at returning an item with a string key than looping over a list of just five or so items looking for the same string key inside the value (even using for-next rather than an iterator). It seems the hashing function for strings is very quick and beats a string equality test after just a few iterations. Granted the switch statement's jump tables are likely to be even more optimised, but my point is that a Dictionary might not be as slow as you think depending on what type your key is. A Dictionary is likely to be quicker than a set of five or more if-else branches that test strings - although ideally you want to initialise your dictionary only once if you can.
It's a fashion trend and it's dumping a veritable shit ton of barely legible code into the world. It's a nightmare that we are all going to have to suffer for. But then all single paradigm advocates generally write god awful code.
Tuples, immutable data structures, pattern matching, null safety, avoiding inheritance hierarchies, ... He basically made a case for functional programing without mentioning it a single time.
I guess, but the way I see it it's moreso advocating for the best of both worlds. C# is still clearly OO even with these additions, but this extends it beyond that
Yes and no, even OOP languages have always advocated not to go overboard with inheritance and to use it only when it makes sense. Quite a few prominent names in C++ (including its creator) have taken that stance from the get-go. It's a useful tool, IF used as intended. Problem is, some people go overboard and start inheriting everything from everything, even when it makes no sense and will only cause problems. Null safety is also not a solely functional programming paradigm. etc.
Let me ask a question: what is a program, unless pure imperative, if not a collection of functions? An object is just a collection of variables and functions after all. Object Oriented Programming is a mouthful way to say that those functions and variables belong to a class, and it helps to describe behaviour and intention. There is really no "functional vs object" paradigm in a program, unless you want to start a flame. Everything is compiled in a neat sequence of operations, and function calls.
Very nice! I actually hated tuples earlier, because I always thought: Why not just create a new class? But the way you are using tuples here is a lot different from how I thought you were going to use them! Very nice examples!
I can't say I'm very comfortable with the idea of allocating two or more Tuples every time you want to do a simple allocation/comparison. Would be better to just change that point class to have one field of type Tuple and compare them by left.tuple == right.tuple.
Point is a struct in the example, so if it allocates it is going on the stack and not on the heap. My guess is there will be some optimizations done in those simple methods but I am also curious if there is a performance cost to the tuple approach. Especially the equality code is a lot more readable though, so that might be worth it in some cases.
@@Eldering the compiler is smart enough. You can play on SharpLab: sharplab.io/#v2:D4AQTAjAsAUCDMACAzgFwE4FcDGrEGFEBvWRMxASwDs8APAblPOrwE9GZzEECAKFxLQA0lGolYBKYky5leqABYVkAOmGJFylZMQBeRL3WSOXAL4zEFniAgA2RACMA9k4A2iJwAcApugCGqE7oerq8hK4ihOhSugB8Bq5qIok6uvq86EmImcZWSDb2zm4ePv6BwQCEoeGR2THxvInqKVJVBpnqORIm5HncACyIAMoA7n6evFIknLJyRjEGrCK03RbmMKZAA==
@@londospark7813 The next feature will be making semicolons and curly braces optional, you'll see.. then they'll discuss the new and exciting world of currying parameters 😂😂
Modern languages like to include functional programming features. Everything that was presented here made me think that C# wants to be like Rust with runtime checks.
I think the Point Distance property is wrong. Since it is initialized to default, HasValue will always be true so the real value is never computed. It should be initialized to null I believe
Discard assignation is hacky and unreadable as fuck. An assignation should be to assign something. The case presented would be way more readable as pattern matching in c#8, and then write null explicit instead, like this: public string HyphenateForPartner(Person partner) => switch partner { null => throw new ArgumentNullException(), _ => $"{partner.LastName} - {this.LastName}" }
Yeah, I don't like the assignment to discard operator either. After all, the result of an expression is already discarded if you don't assign it to something. So, I'd prefer just: partner ?? throw new ArgumentNullException(); but that doesn't compile.
C#9 is going to introduce records, which do these things out of the box. Otherwise, you can approximate some of this behavior already with structs and classes.
What do you think about using underscores for private fields in a class? According to Microsoft naming conventions we shouldn't use it, but I see many examples where it is used and even in this video at: 26:32.
36:56 What might be a use case for chaining switch statements? The result you want (ie a function is returning) is in the last switch statement. Why would one prepend various other switch statements?
for example you could replace the tuples form the tolls example with nested switches. Would be usefull if you had to take into consideration for example mass of the vehicle, but only when inbound in the evening on the weekend, otherwise mass would be irrelevant. You just have more options :)
11:56 could someone break down, a bit more than he did for a noob, the order this happens/why it works. It seems to be taking the expression on the right, and storing the results without coming back to them, then looks at the left and assigns the results. but my question is, did it do that because it's a lambda, or because it's a tuple?
He is basically saying that it works because that's the way they wanted it to work. Internally it is creating a copy of the properties before assigning them back so that it doesn't loose one of them. The real question: it is a behaviour of the tuple. In case you are interested, that is an expression body function, not a lambda, just the newer syntax for defining functions that contain a single expression with => operator rather than enclosing it in { }. They look quite similar, I think it was inspired by the lambda syntax
It works because of tuples and desctructuring. As of C# 7, some types have a method called Deconstruct on them, ValueTupe (which Wagner is using in the example) implements the Deconstruct method. When a type implements Deconstruct it allows you "unwrap" the fields of that type directly into variables: var (x, y, z) = myObject; is the same as var x = myObject.x; var y = myObject.y; var z = myObject.z; If x, y, and z already exists: (this.x, this.y, this.z) = myObject; is the same as this.x = myObject.x; this.y = myObject.y; this.z = myObject.z; In Wagner's example, the right side of the equal sign stores this.Y and this.X in a tuple. The left side then deconstructs the just created tuple into the two existing properties this.X and this.Y You can read more on deconstructing here: docs.microsoft.com/en-us/dotnet/csharp/deconstruct
34:12 When you have come so far, why do you not also discard the discard? The assignment itself is superfluous and confusing. A simple *partner ?? throw Exception()* would imo be much more concise
You're in a context that expects statements, a null coalescing expression is not a statement by itself, but it can be made part of one... Such as a an assignment. I think this looks alright, but code reviewers may label it as an antipattern due to their own preferences, so having a general helper in the project like ThrowIfArgNull(object arg, string nameofArg) is probably much more widely accepted. This can be done without newer C#-features. Correct me if I'm wrong on something.
When you switch if statements to expressions if an exception happens it’s hard to tell what part of the expression is causing the error, so you might want to factor back to if statements sometimes.
I am of the opinion that we should be able to specify that certain objects be allocated from a private set of (OS) pages. When disposed, the entire set of pages is recycled, no need to check if any other object has allocations within those pages. sure, some memory is not used?, but we have memory, it is garbage collection that kills. SQL Server and other established database engines are highly robust in being able to run for very long times because the make extensive use of fix page sizes, which can be easily recycled. We might want the ability to specify certain page sizes (4KB, 2M, 1GB etc)
I had not known about object pools, so thanks the Microsoft documentation says it is a mechanism (pool) for handling objects that are expensive to create or destroy. what I am talking about is making sure the virtual address space can be recycled easily. Even if allocations are mostly released, there is no guarantee that a large contiguous block can be reused, hence new allocations occur beyond the previous.
28:25 - newb question here - I love this use of ArgumentNullException but... can I just use reflection rather than having one of these for every single property I might use?
Reflection is pretty expensive and not supported in some contexts. One solution is to have code that assumes nothing is null, and that forces null pointer exceptions to appear sooner, rather than being passed down through a call stack, but there are drawbacks to that as well.
@@CzarZappy Or use Option/Maybe monad data structures that forces you at compile time to acknowledge the nullability of a reference type before accessing its value.
@@disklosr This is great if you are using C# 8, but if you are doing C# development in Unity, you are stuck with C# 7.3 for now. Also, my answer was in response to the question "can I just use reflection rather than having one of these for every single property I might use?", and addressing the reflection limitations for this use case to show the name of the null parameter given. Your suggestion is another solution to identify that a given parameter is null, but not what property name to report out.
Not buying that HyhpenateForPartner example, you could have refactored in a similar manner with a null check without discards and it would be more readable imho
Glad he didn't use underscore prefix. "This." is a little verbose but only appears once. The underscore appears every time and doesn't tell me anything I need (unless I'm violating single responsibility).
no, not really. void Foo (Class value) { value = null; _ = value.ToString(); } by the time the exception is raised, the argument may not exist. Worse, the argument may have changed.
@@connorboyle2092 Okey, nice. I'm also wondering if the logic of doing comparisons between tuples is more costly than simply doing a normal equality check.
Channel Dad Bryon Lape it’s still getting regular updates mostly for security reasons. Right now I think dotnet framework is on version 4.8.something. However, Microsoft is transitioning a lot of their new features over to dotnet core
This stuff is too high for my beginner ass...lol hopefully after a couple of days I can come back to this video and actually understand what this guy is saying.
I'm looking at some of those statements as they are being typed and I'm completely blank about their meaning. This language is becoming more and more like C++ which was originally referred to as a write-only language because once written nobody could ever read and understand it.
If you follow best practices, then C++ is perfectly understandable. Don't blame a language for programmers thinking they're being clever by being obtuse.
@@stysner4580 That's literally what I just said, not the language's fault if its features are mishandled, or conventions are not agreed upon across an entire team. Hence why I said: 'programmers thinking they're being clever by being obtuse'.
It's definitely becoming C++-ish in the sense of adding more features, but contrary to popular belief, that's a super minor issue (if that's an issue at all). You can easily exclusively write C++11, or C# 7.3, and make sure your compilers and teams follow along. People do this all the time. The real issue with C++ in this case is that the language is old and at the same time, not stuck in time like C. It precedes many modern programming language design good practices and in many cases, C++ was even the first to introduce them to the mainstream community. The consequence of this is that preexisting rules in the language form weird and unintuitive outcomes when used in conjunction with newer features. C# is very immune to this, much of the language is explicit and most of the new features are just shortcuts to things you already do. The only drawback of using them is that you need to keep up and if you don't want to use them, you can choose not to keep up.
This is some nice sugar and all. However, I believe maintaining code is all about making it readable and understandable. Is a constructor made with a one-liner tuple really more readable and understandable than a conventional one? So public Point(double x, double y) { X = x; Y = y; Distance = Math.Sqrt(x * x + y * y); } vs public Point(double x, double y) => (X, Y, Distance) = (x, y, Math.Sqrt(x * x + y * y)); It's not even like the tuple alternative is faster to write or has less characters. You might as well have written this: public Point(double x, double y) { X = x; Y = y; Distance = Math.Sqrt(x * x + y * y); } And be honest - you know people are gonna one-line the shit out of tuple constructors and the like, so it will really inspire to some great! horizontal scrolling. My experience with tuples is like: "lets create this anonymous type using a tuple and use it as a dictionary key because i'm too lazy to create a proper struct for it..". Let me tell you right away. This does not create readable code! So yeah it's nice sugar and might be useful in some situations, but i haven't experienced them yet from a production-code perspective.
There's missing "Umple" and "Kotlin" language features to have an even cooler name... :D Note : C# is doing great on taking inspiration at finests, be it F#.
11:17 how wonder what's the efficiency... Test (run over 100 s): Temp: 91.231.584/s Tuple: 88.273.078/s I knew it! It's 3.3% slower! The tuple method is garbage! :P (It still depends on the type of code you need to write, 3.3% is not that insignificant)
Jetbrains Rider is 10 years ahead of Visual Studio. They've been doing static analysis of code for years now.
4 роки тому+47
I have to admit that I was not impressed with the talk. The language features are fine but the way they were presented did not sit well with me. Lots of talk about reducing the number of lines of code but the way the reductions were made was mostly due to syntax (remove braces, use ternary syntax etc). Is it better? I do not think so. The usage of throwaway variable _ to throw an exception when parameter is null was also a weird example. What is wrong with having 'if' statements? I never had problems reading code with if statements and i would always need more time to grasp code which uses ternary or null coalescing operators.
@Karm Asutor You guys are absolutely spot on, give me an if statement in any language and i know instantly what i'm doing. Give me some language specific syntax and I then have to figure out the 'ins and outs' of that. Somehow its becoming more and more complex in its simplicity...
This reminds me of some old code I came across recently. The code was messy and virtually impossible to read and had to be rewritten. Having a simple if check and some {} is so much more readable and in my opinion therefore better.
I assume the throwaway variable was designed primarily for destructured variable assignments. Does it have any other intended, intuitive, or especially helpful use cases?
agreed. but if some new syntax become very popular (due to it`s usefulness) and made it`s way to other languages, it will make other`s life easy as well. but to do that one must made up some syntax as well.
If you use an if statement, then I’m going to ask you to refactor it in the code review. Logical branching is the quickest way to introduce unintended side effects.
21:45 Should pull the opt out feature forward... Such a waste of calories the whole NRT fiasco. 22:50 Do not care about "potential errors", speaking as a business leader and architect, I care about REAL errors, and not dumbing down my crew by failing to engage the issues at hand. 23:30 Y'all had a sweet spot in the operators a version or two ago. That was plenty sufficient to reason about the "null" question. But if there's really this aversion to the concept, why not just remove null from the language spec altogether? Of course that would be absurd as well, right?
So... case in point. That was a lot of verbiage justifying *object?* , then turn around and simply leverage existing operators, with I will grant the updated *is* operator.
Can someone explain to me if there's a new shortage of disk space on the horizon? I understand why a C programmer in 1988 had to write shorthand. But nowadays? Today a junior programmer gets his code rejected if s/he starts writing "for (int i = 0;" instead of using a meaningful name for "i" that tells me what "i" actually is. Using a tuple as a short-hand assignment for two variables doesn't make the code anymore readable or understandable. The same goes for that awful new "if" syntax that they introduce with C# 8.0.
The pattern matching at the end is fancy, but in my opinion is an absolute waste of time. From a maintainability standpoint I have no idea why switch expressions were prioritised over switch ranges, they actually would make a difference to people like myself who have large volumes of code to produce with little time to make beautiful before moving onto the next job.
tuples are great until you realize the compiler still creates just as much code (pretty much identical code to long form) and you give up readability. When did readability stop being a priority?
I don't know. Why not instead start with data that shows where problems most happen in code, and why the C# team chose to address or improve those? From my perspective, when you're in an enterprise software company, with thousands of people, deadlines, cost concerns, developers on the same team located all over the globe... I'd want to see things you've enhanced and demoed that specifically address data-supported real-world issues rather than what appears to me as the C# team brainstorming about what can be better. These improvements.. maybe someone new to C# will get excited, but not so sure about the people in the trenches. Also, I played this at double-speed on UA-cam... we are techies... get to the point!
Content seemed a bit week, and i had to play back at 1.75 and one point i was playing back 2x speed. I know vid cant know what you know and then be targeted but boy was i hoping this was something cooler than it was. the vid should start with what the content is... like some syntax rubbish and nullable types. Perhaps im too hash but ish i was hoping for more. this could of been a 5min vid if that maybe a 2 min vid.
Readability of these new features is bad. In your private code sure its fine, but when working with a team you need to consider juniors and all the devs still to come. Shorter is not better... the very simple code syntax may be more verbose but everyone can understand and read it. Also having more ways of doing the same thing adds many different structures to your code that increases cognitive load.
IMHO, I think the industry is straying into the weeds... The original purpose of programming languages was to make a way for humans to communicate with machines, where more of the burden was on the machine to adjust to our way of expressing things, rather than the opposite. The "features" shown here look more like humans being asked to communicate more like machines! This seems really backward to me, especially considering that in many cases, the human devs are building systems like Siri, Alexa, Cortana, etc. to make the machines communicate more like humans, but the devs themselves get no such benefits... : b So now, instead of making code that is A. accurate, B. clearly understood and C. easily maintained, we seem to be consumed with making code that is D. most clever (inscrutable?), E. most likely to impress our peers and F. as concise as possible. Not a good trend that I'm seeing... > when working with a team you need to consider juniors and all the devs still to come Preach it!!! > ... having more ways of doing the same thing adds many different structures to your code that increases cognitive load. totally agree
Geez. Why not write some Haskell-to-.NET/CLR compiler and be done with it already? The language envy of all this drip... drip... drip... adoption of ML features is maddeningly apparent.
Before F# was created, there was an effort to do that very thing, but the type systems were not compatible enough to make it work. And then, work to create F# began. fsharp.org/history/hopl-draft-1.pdf
Most expert C# devs I know hate using underscores (_), now you are forcing their use? I do like the `switch` `tupple` code... also... `inbound` should be `isInbound`
Its good for their intended use, like discarding out parameters. For pattern matching, Id prefer default => instead of _ =>, but whatever its short and if you know the syntax its nice.
Sorry but these examples are actually harder to read and harder to understand. Having less code does not make it more readable in these cases. The original code was easy to read. The new code just jams everything together in a mess.
i am sory but this makes me have anxiety: if (bla bla) return apple; else return lemon; instead i would write: if (bla bla) return apple; return lemon; why would you put "else" everywhere
Well, I was hoping to learn something new here, but instead I got nearly half an hour about creating a dumb struct holding two doubles. And even though it's that simple, the implementation is broken (by design!) because of the cached distance. And it doesn't even have a ToString method! In a sane language, something like that should take approximately three lines of code and should be obviously correct.
Readonly feature... LOOOOOKKKK: Now we have a "const" modifier like the we had in C++. It's amazing to see how languages evolves to become more and more close to what C++ always was.
yeah, but the const feature of C++ was the most useless thing ever. You annotate one thing, then you have to annotate 20 files. Then someone just makes a cast to not const and it's worth nothing
Syntactic sugar taken from Python and VisualBasic.NET 1.0.
4 роки тому+5
Why is there so much obsession with reducing code size? Less code doesn't mean it is easier to read or that performance is better. What is next, will we change reserved words and start using € instead of public, ° instead of class etc, just to save few chars?
4 роки тому+2
@wubs23 I worked for 5 years mostly on developing file parsers / converters (xml, gml, xls and custom formats from measuring devices) and never had situation with 50 lines of ifs. I think that the best way to achieve code comprehension is to extract code to methods that are named correctly and document what is going on. When I review someones code, first thing I do is go thorough it quickly to understand the flow. If I stop and have to think what someone was trying to do, then sorry but I will not approve it. You should always be explicit and avoid stuff that do things automagically.
@ Exactly! Dropping out a few ifs and having an even more terse syntax does NOT make things more readable, and so just makes it harder to maintain and actually keep working right. Having decent methods to lay out the calls into something that makes logical sense is 100% more important. I totally agree with you.
I don't think reducing code size was the design team's main goal (tuple syntax excepted perhaps). Instead, it looks to me like they've started to prioritize expressions and patterns over statements.
@@declup, you may be right, that may be what they are doing, I don't know... But who has been asking them to prioritize expressions over statements??? I've never heard a coworker asking for such a thing. I have never asked for this, either.
Typical. Saved a few characters and made the code cryptic. Code should read like a book! It should tell a story. That code is shorter, but it does not translate into words. I would never write my code that way. Maintainability is as important as anything else.
@@igorthelight, I totally agree. However, they don't really take less time or save money for the company when you consider how much resource goes into trying to debug cryptic code...
It’s about following functional programming principles in an object oriented language. You’ll have less bugs, but the code does end up looking a bit awkward.
Maybe.. but how many Guard let pyramids of doom are out there? C# is still more powerful in many areas - e..g. Linq and database frameworks considering those were introduced back around 2008 in c#. Core Data is nowhere near as good.
Returning tuples? This is the single major thing why I'm not into functional languages. What does it mean at all: (int, int, int, double)? Totally useless, and waste of time figuring it each time you encounter such thing. Perhaps fine with the Point representation... But not with anything more complicated.
That's one of the points he made. When you have more than 3 things in a tuple, make a class/struct. I'm personally sick of creating 2-3 property classes just to be able to return 2 ints at the same time. Also, after playing with F# a little, I really like those changes in C#
@@Qrzychu92 Usually, when I return set of values, it has some meaning, therefore I have no problem creating dedicated type for it. Especialy with the help of R#. On the other hand, I would definitely rather use tuple than KeyValuePair. Yuck ;)
@@SebGruch My favourite example is working with sets. For some reason, they are like the only non mutable collection in C#. When you have parsedItems and remaingItems and other sets with groups of items from various sources. I know, you will say "use list instead", but sets are good for some operations, like cross section, exlusion, etc. Then you either use two ref arguments (which becomes ugly if you need to pass them few levels down) or just return a pair. Yes, you can always make a class to hold the state, but sometimes it feels like a huge overkill. On top of that, you don't have use use the tuples if you don't want to. They added them so we CAN use them, not HAVE to, no one is forcing anyone to do anything. It's not Elm :P
@@Qrzychu92 Well, unless you encounter a code where someone used this heavily ;-) And I understand what you mean about this set usage - I didn't like being forced into such resolution either ;-) Perhaps I'm too many years into "procedural" coding to feel comfortable in functional execution of control...
You can actually name your tuple members like so (example): (int x, int y, double distance) You will get intellisense support when you will use the tuple.
Just bullshit that doesn't provide real value. Language doesn't need tricks.... Look at e.g Java it grows because it was addressed for industrial, no one cares that working on spring was a nightmare, or golang this is pure language to solve real problems, great for microservices, make by engineers for engineers. Only Linux matters!
I find it hard to believe that you are watching this video within a day of its release and you don't know you can use the microsoft stack for these purposes... what am I missing?
@@Rsharlan3 Are you trying to say operator overloading was a good idea? It wasn't. This feature specifically was the cause of the downfall of Smalltalk. At least Sun learned a lesson unlike MicroCrap.
Thanks so much for this - C# is constantly getting better and better!
The unique problem of this video is the fact that I can like one time not more ... Awesome lecture!!
Great presentation! Thank you.
We need more such videos with C# getting new features in new releases.
Start at 4:50 if you are impatient.
thanks
I'm patient
Thank you
Haapavuo i am, but i am also tiredof MS bloviation
Great examples and good presentation - thanks :)
Great view on programming languages, THX!
Somehow APL will always feel like write-only programming. "We will make reading insanely hard because nobody likes reading other developer's code..."
OMG! Tks for good presentation :)
Just when I thought I couldn't love that language more than I already do....
@xOr Irrelevant. Why do people who like Python pop up everywhere, jeezes.
I think it looks even better like this:
public override bool Equals(object? obj) =>
obj is Point otherPT && this == otherPT;
But in term of readability, it's not better :D
In my head it sounds as - the object is of the same type AND "this" equals to that casted object.
@@leinh4245 In readability I think "A && B" is more readable than "A ? B : C"
@@leinh4245 Everything in the expression is a direct transfer from the thinking behind it: "it is equal if and only if the other object is a point and that other point is equal to this point."
I wish I could see this a little earlier.. This is an awesome demonstration of neat code. A code that looks beautiful at same time little hard to understand which serves the purpose of abstraction. I really love it.❤️
Thank you NDC!!!
This is literally the first time I've watched a programming speech where the guy speaking ACTUALLY had a personality and a sense of humor. Thank you Bill Wagner for not being dry, and for showing that not all programmers have the same personality.
Stop watching noob tutorials, and start watching conference talks and pluralsight courses then. Lots of personality.
Kevlin Henney has a ton of useful knowledge and lots of good humor, IMO
I used to do mapping/lookup logic similar to 41:50 with Dictionaries; where what you check against is the key, and the result you want is the value. 🙈 Which is runtime-configurable, but obviously way slower to execute. Nice to know about this compact switch syntax.
You might be surprised how fast Dictionaries are. I've found that a Dictionary is quicker at returning an item with a string key than looping over a list of just five or so items looking for the same string key inside the value (even using for-next rather than an iterator). It seems the hashing function for strings is very quick and beats a string equality test after just a few iterations.
Granted the switch statement's jump tables are likely to be even more optimised, but my point is that a Dictionary might not be as slow as you think depending on what type your key is. A Dictionary is likely to be quicker than a set of five or more if-else branches that test strings - although ideally you want to initialise your dictionary only once if you can.
Pattern matching is great escape from nested if else conditions
I love how Functional programming is seeping in C# and making it more and more mainstream.
It's a fashion trend and it's dumping a veritable shit ton of barely legible code into the world. It's a nightmare that we are all going to have to suffer for. But then all single paradigm advocates generally write god awful code.
@@sacredgeometry I agree with this comment. At this point they should be pointing ppl to F#. Some of this stuff is getting out of hand now.
Tuples, immutable data structures, pattern matching, null safety, avoiding inheritance hierarchies, ...
He basically made a case for functional programing without mentioning it a single time.
I guess, but the way I see it it's moreso advocating for the best of both worlds. C# is still clearly OO even with these additions, but this extends it beyond that
OOP at the higher levels, functional everywhere else
You can see F#’s influences here.
Yes and no, even OOP languages have always advocated not to go overboard with inheritance and to use it only when it makes sense. Quite a few prominent names in C++ (including its creator) have taken that stance from the get-go. It's a useful tool, IF used as intended. Problem is, some people go overboard and start inheriting everything from everything, even when it makes no sense and will only cause problems. Null safety is also not a solely functional programming paradigm. etc.
Let me ask a question: what is a program, unless pure imperative, if not a collection of functions?
An object is just a collection of variables and functions after all.
Object Oriented Programming is a mouthful way to say that those functions and variables belong to a class, and it helps to describe behaviour and intention.
There is really no "functional vs object" paradigm in a program, unless you want to start a flame. Everything is compiled in a neat sequence of operations, and function calls.
Beautiful!!
Thx for the tips. Quick tips for the speaker: Shift + Delete to delete entire row. Alt + Up arrow to move a row up (no need for copy paste)
And "Insert" keyboard key for replacing one letter/number for another :-)
actually Shift + Delete, cuts the entire row, if you have something in your clipboard you'll loose it (Y)
And turn off night mode when doing a presentation. That orange hue makes it difficult to read on smaller screens.
GREAT!!! BRAVOO!!!
Very nice! I actually hated tuples earlier, because I always thought: Why not just create a new class? But the way you are using tuples here is a lot different from how I thought you were going to use them! Very nice examples!
Thank you for this talk, you make me LOVE tuples !
ooh my god, it changed my mind
!!!
I can't say I'm very comfortable with the idea of allocating two or more Tuples every time you want to do a simple allocation/comparison. Would be better to just change that point class to have one field of type Tuple and compare them by left.tuple == right.tuple.
Point is a struct in the example, so if it allocates it is going on the stack and not on the heap. My guess is there will be some optimizations done in those simple methods but I am also curious if there is a performance cost to the tuple approach. Especially the equality code is a lot more readable though, so that might be worth it in some cases.
@@Eldering the compiler is smart enough. You can play on SharpLab: sharplab.io/#v2:D4AQTAjAsAUCDMACAzgFwE4FcDGrEGFEBvWRMxASwDs8APAblPOrwE9GZzEECAKFxLQA0lGolYBKYky5leqABYVkAOmGJFylZMQBeRL3WSOXAL4zEFniAgA2RACMA9k4A2iJwAcApugCGqE7oerq8hK4ihOhSugB8Bq5qIok6uvq86EmImcZWSDb2zm4ePv6BwQCEoeGR2THxvInqKVJVBpnqORIm5HncACyIAMoA7n6evFIknLJyRjEGrCK03RbmMKZAA==
Its funny how every new feature added takes from F#.
I would laugh, but that's far too true.
@@londospark7813 The next feature will be making semicolons and curly braces optional, you'll see.. then they'll discuss the new and exciting world of currying parameters 😂😂
well except with tuples i think primarily python.
Modern languages like to include functional programming features. Everything that was presented here made me think that C# wants to be like Rust with runtime checks.
Yeah, but seriously, I want F#'s try-with expressions in C#! I've always hated exception handling in Imperative languages
Is there a single line expression for ensuring none of the values within a tuple is null?
At 25:40 it really bothers me that he didn't do
=> obj is Point otherPt && this == otherPt;
I think the Point Distance property is wrong. Since it is initialized to default, HasValue will always be true so the real value is never computed. It should be initialized to null I believe
I liked new features. (:
I do think that the discard assignation to check null state is much worse than just doing a if(foo == null)
In my opinion 'discard assignation' looks hacky.
if (partner == null)
throw new ArgumentNullEx...
Is cleaner
It's my understanding you really should use if (foo is null) instead of == in the off chance the equality operator is overloaded.
Discard assignation is hacky and unreadable as fuck. An assignation should be to assign something.
The case presented would be way more readable as pattern matching in c#8, and then write null explicit instead, like this:
public string HyphenateForPartner(Person partner) => switch partner
{
null => throw new ArgumentNullException(),
_ => $"{partner.LastName} - {this.LastName}"
}
A ternary-like form would be better IMO:
foo is null ? throw new ArgumentException();
That underscore syntax is an aberration.
Yeah, I don't like the assignment to discard operator either. After all, the result of an expression is already discarded if you don't assign it to something.
So, I'd prefer just:
partner ?? throw new ArgumentNullException();
but that doesn't compile.
Is the code available anywhere?
Does C# have feature like Scala case class (with immutable auto constructor/getters/setters)?
C#9 is going to introduce records, which do these things out of the box. Otherwise, you can approximate some of this behavior already with structs and classes.
What do you think about using underscores for private fields in a class?
According to Microsoft naming conventions we shouldn't use it, but I see many examples where it is used and even in this video at: 26:32.
Microsoft recommends to always use underscore for private fields, maybe you mean C++ style prefixes like s_ for static fields?
Microsoft publicly encourages this.x, but they internally use _x for whatever reason
36:56 What might be a use case for chaining switch statements? The result you want (ie a function is returning) is in the last switch statement. Why would one prepend various other switch statements?
for example you could replace the tuples form the tolls example with nested switches. Would be usefull if you had to take into consideration for example mass of the vehicle, but only when inbound in the evening on the weekend, otherwise mass would be irrelevant. You just have more options :)
@@Qrzychu92 he could show using "when" on switches
11:56 could someone break down, a bit more than he did for a noob, the order this happens/why it works. It seems to be taking the expression on the right, and storing the results without coming back to them, then looks at the left and assigns the results.
but my question is, did it do that because it's a lambda, or because it's a tuple?
He is basically saying that it works because that's the way they wanted it to work. Internally it is creating a copy of the properties before assigning them back so that it doesn't loose one of them. The real question: it is a behaviour of the tuple. In case you are interested, that is an expression body function, not a lambda, just the newer syntax for defining functions that contain a single expression with => operator rather than enclosing it in { }. They look quite similar, I think it was inspired by the lambda syntax
It works because of tuples and desctructuring. As of C# 7, some types have a method called Deconstruct on them, ValueTupe (which Wagner is using in the example) implements the Deconstruct method. When a type implements Deconstruct it allows you "unwrap" the fields of that type directly into variables:
var (x, y, z) = myObject;
is the same as
var x = myObject.x;
var y = myObject.y;
var z = myObject.z;
If x, y, and z already exists:
(this.x, this.y, this.z) = myObject;
is the same as
this.x = myObject.x;
this.y = myObject.y;
this.z = myObject.z;
In Wagner's example, the right side of the equal sign stores this.Y and this.X in a tuple. The left side then deconstructs the just created tuple into the two existing properties this.X and this.Y
You can read more on deconstructing here: docs.microsoft.com/en-us/dotnet/csharp/deconstruct
34:12 When you have come so far, why do you not also discard the discard? The assignment itself is superfluous and confusing. A simple *partner ?? throw Exception()* would imo be much more concise
I guess the mechanics behind it requires an assignment. I think we need something like partner ?? ? throw Exception()
You're in a context that expects statements, a null coalescing expression is not a statement by itself, but it can be made part of one... Such as a an assignment. I think this looks alright, but code reviewers may label it as an antipattern due to their own preferences, so having a general helper in the project like
ThrowIfArgNull(object arg, string nameofArg)
is probably much more widely accepted. This can be done without newer C#-features.
Correct me if I'm wrong on something.
How about the ??= operator?
When you switch if statements to expressions if an exception happens it’s hard to tell what part of the expression is causing the error, so you might want to factor back to if statements sometimes.
You can debug line by line
I am of the opinion that we should be able to specify that certain objects be allocated from a private set of (OS) pages. When disposed, the entire set of pages is recycled, no need to check if any other object has allocations within those pages. sure, some memory is not used?, but we have memory, it is garbage collection that kills. SQL Server and other established database engines are highly robust in being able to run for very long times because the make extensive use of fix page sizes, which can be easily recycled. We might want the ability to specify certain page sizes (4KB, 2M, 1GB etc)
although I agree it would be nice to have more control on how things are put into memory I don't see this as something they would put in C#
Are you talking about object pools? Cos pretty sure they exist
I had not known about object pools, so thanks
the Microsoft documentation says it is a mechanism (pool) for handling objects that are expensive to create or destroy.
what I am talking about is making sure the virtual address space can be recycled easily. Even if allocations are mostly released, there is no guarantee that a large contiguous block can be reused, hence new allocations occur beyond the previous.
28:25 - newb question here - I love this use of ArgumentNullException but... can I just use reflection rather than having one of these for every single property I might use?
Reflection is pretty expensive and not supported in some contexts. One solution is to have code that assumes nothing is null, and that forces null pointer exceptions to appear sooner, rather than being passed down through a call stack, but there are drawbacks to that as well.
@@CzarZappy Or use Option/Maybe monad data structures that forces you at compile time to acknowledge the nullability of a reference type before accessing its value.
@@disklosr This is great if you are using C# 8, but if you are doing C# development in Unity, you are stuck with C# 7.3 for now. Also, my answer was in response to the question "can I just use reflection rather than having one of these for every single property I might use?", and addressing the reflection limitations for this use case to show the name of the null parameter given. Your suggestion is another solution to identify that a given parameter is null, but not what property name to report out.
sooo, the beginning is just what you should do anyways already, right?
Not buying that HyhpenateForPartner example, you could have refactored in a similar manner with a null check without discards and it would be more readable imho
Glad he didn't use underscore prefix. "This." is a little verbose but only appears once. The underscore appears every time and doesn't tell me anything I need (unless I'm violating single responsibility).
When exception happens I want to have all the parameters value in stack trace. Is it possible?
Somehow, but it costs.. with IntelliTrace in VS Enterprise
no, not really.
void Foo (Class value) {
value = null;
_ = value.ToString();
}
by the time the exception is raised, the argument may not exist.
Worse, the argument may have changed.
What's the cost of creating tuples?
It would be nice if we could know the performance impact of all syntactic sugar.
ValueTuple is a struct so there are no extra allocations, but it is a mutable type, so there may be some overhead in more complex cases.
@@connorboyle2092 Okey, nice. I'm also wondering if the logic of doing comparisons between tuples is more costly than simply doing a normal equality check.
@@WorstDeveloper yes, costs more. It uses the default equality comparer for each type.
(X, Y) = (Y, X), beautiful
As this is Core, does that mean the Windows version of .Net is no longer being updated?
Channel Dad Bryon Lape it’s still getting regular updates mostly for security reasons. Right now I think dotnet framework is on version 4.8.something. However, Microsoft is transitioning a lot of their new features over to dotnet core
@@ezzypoo7909 Thanks. That's what I thought, just wasn't 100% sure.
Can we do -
public override bool Equals(object? obj) => (obj is Point) && this == obj;
Lightbringer No. if you do like that, the type of this will be converted to object implicitly, and your statement will be a referential comparison.
I think you can do - public override bool Equals(object? obj) => obj is Point otherPt && this == otherPt;
This stuff is too high for my beginner ass...lol hopefully after a couple of days I can come back to this video and actually understand what this guy is saying.
I'm looking at some of those statements as they are being typed and I'm completely blank about their meaning. This language is becoming more and more like C++ which was originally referred to as a write-only language because once written nobody could ever read and understand it.
If you follow best practices, then C++ is perfectly understandable. Don't blame a language for programmers thinking they're being clever by being obtuse.
@@stysner4580 That's literally what I just said, not the language's fault if its features are mishandled, or conventions are not agreed upon across an entire team. Hence why I said: 'programmers thinking they're being clever by being obtuse'.
It's definitely becoming C++-ish in the sense of adding more features, but contrary to popular belief, that's a super minor issue (if that's an issue at all).
You can easily exclusively write C++11, or C# 7.3, and make sure your compilers and teams follow along. People do this all the time.
The real issue with C++ in this case is that the language is old and at the same time, not stuck in time like C. It precedes many modern programming language design good practices and in many cases, C++ was even the first to introduce them to the mainstream community. The consequence of this is that preexisting rules in the language form weird and unintuitive outcomes when used in conjunction with newer features. C# is very immune to this, much of the language is explicit and most of the new features are just shortcuts to things you already do. The only drawback of using them is that you need to keep up and if you don't want to use them, you can choose not to keep up.
This is some nice sugar and all. However, I believe maintaining code is all about making it readable and understandable.
Is a constructor made with a one-liner tuple really more readable and understandable than a conventional one?
So
public Point(double x, double y)
{
X = x;
Y = y;
Distance = Math.Sqrt(x * x + y * y);
}
vs
public Point(double x, double y) => (X, Y, Distance) = (x, y, Math.Sqrt(x * x + y * y));
It's not even like the tuple alternative is faster to write or has less characters. You might as well have written this:
public Point(double x, double y) { X = x; Y = y; Distance = Math.Sqrt(x * x + y * y); }
And be honest - you know people are gonna one-line the shit out of tuple constructors and the like, so it will really inspire to some great! horizontal scrolling.
My experience with tuples is like: "lets create this anonymous type using a tuple and use it as a dictionary key because i'm too lazy to create a proper struct for it..". Let me tell you right away. This does not create readable code!
So yeah it's nice sugar and might be useful in some situations, but i haven't experienced them yet from a production-code perspective.
when i see => (A, B) = (a, b);
As soon as I see the first open paren I know it is initializing props and nothing more
but the interviewer is probably using .net 3 :(( lol
Waiting in anxiety from 24:26 till 26:22 for him to bring up the logical AND operator... and getting disappointed in the end
Same :-/
He wanted to demonstrate the new feature, but I hope you understand how hard it is to come up with good examples for these features.
10:10 Do you really need a != Operator?
If you implement the == operator, you must also implement the != operator. However, it can be implemented simply as !(left==right)
@@MulleDK19 _sometimes_
42:19 i know it's a demonstration of the language feature, but the hard coding of business logic parameters makes me feel uncomfortable
Adding readonly to getters and certain methods just looks like const-correctness from C++, or is it just me?
It still bugs me that you can set readonly values multiple times in the constructor.
@@someguy3176 You can write your own setter that allows only one-time assignment
@@GeorgeTsiros True, but it seems silly since the keyword "readonly" implies that it would already do that.
@@someguy3176 the keyword "readonly" means something. It does not mean "this may only be read, not written".
Maybe i should learn F#
FC#
There's missing "Umple" and "Kotlin" language features to have an even cooler name... :D
Note : C# is doing great on taking inspiration at finests, be it F#.
11:17 how wonder what's the efficiency...
Test (run over 100 s):
Temp: 91.231.584/s
Tuple: 88.273.078/s
I knew it! It's 3.3% slower! The tuple method is garbage! :P
(It still depends on the type of code you need to write, 3.3% is not that insignificant)
29:44 hyhpenate
Jetbrains Rider is 10 years ahead of Visual Studio. They've been doing static analysis of code for years now.
I have to admit that I was not impressed with the talk. The language features are fine but the way they were presented did not sit well with me. Lots of talk about reducing the number of lines of code but the way the reductions were made was mostly due to syntax (remove braces, use ternary syntax etc). Is it better? I do not think so. The usage of throwaway variable _ to throw an exception when parameter is null was also a weird example. What is wrong with having 'if' statements? I never had problems reading code with if statements and i would always need more time to grasp code which uses ternary or null coalescing operators.
@Karm Asutor You guys are absolutely spot on, give me an if statement in any language and i know instantly what i'm doing. Give me some language specific syntax and I then have to figure out the 'ins and outs' of that. Somehow its becoming more and more complex in its simplicity...
This reminds me of some old code I came across recently. The code was messy and virtually impossible to read and had to be rewritten. Having a simple if check and some {} is so much more readable and in my opinion therefore better.
I assume the throwaway variable was designed primarily for destructured variable assignments. Does it have any other intended, intuitive, or especially helpful use cases?
agreed. but if some new syntax become very popular (due to it`s usefulness) and made it`s way to other languages, it will make other`s life easy as well. but to do that one must made up some syntax as well.
If you use an if statement, then I’m going to ask you to refactor it in the code review. Logical branching is the quickest way to introduce unintended side effects.
✌️
26:00: => obj is Point otherPT && otherPT == this;
21:45 Should pull the opt out feature forward... Such a waste of calories the whole NRT fiasco. 22:50 Do not care about "potential errors", speaking as a business leader and architect, I care about REAL errors, and not dumbing down my crew by failing to engage the issues at hand. 23:30 Y'all had a sweet spot in the operators a version or two ago. That was plenty sufficient to reason about the "null" question. But if there's really this aversion to the concept, why not just remove null from the language spec altogether? Of course that would be absurd as well, right?
So... case in point. That was a lot of verbiage justifying *object?* , then turn around and simply leverage existing operators, with I will grant the updated *is* operator.
I got diabeetus from all the syntactic sugar
why is it brown tho
Solar theme
I thought he had nightshift mode on (or similar)
Can someone explain to me if there's a new shortage of disk space on the horizon? I understand why a C programmer in 1988 had to write shorthand. But nowadays? Today a junior programmer gets his code rejected if s/he starts writing "for (int i = 0;" instead of using a meaningful name for "i" that tells me what "i" actually is.
Using a tuple as a short-hand assignment for two variables doesn't make the code anymore readable or understandable. The same goes for that awful new "if" syntax that they introduce with C# 8.0.
The pattern matching at the end is fancy, but in my opinion is an absolute waste of time. From a maintainability standpoint I have no idea why switch expressions were prioritised over switch ranges, they actually would make a difference to people like myself who have large volumes of code to produce with little time to make beautiful before moving onto the next job.
tuples are great until you realize the compiler still creates just as much code (pretty much identical code to long form) and you give up readability. When did readability stop being a priority?
I don't know. Why not instead start with data that shows where problems most happen in code, and why the C# team chose to address or improve those?
From my perspective, when you're in an enterprise software company, with thousands of people, deadlines, cost concerns, developers on the same team located all over the globe... I'd want to see things you've enhanced and demoed that specifically address data-supported real-world issues rather than what appears to me as the C# team brainstorming about what can be better. These improvements.. maybe someone new to C# will get excited, but not so sure about the people in the trenches.
Also, I played this at double-speed on UA-cam... we are techies... get to the point!
Content seemed a bit week, and i had to play back at 1.75 and one point i was playing back 2x speed. I know vid cant know what you know and then be targeted but boy was i hoping this was something cooler than it was. the vid should start with what the content is... like some syntax rubbish and nullable types. Perhaps im too hash but ish i was hoping for more. this could of been a 5min vid if that maybe a 2 min vid.
it sounds not cooked well - You get a feeling that you are thrown into aaaa multi dimensional vector space
it is like = c# + python + something - discard => return your addres to us neil armstrong
Change your habits: hyhpenate your code
Readability of these new features is bad. In your private code sure its fine, but when working with a team you need to consider juniors and all the devs still to come. Shorter is not better... the very simple code syntax may be more verbose but everyone can understand and read it. Also having more ways of doing the same thing adds many different structures to your code that increases cognitive load.
IMHO, I think the industry is straying into the weeds...
The original purpose of programming languages was to make a way for humans to communicate with machines, where more of the burden was on the machine to adjust to our way of expressing things, rather than the opposite. The "features" shown here look more like humans being asked to communicate more like machines! This seems really backward to me, especially considering that in many cases, the human devs are building systems like Siri, Alexa, Cortana, etc. to make the machines communicate more like humans, but the devs themselves get no such benefits... : b
So now, instead of making code that is A. accurate, B. clearly understood and C. easily maintained, we seem to be consumed with making code that is D. most clever (inscrutable?), E. most likely to impress our peers and F. as concise as possible. Not a good trend that I'm seeing...
> when working with a team you need to consider juniors and all the devs still to come
Preach it!!!
> ... having more ways of doing the same thing adds many different structures to your code that increases cognitive load.
totally agree
Only thing modern is pattern matching, other just new syntax to do old things
Geez. Why not write some Haskell-to-.NET/CLR compiler and be done with it already? The language envy of all this drip... drip... drip... adoption of ML features is maddeningly apparent.
Before F# was created, there was an effort to do that very thing, but the type systems were not compatible enough to make it work. And then, work to create F# began.
fsharp.org/history/hopl-draft-1.pdf
As a python developer, trying to learn C#, seeing this... I'm like: "did C# really just invent tuples? and it blows their mind?!" haha
Most expert C# devs I know hate using underscores (_), now you are forcing their use? I do like the `switch` `tupple` code... also... `inbound` should be `isInbound`
Its good for their intended use, like discarding out parameters.
For pattern matching, Id prefer default => instead of _ =>, but whatever its short and if you know the syntax its nice.
I am changing my habits, after C# since it's inception, I am moving to Java. It's C# without all the extra bs
does it run faster? no so stick with what you're comfortable with.
Yo dawg, i made a touple out of touples
Aka "multidimensional touples"
I really wish .NET gets its Kotlin...
Do you mean F#?
@@someguy3176 No.
Sorry but these examples are actually harder to read and harder to understand. Having less code does not make it more readable in these cases. The original code was easy to read. The new code just jams everything together in a mess.
Many of these examples are more about avoiding side effects. Both goals are important and it can be a difficult balance.
"So good afternoon"
Oh man, bad start.
i am sory but this makes me have anxiety:
if (bla bla)
return apple;
else
return lemon;
instead i would write:
if (bla bla)
return apple;
return lemon;
why would you put "else" everywhere
Well, I was hoping to learn something new here, but instead I got nearly half an hour about creating a dumb struct holding two doubles. And even though it's that simple, the implementation is broken (by design!) because of the cached distance. And it doesn't even have a ToString method!
In a sane language, something like that should take approximately three lines of code and should be obviously correct.
he skipped the most urgent upgrade - fix those braces....
wow, tuples! so advanced! how about a fucking proper Hindley-Milner?
Readonly feature... LOOOOOKKKK: Now we have a "const" modifier like the we had in C++.
It's amazing to see how languages evolves to become more and more close to what C++ always was.
yeah, but the const feature of C++ was the most useless thing ever. You annotate one thing, then you have to annotate 20 files. Then someone just makes a cast to not const and it's worth nothing
Y'all do yourself a favour and watch back at either 1.25 or 1.5x speed because as cool as it is to learn new stuff. It is really dry.
Syntactic sugar taken from Python and VisualBasic.NET 1.0.
Why is there so much obsession with reducing code size? Less code doesn't mean it is easier to read or that performance is better. What is next, will we change reserved words and start using € instead of public, ° instead of class etc, just to save few chars?
@wubs23 I worked for 5 years mostly on developing file parsers / converters (xml, gml, xls and custom formats from measuring devices) and never had situation with 50 lines of ifs. I think that the best way to achieve code comprehension is to extract code to methods that are named correctly and document what is going on. When I review someones code, first thing I do is go thorough it quickly to understand the flow. If I stop and have to think what someone was trying to do, then sorry but I will not approve it. You should always be explicit and avoid stuff that do things automagically.
@ Exactly! Dropping out a few ifs and having an even more terse syntax does NOT make things more readable, and so just makes it harder to maintain and actually keep working right. Having decent methods to lay out the calls into something that makes logical sense is 100% more important. I totally agree with you.
I don't think reducing code size was the design team's main goal (tuple syntax excepted perhaps). Instead, it looks to me like they've started to prioritize expressions and patterns over statements.
@@declup, you may be right, that may be what they are doing, I don't know... But who has been asking them to prioritize expressions over statements??? I've never heard a coworker asking for such a thing. I have never asked for this, either.
you still don't see it?
Typical. Saved a few characters and made the code cryptic. Code should read like a book! It should tell a story. That code is shorter, but it does not translate into words. I would never write my code that way. Maintainability is as important as anything else.
That is the main problem with new "cool" features - they takes less time (less costly for companies) but code became less readable.
@@igorthelight, I totally agree. However, they don't really take less time or save money for the company when you consider how much resource goes into trying to debug cryptic code...
@@toddhoatson5758 Agree.
So it's just looks more cool then - nothing more :-)
It’s about following functional programming principles in an object oriented language. You’ll have less bugs, but the code does end up looking a bit awkward.
swift and kotlin are so much more powerful in 2019/20, think guard let. the null check in c# still looks awful
Maybe.. but how many Guard let pyramids of doom are out there? C# is still more powerful in many areas - e..g. Linq and database frameworks considering those were introduced back around 2008 in c#. Core Data is nowhere near as good.
Returning tuples? This is the single major thing why I'm not into functional languages. What does it mean at all: (int, int, int, double)? Totally useless, and waste of time figuring it each time you encounter such thing. Perhaps fine with the Point representation... But not with anything more complicated.
That's one of the points he made. When you have more than 3 things in a tuple, make a class/struct. I'm personally sick of creating 2-3 property classes just to be able to return 2 ints at the same time. Also, after playing with F# a little, I really like those changes in C#
@@Qrzychu92 Usually, when I return set of values, it has some meaning, therefore I have no problem creating dedicated type for it. Especialy with the help of R#.
On the other hand, I would definitely rather use tuple than KeyValuePair. Yuck ;)
@@SebGruch My favourite example is working with sets. For some reason, they are like the only non mutable collection in C#. When you have parsedItems and remaingItems and other sets with groups of items from various sources. I know, you will say "use list instead", but sets are good for some operations, like cross section, exlusion, etc. Then you either use two ref arguments (which becomes ugly if you need to pass them few levels down) or just return a pair.
Yes, you can always make a class to hold the state, but sometimes it feels like a huge overkill. On top of that, you don't have use use the tuples if you don't want to. They added them so we CAN use them, not HAVE to, no one is forcing anyone to do anything. It's not Elm :P
@@Qrzychu92 Well, unless you encounter a code where someone used this heavily ;-) And I understand what you mean about this set usage - I didn't like being forced into such resolution either ;-) Perhaps I'm too many years into "procedural" coding to feel comfortable in functional execution of control...
You can actually name your tuple members like so (example): (int x, int y, double distance)
You will get intellisense support when you will use the tuple.
The madly brush immunohistologically plant because basketball macroscopically object minus a material lettuce. endurable, mysterious observation
Just bullshit that doesn't provide real value. Language doesn't need tricks.... Look at e.g Java it grows because it was addressed for industrial, no one cares that working on spring was a nightmare, or golang this is pure language to solve real problems, great for microservices, make by engineers for engineers. Only Linux matters!
Wake me up if you can use C# to tackle 3 of the most important segments - webapp, smartphone, and IoT devices
webapp: dotnet.microsoft.com/apps/aspnet/web-apps/blazor
smartphone: dotnet.microsoft.com/apps/xamarin
iot: github.com/dotnet/iot
I would also add distributed segment : getakka.net/
Wait, you really thought you can't use .net for that? Really?
I find it hard to believe that you are watching this video within a day of its release and you don't know you can use the microsoft stack for these purposes... what am I missing?
Seems to be a Java fan which works EVERYWHERE :)
Hate when people shorten code... Source code is for humans to read. Not computers.
Java > C#
public static operator> (Lang lang1, Lang lang2)
{
return lang1.Age > lang2.Age;
}
@@Rsharlan3 Are you trying to say operator overloading was a good idea? It wasn't. This feature specifically was the cause of the downfall of Smalltalk. At least Sun learned a lesson unlike MicroCrap.