181–190 of 214 posts
Heads up for C# devs, you should switch all your code bases to use (x is null) and !(x is null) instead of ==. The is operator can't be overloaded, and always compiles to IL eq, whereas == can be overloaded in custom types. Of course it would also be nice if everything was moved to nullable reference types [0], but that's a non trivial amount of work. Note that most C#8 features can be enabled manually through the cs…
Earlier quoted context omitted.
a number of the C# lang developers prefer (x is object) for the latter, FWIW.
why not add an operator so you can say (x !is null)?
This is neat, but also super confusing. Is the ability to build class hierarchies not the ultimate reason to use C#, an Object-Oriented language? Which one of the two is idiomatic? Great, now we have code littered with methods that take object s as parameters, so we have no clue what to actually pass to the method? C# is a fantastic language but I feel increasingly lost with the barrage of new features added to it.
"Is the ability to build class hierarchies not the ultimate reason to use C#, an Object-Oriented language?" The ultimate reason to use C# is because it's a modern managed language with an excellent base library, excellent tooling and excellent debugging experience. Object oriented hierarchy is not a value in itself. Often it's an antipattern. I'd day 80% of time you are off much better by cleanly separating your prog…
> Writing maintainable, understandable code is important. But "idiomatic" gives the idea that there is some higher level ultimate truth on what is always the best formulation for each and every problem.
This is the sentence that really rings true. Idiomatic is often dogmatic, especially in the OO language world. As far as I am aware, there's very little research backing up the GoF doctrine but it's often rattled off as "what you should be doing" and idiomatic.
As someone who 'saw the light' on this later in my career I have since moved to using functional programming (in C#, because the project I work on started life as OO and is a never ending huge web-app); Mathematics has a lot more to say about correctness than the imperative/OOP world of idioms, and I find I can trust my code much more than in the past.
I needed to create my own Base Class Library to make it happen [1], which has been a labour of love, but has fundamentally changed our multi-million line code-base for the better. But, obviously it has to fight against the baked-in mentality of devs in the OO/C# space by providing a non-idiomatic solution.
The next step on the evolution will be category theoretic approaches (I believe), languages like Statebox are already starting down this path. How languages like C#, that still have the legacy of the OO world baked into its framework and grammar, will cope with this evolution long-term remains to be seen. However, right now I think they're just about getting it right. And C# especially is still one of the easiest languages to be productive in, with a world class tool chain.
Resharper has proven to be a great way for me to start learning and integrating new language features. I code in my original style and resharper suggests changes based on new features like pattern matching. At first I didnt see the benefit, but this is a hugely powerful feature once you start to wrap your mind around it.
I'll take a "limited" language with excellent IDE support over a "powerful" language that you use notepad with.
Resharper has proven to be a great way for me to start learning and integrating new language features. I code in my original style and resharper suggests changes based on new features like pattern matching. At first I didnt see the benefit, but this is a hugely powerful feature once you start to wrap your mind around it.
I have clocked in way more hours in Rider than VS. I can flawlessly run and debug our decades old monolith with 40-50 projects and millions LOC, containing C#, VB, Web Forms, WPF, files with 80k lines... And all of our .NET Core services on MacOS, with all my unix-y tooling. There is “VS for Mac”, but it’s not really VS. It’s Xamarin Studio rebranded. Rider works excellent on my Linux box at home as well, where the a…
This was only true for the first releases, they have been integrating common code from VS and this is one of the reasons why VS moved away from COM plugins into a .NET ones.
Earlier quoted context omitted.
That's not why VS is still 32-bit. Apparently folks at MS dont think the extra address space isnt worth it and think it would adversely affect performance [1]. In my own experience in migrating servers from 32 to 64-bit on Linux 12 years ago, 64-bit was around 10-20% slower than the 32-bit build. Dont how itd fare today (no longer at that job). Even though performance was demonstrably slower, 64-bit it was due to edi…
Rico has a point to a degree and every VS version since then reduced memory footprint and improved performance (mostly due to not calculating stuff up-front which may never be needed and doing it on demand). Microsoft has also pushed since VS 2008 (!) for plug-ins and extensions to use an out-of-process model. I think ReSharper got the message in summer 2019 that it might be a good idea – and incidentally, a lot of t…
I also never liked ReSharper, the performance drop versus vanilla VS isn't worth it.
Earlier quoted context omitted.
> replacement for visual studio but faster How can a IntelliJ Idea derivative written in Java be faster than VistalStudio which is native code? Both Idea and PyCharm work much slower than VisualStudio on my machine.
Visual Studio is written in WPF which is not exactly a speed demon.
I have been using F# since last year, haven't really looked back to C# since. Unfortunately although we are a small community, it does feel like being last on Microsoft priority list. Microsoft please listen to feedback of your F# users namely on fslang-suggestions and fslang-design repository. My personal wish list for F# are type classes, HKTs, macros and GADTs.
The language is already good enough.
Earlier quoted context omitted.
Their long game is to slowly convert C# into F# without anyone realizing it. They're roughly half way through already.
Well C# 7.2 and 7.3 was moving it more to Rust. So that F# statement is a bit limited. They steal best ideas from everywhere and integrate it into the multi-paradigm language C# actually is. In 2020 Pattern Matching is just a elementary feature everyone wants to have in all general purpose language. Like async/await. Or LINQ. That is just 101 for languages from now on.
Heads up for C# devs, you should switch all your code bases to use (x is null) and !(x is null) instead of ==. The is operator can't be overloaded, and always compiles to IL eq, whereas == can be overloaded in custom types. Of course it would also be nice if everything was moved to nullable reference types [0], but that's a non trivial amount of work. Note that most C#8 features can be enabled manually through the cs…
C# compiler doesn’t regard “x is object” or “x is null” as null checking statements, so you get warnings if you’re using nullable references. Also, I don’t understand the scare over operator overloading. It’s not common and it works fine with nulls too as long as it’s implemented correctly. If it’s buggy, you’re screwed for other cases anyway, it isn’t much helpful to try to fix null checks only. I find this advice o…