Die am häufigsten mißverstandene Programmiersprache der Welt

Vorwort des Übersetzers

Douglas Crockford schrieb im Jahr 2001 einen in meinen Augen sowohl klugen als auch leidenschaftlichen Artikel über die in seinen Worten ... World's Most Misunderstood Programming Language.

Heute, 5 Jahre später, hat seine teilweise auch polemische Liebeserklärung an JavaScript im Grundsatz nichts an Aktualität eingebüßt - im Gegenteil. Und egal, wie man selber zu Schlagwörten wie Ajax oder Web 2.0 steht, sollte man das bei vielen wiedererwachte oder gerade geweckte Interesse an diesem riesigen und für Neulinge daher schwer zu überschauenden und noch schwieriger zu bestellenden Themenfeld nutzen, um überhaupt erst einmal über das im Sprachdesign steckende, im Sprachkern (ECMA-262) für die Allgemeinheit aber leider nur versteckt beschriebene, Potential von JavaScript aufzuklären.

Im Nachwort sollen noch ein paar entsprechende Gedanken anklingen.

Doch jetzt will ich Mr. Crockford auch deutschsprachig Gehör verschaffen. Ich habe versucht, so nah wie möglich an Douglas Crockfords Originalton zu bleiben. Wortgenau wurde nur dort übertragen, wo es paßte. Da fachliche Aussagen und andere Inhalte von mir nicht zurechtgebogen wurden, behaupte ich, daß die Übersetzung gut Douglas Crockfords damalige Intensionen widerspiegelt.

Überschriften und Fließtexte sind dem Original entnommen. Die exzessive Verlinkung zu überwiegend deutschsprachigen Wikipedia-Artikeln wurde von mir hinzugefügt, wie auch alle Marginalien. Anmerkungen meinerseits sind als solche gekennzeichnet.

Die Style-Optionen Ihres Browsers bieten die Möglichkeit, sich dieses Dokument sowohl nur im englischen Originaltext bzw. in der rein deutschen Übersetzung als auch in beiden Varianten gleichzeitig anzeigen und auch ausdrucken zu lassen. Die schon erwähnten Marginalien sind momentan nur in Browsern sichtbar, die selbständig Inhalte gemäß CSS 2.1 generieren können.

The World's Most Misunderstood Programming Language

JavaScript, auch bekannt als Mocha, LiveScript, JScript, (A. d. Ü.: ActionScript,) ECMAScript ist eine der am weitesten verbreiteten Programmiersprachen. Auf nahezu jedem PC dieser Welt läuft mindestens ein JavaScript-Interpreter. Die Popularität von JavaScript ist ausschließlich dem Einsatz als Scripting-Sprache des WWW geschuldet.

Trotz ihres Bekanntheitsgrades, wissen nur wenige, daß JavaScript eine sehr schöne, dynamische, objektorientierte, universelle Programmiersprache ist. Warum scheint dies immer noch ein Geheimnis zu sein? Warum wird diese Sprache so sehr mißverstanden?

Der Name

Das Vorwort »Java« legt nahe, daß JavaScript irgendwie mit Java verwandt sei, daß es sich um eine Teilmenge oder um eine weniger leistungsfähige Version von Java handele. Es scheint, dieser Name sei absichtlich gewählt worden, um zu verwirren. Verwirrung aber zieht Mißverständnis nach sich. JavaScript ist nicht interpretiertes Java. Java ist interpretiertes Java. JavaScript ist eine andere Sprache.

JavaScript mag sich in der Schreibweise genauso an Java anlehnen, wie sich Java an C anlehnt, ist aber ebenso wenig Teilmenge von Java, wie auch Java nicht Teilmenge von C ist. JavaScript ist sogar besser als Java, wenn man Anwendungen zugrunde legt, für deren Umsetzung Java (früher bekannt als Oak) ursprünglich vorgesehen war.

JavaScript wurde nicht von Sun Microsystems entwickelt, wo Java beheimatet ist. JavaScript wurde von Netscape entwickelt. Damals hieß es noch LiveScript, aber das war nicht verwirrend genug.

Das Hauptwort »Script« suggeriert, daß es sich nicht um eine richtige Programmiersprache handele, daß eine Skriptsprache weniger sei als eine Programmiersprache. Aber das ist nur eine Frage des Sprachdesigns. Im Vergleich zu C macht JavaScript Abstriche bei der Schnelligkeit zugunsten einer größeren Beweglichkeit und Ausdrucksstärke.

Lisp im Anzug von C

