HN Books @HNBooksMonth

There is, it's called COM, and Windows as an operating system and ecosystem is built on top of it. (Though COM as a specification is not limited to Windows)

The language you use for defining the types is creatively named "Interface Definition Language (IDL)", and the "MIDL" compiler converts the interface definitions into C & C++ types and objects which can be used. Both via in-process/inter-process function calls, or via RPC/DCOM (Distributed COM).

https://en.wikipedia.org/wiki/Component_Object_Model#DCE/RPC...

  "As a cross-language component model, COM relies on an interface definition language, or IDL, to describe the objects and associated functions. The COM IDL is based heavily on the feature-rich DCE/RPC IDL, with object-oriented extensions. Microsoft's own implementation of DCE/RPC, known as MSRPC, is heavily used as the primary inter-process communication mechanism for Windows NT services and internal components, making it an obvious choice of foundation."

  "DCOM (Distributed COM) extended the reach of COM from merely supporting a single user with separate applications communicating on the Windows desktop, to activating objects running under different security contexts, and on different machines across the network. With this were added necessary features for configuring which users have authority to create, activate and call objects, for identifying the calling user, as well as specifying required encryption for security of calls."

If you want to learn more about this (it's an incredibly powerful concept that has a wide range of uses and is very much still used today), my recommendation would be:

1. The book: "Essential COM (1997)" by Don Box, one of the architects of COM at Microsoft in the 90s

  https://www.amazon.com/Essential-COM-Don-Box/dp/0201634465

2. The online tutorial "COM in plain C", which is one of the only (it might even be, like, THE only) resources for learning how COM actually works, since generally you use C++ frameworks to interact with it and they cover up all the details.

  https://www.codeproject.com/Articles/13601/COM-in-plain-C

---------

Disclaimer: I'm no expert in COM myself, I'm also working through these same learning materials.

I have a strong interest in FFI/Interop between languages and so have been working through things like "What is an ABI, conceptually?", understanding the C++ Itanium ABI, reading about vtable's, manually emulating C++ classes and class-inheritance with C structs of function pointers (vtables) etc.

COM is foundational here so it's the thing on my list atm. Hope you find this useful!

⬐ Kinrany

Thank you!

Yeah, I also feel like it's important. Too much time is wasted on X-lang wrappers for Y-lang libraries.

Here are some good COM books.

Essential COM by Don Box

https://www.amazon.com/Essential-COM-Don-Box/dp/0201634465

Inside COM by Dale Rogerson

https://www.amazon.com/Inside-Microsoft-Programming-Dale-Rog...

Then if you have access to public libraries, maybe one of them has one of the several Microsoft Systems Journals issues, later MSDN Magazine, with plenty of low level COM articles.

COM is from the days where good documentation was to be found in books, not on the Interwebs.

⬐ taude

Wow, that's a throw back to the late 90s, early 2000s. I'm still slightly scarred from working with ATL and COM. A lot of people around here would probably be surprised to hear that there were even Python -> COM bindings back in the day that were even used to ship server software once upon a time. Anyway, I remember that Don Box book well.

⬐ ptx

Not only "back in the day" – those COM bindings for Python were most recently updated last month: https://pypi.org/project/pywin32/#history

I highly recommend using them if you're ever forced to work with VBA and need to implement some non-trivial functionality.

⬐ 7thaccount

Yea...Python and Powershell are the only languages that I know of outside C#/VBA/VB.NET with decent COM support. I hate COM, but it works.

⬐ pjmlp

Delphi, Eiffel as well.

⬐ 7thaccount

True... I've looked at Delphi, but at this point I doubt the license fee is worth it compared to say C#. I've never known anyone who actually used Eiffel though.

⬐ crtlaltdel

oh how i wish i knew this back when...or just looked harder i guess ;)

⬐ contextfree

There are also new Python bindings for WinRT (which is based on COM): https://github.com/Microsoft/xlang/tree/master/src/package/p...

⬐ mycall

IronPython supports .NET Core which supports COM

⬐ holy_city

thank you!

⬐ vic20forever

