|
But you understand it! 
|
|
|
|
|
Completely agree...
Many of the new features to the Microsoft .NET compilers, to me, are completely unreadable.
This all started with generics and LINQ years ago, when they introduced the caret as a compiler symbol.
With code,they have made it ambiguous while with LINQ, they turned SQL upside down.
What is the purpose of all this? To show that you can make programming as difficult as rocket science?
I never use any of these features and stick with the "old ways" of writing code. It is much easier with little to ambiguity.
So what if you save a few milli-seconds here or there. Who cares?
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
I really like that you mentioned that.
Just yesterday during a live coding session another dev was showing me how to do a thing.
He used a C# anonymous function / lambda expression and was trying to get it right (and this was his code) and he was typing, backspacing, typing, backspacing...waiting for intellisense, typing waiting for intellisense...
I was like, "yeah, functional programming...no one can remember the syntax..." We both laughed. 
I mean regular old OOP and structured programming is really easy to remember and type actually.
*youngster waves fist and starts..."Old man...!!!"
I know. 
|
|
|
|
|
raddevus wrote: *youngster waves fist and starts..."Old man...!!!"
... older man smiles silently: APL 
Mircea
|
|
|
|
|
In the words of Kernighan - everyone knows that debugging is harder than coding. Therefore if you are being as clever as you can be when writing the code, you will have no chance of debugging it.
|
|
|
|
|
|
That is one reason I never liked to program in Unix. The Programmers wrote code that was that was terrible to understand, even for C programming. Compared to writing C for MS or PC DOS where the code was understandable. I can see why Unix has been called a "write only operating system" and why other coders who read someone else's code will call it crap.
|
|
|
|
|
You can't 'program in Unix', Unix is an operating system not a programming language. The point of compilers is that you can write code that will run on multiple systems. Grep can use the same 'C' code for MSDOS or UNIX or RT11.
|
|
|
|
|
Maybe I'm the odd one out but I don't see the issue. It's an expression syntax instead of a statement syntax. Not to mention this syntax forces an expression as the body of a case section so if your intent is to return something then that is enforced, whereas the statement syntax doesn't care. I feel like it's the same difference and motivations between the ternary operator ?: and if-else. Expression vs statement. Something simple that yields a value vs something possibly complex that may or may not.
Also you save space. 6 lines vs 15 lines 
string x = "test";
int y = x switch {
"test" => 0,
"test1" => 1,
"test2" => 2,
_ => 3
};
int z = -1;
switch (x) {
case "test":
z = 0;
break;
case "test1":
z = 1;
break;
case "test2":
z = 2;
break;
default:
z = 3;
break;
};
|
|
|
|
|
Jon McKee wrote: Also you save space. 6 lines vs 15 lines
If it's line count to want to save, you can write:
int z = -1; switch (x) { case "test": z = 0; break; case "test1": z = 1; break; case "test2": z = 2; break; default: z = 3; break; };
Nothing succeeds like a budgie without teeth.
|
|
|
|
|
Readable line counts are what matters. Most software, including the Windows 10 source, could technically be represented on a single line (get wrecked Python nerds  ).
Also, and I might be a pedant, but I'd say this
int y = x switch { "test" => 0, "test1" => 1, "test2" => 2, _ => 3 };
is way more readable than this
int z = -1; switch (x) { case "test": z = 0; break; case "test1": z = 1; break; case "test2": z = 2; break; default: z = 3; break; };
since it has fewer columns, reads much like an array initializer syntax which is common in modern languages, and due to the restrictions on the expression syntax the case body is a relatively constant size (a compound scope isn't allowed like with the statement syntax).
modified 11-Jun-21 6:04am.
|
|
|
|
|
Jon McKee wrote: (get wrecked Python nerds )
People who program in Python cannot be classified as nerds. Nerds are smart.
Nothing succeeds like a budgie without teeth.
|
|
|
|
|
I used to feel the same way until IntelliJ IDEA showed me how to reduce a block of code to a single line using similar obscure syntax. (much to my surprise!)
The Lounge[^]
Get me coffee and no one gets hurt!
|
|
|
|
|
Cp-Coder wrote: Tonight I will have nightmares of vicious IDEs chasing after me to correct all my many mistakes!
Kind of mandatory[^]
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Because doing something guilelessly makes a person appear to be much cooler.
|
|
|
|
|
IMO, because doing something guilelessly makes a person appear to be a bad engineering example.
|
|
|
|
|
Dennis Ritchie will haunt them.
|
|
|
|
|
We're saving people that think they know better from ever bothering with the nonsense.
Whether or not they're correct is another matter.
|
|
|
|
|
ELI5
Anyone care to explain ?
it looks like a switch.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Personally I find that 1000x more readable than switch/case or if/else, and also tells me if I haven't implemented the default option, so more robust code.
|
|
|
|
|
Terseness is the enemy of clarity. All programmers need to remember this. Programmers who use languages that encourage terseness need to be extra careful to not destroy clarity.
|
|
|
|
|
It's part of the "how much can I pack into one LINQ / SQL statement" school of obfuscation.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Chris Maunder wrote: Are we really helping the Art with this type of syntax?
No.
There seems to be a modern prejudice against classic iteration (for, while) and conditionals (if). Somehow writing these same constructs as imperative statements is "more robust" and "less error-prone". Any construct that introduces a nested scope seems subject to this prejudice. Those imperative statements are only syntactic sugar supplied by the compiler.
I have a hard time liking the new features in the last couple of major versions of C#. Most if not all of them seem to be this sort of syntactic sugar, and they don't really add new functionality.
The features that make the most sense to me are those that let you omit specifying a type where the compiler can figure it out from context. That saves typing (even with IntelliSense) and time.
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote: Those imperative statements are only syntactic sugar supplied by the compiler.
I see this argument a lot, but you do know for is just syntactic sugar too, right? Same with references, same with try-with-resources, same with lambdas, same with properties, same with typedefs... I could go on for hours. Most of the features of modern languages are just sugar. The real litmus test is whether that sugar is useful to add clarity, simplify a common use-case, etc.
|
|
|
|
|
I suppose I could code in IL directly ...
Software Zen: delete this;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
