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 04:13:

Das ist ja der Kern der Idee hinter dem LSP (Aus einem m^n Problem ein m+n Problem gemacht; m: Anzahl Code Editoren, n: Anzahl zu unterstützender Sprachen).

m*n, nicht m^n. Aber es ist natürlich genug.

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

Mich nicht.
Sowas war bis in die 90er hinein mehr als das, was ein PC für einen Entwickler hätte leisten können. Und wirklich nützlich wird es erst, wenn man Refactoring und Doc-Extraktion macht, was - in meinen Augen nicht ganz zufällig - erst seit den 90ern in größerem Umfang gemacht wird. Und 20 Jahre für das Sammeln von Erfahrungen, was so eine API alles können muss und was man besser in anderen Modulen lässt, das finde ich gar nicht mal so furchtbar viel.
Schau mal auf die Zeitleiste: IDEs gibt es seit Smalltalk und den Lisp-Maschinen, die waren aber vollkommen auf jeweils eine Sprache fixiert. Mehrsprachenfähige IDEs gibt es eigentlich erst seit Eclipse, und wie sowas aussehen muss, weiß man eigentlich auch erst seit ungefähr 2000. Und vorher hatte niemand einen Grund, von LSP überhaupt zu träumen, denn LSP macht erst in einer IDE Sinn. Herrje, noch in den 80ern war selbst ein Parser etwas, was die CPU zum Anschlag bringen konnte...

Da muss dann ausgerechnet MS mit einer Implementierung ankommen. Verkehrte Welt. ;-)

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.

Und man *kann* das durchaus performant machen: Alle Interfaces zwischen Client und Server mit Value Types, Datenübergabe per Shared Memory.

Ah, die paar Bit Metadaten die da hin und hergeschoben werden, da braucht man so etwas nicht. Das ist auch so mehr als Performant genug.

Ich fürchte, bei JS ist die Performance schon ein Problem :-)
Und wenn man updatefähige Datenstrukturen verschiebt, kriegt man Locking in die Gleichung. Das ist nicht nur für Race Conditions anfällig, das erzeugt auch massenhaft Flaschenhälse, so dass die Maschine nur noch Uniprozessor-Leistung abliefern kann.

Die strenge Prozesstrennung zwischen Code Editor und semantischer Inhaltsanalyse braucht vielleicht ein paar MB mehr Speicher, aber das ist heutzutage zu verschmerzen. Dafür lässt sich das Analyse-Backend von verschiedenen Editor Clients nutzen, ohne dass diese das selbst implementieren müssten. Ein riesen Win!

Das ginge ja im Prinzip auch mit einer dll/so.

Erlang funktioniert nur so, und obgleich es eine rein interpretierte Sprache ist, hat es mit ein paar Fantastilliarden parallelen Prozessen auf der gleichen CPU keinerlei Probleme.

Ja, Prozesse kann Erlang. Aber Berechnungen sollte man tunlichst von externen nativen Libs durchführen lassen, da die Sprache an sich extrem langsam ist (Das letzte mal als ich geschaut habe war das glaube ich laut Benchmarkgame eine ganze Größenordnung langsamer als Python, welches ja schon schnarchlangsam ist).

Autsch. Das hätte ich nicht erwartet.

In Javascript geht das alles halt nicht: Objekte sind an den Interpreter gekoppelt und können nicht per SHM übergeben werden, Value Types sind schon im Konzept von Javscript nicht vorgesehen.