archive.org has the following pre-dotnet edition of MSDN Library - you'll find a lot of COM info in it:

https://archive.org/details/MSDN_Library_October_2001_Disc_1

https://archive.org/details/MSDN_Library_October_2001_Disc_2

https://archive.org/details/MSDN_Library_October_2001_Disc_3

⬐ teh_klev

+1 for Essential COM by Don Box, it still survives my bookshelf purges..."just-in-case". IUnknown and IDispatch are burned permanently in my memory from a period of my life building a COM/CORBA bridge.

⬐ alxlaz

I'm gonna piggyback on your comment to give another shout out to Essential COM. I haven't touched COM in ages but that book is so good I still pick it up every once in a while -- and it was a lifesaver back when I did touch COM on a daily basis.

I think the history of the internal politics at Microsoft in regards to .NET and also the external industry trends is fascinating.

The common thinking is that C# & .NET was a ripoff of Sun Java because of the "write once run anywhere" threat. That's sort of true but missing some nuance.

I'm not a MS insider but here's my understanding of what happened. We have to separate the C# language from the CLR runtime. In the 1990s, Microsoft was already researching how to enhance and extend the COM interoperability model. (Otherwise known as "how do we get multiple programming languages to talk to each other?")

Based on some old interviews with Don Box[1], instead of this work being productized and released as "COM+ version 3" or whatever, it morphed into the CLR. This was a natural evolution that would have happened even without Sun's JVM threat.

C# the language, on the other hand, was a more direct response to Java the language since Microsoft's J++ (Java clone) was abandoned because of Sun's lawsuit.

As for .NET, it's interesting that Microsoft always had this large internal group of programmers (mostly Windows kernel and Office teams) that didn't fully buy into the .NET vision. On the other hand, Bill Gates himself was a big believer in it. My pet theory is that since Bill Gates programmed in BASIC in the 1970s and not in low-level C/C++/assembly, he had a natural affinity for the vision of high-level C# & .NET being pervasive throughout Windows. Even with Bill's support, there was always an ongoing internal tension between the C++ vs the NET framework camps. (On a related note, it seems like Apple's internal programmers are more happily embracing Swift over Objective-C to a greater degree than Microsoft's internal adoption of C# over C++.)

Two major forces outside of Microsoft's control curtailed .NET's planned world dominance: (1) the rise of Javascript in the browser which negated .NET Silverlight, and also Java applets and Flash. (2) the rise of Apple iOS and Android.

.NET is still very popular but it definitely did not fulfill the more ambitious dreams that Bill Gates had for it.

