Avatar von Bitschnipser
  • Bitschnipser

mehr als 1000 Beiträge seit 14.01.2016

Re: GitHubs "Texteditor" Atom emuliert jetzt Emacs...

MetaCircularEvaluator schrieb am 14.09.2017 11:51:

Was mich nur wundert: Dass da niemand vorher draufgekommen ist das so zu machen!

Mit früher meinte ich auch, dass man auf die Idee hätte kommen müssen, als man angefangen hat, IDEs die mit mehreren Sprachen klarkommen sollen, zu entwickeln.

Auf die Idee hätten also spätestens die Emacs Leute Mitte / Ende der 90'er kommen müssen; "Einfach" mal ein std. Protokoll als Interface zwischen dem Editor und den GCC Modulen entwickeln... Und so etwas hätte eigentlich spätestens in Eclipse landen müssen, als die IDE angefangen hat weitere Sprachen außer Java zu unterstützen.

Auf WIBNIF-Niveau gibt es diese Idee schon länger. Somogyi hatte schon in den 90ern Pläne dafür - und wollte Programmiersprachen in einem Binärformat ablegen, damit man diese lästige Syntax endlich loswird und auf AST-Ebene arbeiten kann. (Ganz nebenbei sorgt man auch für einen wunderschönen Vendor Lock-In, aber das ist schon off-topic.)
Geworden ist nichts draus.

Ich vermute, dass der Teufel eben doch im Detail steckt.
Z.B. wenn man noch nicht wirklich verstanden hat, was OO ist, wie will man die Verlinkung mit Oberklassen machen? Wie die mit Implementationen einer Funktion in Oberklassen? Unterklassen? Wie finde ich die relevanten Aufrufstellen einer Funktion - ist ein Aufruf relevant, wenn er zur Oberklasse/Unterklasse/Parallelklasse gehört? Was mache ich bei Mehrfachvererbung à la C++, bei Interfaces à la Java, bei Vererbung mit Umbenennung à la Eiffel?
Wie kann ich Ober- und Unterklassen finden, wenn die Sprache dynamisch ist? In Python sehe ich das gerade, die Verlinkung scheitert grandios, wenn die Deklaration auch nur minimal vom üblichen Muster abweicht (Pythonistas konstruieren Klassen auch gern mal erst zur Modulladezeit und installieren die per put ins Module Dictionary). In Javascript sieht das garantiert auch nicht schöner aus, und von PHP will ich erst gar nicht reden (obgleich gerade da guter IDE-Support sehr wichtig wäre).
Wie gehe ich mit syntaktisch inkorrekten Programmen um? Das ist ganz zentral für Name Completion, da ist das Programm ja fast immer syntaktisch inkorrekt, weil der Entwickler es noch schreibt.

Zu einigen dieser Fragen habe ich selbst heute noch keine guten, allgemeingültigen Antworten gesehen. Ich vermute, dass die Antworten auch stark von der Programmiersprache abhängen - je größer die Hamming-Distanz zwischen gültigen Programmen, beispielsweise, desto leichter ist der Umgang mit Syntaxfehlern.

Und dann gibt es noch die Sachen, die sich mit allgemeinem Gebrauch einer Sprache ergeben. Bei Java kann man Breakpoints üblicherweise nur auf eine Anweisung setzen, und das ist meistens "gut genug". Mit dem Aufkommen von DSLs mit extrem langen Aufrufketten will man dann aber doch den Breakpoint an einen bestimmten Punkt *innerhalb* der Anweisung setzen. Blöd nur, dass der Java-Compiler die Positionsinformationen nur pro Zeile generiert, man muss also den Breakpoint setzen und dann im Bytecode nachsehen, wie oft man singlestepping machen muss, bis man da ist, wo der Anwender sein will. Allein mit diesem Feature kann man ein Team ein paar Monate lang beschäftigen...

Aber jeder IDE Hersteller hat sich wieder und wieder die gleiche Arbeit gemacht, und so etwas selbst entwickelt, anstatt hier zusammen mit den Compiler Bauern an einem Standard zu arbeiten. Genau das finde ich halt merkwürdig. Niemandem ist anscheinend vorher aufgefallen, dass hier massiv Sachen doppelt und dreifach gebaut werden.

