Anders Hejlsberg

And, and there was, you know, and that is like, I mean, now we're talking like business and whatever, it had nothing to do with, with, with, with, with technical, but it effectively meant that visual J plus plus was never going to be a product that companies would make a bet on because they full well knew that, you know, you, you're not gonna, you're not gonna write your app in a, in a language that has been enjoined by a judge in San Jose, you know, or, or whatever.

And so we kind of realized at that point too, that.

Maybe it's not a great strategy to place your development platform bet on technology that's licensed from a competitor.

And that in turn, along with the sort of dev situation at the time, I mean, Microsoft's main development products at the time were in two camps.

There was Visual Basic, rapid application development loved by

Everybody, you know, because it was so easy to build apps, right?

But performance-wise, had problems.

Extensibility-wise, wasn't so great.

To write new components, you had to write them in C++ and whatever.

And then we had C++ with MFC and power and expressiveness, but really what people wanted was both.

They wanted something that rolled both of those up.

Right.

And then they also wanted like modern things like garbage collection that say Java had, for example, right.

An exception handling and.

a more object-oriented, component-oriented way of building your apps.

And all of that was part of the genesis that led to .NET and to the C Sharp language.

Well, they were simultaneous, I would say, because we knew we wanted to build a runtime that was

language independent, because we knew that we wanted to run Visual Basic on it, and we wanted a way of running C++ on it, and we wanted the ability for other languages to host themselves on this runtime.

But we also knew that we needed to build a language that would appeal to

both Visual Basic and C++ users and give you sort of that golden thing in the middle, right?