About Syntactic Sugar

[gchling]

C# now has an increasing amount of syntactic sugar, which often makes the code harder to understand. The same functionality can be written in multiple ways, making the code difficult to maintain.
In any case, it is an undeniable fact that the abundance of syntactic sugar in C# makes it difficult for beginners to grasp the underlying logic.

[huoyaoyuan]

C# now has an increasing amount of syntactic sugar, which often makes the code harder to understand.

I don't know how people can call the features with wide semantic opportunities as syntax sugar. All the syntaxes are making code easy to understand, without the need to find the focus in a lot of boilerplates.

The same functionality can be written in multiple ways

This is a very basic trait for general-purpose language. If any construct has high utilization of same boilerplate, it can have a shortcut syntax.
For occasional cases like collection construction, the traditional syntax is too limited and verbose, and the scenario is too important, thus it worth some duplication for better experience for future users.

[colejohnson66]

What "syntax sugar" are you talking about? Just about every language feature since C# 2.0 is syntax sugar. Taken to the extreme, C# is sugar for IL.

[HaloFour]

Languages evolve to solve problems and simplify common patterns. That's true of every programming language still being actively maintained, including languages as old as COBOL, C++, FORTRAN, etc. The fact that there are multiple ways to solve a problem is a strength.

[TahirAhmadov]

There are some obvious duplicates syntax-wise, like int[] a = new[] { 1, 2, 3 }; and int[] a = { 1, 2, 3 }; and int[] a = [ 1, 2, 3 ];, but even removing the first two syntaxes is very difficult, unfortunately.

[huoyaoyuan]

The int[] a = { 1, 2, 3 }; syntax is really redundant. It only works in declaration statement, not any target-typed scenario. It also takes up the syntax of {}.

[jnm2]

It's consistent with collection initializer syntax for any IEnumerable collection with an Add method.

[huoyaoyuan]

I'm meaning = {} (when not in object initializer), not = new() {}. = {} is really unique for arrays.

[JoaoVictorVP]

C# now has an increasing amount of syntactic sugar, which often makes the code harder to understand. The same functionality can be written in multiple ways, making the code difficult to maintain.
In any case, it is an undeniable fact that the abundance of syntactic sugar in C# makes it difficult for beginners to grasp the underlying logic.

First, the point of syntactic sugar is to make the code [easier] to express and [understand], not to make it harder, and I honestly can't seem to think of one single example of a syntactic sugar in C# making it harder to read the equivalent before (feel free to point them).
Being able to write things "in multiple ways" is also not a problem, it is just the nature of any proper turing-complete language, you have infinite ways of expressing the same problems by writing them in slightly different ways. You just need discipline to chose a style and stick to it.
And it's also not the case that this abundance makes it "difficult for beginners to grasp the underlying logic", for one, a beginner just need to know what the basics of a language does, not everything. And once the beginner sees a piece of logic he don't understand he will simply ask to a more experienced developer (or read the docs about it). The idea that you should criticize a language evolution on the basis of it having more things and thus taking longer to read is just not reasonable in scale, and it's not a deterrent for anyone trying to learn the language itself, more than learning all the basis of computing and programming would be. You should take your time and learn what you need to learn to use your tools, this is usually the biggest problem I see with beginners either way.

[gchling]

In my opinion, almost all syntactic sugar makes code harder to read. For those who seek code brevity, C++ macros are a classic example, yet their detrimental effects are widely recognized.

[HaloFour]

I don't know what to tell you. C# is mostly syntax candy, as is almost all higher level languages. I doubt you find loops and conditional statements harder to read over raw goto statements, afterall. And pretty much every language that is still active is still evolving and adding new features, including C++, COBOL, Fortran, Ada, etc.

C# is not going to stop evolving or adding new features. "Stop adding syntax candy" is not actionable.

[bbarry]

I'm pretty sure if you want you can write CIL if you create a project that uses Microsoft.NET.Sdk.IL

.class private auto ansi beforefieldinit Program
    extends [System.Runtime]System.Object
{
    .method private hidebysig static 
        void '<Main>$' (
            string[] args
        ) cil managed 
    {
        .maxstack 8
        .entrypoint

        ldstr "Hello World"
        call void [System.Console]System.Console::WriteLine(string)
        nop
        ret
    }
}

