Gepostet von Mads Torgersen, Lead C # Architect bei MicrosoftRoslyn-ProjektRoslyn ist der Codename, der dem Open-Source-Compiler für C # und Visual Basic.NET zugewiesen wurde. Das Projekt begann in der tiefsten Dunkelheit des letzten Jahrzehnts des Unternehmenslebens von Microsoft - und endete als Open-Source-Projekt, eine plattformübergreifende, öffentliche Universal-Engine für C # (und VB, die ich im Rest dieses Artikels als selbstverständlich betrachten werde).
Das erste Gespräch über das Projekt, das später als Roslyn bekannt wurde, war bereits im Gange, als ich 2005 zu Microsoft kam - kurz vor der Veröffentlichung von .NET 2.0. Es war die Rede davon, C # in C # umzuschreiben. Dies ist bei Programmiersprachen üblich - ein Beweis für die Reife der Sprache. Aber es gab eine praktischere und wichtigere Motivation: Wir, die Entwickler von C #, haben nicht selbst in C # programmiert, sondern in C ++! Wenn Sie täglich in C # programmieren, ändern Sie Ihre Meinung: die große Kraft, an dem Werkzeug zu arbeiten, das Sie entwickeln (Hundefutter).
Benutzer sind wie der alte vom Verhalten des neuen Compilers abhängig. Das Schreiben eines neuen Compilers für C # ist ein Versuch, eine Fehler-zu-Fehler-Entsprechung zu finden.
Die Schwierigkeit beim Umschreiben des Compilers, der seit mehreren Jahren aktiv verwendet wird, besteht darin, dass Benutzer wie der alte vom Verhalten des neuen Compilers abhängen. Das Schreiben eines neuen Compilers für C # ist ein Versuch, eine Fehler-zu-Fehler-Entsprechung zu finden. Und ich spreche nicht nur über bekannte Fehler, sondern auch über unbekannte Fehler und unerwünschte Verhaltensweisen, die Entwickler oft unwissentlich gefunden und verwendet haben.
Aufgrund des Ausmaßes dieses Problems konnten wir viele Jahre lang nicht einmal mit dem Projekt beginnen.
Obwohl die Entwickler der Sprachgruppe bei Microsoft viele Vorteile aus dem neuen C # -Compiler in C # erhalten haben, war der Wert für Endbenutzer nicht so offensichtlich: Wie wird der neue Compiler ihnen zugute kommen? Vielleicht sind die Compiler-Entwickler die einzigen, denen es wichtig ist, dass der C # -Compiler in C # geschrieben ist.
Gleichzeitig zeigte sich immer mehr ein anderes Problem: Doppelarbeit zwischen verschiedenen Tools, die mit C # -Code ausgeführt werden. Neben dem Compiler arbeitete ein anderes Team an der IDE-Unterstützung für C # in Visual Studio und musste viel Code schreiben (zu dieser Zeit auch in C ++), um die Syntax und Semantik von C # zu verstehen.
Gleichzeitig nahm die Anzahl der Tools von Microsoft und anderen Unternehmen wie StyleCop, CodeRush usw. zu: Alle sollten eine sinnvolle Verarbeitung von C # -Code implementieren. Jedes dieser Programme hat seine eigenen leicht unterschiedlichen Fehler, unterschiedliche Verständnisniveaus, verschiedene Kompromisse und Zugeständnisse. Und alle würden sich viel Mühe geben, um zu einem gemeinsamen Verständnis des Codes zu gelangen.
Und wir haben uns für einen wichtigen Vorschlag entschieden: um sicherzustellen, dass es nur eine Codebasis auf der Welt gibt - eine einzige Basis für alle Tools, die mit C # -Code arbeiten!
Der Wert eines solchen Vorschlags ergibt sich aus einer Erhöhung der Anzahl der verfügbaren Werkzeuge und insbesondere aus einer Verbesserung der Qualität der vorhandenen Werkzeuge. Alle Anforderungen an die Richtigkeit und Leistung der Sprache sind einer einzigen Codebasis zugeordnet. Genug Einzelarbeit, um eine Basis von herausragender Qualität und großer Vielseitigkeit zu schaffen. Wir werden einen echten Motor für die Sprache schaffen! Einheitliche, offene API für C # -Code. Wir werden das Konzept des „Compilers“ neu definieren.
Sobald Sie eine API für die breitere C # -Community erstellt haben, sollte es sich natürlich um eine in C # implementierte .NET-API handeln. Der langjährige Traum, C # in C # zu schreiben, kommt also fast wie ein zufälliger Nebeneffekt.
So wurde Roslyn aus einer offenen Denkweise geboren: C #s Innenleben für den programmatischen Gebrauch durch die Welt zu teilen. Das an sich war ein kühnes Unterfangen für die immer noch eher geschlossene Unternehmenskultur von Microsoft.
Werden wir geistiges Eigentum kostenlos teilen? Werden wir Werkzeuge stärken, die mit uns konkurrieren?
In der Unternehmensdiskussion wurde uns geholfen, Argumente für die Stärkung des Ökosystems und die Schaffung einer Sprache mit den besten Werkzeugen der Welt zu gewinnen. Es ging um das langfristige Wachstum von C # und .NET im Vergleich zur kurzfristigen Monetarisierung und zum Schutz von Microsoft-Assets. Ohne den Open-Source-Code zu erwähnen, war das Wetten auf Roslyn für Microsoft ein großer und mutiger Schritt.
Natürlich kann es nicht einfach sein, so etwas zu entwickeln. Die Aussichten für Roslyn waren sehr ehrgeizig und mit technischen Problemen behaftet, und wir haben fünfzig Jahre gebraucht, um mit allem fertig zu werden. Aber das ist eine andere Geschichte.
Während des größten Teils der anfänglichen Entwicklung blieb Roslyn ein Closed-Source-Projekt.
Von Beginn der ernsthaften Arbeit an dem Projekt im Jahr 2009 an hatten wir Ideen, um Compiler zu öffnen, aber Microsoft war einfach noch nicht bereit.
Microsoft hat seit den 1970er Jahren eine Kultur der geschlossenen Entwicklung und des Patentschutzes von Quellcode. Obwohl die Änderungen in der Luft lagen, waren sie langsamer als unser Team gehofft hatte.
Tatsächlich schien es für einige Zeit so, als würde das Unternehmen in die völlig entgegengesetzte Richtung gehen.
Das Windows 8-Projekt hat das gesamte Unternehmen stark beeinflusst. Dank des neuen Programmiermodells drangen seine Tentakel tief in die Entwicklungsteams von Tools und Sprachen ein, und alles wurde nicht nur von außen, sondern auch innerhalb des Unternehmens streng geheim gehalten. Zum Beispiel wurde die Async-Funktion, die wir zu dieser Zeit entwickelten, mit dem Windows 8-Programmiermodell koordiniert und gemischt, und ich würde es nicht wagen, Notizen über das Design auch innerhalb des Unternehmens zu veröffentlichen, aus Angst, versehentlich Informationen über Windows 8 und Probleme auf meinem Kopf zu verlieren ! Dies schuf ein schreckliches Klima für Innovationen und erlaubte uns natürlich nicht, uns auf den Open-Source-C # -Compiler zu verlassen.
Am Ende, als Windows 8 seinen eigenen Weg ging, begann sich das Unternehmen zu verändern und fand eine neue Richtung, eine neue Führung und eine völlig andere Philosophie - das Microsoft, das wir heute kennen. Open Source verbreitet sich jetzt schnell innerhalb von Microsoft.
F # wurde 2010 mit einer offenen Lizenz und einer eigenen Organisation -
F # Software Foundation - veröffentlicht . Um ihn herum hat sich eine herausragende Gemeinschaft gebildet, um die wir alle bald beneiden mussten. Unser Team bestand hartnäckig darauf, eine kostenlose Lizenz für Roslyn zu erhalten - und schließlich ermöglichte die Unternehmensinfrastruktur dies.
Bis 2012 gründete Microsoft die Microsoft Open Tech-Organisation, die sich speziell auf Open Source-Projekte konzentriert. Roslyn kam unter ihre Fittiche und wurde offiziell ein Open-Source-Projekt. Roslyn war dafür ziemlich reif: Alle Entwicklungsressourcen waren intern und bekannt, und das Projekt selbst litt nicht unter einer großen Anzahl von Abhängigkeiten, die zu Lizenzkonflikten führen konnten.
Im April 2014 stellte Anders Halesberg auf der Build Developers Conference in San Francisco
Roslyn als Open Source-Projekt vor . Der Quellcode selbst wurde am 3. April auf CodePlex (der früheren Microsoft-Plattform für Repositorys) unter der Apache 2.0-Lizenz veröffentlicht.
Gleichzeitig wurde die
.NET Foundation zur Basis für .NET-Projekte einschließlich Roslyn erklärt.
Diese Veröffentlichung ist zu einem echten Hauch frischer Luft geworden! Wir haben bereits in CodePlex begonnen, die Vorteile der Offenheit zu nutzen, und dann wurden die verbleibenden Verfahrenshindernisse für Open Source bei Microsoft beseitigt. Daher ist Open Source heute ein natürlicher und integraler Bestandteil unserer Arbeit in vielen unserer Teams.
Wir sehen GitHub nicht mehr als Ort, an dem Quellcode veröffentlicht wird - es ist nur der Ort, an dem wir arbeiten.
An anderen Fronten erkannte das Unternehmen auch, dass es nicht notwendig war, alles zu kontrollieren. Es wurde klar, dass es keinen guten Grund für die Existenz von CodePlex gab - und Roslyn migrierte zusammen mit anderen Projekten zu GitHub, der bis dahin de facto Hauptwebsite für Open Source-Projekte. Nicht nur der Code selbst, sondern auch der Prozess seiner Erstellung wird in GitHub durchgeführt: Wir betrachten GitHub nicht mehr als Ort für die Veröffentlichung von Quellcodes - dies ist nur der Ort unserer Arbeit.
C # -Sprachendesign und Compiler-Implementierung sind jetzt vollständig offene Prozesse, an denen maßgeblich Dritte beteiligt sind. Sie erstellen einschließlich ganzer Sprachfunktionen. Der Wert von C # wird nicht nur aufgrund der Skalierung des Schreibaufwands und der Behebung von Fehlern, sondern auch aufgrund des Verständnisses und der Korrektur des Kurses, den wir dank der sofortigen täglichen Rückkopplungsschleife mit der Community erstellen, einfach verlängert.
Es war eine lange und verrückte Reise, und für mich symbolisiert sie die enormen Veränderungen, die Microsoft im letzten Jahrzehnt erfahren hat. Roslyn Nugget wurde im Dunkeln geboren, wuchs aber mit den Ideen der Offenheit auf - und explodierte heute dank der Kraft von Open Source in einer Million verschiedener Anwendungen.
Lernen Sie Roslyn und C # Language Design:Roslyn auf GithubC # auf GitHub