51–60 of 188 posts
This is the second one on the HN front page today [1]. HN tries to avoid paywalled articles, maybe we should also discourage articles that start out by deliberately hiding the content.
I think that C# is underrated. Although TypeScript is my default language choice for most programming, C# / .NET is my choice for cases where: - high performance is important - or interop with native libraries is required (because C#'s DllImport attribute makes that super simple) Another benefit is that C# is syntactically similar to TypeScript (they were both designed by Anders Hejlsberg after all), so switching bet…
C# is my goto for Windows, for sure. Is the native interop good in Linux as well? I've never even considered anything like that, would probably gravitate to C++ since that's what I'm familiar with but would seriously consider Go or Java in non-Windows situations.
(But watch out for bitness)
Earlier quoted context omitted.
if you have built anything on web forms, then you really have no way forward other than rewriting all that. That alone will keep many an enterprise locked on .NET Framework for quite some time.
In our case not web forms but WCF
I think that C# is underrated. Although TypeScript is my default language choice for most programming, C# / .NET is my choice for cases where: - high performance is important - or interop with native libraries is required (because C#'s DllImport attribute makes that super simple) Another benefit is that C# is syntactically similar to TypeScript (they were both designed by Anders Hejlsberg after all), so switching bet…
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…
I have been programming with c# since 2000 i think. But I do not like where the languages is going. It is becoming way to loose in a sense and it seems that it wants more than it should. If you want to do functional programming, pick a fp language. If you want to do dynamic typed programming pick a dp language. Sure you can mix some things in, but c# is becoming way to scattered imo. And it's not pretty i think.
Personally, I enjoy C# becoming a multi-paradigms language like Common Lisp. Multiple inheritance and a good macro system would help close the gap. I don't need safety guards in my language, I'm looking for the right options when I need them.
Earlier quoted context omitted.
I think I'm going to get diabetes from all the syntax sugar... On the more substantive changes, it feels a little like the language designers have been looting F#. Combined with how fast Dotnet Core is moving and how many breaking changes there are there, it does feel like things are getting very fragmented. Stasis isn't good either; just witness the decade or so of stagnation after Java 1.6 as the Sun -> Oracle tran…
I don’t think they’re just randomly throwing stuff at the wall. These are all things they’ve been talking about for years.
Who would have believed a decade ago that there would be a RedHat developer blog entry on C# today? If someone had told you that then you would have thought the world would have collapsed in the meantime.
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…
Anyone who names their variables properly should have no problem telling what kind of types are being worked with anyway. And in the rare case you absolutely need specifics, they’re just a tooltip away.
I always find these arguments against “var” somewhat absurd because those same programmers work with fields and properties and methods from other classes all the time, and none of those requires you to write the type.
For an example, if you were to access “someExternalThing.bigRedTrain”, the type of “bigRedTrain” would be written nowhere in the current class. I fail to see how using “var bigRedTrain” is any different.
Earlier quoted context omitted.
A bit of a tangent but is it possible yet to compile C# to native code easily (like calling a normal compiler on the command-line)? Last time I checked I needed to jump through a bunch of hoops through Visual Studio, and create some XML or other nonsense. I don't get why they've made it so hard compared to just compiling managed code.
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/
Also, the whole thing is still a stateful operation revolving a .csproj file, which (again) is XML I have to create (sure, it's just one command) and manage/deal with every time. Even to compile a tiny C# file from my editor now I need to make a project for it. With a normal C# or C++ compiler I can just invoke csc.exe or cl.exe and produce the executable in one command from my editor... no intermediate state or project file management required. That's kind of what I was getting at with it being "simple". I didn't just mean the syntax, I also meant the structure of the solution.