That is about as close as you can get to no syntax sugar while still writing text based code in .NET.

[gchling]

For exmple:

Default Interface Methods;
Top-level Statements;
Global Using Directives;

And
"var tmp=10;" Is is good than "int tmp = 10;"？

[CyrusNajmabadi]

"var tmp=10;" Is is good than "int tmp = 10;"？

Yes. Now i don't ahve to spend time writing unnecessary code all over the place. I can simply use 'var' everywhere. This makes refactoring and maintenance of code far nicer. For example, say i have:

Goo(SomeMethod(...));

I want to pull SomeMethod out to a local, because i feel like the call is getting too large. I can trivially do that like so:

var temp = SomeMethod(...);
Goo(temp);

and i don't have to waste time figuring out what type to place for 'temp' as i simply do not care.

Just as i didn't have to state the type with Goo(SomeMethod(...)) anywhere, i also don't need to do that when making a local.

Furthermore, if i change the return/arg type of SomeMethod and Goo, i don't need to update anything. It just works. If i have to place a pointless variable on my local type, now i have to update it.

This is why you'll see most languages nowadays allowing to elide the type and infer it from something else. Because a ton of the time it adds only marginal value, while also coming with a lot of drawbacks.

[CyrusNajmabadi]

Default Interface Methods;

Not syntactic sugar.

[CyrusNajmabadi]

Top-level Statements;

Definitely nice. Why have to put in pointless scaffolding that obscures from the actual code of interest. This is in service of increasing the signal of the code and lowering the noise.

[CyrusNajmabadi]

Global Using Directives;

Can be nice. Some usings are just so universally common in a codebase, that it's superfluous to... have... to... repeat... them... every... single... time.

Some people like verbosity and explicitness. That seems to be your perspective here. Most find it just noisy and an unpleasant tax/chore. We allow both sorts of users to have what they want in our ecosystem.

[CyrusNajmabadi]

C# makes it difficult for beginners to grasp the underlying logic.

This assertion needs evidence. We have not seen this to be the case. Indeed, a lot of the niceties C# added later have demonstrated the opposite. Allowing beginners to learn more quickly; getting them to be able to solve the problems they care about in an easier fashion.

There's no special 'underlying' logic that they are generally missing out on. And now there is a nicer, more gradual learning curve to move to the full breadth of the language.

Note that this is like complaining that by using C# beginners can't grasp the underlying logic of IL, or assembly, or any lower level concept this all desugars to. That's not relevant as the purpose of these languages is exactly to make it so that you shouldn't have to know that. And it's especially so a beginner can start with the simple concepts and only take on the deeper ones later if they have a need.

So the thing you're complaining about here is actually a virtue.

[gchling]

One must look beyond the initial coding experience to the long-term maintenance costs. People are not compilers, and projects are collaborative. Every concealed detail raises the cost of reading and understanding, making it essential to weigh the trade-offs carefully.

That's my opinion translated by AI.

I hope more people will join the discussion.

[gchling]

The development of any programming language is meant to make it better, not worse.

[CyrusNajmabadi]

The development of any programming language is meant to make it better, not worse.

We agree. And we think the addition of certain types of syntactic sugar make the language better. Most languages agree with this philosophy. You are welcome to disagree. However, we've seen nothing in the 25+ years of the language that have indicated that going this route has been a mistake. As with the last couple of decades, we will continue doing this, in a thoughtful and careful fashion.

Note: if you want this conversation to be productive, i think it would behoove you to respond substantively to the counterpoints people are bringing up. Simply hard disagreeing, without nuance or interest in engagement is not doing to lead anywhere.

[HaloFour]

The development of any programming language is meant to make it better, not worse.

And it has. You're welcome to disagree. You're also welcome to go find another programming language that better fits your stylistic preferences. Good luck finding one that doesn't have and continue to add syntax sugar.

[gchling]

While C# began as a robust language with impressive ecosystem growth and feature modernization - later excelling in efficiency and multithreading - its recent syntactic choices appear misaligned. Such divergence risks undermining this fundamentally strong language's trajectory, which would be a profound pity.

[CyrusNajmabadi]

its recent syntactic choices appear misaligned

How so?

Such divergence

What divergence?