Worauf hat die Welt denn beinahe so dringend gewartet wie auf einen eingebildeten Berg? Richtig: Auf Atom.
Atom – ich meine ausnahmsweise nicht die Energiequelle – ist ein von GitHub, einem großen Anbieter für fremden Quellcode aller Art, entwickelter Texteditor, der beinahe aussieht wie das recht beliebte Sublime Text und auch ähnlich funktionieren soll, allerdings kostenlos und quelloffen angeboten wird. (Einen ähnlichen Versuch, allerdings mit geringerer medialer Aufmerksamkeit, startete vor einer Weile Adobe mit Brackets.)
„Kostenlos“ ist ja eines der Lieblingswörter von Mitmensch Internetnutzer in seiner Gratiswolke. Qualität gern, aber lieber was geschenkt. Folgerichtig wird TextMate, eines der Vorbilder von Sublime Text, in der Version 2.0 ebenfalls – bezeichnenderweise auf GitHub – gratis zur Verfügung gestellt.
Ein großes Manko von TextMate ist, dass es ausschließlich für Mac-OS-X-Systeme entwickelt wird:; ebenso wie der Atom-Editor übrigens. Trotzdem sind bloggende Entwickler (oder Gelegenheitsskripter) begeistert und freuen sich, dass sie jetzt einen Editor, der auch nicht mehr kann als seine Vorbilder, nicht mehr mühsam erbetteln müssen:
Bisher musste man um einen Beta-Key betteln, wenn man sich die neuste Entwicklung aus dem Hause Github anschauen wollte.
Auch bei heise.de ist man beeindruckt:
Der auf Googles Chromium basierende und Node.js als Backend nutzende JavaScript-Editor soll die besten Eigenschaften anderer Texteditoren kombinieren. Die Entwickler zogen hier den Komfort von Sublime und TextMate sowie die Flexibilität und Erweiterbarkeit von Emacs und Vim heran, die sich aber allesamt nur mit speziellen Skriptsprachen anpassen ließen und nicht allzu intuitiv seien.
Nun, an einer Erneuerung von Vim wird ja ebenso gearbeitet wie an Emacs-Versionen, die das Skripten einfacher machen sollten, etwa mit einem Wechsel der Skriptsprache von Emacs Lisp zu Scheme. Ein Editor, der die Vorteile der bekannten Editoren miteinander verbindet, ohne einen ihrer Nachteile zu übernehmen, klingt zwar zumindest in der Theorie interessant, aber dafür müsste er sich erst einmal positiv von anderen Editoren abheben.
Womit aber will Atom das schaffen?
Die Website sagt zum Beispiel:
Our goal is a deeply extensible system that blurs the distinction between „user“ and „developer“.
Der Editor soll also von jedem Benutzer einfach und komplett frei skriptbar sein. Das sind Vim, Emacs und dergleichen zwar auch, aber sie benutzen nicht so schöne Werbephrasen dafür.
Atom comes loaded with the features you’ve come to expect from a modern text editor.
Atom bringt also alle Funktionen mit, die Editoren wie Notepad++ auch mitbringen. Das ist wirklich sehr praktisch, aber auch nicht innovativ.
Wo bleiben nun die Innovationen? Na, weiter oben:
Atom is a desktop application based on web technologies.
Tatsächlich: Atom basiert auf Chromium. Auf einem Webbrowser. Ein Texteditor, der auf einem Webbrowser basiert. Ein einfaches Werkzeug, das auf einer komplexen, schweren Plattform steht. Ein Texteditor, der Facebook kann. Atome hatte ich mir ja immer als etwas sehr Kleines vorgestellt, aber ich habe noch nie ein Atom gesehen. Vielleicht lag ich da falsch.
Aber die Entwickler haben sich auch etwas dabei gedacht, denn so können sie statt statischen, plattformabhängigen Codes in ihrem Texteditor, der nur unter Mac OS X läuft, plattformunabhängige Pakete entwickeln, die die Leistungsfähigkeit des Editors enorm erhöhen. Zum Beispiel Metrics. Metrics ist ein wohl standardmäßig aktives Paket, das essenzielle Editorfunktionen enthält: Es sendet Benutzerdaten zwecks Auswertung an Google Analytics (provokant gesagt also wahrscheinlich an die NSA).
Das tun andere Editoren tatsächlich meist nicht. Man kann das Paket zwar deaktivieren – dafür aber muss es erst einmal aktiv gewesen sein. Das also sind alle Funktionen, die ich von einem modernen Texteditor erwarte. Ob er wohl auch Texte editieren kann? Die Website schweigt sich aus.
Der Editor des 21. Jahrhunderts, fast so groß wie OpenBSD. Ich fand das letzte Jahrhundert irgendwie besser.
Um also die Diskussion von Twitter fortzuführen. Ich beziehe mich mal für die Definition von Bloatware auf die Wikipedia.
„Als Bloatware (engl. to bloat „aufblähen“), selten als Blähware oder Fatware[1], wird Software bezeichnet, die mit Funktionen überladen ist bzw. die Anwendungen sehr unterschiedlicher Arbeitsfelder ohne gemeinsamen Nutzen bündelt (siehe: eierlegende Wollmilchsau).“
Natürlich haben emacs und Atom ein Plugin-System, um das mehr oder weniger zu steuern. Also könnte man nun das Bloating beiden Editoren vorwerfen, oder keinem.
Und zur Tatsache, dass du Bloat mit Speicherverbrauch gleichsetzt, nun: Atom verbraucht 30MB Speicher, ja. Aber in Anbetracht der Tatsache, dass du heutzutage kaum noch Computer mehr mit weniger als 4GB Speicher kaufen kannst, alleine weil das Betriebssystem so rumbloated, macht die Tatsache, dass ein Editor es wagen kann, 1% des Gesamtspeichers zu nutzen den Braten jetzt auch nicht mehr fett.
Auf deinem Screenshot war klar ein OS mit GUI zu sehen, vermutlich ein Windows. Wieviel Speicher verbraucht das denn so, wenn es gestartet und eingeloggt ist, aber sonst keinerlei Dienste im Hintergrund laufen? Mit Sicherheit mehr als 1% des Hauptspeichers, und dennoch nutzt du es, ohne dich selbst des Bloatings anzuklagen.
Die Wurzeln von GNU emacs reichen bis 1984 zurück, die Wurzeln von emacs als Macrosammlung bis 1976. Ich geh jetzt mal davon aus, dass die Punkte in den Zahlenangaben Dezimalpunkte sind, denn sonst hättest du den eleganten Speicherverbrauch von 50MB, und würdest dich selbst disqualifizieren. Nun, also eine Auslastung von 50kB. Legen wir dem Entwicklerteam von emacs mal einen guten Programmierstil zugegen, und behaupten, dass sich das Programm in den letzten 30 Jahren nicht signifikant aufgebläht hat (wie du schon sagtest, keine Bloatware). Ich geh mal davon aus, dass emacs in den 80er Jahren also mal so grob 45kB Hauptspeicher belegt hat.
Nun gehen wir mal, aus Gründen der Fairness, davon aus, dass ein hypothetischer User im Jahre ’84 emacs auf seinem PC ausführen wollte, und nicht auf irgendeinem Mainframe. In den 80er Jahren lag die typische Arbeitsspeichergröße irgendwo zwischen 64kB in einem C64 und 512kB in einem Amiga 500. Das hieße: emacs hat kurz nach seinem initialen Release irgendwas zwischen 11 und 70% des damaly üblichen Sets an Hauptspeicher verbraucht. Atom hat kurz nach seinem initialen Release irgendwas zwischen 1% (4GB RAM) und 0,25% (16GB RAM) des verfügbaren Hauptspeichers benötigt.
Und du willst mir ernsthaft erzählen, Atom würde bloaten? Setze die Relationen, und überdenk die Aussage.
Ja, natürlich, wir haben nicht mehr die 80er Jahre, also fällt der Speicherverbrauch von 50kB nicht mehr so stark ins Gewicht. Aber wir haben auch nicht mehr den Beginn der 2000er Jahre, wo ein Speicherverbrauch von 30MB groß ins Gewicht fallen würde.
Und dein anderes Argument, man müsse eine komplette Browserumgebung laden, um ein Textfile editieren zu können, stimmt zwar, aber lässt sich auch in Relationen setzen. Aber wenn man sich mal die Dependencies eines emacs anguckt… libc6, libncurses, libpng, libtextbuf, libpango, die zlib…man muss einmal die kompletten Libraries laden, um nur mal eben ein Textfile editieren zu können. Das hätte man aber auch eleganter und weniger bloatend lösen können, oder? Once again, check die Relationen. Die Libraries von emacs zu laden war einst bestimmt auch genau so #aufschrei-Induzierend wie heute das Webkit. Das hätte man ja auch besser lösen können, mit ner nativen Anzeigeengine, oder damals einfach alles statisch linken, oder kurzerhand selbst reinhacken können.
Zu deiner Mac-OS-Only-Argumentationen gibt es mittlerweile mehrere Builds für alle Systeme, auf denen Node läuft, also dürfte das auch widerlegbar sein, und zu dem Spywarevorwurf..ja klar, ist aber deaktivierbar, und es soll ja Leute geben, deren Menge mit der Menge der Leute, die über GA besorgt sind, relativ konjunkt ist, die einfach den Zugriff auf die Google-Analytics-Server in ihrer /etc/hosts (oder woauchimmer das betriebssystemspezifisch definiert wird) unterbunden haben, bzw den DNS-Record umgebogen haben, sodass ich mir über das Problem ehrlich gesagt noch gar keine Gedanken gemacht habe.
Aber ich möchte hier auch keinen Flame- oder Editor-War starten. Es möge jeder genau die Software nutzen, mit der er glücklich wird. Wieso auch nicht?
Und übrigens: Ich mag Wurst.
Nehmen wir mal die beiden Editoren (aktuelle „finale“ Versionen) ohne Extraplugins.
Bloat von Emacs: Ein Psychotherapeutenskript. Hui.
Bloat von Atom: Chromium, das allein über 100 MiB des Downloads ausmachen dürfte.
Möchtest du das in LoC haben oder genügt es dir auch so?
Wie gesagt: Dann nutz‘ doch Eclipse, das kann auch alles, hat keinen Webbrowser, braucht ewig zum Laden und frisst RAM wie blöde, aber sind ja nicht mehr die 80er, man muss ja mit der Zeit gehen.
Variiert. (Irgendwelche Dienste laufen ja immer.)
Emacs läuft übrigens auch ohne GUI (die ersten Versionen hatten gar keines, dein Vergleich ist also gar keiner). Und Atom so?
Jedenfalls die von dir selbst kompilierte Version – das kann stark variieren. Und: RAM-Größe wächst exponenziell, Menge an Editorfunktionen aber nicht. Überdenk‘ die Aussage.
(Und: GB? Nicht eher MB?)
„Wir haben mehr RAM, also belegen wir den auch, obwohl wir auch mit weniger RAM mehr Funktionen haben könnten! Weil wir ein neues Jahrtausend haben!“
Irgendwo fehlt mir da die Kausalität.
Das sind deutlich weniger „Dependencies“ als der Chromium-Quatsch allein besitzt, der in Atom drin ist. Übrigens ist zum Beispiel die libpng optional – hast du sie nicht, gehen halt keine Inline-PNGs. (Ich würde das nur im Twittering-Mode überhaupt bemerken; oder sind das JPEGs? Dann gar nicht.) Was macht Chromium, wenn ihm eine Abhängigkeit fehlt? Nein, lass‘ mich raten … streiken, richtig?
ncurses in einem CLI-Editor: Sinnvoll.
Webkit in einem Editor: Wofür, zum heiligen Henker?!
Äpfel. Birnen. Wie immer.
Hätte sich super auf die Portabilität ausgewirkt. Bemerkt man gerade bei Atom.
„Da hat zwar wer reingekackt, aber wenn man nach dem Reintreten alles sauber wischt, merkt man es gar nicht mehr.“
Super!