(On a related note, I also wrote an old comment about the decline of .NET's WPF and its limited adoption: https://news.ycombinator.com/item?id=14098832)

[1] Was MS Technical Fellow and author of 1998 COM book: https://www.amazon.com/Essential-COM-Don-Box/dp/0201634465

⬐ gambler

>.NET is still very popular but it definitely did not fulfill the more ambitious dreams that Bill Gates had for it.

There is still time. It just recently got open-sourced, got a compiler written in itself and got a run-time unbundled form all the legacy crap. Those things held C#/.NET back. I feel this is a good time to adopt it for people who want to have reasonable performance, static typing and a mix of OOP/functional paradigms.

My two notes on C#:

1. It is possible to write reasonably "functional" applications in .NET. The only problem I had with that is lack of built-in copy-on-write data types and prevalent nullity.

2. LINQPad is the best damn scripting environment I ever worked with.

⬐ bunderbunder

Part of me, though, worries that the ship has sailed. For a while .NET was probably completely fine from Microsoft's perspective, because the platform was (AFAICT) dominant in their target market of enterprise apps.

Then big data became a thing, and basically the entire core ecosystem was written in Java. I think it's becoming a bit of a wedge issue - Java has everything that .NET has, but .NET does not have its own equivalent of, for example, the Hadoop ecosystem.

⬐ Const-me

> Java has everything that .NET has

Java offers nothing for game developers, there're multiple game engines written in .NET or using .NET. Java only runs on Android, .NET on all mobiles. Native interop in Java is a joke.

⬐ pjmlp

Actually Java had jMonkey and LibGDX before Unity became the engine it is today. Which initially was Mac only and only used Boo and Unity Script as programming languages.

Khronos does have some official OpenGL specs for Java. There are none from them for .NET.

Java runs on iOS via Codename One and Gluon AOT compilers.

Native interop in Java was made hard on purpose, as Sun was pushing for WORA. Oracle is in the process of improving the situation with Project Valhala.

I love both stacks, truth is that .NET still has a bit to catch up outside Windows, while Java lost a bit of its mojo on desktops.

⬐ matthewwarren

> truth is that .NET still has a bit to catch up outside Windows, while Java lost a bit of its mojo on desktops.

I agree, that's quite a nice summary of the 2 ecosystems

⬐ Const-me

About games, maybe the reason is lack of value types in Java which stresses GC and creates pauses. .NET works OK, Unity is the most obvious (cities skylines, kerbal space program, etc.), but also XNA, MonoGame, SharpDX. This creates an ecosystem with healthy amount of libraries and other resources.

About native interop, I know Java did it on purpose, but as a developer I don’t care much about the rationale. I’ve heard about upcoming Valhala years ago (announced in 2014), still not ready.

Related to both of them, .NET core 2.1 already has SIMD support. Some parts of it is experimental, but it already works more or less OK, esp. on Intel/Amd.

⬐ pjmlp

Java had such eco systems first with Java3D, JOGL, Khronos OpenGL bindings, 3D for J2ME, jMonkey, LWJGL

Problem was that Sun never was too serious about their Java Gamming initiative.

Unity only adopted C# after moving out of the Mac into the PC, and it was stuck for ages in 3.5 as they didn't want to pay for the new licenses. Which meant it grew to a kind of C# dialect, which is being fixed now.

ManagedDX and XNA were Quixotic projects not well seen by WinDev. Which replaced XNA with DirectXTK when given the opportunity.

Which took a couple of years effort until Microsoft acknowledged the work done by the MonoGame guys.

Things take ages in Java because there are multiple vendors and everyone has to contribute to the process.

Intel has provided SIMD auto vectorization improvements. There are a couple of talks about it.

⬐ aras_p

> Unity only adopted C# after moving out of the Mac into the PC

Not quite true; Unity has always used Mono. The very first Unity 1.0 version in 2005 was already using C#/Mono.

> Which meant it grew to a kind of C# dialect

Unity never had it's own "C# dialect".

⬐ pjmlp

Given that Unity uses different conventions for property names and magical function names with reflection for events, that is a dialect to me, as it is not how C# is used by regular developers.

Actually there are occasional questions on C# forums caused by people learning C# via Unity and then facing issues when using pure .NET.

Then there is the new HPC# for the new ECS and Job systems, which subsets C#.

As for Mono being already in 1.0, OS X only version, I am unsure about it, but the old blog was taken down. So I take your word for it.

⬐ aras_p

That's just coding style, which by itself is not a new dialect. Yes a bunch of APIs in Unity use different naming conventions from the rest of .NET world, but the language is the same.

The new HPC#/Burst indeed are subsets of C#, but that's a very recent development, and completely unrelated to "Unity had to make their own C# dialect to avoid Novell/Xamarin licensing issues".

> As for Mono being already in 1.0, OS X only version, I am unsure about it, but the old blog was taken down

I have worked at Unity since 2006. Yes Unity was Mac only at that point, but it still used Mono there.

⬐ pjmlp

My remark had to do more with being stuck in a v3.5 world, thus making Unity devs live in an universe quite different than what everyone else is using in terms of APIs and language features, on top of Unity specific behaviors like those magical methods called by the component framework.

⬐ svick

> Java has everything that .NET has

C# certainly has many features that Java, the language, does not. It gets better if you consider Kotlin instead, but it's not clear to me if that language has a chance of becoming on par with Java, popularity-wise.

⬐ WorldMaker

You can do "big data" entirely in .NET.

You can use Hadoop "Streaming" with .NET easily enough and still take advantage of the "Hadoop ecosystem".

Orleans is not exactly Hadoop, but it's close enough that conversions between are relatively straight-forward, and Orleans is useful for a number of other work distribution patterns beyond map/reduce.

Beyond that, the map/reduce pattern is one of the easiest abstractions to reimplement yourself from scratch if you get the itch. I believe Hadoop is relatively over-rated from that standpoint, and arguably IMO another case of Java developers over-ceremonializing what should be a simple, lovely abstraction/design pattern into a weird spaghetti mess of configuration and ritual.

⬐ jordanab

LINQPad is awesome, and I'm always amazed to still find a lot of .NET developers who've never given it a try.

A cross platform version is high on my wish list.

⬐ louthy

> 1. It is possible to write reasonably "functional" applications in .NET. The only problem I had with that is lack of built-in copy-on-write data types and prevalent nullity.

I've tried to minmise that pain over the past few years with my 'functional language extensions' for C# [1].

It's a library with most of the common monadic types (as structs so there's no null issues); Immutable collection types that don't have an unweildy naming scheme like like the System.Immutable.Collections library - which are all structs, so no nulls; A type called 'Record<T>' which when you derive a type from it gives your type value-semantics (equality, ordering, GetHashCode, ToString, serialisation/deserialisation) by default; and tons more.