Die C-ähnliche Syntax von JavaScript, einschließlich der geschweiften Klammern und des klobigen »for«-Ausdrucks, lassen sie wie eine gewöhnliche prozedurale Sprache aussehen. Das aber ist irreführend, denn JavaScript hat viel mehr Gemeinsamkeiten mit Sprachen wie Lisp oder Scheme als mit C oder Java. Sie benutzt Arrays anstelle von Listen und Objekte anstelle von Eigenschaftslisten. Funktionen sind Elemente erster Klasse. JavaScript erlaubt »Closures« und »Lambda«-Ausdrücke.

Festgelegte Rolle

JavaScript war für den Netscape Navigator ausgelegt. Doch ihr dortiger Erfolg ließ sie zur Standardausrüstung fast aller Webbrowser werden. Diese Rolle wurde JavaScript nie wieder richtig los. Als »ewige Sissi« ist sie die Romy Schneider der Programmiersprachen. Dabei ist JavaScript gut gerüstet für eine Vielzahl von nicht webverwandten Anwendungen.

Versionenzoo

Die ersten JavaScript-Versionen waren noch ziemlich schlecht, denn sie ließen weder Ausnahmebehandlung noch innere Funktionen oder Vererbung zu. In seiner jetzigen Form handelt es sich aber um eine komplette, objektorientierte Programmiersprache. Viele Urteile stammen jedoch noch aus der Kinderschuhzeit dieser Sprache.

Die ECMA-Kommission, die für den Sprachstandard verantwortlich zeichnet, entwickelt in guter Absicht Erweiterungen, was aber eines der größten Probleme dieser Sprache eher verstärkt: Es gibt schon zu viele Versionen. Auch das stiftet Verwirrung.

Fehler im Sprachentwurf

Keine Sprache ist perfekt. JavaScript bekommt auch seinen Teil an Design-Fehlern ab. Zum Beispiel den sowohl für die Addition wie auch für die String-Verkettung überladenen »+«-Operator mit erzwungener Typumwandlung (A. d. Ü.: bei im Typ ungleichen Operanden). Oder den für Fehler anfälligen »with«-Ausdruck. Außerdem ist die Richtlinie zur Nichtanwendung reservierter Wörter viel zu streng. Die Regeln zum Setzen von Semikola waren ein genauso großer Fehlgriff wie die zur Literalnotation von regulären Ausdrücken. Diese Versehen führen immer wieder zu Programmierfehlern und haben schon den Sprachentwurf in seiner Gesamtheit in Frage gestellt.

Zum Glück lassen sich viele dieser Fallen mit einem guten »lint«-Programm entschärfen.

Das Gesamtkonzept des Sprachentwurfs ist trotzdem vernünftig. Überraschenderweise scheint die ECMAScript-Kommission nicht daran interessiert zu sein, die genannten Probleme zu korrigieren. Vielleicht ist sie auch mehr daran interessiert, neue zu verursachen.

Lausige Umsetzungen

Einige der frühen Umsetzungen von JavaScript waren ziemlich fehlerträchtig. Das rückte aber die gesamte Sprache in ein schlechtes Licht. Um es noch schlimmer zu machen, wurden diese Implementierungen in furchtbar fehleranfällige Webbrowser eingebaut.

Schlechte Bücher

Fast alle JavaScript-Bücher sind unzumutbar. Sie enthalten Fehler, schwache Beispiele und fördern schlechten Stil. Wichtige Sprachfähigkeiten werden oft sehr armselig beschrieben oder ganz unter den Tisch gekehrt. Ich habe dutzende JavaScript-Bücher bewertet und kann nur zwei wirklich empfehlen: »JavaScript The Definitive Guide (4th Edition)« (A. d. Ü.: die deutsche Ausgabe »JavaScript Das umfassende Referenzwerk« in der 4. Auflage) von David Flanagan und »Dynamic HTML (2nd Edition)« von Danny Goodman. Beide sind bei O'Reilly erschienen.

Standard mit Lücken

Die offizielle Spezifikation - »ECMA-262« - der Sprache wurde von der European Computer Manufacturers Association (ECMA) verabschiedet. Das Papier ist schwer zu lesen. Es zu verstehen ist noch viel schwieriger, was zur Existenz schlechter Fachliteratur beigetragen haben dürfte. Das Standarddokument war wenig hilfreich, um den Autoren als Grundlage für ein besseres Verständnis der Sprache zu dienen. ECMA und die TC39-Kommision (A. d. Ü.: »ECMA TC39« ist die bei der ECMA für Programmiersprachen zuständige Kommision) sollten peinlichst berührt sein.

