Zuckersyntax in JavaScript

[Gast]

PHP war übrigens ursprünglich mal eine Template-Sprache und OOP wurde nur nachträglich drauf gesetzt. Demnach sollte man PHP also auch nicht für OOP verwenden, weil es nicht der Idee dieser Sprache entspricht?

Das ist etwas anderes - PHP hatte anfangs überhaupt kein Paradigma - außer man möchte prozedural hier als Paradigma ansehen. Dort hat man sich für OOP entschieden.

OOP hat ja gegenüber FP (funktionaler Programmierung) den Vorteil der Performance. Über eine Schleife zu iterieren und nur Werte im Speicher anzupassen, verbraucht nun mal weniger Ressourcen als Rekursion. Heutzutage spielt das immer weniger eine Rolle (Ich rede von Mainstream-Development, und komme mir bitte keiner mit irgendwelchen Mikrooptimierungen.)

Bei Javascript war das halt nicht so. Dort lag von Anfang an der Fokus auf FP. Als "OOP" gibt es dort die Prototypen. Die Sache, warum dort nun auch Klassen Einzug gehalten haben, ist, dass es nun mal die einzige weit verbreitete Sprache für Browser ist. Das führt dazu, dass es von einer breite Masse benutzt wird. Und wenn wir ehrlich sind, lernt man überall nur OOP. Auf FP stößt man i. d. R. erst später. Dadruch kennen viele auch die Vorteile von FP nicht und denken, OOP ist das Maß aller Dinge. Nicht umsonst erfährt FP gerade eine Renaissance. Und ich prophezeie, dass das mit steigender Professionalisierung zunehmen wird.

Und aufgrund dieser Forderung der breiten Masse wurden halt die Klassen eingeführt, obwohl es bei JS eher wenig Sinn gemacht hat.


EDIT: Und nur, weil irgendetwas von einer Sprache unterstützt wird, heißt das nicht, dass man es auch benutzen muss. Ich sage nur mal php-cli...

[hellbringer]

JavaScript ist auch funktional, aber eben nicht nur. JavaScript nur darauf zu beschränken ist halt sehr engstirnig. Der Vorteil von JavaScript ist die Vielseitigkeit. Man kann JavaScript sowohl funktional, als auch prozedural und objektorientiert einsetzen. Je nachdem, was für die jeweilige Aufgabe mehr Sinn macht.

Davon abgesehen verändern sich Programmiersprachen mit der Zeit. Zum Beispiel haben in PHP und anderen Sprachen auch Lambda-Funktionen Einzug gehalten, die ja eher aus der funktionalen Welt kommen. Was die Programmiersprachen im Endeffekt flexibler macht. Zu sagen, man verwendet irgendein Feature nicht, weil es das ja vor 10 Jahren auch nicht gegeben hat, ist eine sehr konservative Einstellung, die einem in der schnelllebigen IT-Welt auf Dauer nur selbst behindert.

[Gast]

Zu sagen, man verwendet irgendein Feature nicht, weil es das ja vor 10 Jahren auch nicht gegeben hat, ist eine sehr konservative Einstellung, die einem in der schnelllebigen IT-Welt auf Dauer nur selbst behindert.

Davon habe ich nicht gesprochen. Was ich geschrieben habe, ist, dass Klassen in Javascript eingeführt wurden, obwohl es nicht notwendig gewesen ist.

Der Vorteil von JavaScript ist die Vielseitigkeit. Man kann JavaScript sowohl funktional, als auch prozedural und objektorientiert einsetzen.

Ja, und in PHP, Python und fast überall kannst Du auch prozedural programmieren und seltsamerweise machen die Leute es trotzdem nicht, sondern orientieren sich am Fokus der jeweiligen Sprache. Javascript wurde in den ganzen Jahren nicht in Hinblick auf OOP weiter entwickelt. Das wurde erst mit den Klassen irgendwie hineingeklöppelt.

Genauso sind Lambdas, Closures und was in Richtung FP geht, auch in PHP nicht wirklich optimal integriert.

Ich wüsste auch nicht, was gegen eine konservative Einstellung spricht. Was Du meinst, ist Sturheit und davon distanziere ich mich vehement. Ich finde es eher "konservativ", Konstrukte in eine Sprache zu bauen, wo sie nicht notwendig sind, einfach nur, um sie zu haben.

[ChookaP]

Es macht doch von der Lesbarkeit mehr Sinn eine Klasse zu definieren und darin die jeweiligen Funktionen zu implementieren und dann ein neues Objekt zu erzeugen. Anstelle von Funktion Daddy(){ Funktion child1(), Funktion child2(), ... }, auch wenn class Daddy{Konstruktor{this.a, this.b,...} funktion Daddy1{}, .... } nicht wirklich das abbilden was eine Klasse ausmacht ... momentan komme ich damit aber gut zurecht bzw. gefällt mir.

[Gast]

Es macht doch von der Lesbarkeit mehr Sinn eine Klasse zu definieren und darin die jeweiligen Funktionen zu implementieren und dann ein neues Objekt zu erzeugen. Anstelle von Funktion Daddy(){ Funktion child1(), Funktion child2(), ... }, auch wenn class Daddy{Konstruktor{this.a, this.b,...} funktion child1{}, .... } nicht wirklich das abbilden was eine Klasse ausmacht ... momentan komme ich damit aber gut zurecht bzw. gefällt mir.

Nee, das hat damit gar nichts zu tun. Was Du da beschreibst, ist nichts anderes, als Funktionen in ein Objekt zu drücken. Bei funktionaler Programmierung sind Funktionen eben nicht an ein Objekt oder eine Klasse gebunden. Das macht ja einen der großen Unterschiede aus.

[hellbringer]

Man mag das kaum glauben, aber es will halt nicht jeder funktional programmieren

Mir ist das eh egal, ich schreibe kein JavaScript, sondern TypeScript =)

[Gast]

Man mag das kaum glauben, aber es will halt nicht jeder funktional programmieren

Das stimmt in der Tat Aber bei Erlang würde auch keiner auf die Idee kommen, Klassen einzuführen.

Mir ist das eh egal, ich schreibe kein JavaScript, sondern TypeScript =)

Na, das ist aber eine andere Ebene als das oben Diskutierte

[ChookaP]

Nee, das hat damit gar nichts zu tun. Was Du da beschreibst, ist nichts anderes, als Funktionen in ein Objekt zu drücken. Bei funktionaler Programmierung sind Funktionen eben nicht an ein Objekt oder eine Klasse gebunden. Das macht ja einen der großen Unterschiede aus.

Hmmm...