You still have to do stuff like build your own With method for immutable types. I have written of how these can be achieved _realtively_ easily [2]

C# has made great strides over the past 10 years to make it easier for those of us that want to work functionally to do it. It still has some way to go (discriminated unions, higher-kinds, record types, etc.) but it's already possible to write code functionally - you just need to do some boilerplate every now and then.

[1] https://github.com/louthy/language-ext

[2] https://stackoverflow.com/questions/38575646/general-purpose...

⬐ Flow

Wow, what a nice project you have there.

I've read that the next C# will have non-nullable reference types, have you thought about how to make your framework fit in with that? It's a "natural" Some/None in a way.

⬐ louthy

> Wow, what a nice project you have there.

Thanks :)

> It's a "natural" Some/None in a way.

If we lived in the perfect non-nullable reference world from the start then it's arguable whether Option<A> would ever have been needed - and so going forward it should be needed less, or not at all for some devs. The question comes when you need an optional value, and so you use nullable references instead of Option<A>. With nullable references the `null` still honours the contract of `A` - this is what Option<A> protects against. If the flow-analysis for nullable references is good enough to spot that you're possibly going to use null and then forces you to use a predicate of some sort (if/switch/ternary/...) to validate the referenced value exists then I think we're good. I understand that is what's planned, but it needs to be bulletproof.

There will be devs working in the nullable reference world for a long time (due to difficulties with moving to the new world when it comes) - and so I fully expect Option to be useful for its null protection reasons for a long time.

The story is a bit bigger than just protection against null though. If instead of seeing Option<A> as A|null, you see it as A|B, where B is the single-value type: Unit. Then Option is A|Unit. If you then look at Either<L, R> which is designed to represent one of two alternative values: L|R then it's pretty easy to see that Option is Either<Unit, A>. And then when we look at Try<A> which is designed to return A or capture an exception and return it as a value, then that can be seen as Either<Exception, A>...

All of the types that represent one of two values have lots of additional powerful functionality: Fold, Map, Bind, BiFold, BiMap, BiBind, etc. and have been designed to seamlessly switch between each, which won't exist on the standard nullable reference types. So, there's still a place for Option in the bigger scheme of things.

Personally, I can't wait for non-nullable references to come in. I built language-ext to try and get a handle on a 10,000,000+ line code base that kept falling foul to null reference exceptions (along with other common C# coding world problems). It was 100% to help me and my team build more robust code. Non-nullable references is a feature we will turn on immediately, even if it takes a week to fix up the warnings and errors it spits out, this is going to be one of the most important updates the C# team have done.

⬐ pjmlp

The whole Longhorn/Vista debacle, with .NET components being rewritten in COM for Vista, followed up by the increasing the COM usage in Windows 7 and then bringing up WinRT as .NET replacement under Synofsky's leadership is another example of those political internal wars.

⬐ stupidcar

