Re:Stop Building on Corporate-Controlled Languages
by rblatz on Wednesday January 18, 2023 @11:38AM
(#34429004)
I’d also like to throw another counter example out. C# and Typescript from Microsoft are both excellent languages and are led by Anders Hejlsberg.
Re:Stop Building on Corporate-Controlled Languages
by nandalism on Wednesday January 18, 2023 @02:20PM
(#34431561)
Is that the same Anders Hejlsberg who developed Turbo Pascal and Delphi for Borland, another company which microsoft successfully crushed in the 80's and 90's? (Hint: It is).
We could have C# 30 years before we did if it weren't for microsoft.
Re:Stop Building on Corporate-Controlled Languages
by philwelch on Wednesday January 18, 2023 @02:32PM
(#34431765)
C# came out in 2000; Microsoft didn't even exist in 1970.
Re:Stop Building on Corporate-Controlled Languages
by YoshiRulz on Wednesday January 18, 2023 @04:42PM
(#34433531)
The C# language team are doing a great job. Most of what I hate about C#/.NET—such as the lack of a UI framework that runs on Linux, as I just bemoaned in another comment—was either inherited from the earliest versions or got forced through by management at MS.
Re:Stop Building on Corporate-Controlled Languages
by pjmlp on Thursday January 19, 2023 @02:35AM
(#34437693)
Anders Hejlsberg doesn't have anything to do with C# for a few years already.
His focus is TypeScript.
Mads Torgersen has been leading C# design since version 7, more or less.
Re:Stop Building on Corporate-Controlled Languages
by davidw on Wednesday January 18, 2023 @01:25PM
(#34430711)
The economics of all this is where it's at, and so important to understand.
Look at through a lens of scarcity. What Google sells that is 'scarce' is not the Go runtime - it's ads and other things.
But an independent open source project doesn't really have a source of 'scarcity' that it can sell.
https://journal.dedasys.com/2007/02/03/in-thrall-to-scarcity...
The economics for corporate controlled open source are quite clear. It's a cost saver for corporations to open source solutions to common problems. This gets others to buy in, which spreads maintenance costs and ensures that no one is seriously winning in the domain of the project. Essentially de-risking cost/benefits in the domain of the project.
Another problem, which the author didn't discuss, is that corporate controlled software is often designed by a committee, or designed by those with political capital within the corporation. There is not usually a strong selection mechanism for good system designers, or good open source leaders. Go is a happy and rare exception. Projects coming out of corporations are often not as well designed as projects which rose to prominence organically through differential amplification by the community.