Laien

Die meisten Leute, die JavaScript anwenden, sind keine Programmierer. Ihnen mangelt es an Ausbildung und Disziplin, um gute Programme schreiben zu können. JavaScript besitzt jedoch eine solch starke Ausdruckskraft, daß sie immerhin in der Lage sind, damit nützliche Dinge zu tun. JavaScript haftet trotzdem der Ruf an, nur von Amateuren benutzt zu werden und untauglich für professionelles Programmieren zu sein. Das aber ist schlicht und ergreifend falsch.

Objektorientiert

Ist JavaScript objektorientiert? In JavaScript gibt es Objekte als Träger von Daten, und es gibt Methoden, die auf diese Daten wirken können. Objekte können Träger anderer Objekte sein. JavaScript implementiert kein Klassenkonzept, erlaubt aber Konstruktoren, die das machen, was Klassen so tun, unter anderem auch um als Container für Klassen-Variablen und -Methoden zu dienen. In JavaScript erfolgt Vererbung nicht über Klassen, sondern über Prototypen.

Hauptsächlich lassen sich zwei Wege für den Aufbau von Objektsystemen beschreiten: Vererbung (»ist ein«) und Aggregation (»hat ein«). JavaScript kann beides, aber dank seiner Flexibilität tut es sich besonders bei der Aggregation hervor.

Viele sprechen JavScript eine echte OO ab, indem sie darauf verweisen, daß JavaScript Kapselung nicht unterstützte. Gemeint ist damit, daß sich in JavaScript weder private Variablen noch private Methoden realisieren ließen, alle Eigenschaften wären öffentlich. Es zeigt sich aber, daß JavaScript Kapselung ohne weiteres abbilden kann. Natürlich sehen das nur wenige. JavaScript ist eben die am häufigsten mißverstandene Programmiersprache der Welt.

Viele argumentieren, daß JavaScript nicht wirklich OO sein kann, da Vererbung nicht unterstützt würde. Im Gegenteil, JavaScript unterstützt nicht nur klassische (A. d. Ü.: gemeint ist hier klassenbasierte) Vererbung, sondern ermöglicht geradezu eine Vielfalt von Modellen zur Weiter- bzw. Mehrfachnutzung vorhandenen Codes.

Nachwort des Übersetzers

Seit Ende 2005 bittet Mathias Schäfer, der vielen besser als »molily« bekannt sein dürfte, den Patienten JavaScript immer mal wieder auf die Analysecouch. Die Frage-/Antwort-Protokolle veröffentlicht er dann regelmäßig im Weblog von SELFHTML. Diese sind nicht nur umfassend, sondern wirklich reflektiert und deshalb auch aufschlußreich.

Vor allem sein Mitte April erschienener Artikel »JavaScript und Webstandards« machte mir erneut bewußt, daß das über die letzten zehn Jahre erworbene Wissen vieler JavaScript- und Webentwicklungs-Veteranen zusammen mit all ihren gemachten Erfahrungen zwar als Selbstverständlichkeit in deren Köpfen und verteilt in Newsgroups, Foren, Boards, Blogs, online verfügbaren Tutorials bzw. Dokumentationen und in den wenigen guten Fachbüchern steckt, Anfängern und auch Fortgeschrittenen jedoch, wie von molily beschrieben, der Einblick in die Materie des Browser-Scriptings und ein klarer Blick auf ebendiese immer noch genauso schwer zu fallen scheint wie den heutigen Profis zu ihrer eigenen Anfangszeit.

molilys aktueller Artikel ergänzt meiner Meinung nach Douglas Crockfords Schrift in idealer Weise. Die abstrakten Betrachtungen beider Autoren zu JavaScript bieten Anfängern, Fortgeschrittenen und auch mit der Materie noch unvertrauten, in der Programmierung aber schon erfahrenen Quereinsteigern gute Einstiegs- bzw. Anknüpfungspunkte jenseits der schon oben erwähnten Quellen.

Um beide Autoren zu ergänzen, möchte ich zum Schluß noch ein paar eigene, jedoch noch nicht vollständig ausgegorene Gedanken in die Runde werfen.