Yeah, I think this was a far bigger contributor to the failure of .NET to achieve dominance. Silverlight was only ever a slightly weird sideline intended to compete with Flash, which became DOA the moment the iPhone launched and Jobs killed Flash overnight by saying the iPhone would never support it.

Microsoft's biggest internal teams turning against .NET during Longhorn created a schism that the company has never resolved. I often wonder what might have happened if they'd had the requisite leadership to force the change through organisation-wide, and MS had spent the last 15 years with a single, rational dev story.

⬐ ASalazarMX

> Jobs killed Flash overnight by saying the iPhone would never support it.

I think it was a forced choice. Even if Flash had been supported, most flash sites and games would not have worked well on a phone.

⬐ None

None

⬐ pjmlp

Yep, they were forced to sort out the mess introduced with WinRT, UAP, UWP, by making UWP .NET Standard 2.0 compliant, and now making Forms, WPF and EF 6 runnable on top of .NET Core 3.0.

However given the last Office related announcements, it appears that the reorganization did little to sort out those political issues.

⬐ WorldMaker

To further tangent: I don't think the last Office related announcement says anything about UWP that people think it does.

From my understanding, the Office apps that were killed were supposedly forked from the web apps and actually ran as UWP HTML/JS.

Meanwhile, Office has also announced plans to move forward with more UWP XAML Islands to integrate more Fluent Design in the UX starting soon after the Windows October release, and part of why the Office 2019 LTS was shipped where it was and arguably why Office 365 pushed to align to only support latest Windows releases so they could move forward on Fluent Design dogfooding.

They did sunset the non-UWP OneNote with this LTS release, and the UWP XAML app is supposed to be the only Windows version of OneNote moving forward.

⬐ pjmlp

Lets see, I watched the Office sessions at BUILD, so that was my understanding until the announcement came last week.

⬐ WorldMaker

Yeah, BUILD's where most of where my impressions come from, especially from how pleasantly happy that the Fluent Design Team was with finally merging in some of Office's design resources and working to align Office towards dogfooding Fluent controls directly.

The implication I take from the UWP "Office Mobile" app shutdowns is that Office is now confident that if UWP returns to mobile it will do so with "real" Office, which was my takeaway from BUILD that that was the strategy they were pursuing.

I think it's another case of Microsoft not being able to properly spin "nuance" in a press release, because they don't want to comment on future plans or publicly commit to things still in flux/prototyping/development.

⬐ mariusmg

Next stop, making UWP crossplatform :))

Regarding the political issues, the Silverlight/WinRT clusterfuck also helped with WindowsPhone downfall. Release 1.0 and next major update offered a API incompatible with 1.0, what a clusterfuck....

⬐ merb

> Next stop, making UWP crossplatform :))

they do not need. they have xaml over xamarin.forms, which supports all major platforms (including desktopn and mobile) it still says that its in preview however the only things that did not work well is when you need some kind of file interaction with the os, you need to create native views for all your OSs (i.e. NSFilePicker, OpenFileDialog, etc..) since there is no Xamarin.Forms widget for that. besides that it is already really mature.

⬐ Mertax

