Standortbestimmung: Programmierparadigmen, OOP, OOP in JS ...

[peterS.]

gruss Flo,

kampfeslustige gruesse.
Die gebe ich doch gleich mal zurück :-)

naja, so richtig kaempfen willst Du aber nicht.

Tut mir ja leid aber ich habe viel am Hut zur Zeit

lass mal gut sein. Du stellst Dich auf mehreren ebenen einer
grundsatzdiskussion, obwohl Du nicht gerade sanft angefasst
wurdest und Deine arbeit noch nicht umfassend gewuerdigt bzw.
zerrissen oder auch nur ignoriert wurde.

aha ... C#, Java ... Du benötigst also Kapselung und Vererbung?
genauer gefragt - Du vermisst die klassenbasierte Vererbung
statischer Sprachen?

Ja in der Tat, obwohl ich Projekte in kleineren Rahemn auch gerne
mit den Bordmitteln von Javascript umsetzte. Aber gerade in größeren
Projekten erschwert eine nicht statische struktur doch die Lesbarkeit
und die Wartbarkeit von Code. ...
so dass man eigentlich zwansgläufig auf ein Framework zurückgreift,
dass ein scopse kapselung und eine statische Vererbung bereitstellt.

so schlimm ist das nicht - wirklich grosse JavaScript projekte werden
eher durch die abwesenheit etablierter entwicklungsumgebungen behindert,
die dieser sprache standardbibliothek(en), module und pakete beibiegen.

Zumal kenne ich mindestens so viele Webentwickler wie Java Entwickler
und mir ist doch aufgefallen das sich die Mehrheit in statischen
vorgegebenen Strukturen wohler fühlen ...

und ich kenne Ruby-Goetter und Rails-Entwickler, die heisse affaeren
mit server- und clientseitigem JavaScript haben/hatten, weil es sich
so *vetraut* anfuehlt ;-)

Aber vieleicht ist man ja auch als Javascript Programmierer ein wenig
Eitel und Stolz darauf das man die vielen dynamischen Konzepte in
gegensatz zu anderen Programmieren durschaut hat und deshalb die
statische Welt garnicht in JS haben will.

um gotteswillen ... nein. als "taeglich-brot-frontendler" ist man
absolut geerdet, was den einsatz von JavaScript angeht.

die wirklich geilen sachen der letzten Jahre wurden allesamt von
Ruby-, Phyton-, Erlang- und, ja auch von JavaScript-Entwicklern
angestossen.

Naja aus dem Potential ergeben sich die Möglichkeiten, das hat die
Vergangenheit schon oft gezeigt. Und ich find gerade jetzt wo das Web
immer mehr kann ... , sehe ich eigentlich keinen ausweg als, dass die
Objektsysteme in JS immer mehr wachsen und komplexer werden.

dazu braucht es aber keine klassen. das blaeht. JavaScript ist eine
DELEGATIONssprache. FUNKTIONen sind vollwertige OBJEKTe.

nur auf diesen beiden sprachmerkmalen aufbauend lassen sich die frei
haus gelieferte prototypische VERERBUNG und die funktionale KAPSELUNG
ohne metaprogrammierung um MEHRFACHVERERBUNG ueber TRAITs bzw. MIXINs
aufbohren. EVENTsysteme, wie PUBLISH-SUBSCRIBE oder das meiner meinung
nach elegantere SIGNAL-SLOT-Konzept sind mit dem aufwand eines MODUL-
patterns und eines in ihm gekapselten mixins ebenfalls ohne meta-
prgrammierung machbar. grundlagen der ASPEKT Orientierten Programmierung
giesst man sich ueber [Function.prototype] elegant und einfach ueber
METHOD MODIFIER ein.

mir scheint, dass mit einem verzicht auf klassen auch der starke hang
zur typsicherheit abnimmt.

mit dem konsequenten verzicht auf konstruktoren fuer eigene objekttypen
entfiele in JavaScript auch der irrglaube ueber >>obj.prototype.constructor<<
etwas ueber die natur von >>obj<< zu erfahren<<. sobald mehrfachvererbung
ins spiel kommt, hilft auch >>obj instanceof MyConstructor<< nicht weiter.

eingebaute TYPSICHERHEIT ist ueberschaetzt - nur richtig geschriebene TESTS
messen die qualitaet des codes zuverlaessig.

DUCKTYPING liefert hinreichend genaue angaben darueber, was ein objekt kann.
der >>typeof<< operator sowie >>Object.prototype.toString.call(obj)<< sind
wasserdichte indikatoren fuer die in JavaScript eingebauten Kernobjekte.

in diesen grundlagen steckt enorm viel potential. man sollte die intelligenz
von klassisch geschulten programmierern nicht beleidigen, indem man ihnen
immer wieder dieselbe kost vorsetzt. ausserdem bin ich der meinung, dass
die menge X an produzierten code in einer zeit Y mit naturnah gekloeppelten
JavaScript sich nicht wesentlich von der unterscheidet, die auf einem
klassenemulierenden framework aufsetzt. man muss sich einarbeiten. trotzdem
schreibt man auch dort immer noch JavaScript. ausserdem laesst man sich, ob
man will oder nicht, auf einen anstrengenden dauerspagat zwischen der wahren
natur dieser sprache und dem was das framework ihr vorgibt zu sein ein.

entscheidend fuer einen effektiven code output in grossen teams und/oder auf
grossen JavaScript-projekten ist dann doch eher die IDE.

Und währe da nich eine statische Vererbungshierarchie nicht eine
großartige Erweiterung von JS. Nicht ohne grund sind private, protected
public sowie super und class weiterhin reservierte Worte der ECMA5 spec

polemik: dass ist nur altlast, die zum glueck verhindert, dass exakt dieses
wording durch pseudoklassische vererbungstrojaner mit falschen versprechungen
von hinten wieder in JavaScript eingekippt wird.

so long - peterS. - [e-mail]