Hinweis Übersetzer:
Kürzlich eröffnete NodeJS-Erfinder Rain Dahl die HolyJS-Konferenz in St. Petersburg. Und ich erinnerte mich, dass ich eine unveröffentlichte Übersetzung aus seinem Blog hatte und beschloss, sie zu veröffentlichen. An einigen Stellen ist die Übersetzung ziemlich offen. Ich hoffe du wirst interessiert sein. Das Erscheinungsdatum für diesen Artikel ist Oktober 2011. Das Erscheinungsdatum für NodeJS ist der 27. Mai 2009.Es ist auf fast jeder Schicht unnötig und kompliziert. Das Beste, was ich tun kann, ist, jemandem zu der schnellen und einfachen Lösung des Problems zu gratulieren, angesichts der Scheiße, die er liefert. Die einzige Software, die ich liebe, ist, dass ich sie leicht verstehen kann und meine Probleme löst. Die Schwierigkeit, die ich ertrage, ist proportional zur Größe des Problems, das gelöst werden muss.
Ich glaube, ich habe im letzten Jahr endlich die Unix-Ideale verstanden: Dateideskriptoren und -prozesse werden mit C orchestriert. Dies ist eine großartige Idee. Damit haben wir es aber nicht zu tun. Komplexität wurde nicht impliziert. Im Gegenteil, ich muss mich mit DBus, / usr / lib, Boost, ioctls, SMF, Signalen, flüchtigen Variablen, Prototypvererbung, _C99_FEATURES_, dpkg und autoconf befassen.
Diejenigen von uns, die Software über diese Systeme schreiben, erhöhen die Komplexität. Jetzt müssen Sie nicht nur $ LD_LIBRARY_PATH kennen, damit das System funktioniert, sondern auch $ NODE_PATH - wissen Sie, das ist mein Geschäft, das ist meine zusätzliche Komplexität! Benutzer - diejenigen, die eine Webseite sehen möchten - kümmern sich überhaupt nicht darum. Es ist ihnen egal, wie wir / usr organisieren, es ist ihnen egal, wie Zombie-Prozesse funktionieren, sowieso funktioniert das Hinzufügen von Befehlen in Bash, egal wie zlib statisch oder dynamisch mit Node verknüpft ist. Es wird eine Zeit kommen, in der die akkumulierte Komplexität unserer vorhandenen Systeme größer sein wird als die Komplexität der Erstellung eines neuen Systems. Wenn dieser Moment kommt, wird all diese Scheiße in den Müll gehen. Wir können Boost und Glib und Autoconf auf die Toilette spülen und denken nie an sie.
Diejenigen unter Ihnen, die immer noch gerne die Details einer Programmiersprache lernen - zum Beispiel diejenigen, die gerne wissen, wie man sagt, ob NaN null ist oder nicht -, verstehen nicht einmal, wie verdammt es ist. Wenn Sie der Meinung sind, dass es schön wäre, alle gleichen Zeichen in Ihrem Code auszurichten, wenn Sie Zeit damit verbringen, Ihren Fenstermanager oder Editor einzurichten, wenn Sie Unicode-Häkchen in den Testläufer einfügen, wenn Sie unnötige Hierarchien in Ihre Codeordner einfügen, wenn Sie dies tun Zumindest etwas anderes als das Lösen des Problems - Sie verstehen nicht, wie langweilig es ist. Niemand kümmert sich um das glib-Objektmodell.
Eine Sache, die bei der Softwareentwicklung wichtig ist, ist, wie sich der Benutzer fühlt (Erfahrung des Benutzers).