Xamarin.Forms has to manage a lot of friction interfacing with the native UI controls. It's both an advantage and a disadvantage to it's approach. It has to conform to the common denominator of the native platforms, but gets to leverage the native look and feel. But this seems much harder to maintain long term. It would actually make sense if they created a XAML platform (like cross-platform UWP) that used its own rendering stack (similar to Flutter's approach) that wasn't beholden to the design decisions of an externally developed platform and having to reconcile the differences between different platform paradigms.

⬐ hackerfromthefu

This exists - UWP code and UI - deployed to iOS, Android, and WebAssembly.

It's called UNO, check out https://platform.uno/ and https://platform.uno/#Comparison

!! By the way to anyone who wants to build a system in UNO - I would like to build one. !!

I'm a .NET developer with the perfect experience to leverage this system. I've been doing full stack and front end on various platforms for 20 years, and .NET for 15 years (version 1) and thus can leverage UNO to provide rapid and quality development.

I've already done advanced XAML in Silverlight and WPF with MVVMLight and PRISM application architectures based on TDD/CI/CD, animations, transforms, control templates, control building, designing products.

I'm also good with Blend and do the roundtrip Blend designer to Visual Studio developer workflow, or do both parts myself to design a full front end UX, UI, and code, and well as the rest of the full stack.

If you're interested to build a system or product built on UNO with me, get in touch!

⬐ jasode

>Microsoft's biggest internal teams turning against .NET during Longhorn created a schism that the company has never resolved.

From the fragments of leaks I read about the internal strife, the .NET code had huge performance problems and the C++ team was frustrated that "DevDiv" couldn't solve them. ("DevDiv" is Developer Division that owned NET Framework.) Therefore, they ripped a lot of "managed code" out and redid it in native code.

I hope that one day, an ex-Microsoft programmer or product manager writes a tell-all book of this period. It would be a fascinating case study.

⬐ pjmlp

The thing is, if they actually collaborated with each other, the outcome would surely look quite different.

⬐ stupidcar

Yeah, that's my understanding as well. But what I wonder is what would have happened if someone at the top had brought the C++ and .NET teams in and made some Jobsian declaration like "this isn't negotiable, the company is switching to .NET. All of your jobs depend on finding a way to make it work." Were those performance problems really insoluble, if all the engineering ability of the company were brought to bear on them? I get the impression that a lot of the C++ old hands were never pleased with .NET to begin with, and were all too happy to chuck it.

⬐ WorldMaker

Right, it certainly sounded from the outside that a lot of the Longhorn performance issues were various sorts of sandbagging by one side or the other. There's an interesting leadership question there too if some of the worst sandbagging was intentional or just ADHD-style distractions due to a lack of a singular, focused vision for the product. (The biggest example being letting so much of the WinFS team get sucked into the never-ending "semantic web" rabbit hole of trying to "schematize the world"; it's hard to focus on performance when you are busy trying to catalog all the different ways that people store data.)

⬐ pjmlp

At RustConf 2017 keynote presented by Joe Duffy regarding Midori at a certain moment, he mentions that even with Midori running in front of them, WinDev guys were still not open to the idea of such kind of system being possible.

"Safe Systems Software and the Future of Computing"

https://www.youtube.com/watch?v=CuD7SCqHB7k

Sorry a bit lazy to track down the exact moment.

⬐ jjordan

> .NET is still very popular but it definitely did not fulfill the more ambitious dreams that Bill Gates had for it.

Remember when Microsoft was adding '.NET' to practically all of their product names for a time? That was fun...

⬐ thrower123

My hypotheses is that C# would never have become as popular as it became if Java hadn't had the long stall between 1.6 and 7[1]. That long, long pause provided a window, and under the stewardship of the vampires at Oracle there is not the kind of direction to push things forward that C# has had.

[1] Four and a half years! Nowadays it seems like Angular and React are pushing major versions every four and a half minutes.

⬐ wvenable

I'm not sure Java would have changed at all if it wasn't for C#. From the start, Java was never particularly quick to get new features or break any sort of compatibility.

⬐ nicoburns

IMO .NET being closed source until recently was also a big factor in it's lack of world dominance. Why choose a proprietary language when there are several comparable opwn ones to choose from.

⬐ iainmerrick

It does seem like all these .NET projects are reactions to rival technologies. C# is a Java clone, C# generics are an (arguably improved) Java generics clone, .NET Micro is J2ME, Silverlight is Flash, etc.

What are some examples of where C# / .NET paved the way and others followed? Maybe popularizing async/await?

I’m definitely not claiming MS as a whole is always a follower. It seems like Direct3D led the way for the whole industry, for example.

⬐ GordonS

> C# generics are an (arguably improved) Java generics clone

That one at least is incorrect - C# had generic types long before Java

⬐ iainmerrick

I didn’t know that, thanks for the correction! (Edit: although now I’m not sure I was wrong after all; see my reply to the other comment)

I had the wrong idea because (if I understand right) C#’s generic collections seem to be a copy of Java’s (which in turn were inspired by C++’s STL). Do I have that one the right way round?

