> ...they were almost dropped from .NET schedule as being "academic only"
For all the good that has come out of .NET, and the nice platform it is today, there are a lot of high level design decisions where the team decidedly landed on 'the wrong answer'. To their credit they've been moving towards 'the right answer' for a while now.
Auto-wrapped properties instead of exposed value fields. Smart initialization. Safe default values. Generics. Anonymous functions. Nulls. Higher order functions.
Still under way: pattern matching, DSL support, option type, type aliasing, etc.
Related, but I also find it highly fascinating on those topics how much of Visual Basic's design they ignored, derided, and have then had to re-implement after-the-fact. A lot of babies got thrown out with the COM+/VB6/MFC bathwater.
> A lot of babies got thrown out with the COM+/VB6/MFC bathwater.
Not sure what you mean here, COM has become the main way of doing Windows APIs since Vista, going full circle to the original design of COM Runtime with WinRT (now UWP).
I was referring to the APIs, components, and language experience that got recycled incompletely as they were ported into .Net and "abstracted away", moreso than how components are marshaled :)
COMs resilience in the face of competing models, as you've pointed out, and the fractured GUI landscape of the windows client platform are symptoms, IMO, of ceding a pretty mature platform for something almost, but not quite, as capable. It has taken .Net over a decade to relearn lessons won painfully for the VB5 and VB6 teams, and I believe they lost a lot of larger systems because of WinForms restrictions in the 2005-2009 window.
I think the ideal is something close to ML-style polymorphism a la OCaml/Haskell, or F# on .Net.
The generics in C#/Vb.Net are pretty nice too, but their absence in the language during the design of the original standard libraries is still felt (typically along IDictionary and ICollection interfaces).
It seems obvious in retrospect how useful they are, but I do remember lots of contemporaneous "debate" about how academic and complicating they would be that turned out to be. My personal opinion is that these debates were relics of the C++ contingent of the ecosystem, and less applicable to languages running on top of virtual machines.
C# was originally trying to copy Java, a language that took influence from C (weak types retrofitted) and Smalltalk (no static types at all). Industry has since learned a lot about the tremendous value that types bring. Other forms of static analysis are now gaining popularity too.
For the record I'm not trying to argue generics are not important, on the contrary having worked with them for years go seems to be too limiting in this matter for my practical use.
But I agree they can be tricky to get right (compare e.g. declaration-site vs use-site variance [0]) or "accidentaly Turing-complete" TypeScript [1].
For all the good that has come out of .NET, and the nice platform it is today, there are a lot of high level design decisions where the team decidedly landed on 'the wrong answer'. To their credit they've been moving towards 'the right answer' for a while now.
Auto-wrapped properties instead of exposed value fields. Smart initialization. Safe default values. Generics. Anonymous functions. Nulls. Higher order functions.
Still under way: pattern matching, DSL support, option type, type aliasing, etc.
Related, but I also find it highly fascinating on those topics how much of Visual Basic's design they ignored, derided, and have then had to re-implement after-the-fact. A lot of babies got thrown out with the COM+/VB6/MFC bathwater.