When did syntax become so fussy?
-
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 :cool:). 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).
Jon McKee wrote:
(get wrecked Python nerds :cool: )
People who program in Python cannot be classified as nerds. Nerds are smart.
Nothing succeeds like a budgie without teeth.
-
Paraphrased from Microsoft's own docs in order to make it readable
MyMethod(options => _ = provider switch
{
"option 1" => options.Method1(x => x.Prop),
"option 2" => options.Method2(x => x.Prop),
_ => throw new Exception($"Unsupported option: {option}")
});Are we really helping the Art with this type of syntax? I'm trying to work out what we're saving here. Keystrokes? HDD space? Screen real estate?
cheers Chris Maunder
You don't have nearly enough calls to libraries that have interfaces that reference other libraries, all using dependency injection and so on.... so that getting to the code that does the 2 + 2 is fully a dozen files deep in an outdated package that is no longer maintained.
-
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. :rolleyes: 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. :sigh:
-
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
foris 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 ... :laugh:
Software Zen:
delete this; -
Trying to save all the above, show how clever language designers can be, and burn out everyone else's brain cells trying to keep up with, and parse, all this shite.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.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
-
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.
-
Paraphrased from Microsoft's own docs in order to make it readable
MyMethod(options => _ = provider switch
{
"option 1" => options.Method1(x => x.Prop),
"option 2" => options.Method2(x => x.Prop),
_ => throw new Exception($"Unsupported option: {option}")
});Are we really helping the Art with this type of syntax? I'm trying to work out what we're saving here. Keystrokes? HDD space? Screen real estate?
cheers Chris Maunder
Cool kids like functional programming, so this is the new fad. Microsoft evangelists play for them.
-
Paraphrased from Microsoft's own docs in order to make it readable
MyMethod(options => _ = provider switch
{
"option 1" => options.Method1(x => x.Prop),
"option 2" => options.Method2(x => x.Prop),
_ => throw new Exception($"Unsupported option: {option}")
});Are we really helping the Art with this type of syntax? I'm trying to work out what we're saving here. Keystrokes? HDD space? Screen real estate?
cheers Chris Maunder
Sad to say, C# is beginning to look more like JavaScript. The readability is lower and with more linq expressions, it takes longer to understand what the code is doing. For true engineering quality code, it should be more readable so there is less wasting of time understanding it.
-
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.
-
Because doing something guilelessly makes a person appear to be much cooler.
The less you need, the more you have. JaxCoder.com
IMO, because doing something guilelessly makes a person appear to be a bad engineering example.
-
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.
-
Paraphrased from Microsoft's own docs in order to make it readable
MyMethod(options => _ = provider switch
{
"option 1" => options.Method1(x => x.Prop),
"option 2" => options.Method2(x => x.Prop),
_ => throw new Exception($"Unsupported option: {option}")
});Are we really helping the Art with this type of syntax? I'm trying to work out what we're saving here. Keystrokes? HDD space? Screen real estate?
cheers Chris Maunder
I always knew it would come to this. I can see the case for using lambda functions in certain situations but I always regarded their introduction into C# as a bad move due to their potential for abuse. Sometimes adding N dimensions of abstraction is not a good move. I mean, shall we all start doing maths in base 90 just to use fewer digits? How about we join together n to the power of p math opeartors into newer short-hand operators, just to make that calculus even harder to follow? Just think - one hundred lines of calculus could be comprised into a single line!
-
Paraphrased from Microsoft's own docs in order to make it readable
MyMethod(options => _ = provider switch
{
"option 1" => options.Method1(x => x.Prop),
"option 2" => options.Method2(x => x.Prop),
_ => throw new Exception($"Unsupported option: {option}")
});Are we really helping the Art with this type of syntax? I'm trying to work out what we're saving here. Keystrokes? HDD space? Screen real estate?
cheers Chris Maunder
cryptic syntax to programmers in other languages. that's why i don't like it. i always try to write the code in a style that is familiar to all languages. when as a pascal programmer i started using c it affected my future pascal code. when i got better at javascript it affected my future c code. this monday at work they told me to use this syntax for delegates (given
int add(int a, int b)):Func x;
x = add;instead of:
delegate int X(int a, int b);
X x = add;i prefer the later, because it's more language tolerant.
typedef int (*X)(int, int);
X x = add;type X = function(a, b: integer) : integer;
var x: X = add;
