Live data from Hacker News

C# 9 top-level programs and target-typed expressions

developers.redhat.com

161–170 of 188 posts

Re: C# 9 top-level programs and target-typed expressions

#161

Earlier quoted context omitted.

> top level is mostly going to be nice when teaching new programmers. You can just get on with hello world Yeah it seems like kind of a weird thing? “Here’s marginally less boilerplate once , if someone is going to learn to use the language, they may as well learn how it actually works instead of hiding stuff that they’ll soon see anyways...

.NET was designed from the get-go for creating large programs. There is of course some overhead/boilerplate to this. So you could not do a Write("Hello world"); without wrapping it in a method. In a class. In a namespace. In an assembly. After all, why optimise the language for "Hello world" ? How important is that case? language designers rightly decided that supporting large programs was more important. In the code…

> But yeah, show it to a c# newbie who is used to e.g. Python where "Hello world" is literally a one-liner and they might think "what a crapsack language, there's like 6 lines of overhead per 1 line of code, argh this is as bad as Java" - I've seen pretty much this reaction. Is it justified? From my POV, not at all. But I have seen that happen.

I don't understand why we keep optimising for this audience in the first place.

These are people that lack basic understanding, but also have no patience whatsoever, or any intentions to RTFM. Why are we bending the ecosystem for this audience?

Re: C# 9 top-level programs and target-typed expressions

#162
post #144

Earlier quoted context omitted.

> MS really made a grave mistake by coupling the evolution of the C# language to the .NET version. It’s not directly coupled, but each version of C# has a minimum .NET version it can support, due to the requirements of the features in the language itself (like LInQ in the past). And MS has been very up front about .NET framework being legacy and not getting any future upgrades for years now. Keeping every new C# feat…

> Keeping every new C# feature compatible with every obsolete .NET version obviously has a big technical cost Strawman there. The problem is not "every obsolete .NET version", the problem is .net in reality have two incompatible platforms at this point, but newer C# versions are only supported on one of them. Going from framework to core will require (risky, expensive) rewrites, which means lots of real-world code wi…

Exactly this. My current project is on full .NET Framework 4.8. It is on the latest possible version of ASP MVC, Entity Framework and all typical 3rd party libraries(of which 90% is supported on .NET 5). In the last two years we created several POCs for migration to .NET 5. Our current best estimate is 7 years for 80% of our development team. No sane manager will ever approve that crazy effort with almost no benefits for end users. Additionally we are talking here about most typical CRUD application without almost any advanced engineering. Our onboarding is taking at most 2 days and people can start be very productive even in first couple days. I can only imagine nightmares with more complex systems.

Re: C# 9 top-level programs and target-typed expressions

#163
post #125

Earlier quoted context omitted.

> top level is mostly going to be nice when teaching new programmers. You can just get on with hello world Yeah it seems like kind of a weird thing? “Here’s marginally less boilerplate once , if someone is going to learn to use the language, they may as well learn how it actually works instead of hiding stuff that they’ll soon see anyways...

You should see how many new engineers are confused in CS101 when confronted with all of Java's boilerplate just to write a simple "hello world" program. It's a real issue.

So people with no programming experience are confused with Java. That doesn't sound like an issue at all.

I don't think the solution should be to bend Java backwards so that it's easy for people with no progrmming experience to work with.

Re: C# 9 top-level programs and target-typed expressions

#164
post #91

I mean, top-level programs are nice, I guess? IMO it's more of a means of attracting non-.NET developers into the fold. I work in a .NET shop and we probably won't use this in our production code. The benefit of target-typed expressions IMO is that it changes property syntax from: public List Foos = new List (); to simply: public List Foos = new(); It may seem subtle, but if you write C# you see this pattern constant…

top level is mostly going to be nice when teaching new programmers. You can just get on with hello world and now have to type all this boiler plate and explain why you have to. But yeah, for "real" programs it is probably irrelevant. But who knows, maybe we will find a use for it. I am mostly excited about the sort-of option type getting rid of nulls option.

> But who knows, maybe we will find a use for it

Outside of a project that deliberately has multiple entry points so that you can compile different executables from the same code base, or code where Main is, directly or indirectly, recursive, there's no additional utility from an explicit Main(), so i don't see why implicit wouldn't win for the normal case.

Re: C# 9 top-level programs and target-typed expressions

#165

Earlier quoted context omitted.

