The charitable view would be that they come from language/platform that does include the base-class's methods/apis.
Your example of dotnet/C# doesn't seem to be the best - DotNet/C# repeats the base documentation - for example the SaveFileDialog class [1] lists all of the methods but indicates when the methods come from the base class.
Flutter also seems to list inherited methods - for example the TextButton [2].
I liked Edge originally too - it seemed cleaner than chrome and had some cool features like vertical tabs and the Dev tools that were better than Chrome's. I made it my daily driver.
Then they adding a shopping helper; then more ads to the new start-page; then a notification about Microsoft rewards; then popups about how "Bing is better" or that "Bing AI" was there to help - don't forget the "Open links in Edge on Mobile" popup; then they added a side toolbar with a giant B[ing] button that wasn't removable unless you toggled a group policy (now there's an option for it). The damn button was the last straw for me because of the amount of work I needed to do to just disable it.
> I just want to get on my computer - do a few things and get some stuff done
Yeah, so do I and Edge kept getting in the way to keep telling me about all the new things that Microsoft things I should use.
Chrome isn't great - the privacy sandbox/built-in interests stuff is disgusting - but Chrome wasn't as "in your face" so I could just start it and go. Brave avoided the the privacy sandbox and now Firefox works for me everywhere.
I find the best middle ground is setting up the IDE to have TSC watch running while making changes, but using other tools for doing the actual compiling (vite for example). This allows me to refactor quickly - choosing when to ignore type errors - but also be notified of all the other call sites that I need to update, including in all of the files not currently open in the editor.
For this specific example the problem is that the handleClick callback is using a stale/cached onImageDeleted callback (which indirectly has old state). If you add onImageDeleted to the handleClick dependency array, it beings to work as you expect.
I think the point was that it's not different from Node.js - and thus not much of a benefit.
If it was more along the lines of "I want to use this array helper library, but it shouldn't have any permissions" then it would be a lot more useful, but right now if your Deno app needs any file or network access, then all of your dependencies get access too.
> It was only through the total dedication of Microsoft Research, Cambridge during 1998-2004, to doing a complete, high quality implementation in both the CLR (including NGEN, debugging, JIT, AppDomains, concurrent loading and many other aspects), and the C# compiler, that the project proceeded.
I didn't realize that it was less a "must-have" and more of a "research and if-possible" task. I wonder how the .NET framework/languages would have changed if they went with type erasure. Would we even still talking about .NET today?
We're still talking about Java, which does type erasure. Oracle has really been phoning it in for many years, and despite that the platform is still going strong. Killing large, entrenched platforms is not easy.
Windows remains 800lb gorilla on the desktop, and C# is Microsoft's recommended environment on it. It's hardly surprising that .NET remains relevant.
I've been working with .NET since it was in beta in 2001, and I've never considered .NET's strength to be its desktop story. .NET (and now .NET Core) are awesome because of C# and the BCL's generally excellent design. .NET is an excellent choice for building server-side applications of all kinds. .NET Core removed that last complaint I had about .NET: it wasn't cross-platform.
.Net is also well designed. Some of the most subtle design choices drastically exaggerate poor choices in other languages - one example that has always stuck with me is how well C# namespaces are designed. Not only because they are frictionless, but also because of the lack of global namespace types in the standard library. It's a tiny detail, but .Net is just that: hundreds of well-executed small details.
I think the only way you get this is having someone very, very experienced leading the project. MS had Anders Hejlsberg, who hasn't done much in life, except leading the Turbo Pascal and Delphi efforts, two of the most successful rapid app design languages of the 90s (note: heavy sarcasm in last sentence)
I'm not one bit surprised this is the the guy leading the C# effort's second or third language.
I disagree with you about namespaces. I find Java's packages more useful since they give you access control which increases encapsulation. If I want a factory method guarding the instantiation of a class in java I can make the factory public and the class package private. In C# the only answer for this type of encapsulation are assemblies but they're much heavier weight and it is recommended not to have too many of them in a project.
For the simple case yes. But if you want several classes cooperating, maybe helpers or related data classes, your options are assemblies or like you said to shove everything into one giant class. You have less flexibility of separating things out.
On large platforms, I am going to piss off people but I'll do it anyway. It's not because a language is widely used that it is a well designed language. Javascript, VBA and php immediatly come to my mind. There are many other reasons for a language to be a heavy weight other than its own merit.
This reminds me of Peter Lynch's comment about the stock market: "a voting machine in the short term, but a weighing machine in the long term".
In the short-term, languages with good developer outreach and other factors win. But you don't get things like generics or the .NET TPL without some serious long-term vision. I really do believe well-designed languages win over a long enough timescale.
There are many metrics to judge a programming language by, and even different "axes". Going from theoretical correctness, consistency, type system soundness all the way to ease of development, "batteries included", empowerment, developer productivity (on small and very large programs, as that is not the same), and more recently "forcing" good practices.
Even popularity is a value, as it automatically provides a community, but it's also a pitfall, as massive popularity inevitably means the average programmer of language X becomes as smart, careful and reliable as the average programmer irrespective of language. And, to put it mildly, that's not a positive evolution. That, above all others, was VB and Delphi's downfall.
On three axes, I would argue VB, Javascript and Delphi did/do incredibly well: ease of development (of small-ish programs), and the deployment story, as well as the empowerment they provided.
On things like consistency, developer productivity, batteries included (Delphi was better on the batteries included front), type system soundness, ... they were somewhat sub-par.
It's just what people value at the time. And of course, it is critical during a career in development to distinguish yourself from the average programmer.
Yeah, but I wonder if .NET wouldn't have succeeded until .NET Core without generics as a distinguishing feature. I feel like generics + some of the features built on them (LINQ+TPL+etc.) is what let .NET/C# stand apart from Java.
I'm not necessarily saying it would have failed, but I do wonder :: )
C# succeeded based on the strength of Visual Studio.
Sure, the language being nicely designed and having some code translation tools helped people switch from VB.
But C# being the “best supported” language in Visual Studio. The productivity gains for developers were too real to ignore, managers saw it, and bought into the Visual Studio ecosystem en masse.
The CSharpLang github[1] repository would be where to look for this. I didn't find anything that mentioned adding language support for it, and IIRC, in the past they rejected the idea of inline XML or JSON support.
Going the other way of C# inside HTML, you have Razor[2] and Blazor[3], the latter of which is a prototype of Razor running in the browser via web assembly.
Blazor is pretty amazing, but my coder fantasies mostly revolve around a React-JSX-in-C# vision - the syntax and approach just feel so natural and so right. Your point about rejecting inline XML is probably a pretty good data point that I shouldn’t expect what I’m hoping for to happen.
I'm curious if this will change now that webapps/electron-apps have become so popular. It may be that users have begun non-native apps as the new norm.
Your example of dotnet/C# doesn't seem to be the best - DotNet/C# repeats the base documentation - for example the SaveFileDialog class [1] lists all of the methods but indicates when the methods come from the base class.
Flutter also seems to list inherited methods - for example the TextButton [2].
[1]: https://learn.microsoft.com/en-us/dotnet/api/system.windows....
[2]: https://api.flutter.dev/flutter/material/TextButton-class.ht...