The C# collections use generally poorer name choices (e.g. IEnumerator, which does not actually enumerate the elements) so I assumed they wanted to avoid making it identical to Java.

⬐ pvg

Java's collections are not much like STL (and pre-date Java generics) and important implementation details of generics in C++, C# and Java differ very substantially.

⬐ iainmerrick

They are not very similar in implementation due to the nature of the languages. But the idea that it would be useful for the Java standard library to provide flexible, extensible, general-purpose containers (as opposed to ad-hoc stuff like Vector and Hashtable) was inspired by the STL.

⬐ pvg

I don't think that's accurate or that the general idea comes from STL. STL itself is a very particular kind of design.

⬐ iainmerrick

What’s a good example of a really flexible, composable containers library that predates STL?

I think STL was the first mainstream one. I guess some of the ideas came from Ada? But I don’t know if Ada had standardized containers.

⬐ pjmlp

Smalltalk and Eiffel collections.

Long before STL was a thing in C++.

Stepanov started STL original design in Ada, before switching to C++. Recent Ada standards have adopted collection classes as well.

⬐ Const-me

> C# generics are an (arguably improved) Java generics clone

That depends on who you ask.

My opinion is Java doesn’t have proper generics. In Java they’re just language-level syntactic sugar.

Type system is broken i.e. type information is lost at compile time. This makes it hard to do functional-style programming in Java, that’s why other people made Scala.

Performance is broken too, generic containers box everything into objects causing huge performance penalty for containers with value types.

⬐ iainmerrick

that’s why other people made Scala

I think you mean “the same people”, at least in the specific case of Martin Odersky. :)

⬐ hackerfromthefu