It is super easy with dotnet core. The new CLI is pretty simple, you use it as a package manager and compiler. Visual Studio also uses the CLI to run and debug dotnet core projects. https://docs.microsoft.com/en-us/dotnet/core/tools/

Is it possible to create a single, stand-alone, self-contained .exe? (I'm fine with only building for a single platform - Mac/Win/Linux) Needing to run my programs (which show up as .dll's) using dotnet just feels weird (and it doesn't match my intuition for 'how programs are run' in Windows cmd/etc). I'd be fine with an .exe that's not self contained but at least I run it like a 'normal' exe. :)

It's possible but along with an .exe you'll get a couple of .dlls. Exe size will be 60+ Mb.

Re: C# 9 top-level programs and target-typed expressions

#166
post #10

Earlier quoted context omitted.

I can't see var going anywhere, many times you aren't directly creating a new object, but getting a generated object from something ( like linq) which tends to have more complicated type signatures.

I hate hate hate var. Sure, in your own IDE, and reading the code you just wrote, no problem. But when doing code reviews and jumping all over, I want to see the type right there. Nothing more frustrating than reviewing a PR with var's all over. This isn't even up for debate anymore... No more var! It is frustrating to still see var as the recommended way by Microsoft... You can even put in a rule to format the docum…

There's a reasonable convention of specifying full type for a variable that is returned from a method where it's not very clear what the method returns without looking up method signature. This usually means that the method name can be is not descriptive enough, but there are case where you can't really fix that. Other than that, I think var definitely is a huge benefit for readability and overall code design.

Re: C# 9 top-level programs and target-typed expressions

#167
post #132
post #109

I really love c# - one of my favrorite languages, but can any one explain the benefit of this new syntax? Person p1 = new(); Person p2 = new("Tom"); Person p3 = new() { FirstName = "Tom" };

You save typing by not having to repeat the class name.

But you could use var instead of Person on the left, so you're only saving 3 characters which likely you're not typing out in most editors

Re: C# 9 top-level programs and target-typed expressions

#168

Earlier quoted context omitted.

.NET was designed from the get-go for creating large programs. There is of course some overhead/boilerplate to this. So you could not do a Write("Hello world"); without wrapping it in a method. In a class. In a namespace. In an assembly. After all, why optimise the language for "Hello world" ? How important is that case? language designers rightly decided that supporting large programs was more important. In the code…

> But yeah, show it to a c# newbie who is used to e.g. Python where "Hello world" is literally a one-liner and they might think "what a crapsack language, there's like 6 lines of overhead per 1 line of code, argh this is as bad as Java" - I've seen pretty much this reaction. Is it justified? From my POV, not at all. But I have seen that happen. I don't understand why we keep optimising for this audience in the first…

> don't understand why we keep optimising for this audience in the first place.

I wouldn't say "optimise for them". I would say "get them in the door", get them used to how things work in C#, and then drop the training wheels.

I take the point, it seems a marginal case though. IDK.

Re: C# 9 top-level programs and target-typed expressions

#169

Earlier quoted context omitted.

.NET was designed from the get-go for creating large programs. There is of course some overhead/boilerplate to this. So you could not do a Write("Hello world"); without wrapping it in a method. In a class. In a namespace. In an assembly. After all, why optimise the language for "Hello world" ? How important is that case? language designers rightly decided that supporting large programs was more important. In the code…

Why though? I can’t see any advantage to wrapping the startup code in a Main method from a maintainability standpoint.

Consistency, mostly. It's all methods on classes everywhere else, why make it different here?

Even with "top level statements" the startup code is wrapped in a "main" method, it's just compiler-generated in this case.

The CLR insists that code statements are always in method on classes, I believe. In cases where it appears otherwise (e.g. a lambda) the compiler is generating a wrapper class.

Re: C# 9 top-level programs and target-typed expressions

#170

Earlier quoted context omitted.

Why though? I can’t see any advantage to wrapping the startup code in a Main method from a maintainability standpoint.

Consistency, mostly. It's all methods on classes everywhere else, why make it different here? Even with "top level statements" the startup code is wrapped in a "main" method, it's just compiler-generated in this case. The CLR insists that code statements are always in method on classes, I believe. In cases where it appears otherwise (e.g. a lambda) the compiler is generating a wrapper class.

Because it’s just noise that doesn’t mean anything to me, so why keep it? Same as type inference, expression-bodied members, and other LOC savers.
Post reply on HN