Ansonsten ist doch die Industrie relativ flott für solche Sachen gemeinsame Standards zu erarbeiten, damit sich hinterher alle beteiligten einen Haufen Arbeit sparen können.

Vor allem auch sehr merkwürdig, da in dem Fall ja niemand einen Vorteil davon hatte seine eigene Anbindung an Compiler zu bauen, oder gar Teile von bereits vorhandener Compiler Infrastruktur nachzubauen. Reuse vorhandener Funktionalität ist ja wirklich keine revolutionäre Erfindung. Man macht es nur nicht, wenn man sich einen Vorteil von einer eigenen Implementierung erhofft. Ansonsten nimmt man halt das Zeug, was schon da ist, um in anderen Punkten schneller ans Ziel zu kommen.

Es war eben nicht klar, was die API können muss.
Man hätte eine Monster-API machen müssen, die alle Features sämtlicher Compiler unterstützt. Das wäre sehr aufwändig geworden, und es hätte die IDE-Hersteller beim Experimentieren mit neuen Features ausgebremst.
Unter diesen Umständen ist es völlig sinnlos, so ein Gemeinschaftsprojekt aufzuziehen.

Wenn ich mir die ungelösten Fragen von weiter oben so ansehe, habe ich sogar die Befürchtung, dass auch LSP mangels allgemein nützlicher Ergebnisse rasch sterben wird. Man wird mit dem Design anfangen, und dann werden die Compilerteams in den beteiligten Firmen sagen: Das funktioniert so nicht, wir brauchen noch das und das, und nach zwei, drei Runden Feedback ist das Ganze zu einem Bloatmonster sondergleichen geworden.
Oder es wird sowas wie Email: Im Prinzip überall das gleiche, aber mit tausenden schlecht spezifizierter Features, die nach dem "das muss reichen"-Prinzip umgesetzt sind.

Ich begrüße LSP eigentlich eher aus dem Grund, dass man mal so ein Projekt machen muss und schauen, gegen welche Wand es zuerst knallt, damit man die im nächsten Anlauf vermeiden kann... aber erzähl das bitte nicht den Kostenrechnern :-D

LSP ist halt ein Großprojekt. Ebenso wie Eclipse. Da braucht es jemanden, der ein paar Millionen in die Hand nimmt, um das Projekt überhaupt anzuschieben.
Und danach muss das Ding in Open Source gehen, sonst endet die Entwicklung bei "feature complete", statt in Richtung Erweiterbarkeit und universelle Nützlichkeit weiterzugehen.

Ja. Umso mehr wundert mich deswegen, dass es ausgerechnet MS war.

Das ist die Cloud-First-Strategie. Sprich: Kunden-Lock-In per SaaS.
Da sparen sie sich die rufschädliche Konfrontation mit den Open-Source-Vertretern. Und selber Code weiterzugeben wird dann vorteilhaft: Man kriegt kostenlos Reviews, Verbesserungsvorschläge, sogar Prototypen.

Die Betriebshandbücher ihrer Rechenzentren sind dann die neuen Geschäftsgeheimnisse. Es würde mich nicht mal wundern, wenn sie irgendwann nicht sogar Teile des Betriebssystems offenlegen würden - mit Cloud First ist das kompatibel.

Das wird auch gutgehen mit dieser Strategie. Nicht jeder ist willens und in der Lage, sein eigener PC-Admin zu sein.
Das Ganze wird erst zusammenbrechen, wenn das Entwickeln von Software in freien P2P-Netzen so einfach wird, dass auch der Frickler auf PHP-Niveau damit experimentieren kann - die meisten bleiben auf Frickelniveau, aber die wenigen, die dabei tatsächlich immer weiter lernen und besser werden, die setzen dann sowas wie Diaspora auf und plötzlich zählt Facebooks Vorsprung beim Rechenzentrumsbetrieb nicht mehr viel, weil die Software dezentral beim Enduser zuhause läuft.
Das dauert aber alles noch viele, viele Jahre, und bis dahin sind die Aktionäre glücklich ;-)

Bewerten
- +