> Generics in the runtime not the compiler (c# 2)

> Functional deeply integrated into a mainstream language (LINQ c# 3)

> Unified graphical application model incorporating all main styles of web, forms, svg, and 3d. (WPF .net 3.5)

> Compiler language services (c# 5)

> Async await (c# 5)

⬐ pjmlp

How come C# generics are a copy of Java when they were invented first and the only reason they didn't make it to 1.0 was not to delay the release schedule?

Java annotations are based on .NET atributes, and initially had a clusmy implementation requiring an annotations processing tool until they finally got integrated into javac.

LINQ paved the way to more FP acceptance among enterprise developers. Check "confessions of a language salesman" from Erik Meyer.

Also .NET always had AOT/JIT from the very beginning, whereas AOT was tabu at Sun and only commercial JDKs always had it as option.

⬐ iainmerrick

Hang on, Wikipedia says Generic Java was 1998, generics were adopted in J2SE 5.0 in 2004, and C# 2.0 wasn’t released until 2005. Am I missing something? I’m sure there was cross-fertilization both ways but it seems like Java generics came first.

LINQ is a good one though, that’s definitely a .NET innovation.

⬐ coldacid

If you trust Wikipedia for your answers, I have a bridge to sell you.

⬐ iainmerrick

Combined with other sources, and when it fits with my own recollection, sure.

I played around with Pizza (AKA Generic Java) in the late 90s, before the launch of C#.

⬐ pjmlp

Yes you are missing the remaining part of the sentence "the only reason they didn't make it to 1.0 was not to delay the release schedule".

Don Syme of F# fame was leading generics research since 1999, while they were designing the CLR, but it was clear they would have to delay 1.0 if they wanted to included them, so they just went ahead without them for 1.0 release.

https://blogs.msdn.microsoft.com/dsyme/2011/03/15/netc-gener...

https://blogs.msdn.microsoft.com/dsyme/2012/06/19/some-histo...

https://blogs.msdn.microsoft.com/dsyme/2012/06/26/some-more-...

Additionally C#, like Java, also had CMU, ML, Ada, Eiffel, Sather, BETA, C++ and Modula-3 as possible sources of inspiration for generics.

⬐ iainmerrick

Just lost out in a photo finish, then (over a span of 5 or 6 years...!)

But Generic Java was started in 1998 (IIRC originally as part of Pizza). It seems reasonable to say that Java covered this ground first.

⬐ pjmlp

Faire enough I forgot about Pizza.

Although what Java got wasn't all of Pizza, which had better generics.

⬐ jorgeleo

"Two major forces outside of Microsoft's control curtailed .NET's planned world dominance: (1) the rise of Javascript in the browser which negated .NET Silverlight, and also Java applets and Flash. (2) the rise of Apple iOS and Android."

I agree with those 2 forces:

1) the raise of javascript: Now is starting to develop an answer to this in Blazor (https://github.com/aspnet/Blazor)

2) iOS and Android: both are here to stay, so Xamarin is the answer. I have been using Xamarin for iOS and all though still lack of some maturity, in its actual form is very viable.

⬐ hackerfromthefu

Shameless plug - do you want a system built with either Blazor or UNO.

I'm a .NET developer with the perfect experience to leverage this system. I've been doing full stack and front end on various platforms for 20 years, and .NET for 15 years (version 1) and thus can leverage UNO to provide rapid and quality development.

I've already done advanced XAML in Silverlight and WPF with MVVMLight and PRISM application architectures based on TDD/CI/CD, animations, transforms, control templates, control building, designing products.

I'm also good with Blend and do the roundtrip Blend designer to Visual Studio developer workflow, or do both parts myself to design a full front end UX, UI, and code, and well as the rest of the full stack.

I've also done a lot of Razor MVC and modern web front end and I can't wait to get into Blazor as well - it seems about the dream platform for my style of development.

If you're interested to build a system or product built on UNO or Blazor with me, get in touch!

⬐ cm2187

I think the game changer (one way or another) will be webassembly, which will level the playing field in term of portability. Then the popularity of the different languages being ported to wasm will be based on their own merits.

⬐ ridruejo

J++ I completely forgot about that! It brings back memories :)

⬐ bitwize

Microsoft developed .NET (internal codename COOL) to get back at Sun for suing them over Java compliance. Microsoft wanted to do embrace-extend-extinguish with the Java runtime and Sun would have none of it, so Microsoft took their ball and were like "Fine! We'll develop our OWN managed runtime and it'll be more better-er than yours is! Neener neener!"

And Bill certainly did program in low level assembly. The last Microsoft code he wrote himself was in the ROM of the Tandy 100 portable computer.

⬐ pjmlp

The Ext-VOS design document as provided by Don Syme, alongside other blog entries, tells another story.

⬐ Someguywhatever

I think it is better-er than Java and the JVM and they have stewarded their language much better than Java, and now Java borrows heavily from C#. I think they will win in the long run if they haven't "won" already.

⬐ bitwize

Considering the language and runtime in themselves, I agree.

But they sort of missed the point of Java, which was that it was cross-platform, and a single Java package could be expected to run on a variety of hardware and OS loadouts with no changes (except maybe in configuration). Microsoft, at the time, wanted .NET to be closely tied to Windows, and though the base libraries were submitted to ECMA, to get anything useful you had to have Windows and Microsoft's Windows-only libraries. (There was Mono, but it was not compatible with Microsoft's stuff and few on the Linux side wanted to touch it.)

Things are changing, obviously, with .NET Core. We'll see if Microsoft or someone else solves for cross-platform GUI and other end-user concerns, where .NET has historically been strongest.

⬐ ot

> Bill Gates programmed in BASIC in the 1970s and not in low-level C/C++/assembly

He didn't program in BASIC, he programmed a BASIC interpreter in 8080 assembly.

⬐ maxxxxx

True. But he definitely had a love for BASIC.

⬐ jasode

Thank you for the clarification. Yes that makes sense. I'm probably mixing it up with an interview where one of MS ex-employees (Joel Spolsky?) mentioned Bill's affinity for BASIC which is why early MS Word has WordBASIC (not Lisp or Pascal) as its first macro language. It later became VBA Visual Basic for Applications. This philosophy and influence continued all the way into the CLR languages VB.NET and C#. Bill was never a C/C++ guy like his employees who were working on Windows & Office codebases.

⬐ mattl

Excel BASIC, I believe.

https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...