Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Facebook: Programmiersprache Hack…

Nach umfangreicher Analyse...

  1. Thema

Neues Thema Ansicht wechseln


  1. Nach umfangreicher Analyse...

    Autor: TheUnichi 21.03.14 - 14:38

    ...muss ich sagen, bin ich sehr enttäuscht von Hack. Ich habe bei weitem mehr von Facebook erwartet.

    In meinen Augen sind "Hack" einfach nur eine Sammlung von kleinen Fixes und Erweiterungen, die so aber gar nicht in den Sprachenstil passen.

    Damit man versteht, worüber ich hier rede, sollte man sich auch folgendes angucken:
    http://docs.hhvm.com/manual/en/hack.unsupported.php

    1. Traits waren von vornherein ein unsauberes Konstrukt, dass eher mit Multiple Inheritance hätte gelöst werden sollen. Traits erinnern eher an Mixins, da der Trait nie wissen kann, in welche Klasse er gepackt wird. Was macht Hack? Sie erweitern Traits um "require", anstatt Multiple Inheritance zu implementieren. Traits können nur andere Traits "use"n, sie können keine Traits erweitern. Damit haben sie zwar das Problem gelöst, aber es macht das Feature selbst nicht sinnvoller im Vergleich zu Äquivalenten.

    2. Statt der []-Array Syntax wird hier die Nutzung von array() erneut vorrangetrieben, sowohl als auch eine neue Syntax, nämlich "Class { val1, val2, val3, ... }" eingeführt. Da hätte man es auch wirklich bei "new Class( [ val1, val2, val3 ] )" belassen können und ein sinnloses Konstrukt weniger implementieren können. Die Collections sind doch im Backend eh Klassen, was macht die neue Syntax? Sie entfernt "new" und die "()"-Klammern und ersetzt "[]" mit "{}". Wirklich spannend........warum??

    3. Asynchronität...schön und gut. Hilft aber nicht, wenn die Sprache dahinter eine Krücke voll mit Altlasten ist. Wenn ich asynchron arbeiten möchte, nehme ich Ruby oder JavaScript(Node.js), die darauf ausgelegt sind, aber zurzeit macht die Asynchronität in PHP maximal für Proof-of-Concept PHP Webserver Sinn (Also effektiv gar keinen)

    4. Warum <<Override>> und nicht einfach override? Wenn sie schon Keywords wie "require" überschreiben können, dann doch wohl auch override?

    5. Sämtliche dynamischen Funktionalitäten ($$varName, $obj->$varName etc.) wurden entfernt.

    6. ArrayAccess interface wurde entfernt?! Offensichtlich, weil man mit ->offsetSet( null, $val ) wohl quasi [] statt [ $key ] nutzt, also appended. Warum wird dann nicht in den Core eingebaut, dass [ null ] so oder so appended? Wie oft setzt man den Key dynamisch zusammen, möchte vllt. aber auch appenden, wenn "null" dabei rauskommt (Also ich oft genug), warum brauche ich nun ERST RECHT "if( $key == null ) { $arr[] = $val; } else { $arr[ $key ] = $val; }"?

    7. Kein if/elseif/else ohne {} mehr. Kann ich nachvollziehen, irgendwo aber auch nicht. "if( "!is_string( $var ) ) throw new Exception( "is not a string" );" nutzt man einfach zu oft, als dass man es rausnehmen sollte und da braucht man kein weiteres Debugging zwischen den {}, denn eine Exception ist eine Exception. Irgendwer fängt sie immer auf.

    8. Mehrere Modi. Warum nicht einfach strict forcen? Wenn schon denn schon, sonst machen sie doch wieder denselben Fehler, unter den bereits PHP gelitten hat.

    9. Keine sinnvolle Stdlib außer ihrer nutzlosen Collections. Warum keinen vordefinierten "Loader" den man über "Loader::addPath()" nurnoch mit Pfaden füttern muss? Warum nach wie vor kein Autoboxing? Wo liegt das Problem mit Autoboxing? Warum keine kleine sinnvolle Stdlib inkl. Standardklassen für Primitive-Types? Wie lange muss ich noch auf "a b c"->split( ' ' ) und Url $url = (Url)"http://google.com"; echo $url->host; warten

    10. Shapes, erwähnen aber dabei nochmal, dass man auch Classes mit public properties als "struct" verwenden kann. Richtig definiert anhand einer Klasse "Struct" kann man sich so auch ganz schnell via "$var = new Struct( [ 'field1' => $val1, 'field2' => $val2 ] );" Structs schaffen, die auch noch mächtiger und dynamischer sind als die Shapes.

    11. Dispatching nurnoch mit call_user_func und call_user_func_array. Habe ich sowieso immer gemacht, aber es nervt dennoch, die Namen sind zu lang, ganz einfaches Ding. Wenn Anonyme Funktionen doch eh vom Typ Closure sind, demnach eine Klasse im Hintergrund werkeln "könnte", warum dann nicht sämtliche Funktionen daran binden und ein ->call/->apply ala JS realisieren? Wäre bei weitem einfacher und evtl. auch intuitiver. Man muss ja nicht den Kontext setzen sollen.

    12. $this in Closures. Fehlt auch hier wieder. Wenn schon Lambda und wenn schon Scope-Copy, warum nicht auch $this?

    13. Überladung haben sie nicht hingekriegt. Wenn sie schon auf .NET machen, dann doch bitte richtig. Die Überladung fehlt, nach wie vor. Und ich rede von Überladung und nicht PHPs Definition in den "Magic Methods". Ich kenne den PHP Source nicht, aber ich denke nicht, dass sie die Klassen auf C++ Klassen mappen, sie führen doch eher ein eigenes Register, dass sie führen können, wie sie wollen und maximal auf native Funktionen zurückgreift. Also wo ist das Problem?

    14. ?Vector $vec = Vector {1, 2, 3};
    if( !$vec ) { /* Ist $vec hier nur empty() oder konkrett null? Man weiß es nicht. Hack auch nicht, denn sie casten (bool)$vec auf $vec->isEmpty() :) */ }

    14. if(): endif; Syntax ist raus, weil sie angeblich "selten genutzt" wurde. So ein Schwachsinn, gerade zurzeit, im Aufschwung der PHTML-Template-Systeme ist dies ein wunderbares Konstrukt, damit man eben KEINE neue Wurkssyntax ala Smarty einführen muss, damit der Designer den Code noch versteht. Warum wird so etwas entfernt? Was hat Facebook an diesem _optionalen_ Konstrukt gestört?


    Es gibt genau 3 Dinge, die mir an Hack zusagen, die ich aber auch in normalem PHP sehe, wenn die Entwickler endlich mal die Augen aufmachen

    1. Generics. Sehr schön. Vor allem array<T> gefällt mir.

    2. XHP. Naja, hätte man nun auch einfach Inline-XML nennen können, scheint auch nur XML zu unterstützen, kein konkretes HTML5 o.ä. Tut aber was es soll (Auch wenn es natürlich jeder Controller-View-Logik widerspricht)

    3. Lamba-Ausdrücke generell. Die haben wirklich gefehlt. Jetzt nur noch $this rein und Closures allgemein (und nicht nur die Lambda ausdrücke) nicht mit use() verarbeiten, sondern einfach das aktuelle Scope freezen und übernehmen, wie in JavaScript

    4. Primitive Type Hints. Naja. Die kann ich mit nem set_error_handler auch dirty selbst zusammenbasteln, aber das ist immerhin der richtige Weg.


    Alles in allem hätten sie lieber einfach eine neue Sprache bauen sollen, die auf PHP basiert, aber nicht dessen Altlasten hinterherzieht. Ich kann die Punkte der Kompatibilität verstehen, aber es hilft nicht, hier wird Scheiße mit Gold angemalt.
    Und noch dazu entfernen sie ja die meisten PHP Features, also wozu dann Kompatibilität schaffen, wenn sie am Ende doch nicht existiert?

    Ich sehe hier nur, dass Facebook PHP "idiotensicherer" gemacht hat, damit auch die letzten, dümmsten Programmierer zusammen mit der passenden IDE (z.B. Visual Studio) auch wirklich jedes kleine Fitzelchen an komplexeren Konstrukten gleich wieder mit Fehlern zurückgeschossen bekommen. Ganz großes Kino.

    Ich habe nichts gegen strict typing, ich finde es durchaus sinnvoll, aber das hier ist kastriertes PHP mit Strict Typing und Funktionen, die meist durch sinnvollere Konstrukte hätten gelöst werden können.
    Da wird aus PHP ein Mix aus C/C++, Java, JavaScript und nun auch noch C# gemacht und dazu noch tausende Features, die die Probleme eben genau dieser Struktur nicht etwa beheben, sondern eher "übermalen". Das passt einfach nicht.

    Wirklich schade, da denkt man, bei Facebook sitzen kompetente Entwickler und dann kommt so eine Grütze dabei raus....

  2. Re: Nach umfangreicher Analyse...

    Autor: am (golem.de) 21.03.14 - 15:03

    > 3. Asynchronität...schön und gut. Hilft aber nicht, wenn die Sprache
    > dahinter eine Krücke voll mit Altlasten ist. Wenn ich asynchron arbeiten
    > möchte, nehme ich Ruby oder JavaScript(Node.js), die darauf ausgelegt sind,
    > aber zurzeit macht die Asynchronität in PHP maximal für Proof-of-Concept
    > PHP Webserver Sinn (Also effektiv gar keinen)
    HHVM ist PHP-Kompatibel, aber eben kein Just-Another-PHP-Interpreter. Es ist extrem wahrscheinlich, dass HHVM früher oder später tatsächlich standalone ohne Webserver laufen wird.

    > 5. Sämtliche dynamischen Funktionalitäten ($$varName, $obj->$varName etc.)
    > wurden entfernt.
    Weil Perfomance-Killer, da erst zur Laufzeit auflösbar.

    > 12. $this in Closures. Fehlt auch hier wieder. Wenn schon Lambda und wenn
    > schon Scope-Copy, warum nicht auch $this?
    Weil der Kontext von $this nicht zweifelsfrei auflösbar ist und die Verwendung geradezu Bugs provoziert. Meint der Programmierer nun damit die Instanz, in welcher die anonyme Funktion tatsächlich definiert wurde oder tatsächlich $this im Sinne der Instanz, innerhalb welcher Code tatsächlich ausgeführt wird? Wird $this dann ausserhalb des Klassenkontextes zu einer normalen Variable, womit du dann ziemlich verwirrenden Code schreiben kannst?
    In Javascript bist du auch gezwungen sowas zu schreiben, um den Ursprungsscope zu garantieren:
    function bla() {
    var self = this;

    return function() {
    // mach was mit self, wo du eigentlich this benutzen wolltest
    }
    }

    Grüße,
    Alexander Merz (golem.de)

  3. Re: Nach umfangreicher Analyse...

    Autor: TheUnichi 21.03.14 - 15:40

    am (golem.de) schrieb:
    --------------------------------------------------------------------------------
    > > 3. Asynchronität...schön und gut. Hilft aber nicht, wenn die Sprache
    > > dahinter eine Krücke voll mit Altlasten ist. Wenn ich asynchron arbeiten
    > > möchte, nehme ich Ruby oder JavaScript(Node.js), die darauf ausgelegt
    > sind,
    > > aber zurzeit macht die Asynchronität in PHP maximal für Proof-of-Concept
    > > PHP Webserver Sinn (Also effektiv gar keinen)
    > HHVM ist PHP-Kompatibel, aber eben kein Just-Another-PHP-Interpreter. Es
    > ist extrem wahrscheinlich, dass HHVM früher oder später tatsächlich
    > standalone ohne Webserver laufen wird.

    Exakt, aber da gibt es eben wichtigere Konstrukte als Asychronität, um die man sich kümmern sollte, wie eben die Performance des Ganzen. Zugegeben, ich habe es noch nicht getestet, wie viel Last PHP-Webserver tatsächlich aushalten, aber ich denke, dass es dort diverse Flaschenhälse gibt, die auch die HHVM noch mit sich bringt, solange sie nicht den halben Core umschreiben

    > > 5. Sämtliche dynamischen Funktionalitäten ($$varName, $obj->$varName
    > etc.)
    > > wurden entfernt.
    > Weil Perfomance-Killer, da erst zur Laufzeit auflösbar.
    Akzeptiere ich (wie auch allgemein die Änderung), aber da ist natürlich so dann nicht viel mit Abwärtskompatibilität, da man eben dieses Konstrukt permanent sieht.
    Gerade bei $obj->$varName sehe ich das kritisch, darauf basieren meistens Iterationen von Objekten in PHP.

    > > 12. $this in Closures. Fehlt auch hier wieder. Wenn schon Lambda und
    > wenn
    > > schon Scope-Copy, warum nicht auch $this?
    > Weil der Kontext von $this nicht zweifelsfrei auflösbar ist und die
    > Verwendung geradezu Bugs provoziert. Meint der Programmierer nun damit die
    > Instanz, in welcher die anonyme Funktion tatsächlich definiert wurde oder
    > tatsächlich $this im Sinne der Instanz, innerhalb welcher Code tatsächlich
    > ausgeführt wird? Wird $this dann ausserhalb des Klassenkontextes zu einer
    > normalen Variable, womit du dann ziemlich verwirrenden Code schreiben
    > kannst?
    > In Javascript bist du auch gezwungen sowas zu schreiben, um den
    > Ursprungsscope zu garantieren:
    > function bla() {
    > var self = this;
    >
    > return function() {
    > // mach was mit self, wo du eigentlich this benutzen wolltest
    > }
    > }

    Bei JavaScript ist das imo etwas anderes, da hier jede Funktion generell einen this-Kontext hat. Wäre dieser nicht gegeben, würde es auch hier einfaches Scope-Freezing tun.
    Und genau darum geht es ja, eben das Scope Freezing. Wird $this in der Closure verwendet, entspricht es immer dem Objekt, in der die Closure definiert wurde. Wurde es in keinem definiert, existiert $this nicht.

    In JavaScript tut es da ja ein sauberes Proxy-System, dann spart man sich auch die var self/_this = this;, aber so was ist ja in PHP leider nicht möglich.
    $self = $this; ist einfach hässlig und gehört verboten.

    Könnte man wenigstens $this via use() übergeben, würde ich ja sagen, okay, aber eben genau das ist nicht möglich.

  4. Re: Nach umfangreicher Analyse...

    Autor: ch 21.03.14 - 17:06

    Danke für die Analyse und dass du dir die Mühe gemacht hast, dies hier wiederzugeben! Spart mir sehr viel Zeit.

  5. +1

    Autor: p3x4722 21.03.14 - 17:54

    >Wirklich schade, da denkt man, bei Facebook sitzen kompetente Entwickler und dann >kommt so eine Grütze dabei raus....

    dem kann ich leider nur zustimmen. aber es hat wieder für eine schlagzeile gereicht; egal in welche richtung ;)

  6. Re: Nach umfangreicher Analyse...

    Autor: Shyru 22.03.14 - 00:18

    Also ich weiß ja nicht auf welchem Wissensstand Ihr stehen geblieben seid, aber use $this in closures geht seit php 5.4.0!

  7. Re: Nach umfangreicher Analyse...

    Autor: redmord 22.03.14 - 00:57

    IMHO kräht in fünf Jahren kein Hahn mehr nach PHP. Webserver werden immer mehr auf REST reduziert und wenn ich mir Konzepte wie Meteor ansehe, frage ich mich eh was auf dem Server selbst noch großartiges außer Datensparsamkeit in der Kommuniktation, Security und Skalierbakeit geregelt werden muss.

    So sehr ich Composer, Symfony2 und Silex mag ... doch wenn da nicht bald mal ein ordentlicher Push Richtung Websockets kommt, seh ich schwarz. React PHP mit zeromq ist zwar witzig, doch verglichen mit Node.js ist das alles sowas von reingefrickelt.

  8. Re: Nach umfangreicher Analyse...

    Autor: GodsBoss 22.03.14 - 08:13

    > > 12. $this in Closures. Fehlt auch hier wieder. Wenn schon Lambda und
    > wenn
    > > schon Scope-Copy, warum nicht auch $this?
    > Weil der Kontext von $this nicht zweifelsfrei auflösbar ist und die
    > Verwendung geradezu Bugs provoziert. Meint der Programmierer nun damit die
    > Instanz, in welcher die anonyme Funktion tatsächlich definiert wurde oder
    > tatsächlich $this im Sinne der Instanz, innerhalb welcher Code tatsächlich
    > ausgeführt wird? Wird $this dann ausserhalb des Klassenkontextes zu einer
    > normalen Variable, womit du dann ziemlich verwirrenden Code schreiben
    > kannst?
    > In Javascript bist du auch gezwungen sowas zu schreiben, um den
    > Ursprungsscope zu garantieren:
    > function bla() {
    > var self = this;
    >
    > return function() {
    > // mach was mit self, wo du eigentlich this benutzen wolltest
    > }
    > }

    Anonymous functions: Changelog:
    "5.4.0 $this can be used in anonymous functions."

    Schön, eine Erklärung zu lesen, warum etwas nicht funktioniert, wenn es längst funktioniert. :-P

    Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

  9. Re: Nach umfangreicher Analyse...

    Autor: am (golem.de) 22.03.14 - 11:32

    Uff... und die Implementierung ist noch übler als ich annahm:

    <?php
    class Y {}

    class X {
    public function fn() {
    $fn = function() {
    $this = new Y;
    };
    return $fn;
    }
    }

    $x = new X;
    $fn = $x->fn();
    ?>

    ~$ php -f this.php

    Fatal error: Cannot re-assign $this in /Users/alexandermerz/this.php on line 7

    Ergibt noch Sinn, aber mit bindTo() kann ich $this umbiegen:

    <?php

    class Y {
    public function a() {
    echo "Hallo Ya\n";
    }
    private function b() {
    echo "Hallo Yb\n";
    }
    }

    class X {
    public function a() {
    echo "Hallo Xa\n";
    }
    private function b() {
    echo "Hallo Xb\n";
    }

    public function fn() {
    $fn = function() {
    $this->a();
    $this->b();
    };
    return $fn;
    }
    }

    $x = new X;
    $y = new Y;
    $fn = $x->fn();
    var_dump($fn);
    $fn();

    $fn2 = $fn->bindTo($y);
    var_dump($fn2);
    $fn2();

    ?>

    ~$ php -f this2.php
    object(Closure)#3 (1) {
    ["this"]=>
    object(X)#1 (0) {
    }
    }
    Hallo Xa
    Hallo Xb
    object(Closure)#4 (1) {
    ["this"]=>
    object(Y)#2 (0) {
    }
    }
    Hallo Ya

    Fatal error: Call to private method Y::b() from context 'X' in /Users/alexandermerz/this2.php on line 23

    ... oder auch nicht?!
    $this ist also nicht wirklich $this, sondern irgendwas spezielles, das mal so, mal so behandelt wird.

    Grüße,
    Alexander Merz (golem.de)

  10. Re: Nach umfangreicher Analyse...

    Autor: GodsBoss 22.03.14 - 12:00

    > Uff... und die Implementierung ist noch übler als ich annahm:
    > (...)
    > ... oder auch nicht?!
    > $this ist also nicht wirklich $this, sondern irgendwas spezielles, das mal
    > so, mal so behandelt wird.

    Closure::bindTo hat einen zweiten Parameter, der den Klassen-Scope angibt, mit dem die anonyme Funktion an ein Objekt gebunden wird:

    $fn2 = $fn->bindTo($y, 'Y');

    So würde es funktionieren. Ohne Angabe wird der Ausgangs-Scope verwendet, in deinem Beispiel Klasse X, von dort darf Y::b natürlich nicht aufgerufen werden.

    Ich halte die Implementierung auch für übel, aber aus einem ganz anderen Grund: Dank des zweiten Parameters können Closures von außen auf private Eigenschaften und Methoden einer Klasse zugreifen. Ganz schlechter Stil.

    Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

  11. Re: Nach umfangreicher Analyse...

    Autor: am (golem.de) 22.03.14 - 14:09

    Ja, das ist richtig. Ändert aber am Kernproblem nichts, weshalb ich es wegliess, um es besser zu demonstrieren: Du hast als Ersteller der anonymen Funktion keinerlei Kontrolle über den Wert von $this. $this ist zwar da, aber es muss nicht das sein, was du denkst, was es ist. Deswegen bin ich ja auch so dagegen, überhaupt $this in Closures zu verwenden.

    Oder PHP sollte dann so konsquent sein, das gleich auf Python-Manier zu lösen und auch für alle Klassenmethoden ein function bla(self,...) zu erzwingen oder allgemein: Wenn schon Scope/$this-umbiegen, dann wenigstens für alle Methoden ;)

    Grüße,
    Alexander Merz (golem.de)

  12. Re: Nach umfangreicher Analyse...

    Autor: GodsBoss 22.03.14 - 15:03

    > Ja, das ist richtig. Ändert aber am Kernproblem nichts, weshalb ich es
    > wegliess, um es besser zu demonstrieren: Du hast als Ersteller der anonymen
    > Funktion keinerlei Kontrolle über den Wert von $this. $this ist zwar da,
    > aber es muss nicht das sein, was du denkst, was es ist. Deswegen bin ich ja
    > auch so dagegen, überhaupt $this in Closures zu verwenden.

    Ich sehe das nicht nur nicht als Kernproblem, sondern als überhaupt kein Problem. Wenn ich innerhalb einer Instanzmethode eine anonyme Funktion erzeuge, ist darin $this die Instanz selbst. Sollte ich - aus welchen Gründen auch immer - darin einen anderen Wert für $this haben wollen, kann ich mir aus meinem bestehenden Closure ein neues mit dem alternativen $this erzeugen und dabei sogar den Scope auf eine andere Klasse ändern, so dass ich dort vollen Zugriff habe.

    Wenn jetzt jemand anderes diese anonyme Funktion erhalten hat und daraus eine erzeugt, deren $this wieder etwas anderes ist, ist das seine Verantwortung.

    Wo ich eine anonyme Funktion verwende, habe ich also volle Kontrolle darüber, was $this ist, wo andere das tun, haben andere die Kontrolle. Aus meiner Sicht korrekt.

    Gut, einen sinnvollen Anwendungsfall habe ich jetzt auch nicht parat. Von mir aus hätte man Closure::bind und Closure::bindTo auch weglassen können, aber ich möchte nicht ausschließen, dass es sinnvolle Anwendungsfälle gibt.

    > Oder PHP sollte dann so konsquent sein, das gleich auf Python-Manier zu
    > lösen und auch für alle Klassenmethoden ein function bla(self,...) zu
    > erzwingen oder allgemein: Wenn schon Scope/$this-umbiegen, dann wenigstens
    > für alle Methoden ;)

    Mir würde in dieser Hinsicht auch reichen, wenn man $this als lexikale Variable (?) nutzen könnte. Als Referenz hätte man es ja weiterhin verbieten können.

    Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

  13. Re: Nach umfangreicher Analyse...

    Autor: TheUnichi 24.03.14 - 11:50

    Shyru schrieb:
    --------------------------------------------------------------------------------
    > Also ich weiß ja nicht auf welchem Wissensstand Ihr stehen geblieben seid,
    > aber use $this in closures geht seit php 5.4.0!

    Du hast Recht, da habe ich doch tatsächlich ein Feature übersehen.
    Das ändert natürlich so einiges :)

    Danke für den Hinweis

  14. Re: Nach umfangreicher Analyse...

    Autor: TheUnichi 24.03.14 - 16:23

    redmord schrieb:
    --------------------------------------------------------------------------------
    > IMHO kräht in fünf Jahren kein Hahn mehr nach PHP. Webserver werden immer
    > mehr auf REST reduziert und wenn ich mir Konzepte wie Meteor ansehe, frage
    > ich mich eh was auf dem Server selbst noch großartiges außer
    > Datensparsamkeit in der Kommuniktation, Security und Skalierbakeit geregelt
    > werden muss.
    >
    > So sehr ich Composer, Symfony2 und Silex mag ... doch wenn da nicht bald
    > mal ein ordentlicher Push Richtung Websockets kommt, seh ich schwarz. React
    > PHP mit zeromq ist zwar witzig, doch verglichen mit Node.js ist das alles
    > sowas von reingefrickelt.

    Das sagt sich so einfach, so wie sich auch heute die ganzen Node.js-ler sagen "PHP ist tot" und die ganzen RoR-Helden "Ruby ist besser als PHP wegen bla bla bla bla bla"
    Ja, Ruby, Node.js UND ASP.NET sind besser als PHP, alle 3. Aber umständlicher in der Bereitstellung, in jeder Hinsicht, und zwar alle 3.

    Wie sieht es in der Realität aus?
    Möchte ich eine dynamische Seite bauen, die auf einem Webspace von einem Hoster wie Strato gehostet wird, über den ich nur via FTP rankomme, sind alle 3 vorher genannten Lösungen TOT.
    PHP ist die einzige Alternative die heutzutage wirklich nahtlos, auf jedem Webspace ohne große Einschränkungen läuft.
    PHP ist für jedes System, für jeden Webserver und wenn man will auch für die CLI und das arbeiten mit PHP benötigt nichts weiter als eine Datei irgendeiner Art in der irgendwo mit <?php ?> PHP Code eingebettet wird.

    Ich mache alles mit PHP, ich konvertiere damit Dateien, ich batch-manipuliere Bilder damit, ich schreibe damit meine Batch-Scripts auf meinen Linuxen (Init-Scripts, Backup-Crontabs etc.), ich habe absolute Freiheit in dem, was ich mit PHP mache und wie ich es mache.
    Das ist das schöne an PHP.

    Klar ist PHP nicht schön, aber wenn ich eine Software schreiben möchte, die ich womöglich auch für andere Menschen freigeben möchte sodass sich kleine Personen sie installieren und damit arbeiten können, ist und bleibt PHP die einzige Alternative.

    Im Endeffekt ist PHP ja auch irgendwo nur so hässlig, weil es zu stark an C++ Syntax anknüpft und dafür zu Java-lastig definiert wurde.

    Was wirklich eine Erfrischung wäre, wäre eine JS-ähnliche Syntax in PHP, aber mit Vollbluts-OOP.

    Node.js geht da ja schon einen richtigen Schritt, aber ausgereift ist das Ganze leider dennoch nicht.