Naja, was nicht ist, kann ja noch werden: "const" gibt es ja mittlerweile, das ließe sich ggf. zu Value-Objekten erweitern (von Value-Types will ich nicht sprechen, da JS schließlich eine "mono-typed language" ist [ https://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/ ]).

Na ja, ein dynamisches Typsystem per Monotype zu einem statischen zu erklären verfehlt den Kern der Sache ja.
Aber JS ist halt eine prototypbasierte Sprache, keine objektorientierte. Und prototypbasierte Sprachen haben per Definition ein dynamisches Typsystem.

Und wenn Atom immer noch langsam ist, dann sind die ganzen Versprechen von wegen "wir kriegen JS auf anständige Performance optimiert" wohl etwas zu... optimistisch? ... gewesen.

Naja, JS an sich ist gar nicht sooo langsam. (Ich weiß gewagte Aussage, aber man suche mal nach Benchmarks zwischen gleichen Programmen auf der JVM und auf Node.js; ich habe selbst kaum glauben können was ich da gesehen habe; aber sowohl der JVM- als auch die JS-JITs sind halt durchaus sehr leistungsfähig)!

Hm... na ja... in ein beiden Sprachen sind bestimmte Optimierungen wegen allzugroßer Dynamik unmöglich. In Java wegen der zur Laufzeit neu entstehenden Datentypen (i.d.R. wegen Nachladen), in Javascript wegen der sich zur Laufzeit verändernden Datentypen (die dort "Prototyp" heißen).
Man kann da mit hohem Aufwand auch die "unmöglichen" Optimierungen durchführen, aber das steht und fällt mit der Fähigkeit zur statischen Analyse. Am Ende stehen dann lange Anleitungen, was der Programmierer tun und was er bleiben lassen soll, damit die Optimierer sich noch auskennen, und man hat doch wieder das Äquivalent eines statischen Typsystems... immerhin gewinnt man die Möglichkeit, auf die Performance zu verzichten, wenn die Flexibilität wichtiger ist, aber diesen Trade-off kann man nicht sehr gut steuern.

Das Problem ist das DOM. Das DOM ist langsam. Sehr langsam.

Wobei man auch hier wieder differenzieren muss:

Solange man die gerenderte Repräsentation des DOM nicht anfasst, ist alles in Ordnung. Aber in dem Moment in dem man diese Repräsentation vermessen, oder gar manipulieren will, wird es zäh. Eine Operation auf einem mit dem Rendering verbundenen DOM-Fragment im Vergleich zu der selben Operation auf einem nicht "eingehängten" DOM-Fragment kann gern mal um den Faktor 1000 langsamer sein.

Das kann natürlich auch eine Rolle spielen.
Eine große, Faktor 1000 wundert mich da nicht.

Wenn man sich den in den Browsern eingebauten Profiler schnappt, und mal schaut was da Zeit frisst, dann wird man sehr schnell erkennen, dass es meist die "layout" Calls sind, die (im Vergleich) ewig brauchen (natürlich solange Netzwerklatenzen für's nachladen von Elementen keine Rolle spielen, die sind natürlich nochmal übler).

D.H. man würde durchaus performante Anwendungen in JS schreiben können, wenn man den ganzen HTML/CSS View Layer in die Tonne kloppen würde. Aber solche Mist-Konstrukte wie Electron die eine HTML Browser-Engine für die GUI nutzen, wird man NIE performant bekommen, das ist ein Dead-End.

Das kommt halt dabei heraus, wenn man eine Auszeichnungssprache für Hypertext Dokumente als Applikations-Framework missbraucht! (Wer für diese Entwicklung verantwortlich ist, sollte ins Abklingbecken von einem der Atommeiler geworfen werden, die gebaut werden müssen, um diese gigantische Ressourcenverschwendung mit Energie zu versorgen! Am besten mit einem Paar <a>-Tags an den Füssen ;-)).

:-D

Wobei das eigentlich zu beschleunigen sein müsste. Man verpasse dem DOM eine Transaktionslogik, so dass das Layouting erst dann aktiv wird, wenn der Editor sagt, dass er mit dem Ändern fertig ist.
Oder der Editor arbeitet auf einer Kopie des DOM und tauscht das komplette DOM aus, sobald er fertig ist. Mit etwas Optimierung nur bis hinauf zu dem Knoten, der tatsächlich eine Änderung braucht.

... hmm... das würde allerdings erklären, warum das Cursorblinken so teuer ist. Das ist ein Leaf Node, und wenn der Browser aus dem DOM nicht ablesen kann, dass der Cursor niemals Einfluss aufs Layout hat, dann wird mit jedem Ein- und Ausschalten des Balkens ein neuer Layout-Durchlauf fällig.
Das ist hässlich.

Bewerten
- +