Schon seit ein paar Jahren gab und gibt es technisch komplexe und aus Programmierersicht anspruchsvolle browserbasierte Webapplikationen. Zum Glück ist die Wahrnehmung und Akzeptanz solcher Anwendungen seit Google Mail, Google Maps und Flickr gestiegen. Spätestens mit der Etikettierung dieser Dienste als Web 2.0 und dem Ajax-Marketing-Coup dürften auch Entscheider mitbekommen haben, wohin die Reise gehen kann.

Anwendungen, die das JavaScript-Sprachkonzept ausreizen, indem sie sich aller im durch die ECMA standardisierten Sprachkern steckenden Mittel bedienen, sollten dann auch die ewigen, meist auf Unkenntnis basierenden Lästereien über diese moderne, schlanke und effektive, objektorientierte, prototypenbasierte Programmiersprache beenden.

Komplexe browserbasierte Anwendungen werden schon seit geraumer Zeit und in Zukunft vielleicht sogar ausschließlich mit den Mitteln moderner Softwareentwicklung (u.a. Entwurf, Programmierung, Test) geschaffen. Die Frameworks einiger mit ActionScript 2.0 (klassenimitierende IDE, trotzdem ECMA-basiert) umgesetzter Flashprojekte wurden vorher komplett mit UML beschrieben. Unittesting hat ebenfalls schon Einzug gehalten. Und einfache Entwurfsmuster finden sich seit Jahren in vielen Programmcodes, auch wenn deren Entwickler sich der Existenz ebensolcher Muster vielleicht nicht einmal bewußt waren.

Gerade weil es möglich und zunehmend populär geworden ist, auf Basis von Prototypen Klassenhierarchien und klassenbasierte Vererbung nachzubauen, sollte man nicht die in ihrer Flexibilität und Schlankheit liegende Stärke der Schnittstellen-Vererbung unterschätzen oder gar aus dem Auge verlieren. Während klassenbasierte Vererbung die Implementierung eines Objekts über die Einbindung eines anderen Objekts beschreibt, legt Schnittstellen-Vererbung fest, wann ein Objekt anstelle eines anderen verwendet werden kann. Dies geschieht über Delegation. Mehr als der durch die im Sprachkern für jedes "Function"-Objekt beschriebenen Methoden »apply« und »call« bedarf es dazu nicht. Beide ermöglichen es einem Objekt, auf die Methode eines anderen Objekts zuzugreifen und ebendiese geborgte Methode im Kontext des ausborgenden Objekts auszuführen.

Tiefere Einsichten dazu gewinnt man beim Lesen des Kapitels 1.6 des beim Verlag Addison Wesley erschienen Buches »Entwurfsmuster. Elemente wiederverwendbarer objektorientierter Software«. Speziell die Abschnitte 1.6.4 bis 1.6.6 befassen sich mit den vielfältigen Möglichkeiten Code zu recyceln. Die erst 2004 erschienenen deutsche Ausgabe ist sehr gelungene Übersetzung des schon 1995 von der sogenannten Viererbande geschriebenen Klassikers »Design Patterns«.

Zwei Leitsätze der »Gang of Four« für den erfolgreichen Einsatz von Entwurfsmustern lauten: Programmiere auf eine Schnittstelle hin, nicht auf eine Implementierung. (klassenbasierte vs. Schnittstellen-Vererbung) und Ziehe Objektkomposition der Klassenvererbung vor. (Vererbung vs. Komposition) - JavaScript unterstützt diese Programmierparadigmen.

Resümee

JavaScript existiert in seiner modernen Form seit knapp zehn Jahren und ist für die Zukunft bestens gerüstet. In den Zeiten von Mozilla als Entwicklungsplattform (XUL, XBL Bindings, XPCOM) von Konfabulator-/Yahoo!-Widgets und anderen Rich Internet Application-Frameworks wartet diese Sprache nur darauf, endlich von einer noch breiteren Entwicklergemeinde richtig ausgereizt zu werden.

The World's Most Misunderstood Programming Language

JavaScript, aka Mocha, aka LiveScript, aka JScript, aka ECMAScript, is one of the world's most popular programming languages. Virtually every personal computer in the world has at least one JavaScript interpreter installed on it and in active use. JavaScript's popularity is due entirely to its role as the scripting language of the WWW.

Despite its popularity, few know that JavaScript is a very nice dynamic object-oriented general-purpose programming language. How can this be a secret? Why is this language so misunderstood?

The Name

The Java- prefix suggests that JavaScript is somehow related to Java, that it is a subset or less capable version of Java. It seems that the name was intentionally selected to create confusion, and from confusion comes misunderstanding. JavaScript is not interpreted Java. Java is interpreted Java. JavaScript is a different language.

