I still think C# is one of, if not the best of designed languages exist. Even it moves in much smaller steps than it was before I think it's for good. I left .NET land at 6.0 and .NET 4.x versions mostly because of Windows eco-system (small open source community, almost no alternatives to out of the MS things, bad linux support). Since that I've been working with Java, Swift,JS, Python, Golang and I still think that…
To me C# is the second best designed language, the first being IMHO Kotlin. I'm very interested in what you think would make C# more well designed than the latter :}
Welcome to C# 9.0
171–180 of 196 posts
Re: Welcome to C# 9.0
#172What is the winforms simple (ie, drag and drop form designer, click through for code) current windows development recommendation. I've seriously lost all track of how to just get up and going. I've tried UWP/WPF etc - they felt like a bit of nightmare for quick and go, but the tooling now seems to have dropped winforms? I couldn't get the form designer to actually show up even on a WinForms project?
You can write Winforms like code in WPF and get better layout capabilities. If you stay away from MVVM then WPF is pretty straightforward.
Re: Welcome to C# 9.0
#173Well, we're getting closer to F#. Still waiting on discriminated unions and expression blocks. (Yes, I know, discriminated unions in F# are just implemented in the class hierarchy. But it's awfully nice syntactic sugar.) > Point p = new (3, 5); At first glance, not impressive, since you could just do: > var p = new Point(3,5); However, it would clean up code like: > graphics.DrawRectangle(RedBrush, new(3, 5, 2, 2))
I would love for C# to get rid of "new" as F# does -- why do we need it? var p = Point(3,5). For cases like this it's no big deal, but deep/complex initalizers (like expression trees, etc.) look horrible in C# unless you create static helper fn's to init objects.
Re: Welcome to C# 9.0
#174Earlier quoted context omitted.
Looking at a random file in Powershell, the first thing I see is: private string _typeName; /// /// Add new type name to the specified object for TypeNameSet. /// [Parameter(Mandatory = true, ParameterSetName = "TypeNameSet")] [Parameter(ParameterSetName = "MemberSet")] [Parameter(ParameterSetName = NotePropertySingleMemberSet)] [Parameter(ParameterSetName = NotePropertyMultiMemberSet)] [ValidateNotNullOrEmpty] publi…
since c# 3 (2008) this would normally be expressed as public string TypeName { get; set; } not sure why it's not here, could just be older code. The [Parameter] etc stuff is all powershell-specific metadata that defines how to use it from the powershell language.
It would be nice to see if some other codebases managed to free themselves from some of this cruft and make something more approachable.
Re: Welcome to C# 9.0
#175I have worked with C# since the early beginning I have used it daily since then. I do know the ins and outs of the different up until C# 8 (latest released) and now .Net core. because I work with it every day. This probably an unpopular opinion but I wish they would make fewer changes to the language. A codebase from C# 2 will look entirely different than something written in C# 9. If you get a developer who has grea…
Re: Welcome to C# 9.0
#176Earlier quoted context omitted.
It's about trade off. A language that keep getting new features every year, will make some users happy, but will lose compiler speed and it will be harder to learn.
I love C# and have used it since the beginning (my online handles are often VisualCSharp), but I do worry about the cognitive burden of remembering idioms and dealing with multiple ways to do the same thing. This is already a huge issue with C++, and now it's slowly happening to C#. I work with many, many developers--some overseas--that are still in the string.Format era. The language is starting to show some warts d…
Re: Welcome to C# 9.0
#177Damn, this is fantastic. One big syntactical thing I should really put in a proposal for is null-conditional returns. Turning if(foo != null) return foo; Into return? foo; It fits perfectly with the existing null coalescing operators and such, while really cleaning up a lot of code.
An interesting idea; it could be extended to other constructs - assignments, method calls... Also, imagine having something like this: while (!return? foo) { foo = get_foo(); }
Re: Welcome to C# 9.0
#178> " Top-level programs " I'm not usually one for causal dismissals but that made me cringe. What on earth is the use case for getting rid of that tiny bit of boilerplate, relative to the complexity it adds to the language definition, that makes it worthwhile?
Re: Welcome to C# 9.0
#179Earlier quoted context omitted.
My understanding is that the dotnet runtime and powershell are both decent codebases. https://github.com/dotnet/runtime https://github.com/PowerShell/PowerShell
Looking at a random file in Powershell, the first thing I see is: private string _typeName; /// /// Add new type name to the specified object for TypeNameSet. /// [Parameter(Mandatory = true, ParameterSetName = "TypeNameSet")] [Parameter(ParameterSetName = "MemberSet")] [Parameter(ParameterSetName = NotePropertySingleMemberSet)] [Parameter(ParameterSetName = NotePropertyMultiMemberSet)] [ValidateNotNullOrEmpty] publi…
Re: Welcome to C# 9.0
#180I would like to know what is the future of Mono now that dotnet core is crossplatform and Microsoft bought Xamarin. Mono remains the best (only?) solution to call C# from C++ in a crossplatform way using embedding.
Mono as a project is a dead man walking. And honestly, that is good. Unity as the major other user is surely heading for .NET 5.
I would suggest to learn to embed .NET Core 3.1 and later .NET 5. Surely possible (see Unity, interop with WinRT etc, ..).