Neues Thema Ansicht wechseln


Dieses Thema wurde geschlossen.

Stellenmarkt
  1. Robert Bosch GmbH, Stuttgart
  2. ESG Elektroniksystem- und Logistik-GmbH, Berlin
  3. ORBIT Gesellschaft für Applikations- und Informationssysteme mbH, Darmstadt
  4. RADIO-LOG, Passau

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Overwatch GOTY für 22,29€ und South Park - Der Stab der Wahrheit für 1,99€)
  2. 134,98€ (beide Artikel in den Warenkorb legen, um 60€ Direktabzug zu erhalten. Einzelpreise im...
  3. 176,98€ (beide Artikel in den Warenkorb legen, um 60€ Direktabzug zu erhalten. Einzelpreise im...
  4. 179€


Haben wir etwas übersehen?

E-Mail an news@golem.de


CD Projekt Red: So spielt sich Cyberpunk 2077
CD Projekt Red
So spielt sich Cyberpunk 2077

E3 2018 Hacker statt Hexer, Ich-Sicht statt Dritte-Person-Perspektive und Auto statt Pferd: Die Witcher-Entwickler haben ihr neues Großprojekt Cyberpunk 2077 im Detail vorgestellt.
Von Peter Steinlechner


    Kreuzschifffahrt: Wie Brennstoffzellen Schiffe sauberer machen
    Kreuzschifffahrt
    Wie Brennstoffzellen Schiffe sauberer machen

    Die Schifffahrtsbranche ist nicht gerade umweltfreundlich: Auf hoher See werden die Maschinen der großen Schiffe mit Schweröl befeuert, im Hafen verschmutzen Dieselabgase die Luft. Das sollen Brennstoffzellen ändern - wenigstens in der Kreuzschifffahrt.
    Von Werner Pluta

    1. Hyseas III Schottische Werft baut Hochseefähre mit Brennstoffzelle
    2. Roboat MIT-Forscher drucken autonom fahrende Boote
    3. Elektromobilität Norwegen baut mehr Elektrofähren

    IT-Jobs: Fünf neue Mitarbeiter in fünf Wochen?
    IT-Jobs
    Fünf neue Mitarbeiter in fünf Wochen?

    Startups müssen oft kurzfristig viele Stellen besetzen. Wir waren bei dem Berliner Unternehmen Next Big Thing dabei, als es auf einen Schlag Bewerber für fünf Jobs suchte.
    Ein Bericht von Juliane Gringer

    1. Frauen in IT-Berufen Programmierte Klischees
    2. Bitkom Research Höherer Frauenanteil in der deutschen IT-Branche
    3. Recruiting IT-Experten brauchen harte Fakten

    1. Grafikkarte: Jensen Huang verteilt CEO-Edition der Titan V
      Grafikkarte
      Jensen Huang verteilt CEO-Edition der Titan V

      Nvidia-Chef Jensen Huang hat einigen Teilnehmern einer Computer-Vision-Messe eine limitierte CEO-Version der Titan V genannten Grafikkarte geschenkt. Eine authentische Lederjacke gab es leider nicht dazu.

    2. EA Sports: NHL 19 bietet Hockey im Freien und härtere Kollisionen
      EA Sports
      NHL 19 bietet Hockey im Freien und härtere Kollisionen

      Nicht nur in Hallen, sondern auch im Freien sollen Spieler in NHL 19 den Puck jagen können - wahlweise in Freizeitkleidung. Für sportlich-brachiale Matches ist ein neues Kollisionssystem geplant.

    3. Deutsche Telekom: T-Systems will 10.000 Stellen streichen
      Deutsche Telekom
      T-Systems will 10.000 Stellen streichen

      Bei T-Systems sollen in den nächsten drei Jahren 10.000 Arbeitsplätze eingespart werden, davon 6.000 in Deutschland. Verdi hat entschiedenen Widerstand angekündigt.


    1. 17:14

    2. 17:03

    3. 16:45

    4. 16:08

    5. 16:01

    6. 15:52

    7. 15:21

    8. 13:51