JavaScript has a syntactic similarity to Java, much as Java has to C. But it is no more a subset of Java than Java is a subset of C. It is better than Java in the applications that Java (fka Oak) was originally intended for.

JavaScript was not developed at Sun Microsystems, the home of Java. JavaScript was developed at Netscape. It was originally called LiveScript, but that name wasn't confusing enough.

The -Script suffix suggests that it is not a real programming language, that a scripting language is less than a programming language. But it is really a matter of specialization. Compared to C, JavaScript trades performance for expressive power and dynamism.

Lisp in C's Clothing

JavaScript's C-like syntax, including curly braces and the clunky for statement, makes it appear to be an ordinary procedural language. This is misleading because JavaScript has more in common with functional languages like Lisp or Scheme than with C or Java. It has arrays instead of lists and objects instead of property lists. Functions are first class. It has closures. You get lambdas without having to balance all those parens.

Typecasting

JavaScript was designed to run in Netscape Navigator. Its success there led to it becoming standard equipment in virtually all web browsers. This has resulted in typecasting. JavaScript is the George Reeves of programming languages. JavaScript is well suited to a large class of non-Web-related applications.

Moving Target

The first versions of JavaScript were quite weak. They lacked exception handling, inner functions, and inheritance. In its present form, it is now a complete object-oriented programming language. But many opinions of the language are based on its immature forms.

The ECMA committee that has stewardship over the language is developing extensions which, while well intentioned, will aggravate one of the language's biggest problems: There are already too many versions. This creates confusion.

Design Errors

No programming language is perfect. JavaScript has its share of design errors, such as the overloading of + to mean both addition and concatenation with type coercion, and the error-prone with statement should be avoided. The reserved word policies are much too strict. Semicolon insertion was a huge mistake, as was the notation for literal regular expressions. These mistakes have led to programming errors, and called the design of the language as a whole into question.

Fortunately, many of these problems can be mitigated with a good lint program.

The design of the language on the whole is quite sound. Surprisingly, the ECMAScript committee does not appear to be interested in correcting these problems. Perhaps they are more interested in making new ones.

Lousy Implementations

Some of the earlier implementations of JavaScript were quite buggy. This reflected badly on the language. Compounding that, those implementations were embedded in horribly buggy web browsers.

Bad Books

Nearly all of the books about JavaScript are quite awful. They contain errors, poor examples, and promote bad practices. Important features of the language are often explained poorly, or left out entirely. I have reviewed dozens of JavaScript books, and I can only recommend two: JavaScript: The Definitive Guide (4th Edition) by David Flanagan and Dynamic HTML (2nd Edition) by Danny Goodman. Both are from O'Reilly.

Substandard Standard

The official specification for the language is published by ECMA. The specification is of extremely poor quality. It is difficult to read and very difficult to understand. This has been a contributor to the Bad Book problem because authors have been unable to use the standard document to improve their own understanding of the language. ECMA and the TC39 committee should be deeply embarrassed.

Amateurs

Most of the people writing in JavaScript are not programmers. They lack the training and discipline to write good programs. JavaScript has so much expressive power that they are able to do useful things in it, anyway. This has given JavaScript a reputation of being strictly for the amateurs, that it is not suitable for professional programming. This is simply not the case.

Object-Oriented

Is JavaScript object-oriented? It has objects which can contain data and methods that act upon that data. Objects can contain other objects. It does not have classes, but it does have constructors which do what classes do, including acting as containers for class variables and methods. It does not have class-oriented inheritance, but it does have prototype-oriented inheritance.

The two main ways of building up object systems are by inheritance (is-a) and by aggregation (has-a). JavaScript does both, but its dynamic nature allows it to excel at aggregation.

Some argue that JavaScript is not truly object oriented because it does not provide information hiding. That is, objects cannot have private variables and private methods: All members are public.

But it turns out that JavaScript objects can have private variables and private methods. (Click here now to find out how.) Of course, few understand this because JavaScript is the world's most misunderstood programming language.

Some argue that JavaScript is not truly object oriented because it does not provide inheritance. But it turns out that JavaScript supports not only classical inheritance, but other code reuse patterns as well.

Peter Seliger - Hamburg, den 1. Mai 2006 - pseliger@gmx.net

-- 
»Because objects in JavaScript are so flexible, you will want to think differently about class hierarchies. Deep hierarchies are inappropriate. Shallow hierarchies are efficient and expressive.« (Douglas Crockford about inheritance in JavaScript.)