Warum PHP Unsinn für Applikationen ist

Wie ein running Gag zieht sich das teils mehr, teils weniger qualifizierte Genörgel über PHP durchs Forum. Ich finde man sollte mal Nägel mit Köpfen machen und in einem Thread diskutieren, was die wahren Gründe sind PHP für Applikationsentwicklung abzulehnen. Sicher hat der eine oder andere seine eigenstpersönlichen Gründe, nichts von PHP zu halten, aber es gibt auch einige wirklich gute und sachliche Argumente zum Thema, wo PHP einfach Grenzen gesetzt sind. Ich werf einfach mal einige in den Raum:

PHP ist ein Script, und das kann es auch nicht verbergen. Ursprünglich ist PHP als Templating Scriptsprache für html-Ausgabe entwickelt worden. die Oldies beherrschen zum Teil noch die short_open_tag Scriptweise, in einer Webseite Bits und Pieces von PHPCode elegant unterzubringen, um http://www./ mit dynamischen Inhalten zu versehen.

Wenn man nicht mit PHP als Programmiersprache konfrontiert wurde, so wie viele arme Seelen anno dunnemals mit Basic, sondern es als PHP - Hypertext Preprocessor kennengelernt hat, dann staunt man heutzutage zuweilen darüber, was PHP alles zugemutet wird.

Besonders seltsam muten dann die vielen CMS in PHP an, die doch letztlich nichts anders sind als aufgeblasene Scripte um mit horrendem Aufwand Inhalte zu formatieren. Das Sessionhandling hat auch etwas von "halt doch mal die Daten, mit meinem Alzheimer weiss ich beim nächsten Pageview sonst nicht mehr was du willst".

Es ist schon spassig, das marktführende Produkte wie typo3 dann die Sache auf die Spitze treiben und in einem aufgeblähten Templating Script(PHP) ein geschachteltes Templating Script (TypoScript) implementieren, weil vielen garnicht mehr klar ist, wo die wirklichen Stärken von PHP liegen,

A propos Stärken, OOP ist sicher keine Stärke von PHP. Aus einer Vielzahl von Gründen. Ganz weit voran: EIne Lampp Umgebung schreit an sich nach konsequenter Umsetzung einer REST Architektur, obengenannte Krücken wie Cookies oder SessionHandling versuchen dann eine persistente Applikation zu emulieren, aber letztlich bleibt der ganze Ablauf prozedural.

Am Ende jedes Scriptablaufes sind die verwendeten Klassen zu serialisieren, um dann beim nächsten Aufruf wieder neu instantiiert und mit den aktuellen Daten populiert zu werden. Eigentlich ein gräusliger Overhead, und einfach schlechte Architektur, oder?

Die schon länger mit PHP-"OOP" gestraften werden sich noch an katastrophale Anfangsprobleme erinnern, die bei deserialisieren von Objekten einfach die Daten unter den Tisch fallen liessen. Nein, dass sieht Oberflächlich nach OOP aus, hat aber in Realität ausser einer OOP-artigen API nichts damit zu tun.

Hochfliegende Planungen, Application Server in PHP zu realisieren machen mir schlichtweg Angst.

Soll das heissen, PHP ist schlecht?

Nein, man sollte nur keinen Spachtel benutzen um Holz in Form zu sägen. Ich finde es bedauerlich, dass die PHP-Entwickler seit längerer Zeit schon ein von Anfang an verlorenes Rennen angefangen haben, um PHP als vollwertige Programmiersprache zu etablieren, anstatt die Stärken von PHP zu betonen und es als eingängige und mächtige Templating-Scriptsprache zu perfektionieren.

Soll das heissen, PHP-Programmierer sind keine Entwickler?

Auch nicht, es nötigt mir sogar einigen Respekt ab, wie es Entwickler schaffen, teilweise beeindruckend gut funktionierende Designs in PHP zu schaffen, aber sie haben da sicher nicht das beste Werkzeug gewählt, und machen sich sicher etliches schwerer, als es sein müsste.

Ein wichtiger Bestandteil des Erfolgs in jeder Arbeit und in jedem Beruf ist, alle seine notwendigen Werkzeuge zu beherrschen, und sie entsprechend geschickt für die anliegende Aufgabe auszuwählen. Alles mit PHP erschlagen zu wollen ist einfach oberflächlich bequem, und nicht einmal sinnvoll. Das Hinzulernen weiterer Sprachen ist weitaus nicht so aufwendig wie man meinen möchte, wenn man erst einmal ein Grundverständnis für Softwarearchitektur entwickelt hat. Es muss ja nicht gleich Java oder C++ sein. Python zum Beispiel stellt eine einfach erlernbare Alternative dar, wenn eine vollwertige Programmiersprache benötigt wird. Von dialekten Abgesehen bietet Python als interpretierte Sprache zwar keinen Performancevorteil, aber bei komplexerer Applikationsarchitektur eröffnen sich etliche Möglichkeiten, auf sauberere Art und weise die geplante Architektur umzusetzen, ohne auf halbgare Workarounds zurückzugreifen.

Wie sind eure Erfahrungen mit PHP? Wo stosst ihr an Grenzen? Haben euch andere Sprachen geholfen, diese Hindernisse besser zu bewältigen?

Original von Tron

PHP ist ein Script, und das kann es auch nicht verbergen. Ursprünglich ist PHP als Templating Scriptsprache für html-Ausgabe entwickelt worden. die Oldies beherrschen zum Teil noch die short_open_tag Scriptweise, in einer Webseite Bits und Pieces von PHPCode elegant unterzubringen, um http://www./ mit dynamischen Inhalten zu versehen.

Ja, weswegen es für mich ein Rätsel ist wie sich Sachen wie Smarty durchsetzen können. PHP ist doch eine Templatesprache und lässt sich sehr gut für die View Schicht verwenden.

Meiner Meinung nach sollte man aber bei mittleren und größeren Anwendung sehr schnell von dem reinen Templategedanken weggehen und anfangen die Anwendung MVC basierend aufzubauen.

Wenn man nicht mit PHP als Programmiersprache konfrontiert wurde, so wie viele arme Seelen anno dunnemals mit Basic, sondern es als PHP - Hypertext Preprocessor kennengelernt hat, dann staunt man heutzutage zuweilen darüber, was PHP alles zugemutet wird.

Was PHP zugemutet wird oder was PHP leisten kann? Ich würde sagen es kann wesentlich mehr, also die Entwickler davon nutzen.

Besonders seltsam muten dann die vielen CMS in PHP an, die doch letztlich nichts anders sind als aufgeblasene Scripte um mit horrendem Aufwand Inhalte zu formatieren. Das Sessionhandling hat auch etwas von "halt doch mal die Daten, mit meinem Alzheimer weiss ich beim nächsten Pageview sonst nicht mehr was du willst".

PHP hat keinen Application Scope, das finde ich mit den größten Nachteil. MemCache ist ja (soweit ich weiß) nicht überall verfügbar, sondern optional. Deswegen kommt der angesprochene Overhead zu stande, die Initialisierung und Objekte immer wieder neu zu machen.

Die schon länger mit PHP-"OOP" gestraften werden sich noch an katastrophale Anfangsprobleme erinnern, die bei deserialisieren von Objekten einfach die Daten unter den Tisch fallen liessen. Nein, dass sieht Oberflächlich nach OOP aus, hat aber in Realität ausser einer OOP-artigen API nichts damit zu tun.

In PHP 4 sicherlich richtig, in PHP 5 allerdings empfinde ich das OOP als angenehm, mit weniger Overhead und dadurch agiler zu entwickeln als mit vergleichsweise Java.

Auch nicht, es nötigt mir sogar einigen Respekt ab, wie es Entwickler schaffen, teilweise beeindruckend gut funktionierende Designs in PHP zu schaffen, aber sie haben da sicher nicht das beste Werkzeug gewählt, und machen sich sicher etliches schwerer, als es sein müsste.

Was für Designs? Ich würde Designs eher mit HTML und CSS machen. :)

Ein wichtiger Bestandteil des Erfolgs in jeder Arbeit und in jedem Beruf ist, alle seine notwendigen Werkzeuge zu beherrschen, und sie entsprechend geschickt für die anliegende Aufgabe auszuwählen. Alles mit PHP erschlagen zu wollen ist einfach oberflächlich bequem, und nicht einmal sinnvoll. Das Hinzulernen weiterer Sprachen ist weitaus nicht so aufwendig wie man meinen möchte, wenn man erst einmal ein Grundverständnis für Softwarearchitektur entwickelt hat. Es muss ja nicht gleich Java oder C++ sein. Python zum Beispiel stellt eine einfach erlernbare Alternative dar, wenn eine vollwertige Programmiersprache benötigt wird. Von dialekten Abgesehen bietet Python als interpretierte Sprache zwar keinen Performancevorteil, aber bei komplexerer Applikationsarchitektur eröffnen sich etliche Möglichkeiten, auf sauberere Art und weise die geplante Architektur umzusetzen, ohne auf halbgare Workarounds zurückzugreifen.

Wie sind eure Erfahrungen mit PHP? Wo stosst ihr an Grenzen? Haben euch andere Sprachen geholfen, diese Hindernisse besser zu bewältigen?

Die Grenzen sind in deinem Absatz hier schon sehr gut nachvollzogen. Für Anwendungen die sich ohne Krampf in PHP umsetzen lassen finde ich PHP sehr angenehm. Wenn es um Dinge geht die einen eigenen Application Server benötigen, Performancemäßig sehr kritisch sind oder hardwarenahe Umsetzung gefordert ist stößt man schnell an die Grenzen.

Wie in vielen anderen Sprachen würde ich PHP alleine auch nicht mehr nutzen/betrachten. Ich sehe PHP in Verbindung mit dem Zend Framework beispielsweise gut Konkurrenzfähig zu Rails, ASP.NET oder JSP/Servlets. Jede Sprache hat irgendwo noch mehr Stärken, aber vom Gesamtkonzept her würde ich PHP eher als ausgereift ansehen. Und vor allem die breite Unterstützung auf Webspaces ist für mich immer wieder ein ausschlaggebender Faktor gewesen.

ich finde immer wieder amüsant mit welchem Eifer hier über PHP gezogen wird.  Wenigstens hat PHP noch eine gesunde Syntax, wenn jemand meint, dass Python dank seiner  Klammerfreiheit oder whatever im grossen Vorteil ist, dann tut es mir auch leid. Es ist halt immer Ansichtsache und dabei sollte man es belassen und die Welt nicht tagtäglich mit tollen Sprüchen und Bannern über das böse PHP aufklären.

PHP ist keine "echte" Programmiersprache- naund?!

PHP ist langsam - naund?!

PHP + OOP nahezu sinnlos - naund?!

Dafür bietet PHP einen unglaublich leichten Einstieg in die Webprogrammierung und quält nicht mehr Typisierung oder Sonstigem. Man kann in Ruhe die Zusammenhänge(Browser/Server/DB) lernen. Wo PHP halt nicht weiterkommt, sucht man Alternativen, aber heisst es dann, dass die Sprache an sich gleich zu verteufeln ist?

Entscheidend ist, was die Entwickler aus der Sprache rausholen. Und warum soll die grosse Auswahl an php-CMSen schlecht sein (typo3 ist halt bissel overengineered, typoscript ist halt ikea-style aber sollte man den skandinaviern lassen, da oben ist es kalt)

Nix ist perfekt und das ist vielleicht auch gut so

Ich kann Tron nur zustimmen.

Ich habe 2 Versuche unternommen ein nicht-triviales Spiel mit einigen netten Sachen zu programmieren (letzten Versuch kann man hier bestaunen). Anfangs klappt das auch super. Nach 1 Wohe hat man fast ein Ogame-Klon stehen - sprich Gebäude bauen, Forschungen forschen, Schiffe bauen und können zu flotten zugeteilt werden.. aber dann kommen die ersten probleme. Da ich einen 2D-Raum habe, in dem man schiffe auch im Flug sieht muss ich entweder die daten vektorisiert in der DB speichern und immer neu berechnen bei der Ausgabe (was die Galaxieansicht extremst langsam macht, wenn 10 User sie nutzen!) oder ich verzichte darauf. Die möglichkeit solche Daten sessionübergreifend im RAM zu halten ist in PHP ja nicht existent.

Der nächste brocken ist das Kampfsystem.. da merkt man schnell die performance-schwächen von PHP - gerade, wenn es wie bei mir um die realistische simulation des Kampfes gehen sollte.

Bei meinem Spiel war ein anderer extrem kritischer Punkt die Ressourcenberechnung. Ich hab mich hier ja schon öfters eingehend darüber ausgelassen - daher hier nur ein paar kurze anmerkungen:

Ich musste einiges an berechnungen in die DB auslagern.. weil php einfach zu grottenlahm war. Auch hatte ich pro spieler einige 100 zwischenwerte, die ich so gut es ging in die db serialisierte, damit sie beim nächsten request nicht nochmal berechnet zu werden brauchen.. aber meist mit wenig erfolg.

Das bloße aufrufen einer Seite im Spiel hat bei php für 1 Spieler mit 1 anfrage meine CPU für ein paar ms auf 100% belegt. Kamen mehrere Spieler zusammen hat das Spiel sofort angefangen zu laggen (so ab 10 Spieler hat mans im browser schon gemerkt)

Das alles führte dazu, dass ich meine Flottenankunfts-sachen und mein Kampfsystem in C++ umsetzte.. und mich dann immer schön per Socket mit php unterhalten hab. Das lief in der Kombination soweit ganz gut .. bis auf dass der C++-Code langsam immer ekelhafter und unwartbarer wurde (hey! mein erstes c++-ding, dass über ein simples ding wie "hello world" oder "taschenrechner" hinaus ging!).

Außerdem hatt ich bei so einer Lösung einiges an Code doppelt zu schreiben.. und als es dann daran ging die Ressourcenberechnung in C++ zu implementieren hab ich aufgegeben.

Den dritten Versuch mache ich nun in Java, um im Templating-System wie im Daemon dieselbe Sprache zu haben und einen Vollwertingen Application-Server zu bauen.

Ich hätte lieber C# genommen aber mangels ordentlicher IDE und den Problemem mit mono (die sicher gekommen wären.. ich trau diesem "es geht auch alles!!!*"-braten nicht) habe ich darauf verzichtet.

Andere Lösungen wie python, ruby, * kamen aus performance-Sicht nicht in Frage. Und bevor hier ein Flame anfängt: Ja, Java kann performant sein. Wenn man nicht für jeden Furz ein Framework oder ganze Factory-Factories einsetzt.

Was ich in Java vermisse ist die Einfachheit von PHP. Bei mir lief das schon sehr ähnlich zu einem MVC-Appserver ab. Ich hab in PHP einfach geschrieben, einmal die Seite aufgerufen, ob es parse-error gab und wenn nicht, dann war ich meist schon fertig - ohne groß rumzufrickeln (leider .. :/).

Original von DrakeL

Original von Tron

PHP ist ein Script, und das kann es auch nicht verbergen. Ursprünglich ist PHP als Templating Scriptsprache für html-Ausgabe entwickelt worden. die Oldies beherrschen zum Teil noch die short_open_tag Scriptweise, in einer Webseite Bits und Pieces von PHPCode elegant unterzubringen, um http://www./ mit dynamischen Inhalten zu versehen.

Ja, weswegen es für mich ein Rätsel ist wie sich Sachen wie Smarty durchsetzen können. PHP ist doch eine Templatesprache und lässt sich sehr gut für die View Schicht verwenden.

Meiner Meinung nach sollte man aber bei mittleren und größeren Anwendung sehr schnell von dem reinen Templategedanken weggehen und anfangen die Anwendung MVC basierend aufzubauen.

Im Falle von Smarty gebe ich dir Recht da es nur eine leicht von PHP abweichende Syntax ist. Grundsätzlich ist Templating für PHP aber nicht unbedingt falsch wenn die Templatesyntax sich auf reine Präsentationsfunktionen konzentriert und keine vollwertige Programmiersprache simuliert. Für mich gibt es 3 Gründe eine präsentationsorientierte Templateengine zu nehmen: 1) Vereinfachung der Syntax für Nicht-Programmierer, 2) Sharing von Themes ohne einzelne Templates auf schädlichen PHP-Code untersuchen zu müssen (interessant bei Software welche als Massenprodukt an Endkunden verteilt wird, siehe z.B. Bulletin Boards), 3) Beschneiden der "Templateprogrammierung" auf reine Präsentationslogik.

Performance ist hier eher irrelevant, man kann die Templatesyntax transparent in PHP-Code übersetzen und danach ganz normal PHP-Templates includen. Auch bei Software für den Eigenbedarf bevorzuge ich persönlich schlicht aus syntaktischen Gründen eine Templateengine. Die Syntax kann generell übersichtlicher sein und Shortcuts für Konstrukte anbieten welche in PHP programmiert die Templates aufblähen und unübersichtlich machen würden.

http://www.shlomifish.org/open-source/anti/php/:

• PHP annoyances (broken link as of 2008-11-17)
• Some comments from use Perl;
• Experiences of Using PHP in Large Websites
• Nathan Torkington's list of PHP's shortcomings
• GNU-Friends article by lupo (broken link - parked domain)
• PHP in contrast to perl systematically points out PHP inconsistencies
• Joel on Software mentions PHP's willful ignorance of character encodings[1]
• The PHP::Strings perl module will provide much enlightenment

[1] character encodings are a pain in the neck, but they are necessary

Some points of my own:

Of course you can write complex scripts in PHP - it's Turing complete. It's just painful. (See Paul Graham's Succinctness is Power article.) You can write complex scripts in assembler; it's also painful. But assembler has a niche, a place where it shines: when you need to hand-optimize something or write low-level code (think kernels, trampolines, compiler magic). PHP doesn't. There's nothing for which it is the best choice.

Ist jetzt bischen PHP Bashing aus der Perl Community (und einige Argumente sind mit Sicherheit veraltet), aber grad PHP in contrast to perl zeigt echt wie mies geplant und designed die Sprache ist.

Wie bereits erwähnt ist der herausragendste Vorteil von PHP die extrem breite Unterstützung auf Webservern. Natürlich braucht ein Browsergame früher oder später einen eigenen Server, den man dann ja auch konfigurieren kann wie man will. Aber während der Entwicklung lohnen sich IMHO die Kosten eiens vServers oder Rootservers kaum.

Weiterhin gefällt mir persöhnlich die übersichtliche Syntax von PHP sehr gut (z.B. {} statt begin...end), obwohl diese ja auch in C(++) zu finden ist. Praktisch finde ich den fehlenden Stress mit zu strengen Typen.

Performance ist natürlich ein Argument. Allerdings schaut man sich mal größere Browsergames wie Travian, KnightFight an - nur ganz selten auf SpeedServern mal ausgelastete Server. Und die sind in PHP geschrieben, so weit ich weiß. Haben die dann Monster-Server? Ich hatte bisher nur an den MySQL-Sockets Performenceprobleme.

Da muss ich doch mal mein

auspacken...

PHP scheitert an überkomplexen Business-Logiken, das ist richtig.

Bei Browsergames liegt das Nadelöhr aber doch meist in der Datenbank. 80% der Rechenzeit zur Seitengenerierung geht für Querys drauf. Der rest ist ja nix anderes als ein bisserl String-Basteln.

Allerdings: Wenn ich mir den SAP Netweaver so anguck ... performanter ist das auch nicht! Und ABAP kann auch nicht mehr als PHP.

Bei Java hat sich in sachen Ausführgeschwindigkeit richtig was getan. Leider nicht in Bezug auf die miese Doku und den Klassen-Wahnsinn.

Original von rami95

Weiterhin gefällt mir persöhnlich die übersichtliche Syntax von PHP sehr gut [...]

HUST!

http://www.tnx.nl/php.html sagt:

PHP has inconsistent function naming

• Case insensitive functions have the 'i' or 'case' at different positions in their names.
• There is no apparent system in underscore(s) versus no underscore(s):

  underscore               no underscore:
  stream_get_line          readline
  disk_free_space          diskfreespace
  is_object                isset
  mcal_day_of_week         jddayofweek
  set_error_handler        setlocale
  snmp_get_quick_print     snmpget
  get_browser              getallheaders
  base64_encode            urlencode
  image_type_to_mime_type  imagetypes
  msql_num_fields          mysql_numfields
  php_uname                phpversion
  strip_tags               stripslashes
  bind_textdomain_codeset  bindtextdomain
  cal_to_jd                gregoriantojd
  str_rot13                strpos
  

  Perl has no core function names with underscores in them.
• PHP has unlink, link and rename (system calls), but touch (the system call is utime, not touch).
• And they can't decide on word order:

• object verb: base64_decode, iptcparse, str_shuffle, var_dump
• verb object: create_function, recode_string

Perl core functions are all "verb object" except the superseded dbm* functions. (Note that sys is a prefix, not an object. And that flock and lstat were named after the system calls. shm* and msg* are library calls)

"to" or "2"?

ascii2ebcdic, bin2hex, deg2rad, ip2long, cal_to_jd (jdto*, *tojd), strtolower, strtotime,

PHP lacks abstraction and takes TIMTOWTDI to bad extremes

Why has PHP got 3079 functions while Perl does with only 206? In PHP, there are usually several functions that are very similar. In Perl, you have to know and remember less.

Another important factor is the use of modules, especially the DBI module which provides support for SQL databases, instead of bloating the core with lots of features that occupy memory but are rarely used.

(Modules that are more often not used than used don't count (This rules out PEAR for PHP and IO::File for Perl). Modules may be pulled in when the core provides no similar functionality. For simplicity, internal working is left out of this comparison.)

* Escaping:
    * PHP: (14)
    dbx_escape_string, escapeshellarg, escapeshellcmd, pg_escape_bytea,
    pg_escape_string, pg_unescape_bytea, addslashes, addcslashes, preg_quote,
    quotemeta, mysql_escape_string, mysql_real_escape_string,
    mysqli_real_escape_string, sqlite_escape_string
    * Perl: (2) [1]
    quotemeta, $dbh->quote
* Sorting:
    * PHP: (16)
    sort, arsort, asort, krsort, ksort, natsort, natcasesort, rsort, usort,
    array_multisort, uasort, uksort, dbx_sort, imap_sort, ldap_sort, yaz_sort
    * Perl: (1)
    sort
* Walking a list
    * PHP: (10)
    array_filter, preg_grep, array_search, array_unique, in_array, array_map,
    array_walk, array_count_values, array_change_key_case, array_sum
    * Perl: (2)
    map, grep
* Splitting:
    * PHP: (8)
    split, explode, strtok, spliti, chunk_split, mb_split, preg_split,
    str_split
    * Perl: (1)
    split
* Matching:
    * Strings:
        * PHP: (11)
        strstr, strchr, stristr, strpos, strrchr, stripos, mb_strpos,
        mb_strrpos, strrpos, strripos, substr
        * Perl: (3)
        index, rindex, substr
    * Regular expressions:
        * PHP: (6)
        ereg, eregi, mb_ereg, mb_eregi, preg_match, preg_match_all
        * Perl: (1)
        m//
* Substituting a matched part:
    * PHP: (12)
    ereg_replace, eregi_replace, mb_ereg_replace, mb_eregi_replace,
    preg_replace, str_ireplace, str_replace, ltrim, rtrim, trim, nl2br
    * Perl: (1)
    s///
* Connecting to an SQL database:
    * PHP: (17)
    dbx_connect, fbsql_connect, ibase_connect, msql_connect, msql_pconnect,
    mssql_connect, mysql_connect, odbc_connect, pg_connect, pg_pconnect,
    sesam_connect, ifx_pconnect, ifx_connect, sqlite_open, sqlite_popen,
    mysqli_connect, mysqli_pconnect
    * Perl: (2)
    DBI->connect, DBI->connect_cached
* Opening:
    * PHP: (5)
    dio_open, fopen, proc_open, popen, gzopen[2]
    * Perl: (2)
    open, sysopen
* Reading/receiving:
    * PHP: (12)
    dio_read, fread, gzread[2], socket_read, socket_recv, socket_recvfrom,
    socket_recvmsg, readline, fgetc, fgets, stream_get_line, file
    * Perl: (5)
    read, readline, sysread, recv, getc
* Printing/writing:
    * PHP: (14)
    print, echo, printf, fprintf, vprintf, dio_write, fwrite, fputs,
    gzwrite[2], socket_send, socket_sendmsg, socket_sendto, socket_write,
    socket_writev
    * Perl: (5)
    print, printf, syswrite, send, write
* Closing:
    * PHP: (7)
    closelog, dio_close, fclose, gzclose[2], pclose, socket_close,
    proc_close
    * Perl: (1)
    close
* Miscellaneous:
    * PHP:
    array_combine, array_fill, array_merge, list, range, count,
    create_function, strtr, pow, putenv, getenv, getmygid, getmypid, getmyuid
    * Perl:
    syntax or magic variables

Syntax <> Funktionsnamen. Das ist die API. Und dort findet man zumindest das was man sucht.

Und die API / Funktionen sind ja wohl ein unvermeidbarer Kern der Sprache und haben eben selbst auch eine Syntax, welche der Artikel und ich kritisieren.

Insofern finde ich es durchaus zulaessig Unzulaenglichkeiten in der API Syntax verallgemeinernd als Unzulaenglichkeiten in der PHP Syntax darzustellen.

Ich nicht, PHP hat eine schöne Syntax (finde ich) aber eine inkonsistente API. Wobei wiederum die Doku recht gut ist und bisher war die API das kleinste Problem bei der Entwicklung mit PHP.

Es ist auf jeden Fall besser als eine "durchdachte" API mit einer schlechten Dokumentation.

Wir entwickeln Browsergames, die vielleicht < 0,05 % des Internets ausmachen. Browsergames können sehr Rechenlastig sein (Warum verbieten die meisten Free-Hoster sie?). Deshalb würde ich mir sehr gut überlegen, ob ich ein BG in PHP schreibe (wenn ich weiß, dass es rechenintensiv sein wird).

Für ein simples Blogsystem (das an sich ja nur eine etwas erweiterte "Template-Engine-mit-Contenteingabe" ist) ist PHP besser geeignet, auch, weil man keinen vServer oder "echten"  Server benötigt, also die mögliche Verbreitung größer ist, wie Rami95 schon sagte.

Und da diese simplen Blogsysteme einen viel größeren Teil des Internets ausmachen, kann man jetzt nicht über die Langsamkeit von PHP herziehen, da die bei den meisten Anwendungen uninteressant bzw. nicht störend ist.

Alles natürlich IMHO ;)

Und wie nach jeder dieser Diskussion kann man in dem Punkt übereinstimmen, dass PHP durchaus brauchbar für kleinere Webandwendungen ist, da es schnell und überall aufgesetzt werden kann. Bei größeren Anwendungen dagegen, worunter auch Browsergames fallen, ist der anfallende Overhead an Performance und Entwicklungszeit aber ein großes Übel.

Nichtsdestotrotz ist anhaltende Kritik in meinen Augen notwendig, damit auch Druck auf die Entwickler ausgeübt die Zustände zu verbessern. Beispiel Python: die räumen ihre API mit jedem großen Release auf um inkonsistenzen zu entfernen - auf Kosten der Rückwärtskompatiblität. Allerdings bieten sie Migrationstools an, um schnell wieder auf dem neusten Stand zu sein. So einen Bruch vermisse ich bei PHP.

Ungefähr so (mit Ausnahmen) hatte ich mir die Diskussion gewünscht. Nach ein Paar kleinen Anmerkungen würde ich das Zwischenergebnis gern mal zusammenfassen:

Als erstes etwas, was mir beim editieren der Forenparser versaut hat:

  PHP ist ein Script, und das kann es auch nicht verbergen. Ursprünglich ist PHP als Templating Scriptsprache für html-Ausgabe entwickelt worden. die Oldies beherrschen zum Teil noch die short_open_tag Scriptweise, in einer Webseite Bits und Pieces von PHPCode elegant unterzubringen, um http://www./ mit dynamischen Inhalten zu versehen.

So elegant kann Templating in PHP sein. Viele PHP-Nutzer übersehen auch, dass man Scriptbereiche auch in Kontrollstrukturen unterbrechen kann, wie in:

 
Dh'fhàg min seo 'na shìneadh e,
'Na shìneadh e, 'na shìneadh e;
Gu'n dh'fhàg mi'n seo 'na shìneadh e
'Nuair dh'fhalbh mi 'bhuain nam braoilegan.

Zu den Kommentaren im einzelnen:

DrakeL:

Das "Design in PHP" bezog sich auf das Softwaredesign, nicht aufs Visuelle, entschuldige die flapsige Ausdrucksweise, Für "Umsetzung des Geschäftsmodells" war ich zu faul ;) mea culpa.

Zu OOP in PHP sag ich hernach noch was

Redrick:

Du hast entweder bewusst oder unbewusst den Einleitenden Beitrag nicht verstanden. Lies noch mal nach: ich verteufle PHP nicht, sondern ich versuche bei den PHP-Nutzern den Zweifel zu wecken, ob sie für die anliegende Aufgabe das richtige Werkzeug benutzen. 1986 hat sich die Dartmouth Universität öffentlich für die Erfindung von BASIC entschuldigt, weil ein Zusammenhang zwischen dem erlernen von BASIC als erste Programmiersprache und verkorkstem Entwicklungsstil gesehen wurde. Die PHP Entwickler laufen Gefahr, sich in eine ähnliche Situation zu manövrieren.

PHP ist turing complete, und IST damit per Definition eine vollwertige Programmiersprache. Es geht mehr um die Frage ob sie in den vielbenutzten Bereichen produktiv ist, und nicht teilweise eher ein Klotz am Fuss.

Drezil:

Java kann einfach sein, lass dich nicht von sogenannten "best practices" von halbreligiösen Javajüngern beirren. Was gewöhnungsbedürftig ist ist die Typgenauigkeit, was teilweise noch gewöhnungsbedürftiger durch Generics wird, aber wo PHP einfach schätzt und draufloscasted, was im Zweifel zu Fehlberechnungen führen kann, ohne dass du genau weisst wo der Fehler angefallen ist, liefert dir bei Java schon beim compilieren (oder abhängig von der IDE schon beim schreiben des Quellcodes) die Fehlermeldungen zu dem, was später falschlaufen wird oder eine Warnung zu dem, was falschlaufen kann.

Persönlich habe ich die Erfahrung gemacht, dass das die Entwicklungsarbeit eher verkürzt.

exe:

Deine Ausführungen zu Vorteilen von reinen Templatingengines kann ich nachvollziehen, allerdings würde ich sie ungern (aus Performancegründen) in PHP umgesetzt sehen (die Engine schreibe ich ja nur einmal), und ansonsten zöge ich einen precompiler vor, der mir aus einem "Dummyfreundlichen" template direkt PHP-code generiert, um einen zyklischen Berechnungsschritt zu sparen.

Kallisti:

Ich find PHP nicht vom Start weg schlecht geplant, die Sprache ist sich imo scheinbar nur selbst über den Kopf gewachsen, sozusagen irgendwo im Wald falsch abgebogen.

Der Perl/PHP vergleich ist zum Teil Äpfel mit Birnen vergleichen, zum beispiel beim Datenbankconnect:

Bei Perl ist hier ein Interface angegeben, bei PHP die 3rd-party API. Da kann PHP nicht wirklich etwas dafür, aber entsprechende Frameworks bieten auch für PHP abstraktionslayer an.

rami95:

Ich denke du hast einen positiven Kernpunkt von PHP getroffen: die kostengünstige Breitenverfügbarkeit. allerdings gibt es auch einige Hosts, die cgi schnittstellen, z.B. mit perl anbieten, und auch Javahosting z.B. mit Tomcat-instanzen ist nicht unbekannt. Andererseits wird auch angeboten, was nachgefragt wird, und wenn ein hinreichend grosser Kundenkreis nach Application-server hosting fragen würde anstatt einfach mit dem Gebotenen zu leben, dann gäbe es sicher hier auch mehr Angebot.

Amun Ra:

Dir gings nur darum das tolle Bild rumzuzeigen, sonst hättest du sicher konstruktivere Kritik angebracht, oder zumindest einen Hinweis gegeben, wenn du grad im Auge hast. Im Verhältnis zu sonstigen PHP-Kommentaren fand ich den Thread soweit jedenfalls recht konstruktiv ansonsten. Sprayst du dich da selbst?

Kampfhörnchen:

Performancetechnisch ist Java mittlerweile vergleichbar mit C++, und was die Dokumentation angeht, ich finde z.B. die Sun Dokumentation durchaus hinreichend, es gibt eine vielzahl von Tutorials auch für Einsteiger, und das es bei Drittanbieter-Bibliotheken teilweise grottig aussieht, das ist kein Javaspezifisches Problem, das gibt es unter anderem auch bei PHP.

Sehr schön finde ich, dass du die 80% Datenbank erwähnst. Schon mal darüber nachgedacht, dass das nicht unbedingt sein müsste? Ein grosser Anteil dieser 80% ist doch häufig die schon angemerkte Pseudopersistenz, und mit anderen Möglichkeiten in der Programmierung könnte die Architektur ganz anders aussehen (Zum Beispiel persistente Objekte mit Filesystem oder Datenbankserialisierung im Backend).

Dubbel:

schlechte Performance trägt zur Entropie bei und hält Serverspacekosten hoch. Wäre es nicht toll, wenn man durch effizientere Ressourcennutzung die doppelte Leistung fürs halbe Geld bekäme?

Klaus:

Deine Schlussfolgerung fasst die Sachlage gut zusammen, wobei ich allerdings den Punkt zum Druck ansetzen woanders sehe: Ich brauche kein verbessertes PHP, ich brauche mehr auswahl in alternativen Hostanbietern, die ab vom 0815 Lampp bezahlbare Alternativen anbieten. Und hier macht Konsumentendruck auch Sinn und hat Erfolgsaussichten.

Und abschliessend noch eitwas zu OOP in PHP:

OOP bedeutet mehr als nur Namespaces in Klassen zu schützen. OOP ist immer ein Tradeoff zwischen Wartbarkeit, Architektur und Performance. Wenn ich alle Aspekte der OOP nutzen kann inclusive Eventsteuerung etc. dann lohnt es sich, den Performanceabstrich in Kauf zu nehmen. Aber die typische "Seitenaufruf -> Scriptverarbeitung -> Contentrückgabe"-Architektur ist sowas von prozedural, dass sich die Frage stellt, ob OOP hier nicht verschwendet ist.

Original von Tron

Kallisti:

Ich find PHP nicht vom Start weg schlecht geplant, die Sprache ist sich imo scheinbar nur selbst über den Kopf gewachsen, sozusagen irgendwo im Wald falsch abgebogen.

Der Perl/PHP vergleich ist zum Teil Äpfel mit Birnen vergleichen, zum beispiel beim Datenbankconnect:

Bei Perl ist hier ein Interface angegeben, bei PHP die 3rd-party API. Da kann PHP nicht wirklich etwas dafür, aber entsprechende Frameworks bieten auch für PHP abstraktionslayer an.

Im Gegenteil, es ist kein Aepfel <> Birnen Vergleich, sondern es sind bereits zwei Kritikpunkte in einem.

1. Den Kern der Sprache mit Dingen aufblasen, die eigentlich optional sein sollten

2. Dabei eben eine miese API, stand das Ganze konsolidiert und aufgeraeumt in einem Befehl darzubieten.

Denn genau so etwas ruiniert einem die Portablitaet. Und selbst wenn ich in PHP ein Modul dafuer verwendet, hab ich immer noch den bloated Core, der hier kritisiert wird.

@Tron: Das war mehr als Bildantwort auf Kallistis Bild zu verstehen.
Vielleicht bin ich auch nur ein bisschen durchs Heise-Forum geschädigt.
Auch da verstehe ich die ganze Aufregung um PHP immer nicht.
Man kann mit PHP schnelle und sichere Anwendungen programmieren.
Im Bereich Blogs, Foren und CMS ist PHP durchaus ein mächtige Sprache.
Wenn ich mir die Spieleliste auf GN so ansehe,
ist PHP auch hier für 95% der gelisteten Titel die optimale Sprache.

Viel besser als das Riesen-Jpeg :) Immerhin eine Meinung, die ich nicht teilen kann. Meintest du wirklich "schnelle und sichere Anwendungen", oder  "schnell sichere Anwendungen"? Was Blogs und Foren angeht sehe ich das durchaus ähnlich, bei CMS habe ich da einige Bedenken, die zum Teil schon angedeutet sind.

Die 95% Aussage mit der optimalen Sprache halte ich so unbelegt und unbegründet für spekulativ und gewagt.

OOP und eine MVC Architektur sind meiner Meinung nach für Webentwicklung (Webseiten) unabdingbar. Verstehe gar nicht, wie man darüber diskutieren kann.

Und PHP lebt in einer prozeduralen Welt. Corefunktionen und APIs sind alle nicht für OOP angedacht, und alle planlos zusammengewürfelt. Verwendet man ein PHP Framework wie Cake oder CodeIgniter welches konsequent OOP und MVC beherzigt - oder baut sein eigenes - dann lässt sich in PHP zum Teil vernünftig arbeiten (im Rahmen dessen Möglichkeiten).

Doch dann stößt man immernoch auf die bereits oben genannten Probleme, wie totales API Chaos, schwachsinniges implizites Typecasting ('string' == true && 0 == false && 'string' == 0) (und das auch noch als "Feature" verkaufen). Man hat ohne eine komplexe vor overhead triefende Reflection API keine Möglichkeit für Metaprogrammierung. Man hat keine Closures. Man kann zum Beispiel kein (elegantes!, kommt mir jetzt nicht mit Propel oder sowas) ActiveRecord Pattern implementieren. Man hat außer ein paar popeligen OOP Ansätzen einfach nix brauchbares in PHP, womit das Coden vereinfacht wird. Aber egal, denn diese Programmierparadigmen vermisst in PHP niemand, weil die Leute die es gerne benutzen, gar nicht kennen.

Darum kann ich nur sagen, je eher ihr Euch mit Alternativen wie Ruby oder Python beschäftigt, desto besser.

Ps.: Es macht sowas von keinen Unterschied ob man ein "großes" oder "kleines" Projekt schreibt. Man kann prinzipiell mit allem alles machen. Die Frage ist nur, wie masochistisch man sein möchte.

Pps.: Das Performance-Argument ist doch heutzutage total irrelevant und nix, was man nicht mit 10 Euro Serverkosten mehr im Monat ausgleichen könnte. Viel wichtiger sind andere zeitliche Aspekte. Z.b. Deployment, Patches, Migration.

Original von Tron

exe:

Deine Ausführungen zu Vorteilen von reinen Templatingengines kann ich nachvollziehen, allerdings würde ich sie ungern (aus Performancegründen) in PHP umgesetzt sehen (die Engine schreibe ich ja nur einmal), und ansonsten zöge ich einen precompiler vor, der mir aus einem "Dummyfreundlichen" template direkt PHP-code generiert, um einen zyklischen Berechnungsschritt zu sparen.

Der Performancenachteil der Implementierung in PHP ist nun nicht so wichtig denn das betrifft nur den Parser und Compiler. Aber die werden nur einmalig ausgeführt um das Template in PHP-Code zu übersetzen und daraus ein PHP-Script auf die Festplatte zu schreiben - also einmalig pro Template, nicht einmalig pro Request. Dadurch ist zur Laufzeit kein Unterschied mehr zur reinen PHP-Lösung, da in beiden Fällen nur noch ein include auf ein PHP-Script gemacht wird.

Einen Performancenachteil der PHP-Lösung hat man dann, wenn man eine Art hot-deployment der Templates haben will, also auch zur Laufzeit ständig checkt ob sich ein Template geändert hat und wenn ja es neu kompiliert. In dem Fall hätte man pro Request und Template zwei zusätzliche stat() oder filemtime() Aufrufe um den Zustand des Templates zu prüfen. So ein Mechanismus ist O.K. während man sich in der Entwicklung befindet um nicht ständig manuell einen Compiler anzuschmeissen, sobald man die Anwendung dann produktiv installiert kompiliert man die Templates halt alle einmal und damit hat sich die Sache.

Ich find PHP nicht vom Start weg schlecht geplant, die Sprache ist sich imo scheinbar nur selbst über den Kopf gewachsen, sozusagen irgendwo im Wald falsch abgebogen.

Das ist ein wahrer Euphemismus. PHP ist überhaupt nicht falsch geplant und es ist entstanden aus einer Horde von Studenten und Hobbyprogrammierern, von denen jeder mal seine Funktionen und seine Extensions einbauen wollte.

Wenn ich mir nun die Eleganz des PHP 6 anschaue, dann weiß ich nicht, ob ich lachen oder weinen soll. Ich bevorzuge das lachen. Bis heute werden keine echten Lambda-Expressions unterstützt und mit PHP 6 soll sich dies auch nicht ändern. Insbesondere daher, dass die 'PHP'-Entwickler dies nicht sinnvoll in den jetzigen Quellcode reinbrachten.

Es ist auch ein klares Zeichen, dass die Win-Variante von PHP 5.2 noch mit Visual C++ 6 kompiliert worden ist, weil es auf neueren MS-Compilern nicht lief. Erst als Microsoft knapp ein Dutzend Programmierer auf den PHP-Quellcode losgelassen hatte (im Rahmen des 'Wir werden interoperabel'-Programms) ist dieses nun auch mit der aktuellen Visual Studio-Version kompilierbar. Ich denke, dass diese kleine Anekdote viel über die ungesteuerte und chaotische Qualität der PHP-Entwicklung aussagt.

Du sprichst von Abbiegen: Zum Abbiegen braucht man einen Weg. PHP hat keinen Weg. PHP ist eine Horde verlaufener Abenteuerer im dichten Dschungel.

Zum Thema Typsicherheit: In meinen Augen ist Typsicherheit für qualitative Softwareentwicklung sehr förderlich. Dass dies in PHP fehlt und zwar in dem Maße, dass man sogar einen absolut überflüssigen String-Konkenationsoperator einführen muss, ist ein Relikt der ersten Stunde. Das Projekt begann chaotisch und zieht eine Herrschar von anfangenden Programmiern auf die schlechten Seiten der Programmierung. Und von 'Schutzmaßnahmen' wie magic_quotes mal ganz abgesehen.

Und die schlechten Entscheidungen, wie sie hier schon mehrfach angesprochen wurden, haben Auswirkungen bis heute.

Und BTW: Java als genericfähig zu bezeichnen, ist ebenfalls sehr amüsant.

Oder geht mittlerweile das Überladen einer Methode mit unterschiedlichen Generics: Add (vector a); auf Add (vector a); So lang dies nicht geht, entspricht die Genericfähigkeit von Java etwa der Multithreading- und Unicodefähigkeit von PHP.

Statt die negativen Aspekte der einzelnen Sprachen hervorzuheben, wäre es nicht mal sinnvoll die Vorteile der Sprachen zu nehmen und darüber zu diskutieren welche Sprache "optimal" für ein Browsergame geeignet wäre?

Dass PHP noch viele Schwachpunkte hat und die Entwicklung nur schleppend voran geht ist klar, aber was wäre die Alternative? Welche Sprache würde soviel Vorteile gegenüber PHP bringen sodass sich der Aufwand lohnt umzusteigen?

Eine Sache ist mir noch in den Sinn gekommen: Es ist trotz allem - um auf den Topictitel zu kommen - aus Unternehmensperspektive kein Unsinn eine Applikation in PHP zu schreiben. Bei einer Umstellung müssten sich Mitarbeiter anpassen, sind womöglich gar nicht in der Lage, ihr Denken von prozeduralen Paradigmen zu lösen (dann hat man eh die falschen Leute). Der Auftraggeber verlangt womöglich PHP, usw.

EOriginal von DrakeL

Statt die negativen Aspekte der einzelnen Sprachen hervorzuheben, wäre es nicht mal sinnvoll die Vorteile der Sprachen zu nehmen und darüber zu diskutieren welche Sprache "optimal" für ein Browsergame geeignet wäre?

Es gibt gar keine optimale Sprache. Man kann mit jeder Sprache alles machen. Es liegt in der Hand des Entwicklers, keinen Unsinn zu fabrizieren. Aber PHP verleitet mit seiner (haha) Architektur jedoch eben zu unsauberem, unschönen Code. Man hat keine Metaprogrammierung, Closures, Lambda-Expressions, kein gar nix. Viele PHP-Entwickler sagen: "Brauch ich eh nicht". Doch was sie damit ehrlich sagen ist: "Ich hab keine Ahnung." Man hat nur lediglich OOP in Ansätzen und schwachsinniges Typecasting. Wie ich bereits weiter oben gesagt habe, lässt sich mit einem gescheiten Framework auch in PHP halbwegs guter Code produzieren. Es sind eben keine schönen sexy Sprachkonstrukte möglich, wie z.b. in Ruby oder Python.

Ich denke, dass da buhrmi soweit Recht hat.

Jeder wird nun seine Sprache nennen, die ER für optimal und sehr gut befindet. Manche Leute denken eher stark typisiert, der andere lieber funktional, der andere nutzt lieber eine altmodische Sprache mit einem sehr stabilen Kern, aber nur wenig Features und der andere rennt allen Bleeding-Edge-Technologien hinterher, die ein großes Softwareunternehmen auf den Markt wirft.

Ich persönlich würde mir zum Beispiel die Schönheit von C# mit der Bibliothek von Java und .Net vereint, in einem Applikationsserver wünschen, der so einfach zu programmieren ist, wie PHP unter Apache.

Pps.: Das Performance-Argument ist doch heutzutage total irrelevant und nix, was man nicht mit 10 Euro Serverkosten mehr im Monat ausgleichen könnte. Viel wichtiger sind andere zeitliche Aspekte. Z.b. Deployment, Patches, Migration.

Das halte ich aber für äußerst fraglich. Bei größeren Projekten kann man nicht mehr von 10 Euro sprechen. Klar, Wikipedia, Wordpress und sogar CakePHP (addons.mozilla.org) machen gut vor, dass PHP sich gut skalieren kann. Allerdings sind dies auch alles (inbesondere die Top10-Anwendung Wikipedia) Anwendungen, die eine extreme Read/Write-Ratio haben.

Tja, aber Wikipedia und Wordpress sind nun wirklich kein Paradebeispiel für OOP und MVC? Oder hab ich da mittlerweile eine Entwicklung verpasst?

@TheUndeadable

Ich denke, dass man unter Java Generics anders versteht - vielleicht auch deswegen/ausdemgrunde anders implementiert: Der Generic gehört zur Operation. Also, der Operator (Name, Ein- und Ausgabe und Typ) sind eine Definition. Deswegen ist ja auch statisch (im Quelltext) add() ungleich add(). Unabhängig davon würde ein Ersetzen des Generictypen sicher Vorteile bringen, aber ob ein Ableiten da die richtige Wahl ist?

@knalli:

Damit wir uns nicht vollständig missverstehen:

In Java werden Generic nur als reines Compiler-Feature gesehen, was ich als Fehler sehe. Die Runtime selbst kennt keine Generics.

Daher kann man in einer Klasse nicht zwei Methoden mit folgender Signatur deklarieren:

• int Sum(vector a) { return ... }
• int Sum(vector a ) { return ... }

Da diese aus der Sicht der JIT-Engine die absolut gleiche Signatur haben.

http://www.jprl.com/Blog/archive/development/2007/Aug-31.html

Furthermore, C#/.NET convey additional performance benefits due to the lack of required casts (as the verifier ensures everything is kosher) and support for value types (Java generics don't work with the builtin types like int), thus removing the overhead of boxing, and C# permits faster, more elegant, more understandable, and more maintainable code.

Man kann bei Java höchsten von einer Generic-ähnlichen Programmierung sprechen... Aber Generics sind was anderes.

Aber nun wieder, wenn gewollt, Back To Topic :-)

> dass PHP sich gut skalieren kann

Dies ist in der Tat der Fall, solange man dieses Problem im Auge behält und seine Architektur intelligent wählt.

Hier gebe ich dir voll und ganz Recht: Es gibt viele Projekte, die gut in PHP implementiert worden sind. Dem gegenüber steht aber die Horde von 'PHP-Proggern', die als erste Programmiersprache ausgerechnet PHP ausgewählt haben und durch krasse Fehlentscheidungen der Sprachentwickler eine völlig verkorkste Sprache erlernen.

Hier würde ich mir wünschen, wenn diese Personen lieber am Anfang eine Sprache mit Struktur erlernen. Sei es Python, Ruby, C# oder Java.

Original von TheUndeadable

Es ist auch ein klares Zeichen, dass die Win-Variante von PHP 5.2 noch mit Visual C++ 6 kompiliert worden ist, weil es auf neueren MS-Compilern nicht lief. Erst als Microsoft knapp ein Dutzend Programmierer auf den PHP-Quellcode losgelassen hatte (im Rahmen des 'Wir werden interoperabel'-Programms) ist dieses nun auch mit der aktuellen Visual Studio-Version kompilierbar.

Für die einen ist ein Qualitätskriterium des vorliegenden Codes, für die anderen ein Bewertungskriterium für die Migrierbarkeit von Microsoft Produkten. Manchmal kann man sich ganz schön in den Fuß schießen, nicht wahr?

Ich denke der durschlagende Erfolg der Sprache gibt ihr Recht. Den vielen Argumenten gegen PHP möchte ich die vielen Projekte, Produkte und Firmen gegenüberstellen die um PHP herum entstanden sind. Auch das sich überhaupt so viele Entwickler so detailiert an dieser Diskussion teilnehmen können bescheinigt den Siegeszug von PHP. PHP ist hier und wird uns sicher noch eine Weile bleiben. Für Neuentwicklungen gilt selbstverständlich: choose the right tool for the job (oder manchmal auch: choose the tool developed by a corporate overlord, siehe oben). Es gibt Vorteile, es gibt Nachteile, es gibt geeignete Projekte, es gibt ungeeignete Projekte.

Die Argumentation des Threaderstellers kann ich jedoch nicht nachvollziehen. Es ist keine Argumentation die vor der Benutzung von PHP sondern vor der Entwicklung von Webapplikationen warnt.

Original von knalli

Tja, aber Wikipedia und Wordpress sind nun wirklich kein Paradebeispiel für OOP und MVC? Oder hab ich da mittlerweile eine Entwicklung verpasst?

Willst du damit sagen dass du der Meinung bist, dass OOP und MVC unnötig sind, nur weil es Projekte gibt, die es nicht verwenden? Wie TheUndeadable weiter oben sagte: Jedem das seine.... Es ist jedenfalls meine persönliche unerschütterliche Meinung, dass man heutzutage ohne OOP und MVC kein größeres Projekt mehr angehen sollte.

Original von cherry

Ich denke der durschlagende Erfolg der Sprache gibt ihr Recht.

Genauso wie der durchschlagende Erfolg von "Pferdekacke" als Hauptnahrungsmittel. Milliarden von Fliegen sprechen für sich :)

scnr *g*

http://thedailywtf.com/Articles/FrontAhead-Design.aspx

Der einzig wahre Grund für PHP ;)

Find da nix was mit PHP zu tun hat und nicht auch in anderen Sprachen genauso gut oder besser geht.

Passt aber für typische PHP-Anwendungsentwicklung wie die Faust aufs Auge. Darum sind PHP-Entwicklungen im Unternehmensbereich auch so beliebt. Schneller und billiger entwickelt und am Ende sogar perfomanter als eine 'ordentliche' Java-Entwicklung mit 100 Abstraktionsschichten.

Original von TheUndeadable

@knalli:

[...]

Man kann bei Java höchsten von einer Generic-ähnlichen Programmierung sprechen... Aber Generics sind was anderes.

Ich hatte gehofft, die Betonung auf Quelltext legt dir das Nahe. Ja ich weiß das :) 2 Klassen, die sich nur durch einen Generic-Typen unterscheiden, im Java-Bytecode identisch sein sollten. Rein statisch also.

Aber nun wieder, wenn gewollt, Back To Topic :-)

Jup.

> dass PHP sich gut skalieren kann

[...]

Hier würde ich mir wünschen, wenn diese Personen lieber am Anfang eine Sprache mit Struktur erlernen. Sei es Python, Ruby, C# oder Java.

 Das ist richtig: Aber das ist nicht ganz der Kern dieser Threads, vor allem weil es genau in die falsche Richtung geht. Diese Anfänger beginnen eugentlich nicht mit "Applikationen" bzw. wenn, dann machen sie es in jeder Sprache irgendwie falsch. DAUs bzw. DAEs (Dümmste anzunehmender Entwickler :P) kriegen das hin.

Aber, großes Ja für einen Bruch (bsp. für PHP6 vorstellbar gewesen), der einfach grundlegende API-Strukturen und anderes macht. Aber nun gut..

Original von buhrmi

Original von knalli

Tja, aber Wikipedia und Wordpress sind nun wirklich kein Paradebeispiel für OOP und MVC? Oder hab ich da mittlerweile eine Entwicklung verpasst?

Willst du damit sagen dass du der Meinung bist, dass OOP und MVC unnötig sind, nur weil es Projekte gibt, die es nicht verwenden? Wie TheUndeadable weiter oben sagte: Jedem das seine.... Es ist jedenfalls meine persönliche unerschütterliche Meinung, dass man heutzutage ohne OOP und MVC kein größeres Projekt mehr angehen sollte.

Hum, leider genau falsch herum verstanden: Ich meinte ja, dass diese Projekte eben kein OOP und MVC (oder ich hab es verpasst) nutzen.. zumindestens nicht so, als das man es als solches bezeichnen könnte. Sie sind aber auch nicht super.. aber das Ergebnis ist alles andere als schlecht. Wikipedia ist eine Top10-Seite.. aber eine ausgerichtete Nur-Lesen-Seite.. naja, siehe eben Posting vorher.

Die 10.000 Diskussion wie scheiße PHP ist. Wird das nicht langsam langweilig? Diese religiös anmutenden Debatten sind es eigentlich echt nicht wert darauf einzugehen. Jeder soll doch das Werkzeug benutzen, das ihm am ehesten zusagt.
Diese Versuche andere zu überzeugen das der eigene Hammer besser zum hämmern geeignet ist als jeder anderer Hammer sind doch Unsinn.
Mag ja sein, das PHP seine Schwächen hat, einverstanden. Aber dann zeigt mir doch jemand mal bitte eine perfekte Sprache, die gibt es nämlich nicht.
Und für die allermeisten Webapplikationen reicht PHP absolut aus.
Scheiße kann man in jeder Sprache zusammenschreiben. Der Profi aber kann in allen Sprache glänzen...

@Tron: Ich kann Bekehrertypen nicht ausstehen, gerade wenn sie auf "Onkel" machen. Es macht auch einfach keinen Sinn, Programmiersprachen sind keine Religion. Sinn würde machen, wenn man Tipps gibt, wie man sauber und gut programmiert, unabhängig von der verwendeten Sprache.

@PHP-Hasser: Hat man euch die Sandförmchen geklaut? Geht woanders euren Frust ablassen. Lustige Bilder in der Signatur zeigen übrigens nur Unreife, aber seis drum, dafür gibts Filter. *gähn*

Der 10.000 Post warum Diskussionen wie scheiße PHP ist scheiße sind! Wird das nicht langsam langweilig?

Du hast anscheinend mehr Hass auf die "PHP-Hasser" als die PHP-Hasser auf PHP. Hat man dir deine Sandförmchen geklaut? Egal! Thema verfehlt, setzen, 6.

Mag ja sein, das PHP seine Schwächen hat, einverstanden. Aber dann zeigt mir doch jemand mal bitte eine perfekte Sprache, die gibt es nämlich nicht.

Ja.

Steht hier, das "PHP scheiße" ist? Oder geht es um [größere] Web-Applikationen? Moment, ich überlege noch..

Toby, Cherry, lest ihr eigentlich Threads, bevor ihr was dazu schreibt, oder reicht euch der Titel, um zu spekulieren?

Der Thread Bezeichnet Applikationsentwicklung in PHP als Unsinn, weil dies zu 95% der Grundtenor der sehr verbreiteten PHP-Kritiken ist. Ich finde in diesem Thread versammelt sich mittlerweile viel mehr an konstruktiver Diskussion zu dem Thema, und das war der Grundgedanke ihn anzufangen.

Tobi, ich hab nicht vor jemanden zu bekehren, meinetwegen kannst du nen Egoshooter in PHP coden wenn du bock drauf hast, bis du mit dem debuggen fertig bist gibts dann auch die Hardware die Realtime 3DE Grafik mit PHP und ImageMagick erlaubt. Ich schenk auch nem Penner keine Seife, wenn er nicht drum bittet.

Der Brainwanker kann in jeder Sprache glänzen, der Profi muss von seiner Arbeit leben und wird daher die Sprache nach Kriterien auswählen die im kritischen Pfad seines Projektes liegen. Sofern er die Wahl hat, heisst das.

Den Wirsing mit "der wahreProfi kann in allen Sprachen" hab ich schon mal vor über 20 Jahren von einem Informatikstudenten gehört, den ich mit nem Disassemblerlisting durchs Büro gejagt hab, weil er in 8086 Assembler einen imul mit ner Konstanten von 4 verbrochen hat.

Hast du dich übrigens mal gefragt, warum der Zimmermann einen anderen Hammer verwendet als der Hufschmied oder der Juwelier? ;) Selten wirst du jedenfalls Handwerker sehen, die mit einem grossen unregelmässig geformten Stein hämmern.

Die Anmerkung mit dem religiösen Fanatismus hat dich letztlich völlig disqualifiziert. Oder findest du es religiös, wenn ich jemandem, der bei Kopfschmerzen wie immer ne Kerze anzündet sage: "Mal drüber nachgedacht zum Arzt zu gehen oder einfach mal ne Aspirin einzuschmeissen?"

Aber die Kollegen, die noch nicht zu verbohrt sind und noch offen genug, mal den Horizont zu erweitern und Entwicklung in jeweis fürs Projekt geeigneten Sprachen zu versuchen, denen möchte ich einfach qualifiziertere Diskussionen anbieten als "PHP ist Scheisse".

Cherry, das Scheisse/Fliegen Beispiel war schon nicht schlecht, aber es geht noch besser. Zigaretten sind gut für dich, muss so sein, der Erfolg gibt ihnen Recht. Frag mal den Phillip Morris Vorstand. Es wurden einige Gründe angeführt, warum PHP so verbreitet ist, aber das muss nicht heissen, dass es nicht an vielen Stellen besser ginge.

Wo du rauslesen willst, dass ich vor Webanwendungsentwicklung warne ist mir völlig unklar, ich verdien schliesslich meine Brötchen damit. Webentwicklungen sind toll, falls wir denn irgenwann nochmal auf Lucent hören und noch ein paar Kabel über den Teich gelegt bekommen.

Engstirnig.

Wenn Browsergameentwicklung auf immer die selben Werkzeuge begrenzt wird, dann ist es nicht verwunderlich, wenn auch immer wieder das gleiche dabei herauskommt.

Zurück zu den Konstruktiveren.

Undeadable, ich hab nie behauptet, die Generic-Implementation in Java sei vollständig oder gut. Ich mag Java nicht einmal besonders, aber es hat seine sinnvollen Anwendungsbereiche. Ich sehe allerdings eine positive Verwendung in Typensicherheit und Generics, wenn sie dazu beitragen, die Fehler und Fehlermöglichkeiten aus der Runtime herauszuhalten, und schon beim compilen zu berücksichtigen. Ich bin auch nicht der Typ, der jedes piselige Feld auf private setzt um andere Nutzer meiner Bibliotheken vor ihrer eigenen Faul- und Dummheit zu schützen, die sollen gefälligst die Dokumentation meiner Interfaces lesen oder ihren Mist selber schreiben.

DrakeLs Idee, Positivbeispiele zu liefern, welche Sprache sich wofür eignet find ich grundsätzlich gut, aber ich glaube nicht, dass es DIE Sprache für Browserspiele gibt, die am besten geeignete Sprache zur Umsetzung kann ich an sich erst ermitteln, wenn das Modeling schon etwas weiter vorangeschritten ist. Zudem wäre das wohl etwas für andere Threads.

Knalli, "PHP ist Scheisse", steht in diesem Thread statistisch zumindest viel weniger als im Durchschnitt, und wenn, dann wohl eher für die, die es unbedingt überall herauslesen wollen. Und denen unterstelle ich einfach mal ganz provokant, dass sie ihr PHP verteidigen, weil sie zu faul sind, sich auch in was anderes einzuarbeiten, wenn es Sinn macht.

Ich denke alle, die bewusst PHP benutzen, mit den Schwächen leben in dem qualifizierten Wissen, dass es für ihre Projekte funktioniert, die haben KnowHow und Ego genug sich nicht angegriffen zu fühlen, wenn man über die Grenzen und Alternativen spricht. Ich mag viel mehr die ansprechen, die einfach noch nicht wissen, dass das nicht der Weisheit letzter Schluss sein muss.

> Der Thread Bezeichnet Applikationsentwicklung in PHP als Unsinn
Was für Applikationen meinst du denn genau?
Dein Egoshooterbeispiel oder ein CMS oder ein Blog oder Browsergames?

@tron:

keine sorge, ich verstehe sehr wohl um was es dir ursprünglich gegangen ist, allerdings wollte ich noch bissel abwarten damit noch mehr schmutz hier ansammelt

die argumentationen von dir sind nachvollziehbar, trotzdem ist die gesammte diskussion absolut für den a...

Die meisten entwickler sind nun mal NICHT hauptberuflich in der spielentwicklung. Und IMHO findet die entwicklung sowieso erst dann statt , wenn die eine (oft die einzige) sprache gerade mal gut genug für gesteckte ziele beherrscht wird. Dann fängt man an zu "hacken" und womöglich hat man sogar spass daran und wenn genug interesse/motivation für spielentwicklung da ist, versucht man immer komplexere dinge und erkennt unweigerlich SELBSTÄNDIG, dass PHP nicht mehr ausreichend ist.

Was hier aber betrieben wird ist die abwürgung der motivation im ansatz. ihr könnt nicht von leuten erwarten , dass die erst paar jährchen eure allmächtige C-familie "studieren" um ein BG programmieren zu dürfen. Einfach nur lächerlich und eine 1001e diskussionsrunde darüber, die sowieso in einer PHP-Hassrunde ausartet wird absolut nix neues bewirken. Da kannst du noch soviel moderationswillen reinstecken, wobei mir deine haltung ehrlich gesagt nicht ganz neutral anmutet

Auch ich persönlich  empfinde  manche kommentare durchaus  als religiosen fanatismus  aber auch sehr viel  gegenseitige arschkriecherei dabei. Du hast vergessen, dass viele andere überhaupt keine kopfschmerzen mit PHP haben und woher willst du wissen was sie alle anzünden um diese zu kurieren. Klingt mehr nach blinder argumentationswut als sachlicher diskussion

Auch ich persönlich  empfinde  manche kommentare durchaus  als religiosen fanatismus  aber auch sehr viel  gegenseitige arschkriecherei dabei. Du hast vergessen, dass viele andere überhaupt keine kopfschmerzen mit PHP haben und woher willst du wissen was sie alle anzünden um diese zu kurieren. Klingt mehr nach blinder argumentationswut als sachlicher diskussion

Da kann man gut dran ansetzen: Nur weil andere diese Kopfschmerzen nicht haben, heißt das ja noch nicht, das sie die eigentlich haben bzw. verdient haben (nach einer durchzechten Nacht, um das Bild auch zu verdeutlichen).

Selbst  unter den Entwicklern hier - ich nehme mal die meisten Teilnehmenden aussen vor - werden die meisten sicherlich die Wahl von PHP ernsthaft für ihre Anwendung in Frage gestellt haben. "Das geht schon irgendwie" und Fummeln (nein, anders gemeint).. damit geht es. Schließlich ging es für das andere Projekt auch, schließlich kann ich eh nichts anderes. Soll weniger provokant rüberkommen (als es wahrscheinlich jetzt tut), aber so ist es doch in der Praxis.

Ein guter Programmier / Informatiker kann erstmal nur das, was er kann. Das mag ja vielleicht vor 10 Jahren so gewesen sein, aber heute ist das Feld bereits so groß, dass man mit Sicherheit nicht mehr alles kann. Selbst alle Programmiersprachen zu erlernen (nicht beherrschen), ist etwas, was man quasi nicht mehr schaffen kann.

Was man aber gut können muss: Entscheiden. Und zwar nicht nur das Mittel (Hallo, Threadthema) sondern auch Werkzeug und der Weg zum Ziel. Ach ja, das war jetzt bisl religiös angehaucht..  

ich versuch es ein letztes mal :

1. ich bin 100% davon überzeugt, dass ich  mit gutem PHP ein besseres spiel machen kann  als in  schlechtem/unbekannten  C++(whatever), das ist  alles. Wenn ich eingeredet bekomm, dass mit PHP kein spiel zu programmieren ist und sonst keine sprache kann (eine neue sprache gescheit lernen kostet auch mindnestens halbes jahr tägliches freizeitcoden), dann lass ich im schlimsten fall KOMPLETT SEIN. Ich warne EUCH genau das zu predigen! NICHT MEHR UND NICHT WENIGER!

2. ich habe nie gesagt, man solle auf dem PHP ausruhen und nix neues lernen, lebenslange fortbildung ist pflicht, der ich gerne nachkomme (zum glück finde ich in der spielprogrammierung die dafür notwendige motivation). Ja ich glaube, dass ihr die Zielgruppe falsch einschätzt. Mir müsste keiner beweisen, dass PHP dreckig und eingeschränkt ist, das habe ich für mich schon längst rausgefunden. Auf die quereinsteiger  und  sich in der ausbildung befindliche leute wirken die elendigen gebete ala "C++ und OOP sind  unser tägliches brot" und behauptungen "wenn man das nicht beherscht dann sollte man es gleich lassen"  schlichtweg überheblich. NICHT MEHR UND NICHT WENIGER!

3. vielleicht sollte man auch langsam lernen zwischen realität und wunschdenken zu unterscheiden und auch mal einen gang runterschalten, ihr würdet diesem portal/forum damit eine grossen gefallen tun!

Mit welchem Bein bist du denn heute aufgestanden? Hier wird doch gar nichts gepredigt.. aber es herrscht hier wohl durchaus ein Unterschied zwischen dem Verständnis einiger Angelegenheiten.

Tja, wenn wir mal realistisch sind, so wissen wir alle, das es eine ganze Reihe von Projekten (Dunkelziffer hoch) gibt, die nicht "gut" gelöst sind. Das packe ich in die Schublade "funktioniert augenscheinlich, aber keine geeignete Lösung". Und ich weiß auch, was manche "Programmierer" so machen.. das will man als Anwender gar nicht wissen, wie das Produkt zustande gekommen ist. Und nein, ethisch gesehen ist "Hauptsache, das funktioniert" nicht gut.

> dass die erst paar jährchen eure allmächtige C-familie "studieren" um ein BG programmieren zu dürfen.

C und C++ sind auch im Allgemeinen nicht für Webentwicklung zu empfehlen.

Dafür gibt es andere Sprachen, mit dessen Hilfe man auch innerhalb von wenigen Wochen ein BG lauffähig hat.

Original von knalli

Mit welchem Bein bist du denn heute aufgestanden?

lass mal überlegen, ich glaub das ist immer das rechte!

ich weiss auch nicht warum mir das antue, php ist wirklich schlecht und verdient es nicht vom server verarbeitet zu werden, ich hoffe jetzt ziehen die dunkeln wolken ab, amen!

oh mann...dass ich das noch erleben darf

Original von TheUndeadable

Dafür gibt es andere Sprachen, mit dessen Hilfe man auch innerhalb von wenigen Wochen ein BG lauffähig hat.

 Das wäre doch viel eher nen Thema werd als das hier...finde ich

> Das packe ich in die Schublade "funktioniert augenscheinlich, aber keine geeignete Lösung"
Wenn eine Applikation (augenscheinlich) funktioniert ist es in meinen Augen eine geeignete Lösung.
> das will man als Anwender gar nicht wissen, wie das Produkt zustande gekommen ist
Ich denke das will der Anwender auch nicht.
> Und nein, ethisch gesehen ist "Hauptsache, das funktioniert" nicht gut.
Na ja "ethisch" gesehen, was immer das in der Applikationsentwicklung heissen mag, ist es das vielleicht nicht, aber welchen Anwender interessiert das schon?
Mich als Anwender, beispielsweise eines Nachrichtenportals, eines Social Networks, eines Browsergameportals oder was auch immer, interessiert nicht die Bohne mit was oder wie schlecht da programmiert wurde.
Mich interessiert von der technischen Seite doch nur, ob die Seite verfügbar ist, die Ladezeiten niedrig sind und das gegebenenfalls meine vertraulichen Daten sicher sind.
Alles andere ist mir doch egal.

Informatiker haben - bzw. sollten sie haben - eine Berufsethik. Tangiert dich sofort, wenn es um die E-Mail-Adresse und die notwendige Sicherheit geht und geht natürlich auch auf die Entwicklung ein.

Wenn eine Applikation (augenscheinlich) funktioniert ist es in meinen Augen eine geeignete Lösung.

Das hört sich genauso an, wie manche ihre Übungsaufgaben machen: Solange schrauben, bis foo(bar)=abc ist. Warum, wieso völlig egal. Hauptsache es kommt raus, was raus soll. 

Twitter hat funktioniert und funktioniert (und wird nach den Millionen wohl sogar noch ein paar Jahre funktionieren).. und dennoch haben sie vor 1-2 Jahren derbst ihre Struktur umbauen müssen, weil sie eben nicht gut gebaut war (sogar _mit_ oop/mvc). Nur weil "etwas funktioniert", ist das noch lange nicht richtig.

Natürlich will der Anwender das nicht wissen.. aber kein Mensch würde einen Porsche kaufen wollen, wenn er wüsste, das da ein Treckermotor drin ist. Ne, er will und kann nicht die Motorhaue aufmachen (sonst hinkt der Vergleich) und würde - weil er nur Tempo 30 fährt - es auch nicht merken. Ist es jetzt "gut", wenn du als Verkäufer den Kunden so verarschst? Ethisch sicherlich nicht, unternehmerisch kurzfristig gesehen allemal.

Mich interessiert von der technischen Seite doch nur, ob die Seite verfügbar ist, die Ladezeiten niedrig sind und das gegebenenfalls meine vertraulichen Daten sicher sind.

Genau. Kriegst du alles mit ohne OOP und Co hin. Jeder Informatiker wird allerdings bei größeren Anwendungen die Nichtexistenz nicht nur einmal in Frage stellen. Denn die Anwender wollen auch bei steigenden Userzahlen keine langsamen Seiten, die wollen ständig Neuerungen, die verstehen Ausfälle nicht, für die gibt es nur einen Server, die verstehen nichts von Technik.

* Disclaimer: Nein, hier soll PHP keinem Trecker gleichgesetzt werden. Noch soll behauptet werden, irgendeine andere Programmiersprache wäre ein Porsche im Vergleich zu PHP. Noch war die Idee, mal wieder Auto-Computer-Vergleich zu missbrauchen.. bietet sich aber an.

Redrick, ich kann deine Meinung, die Diskussion sei für den Arsch, nicht nachvollziehen. Die Form lässt an einigen Stellen zu Wünschen übrig, aber das tat sie bei den verbreiteten PHP Flames im Forum vorher schon, sei es im Kommentar oder Reaktionen darauf.

Was ich erreichen wollte, ist, dass argumentiert wird, WARUM so viele Bedenken haben, PHP in umfangreichen Projekten einzusetzen, und das ist finde ich prima gelungen. Ebenso hat der Titel des Threads funktioniert. Mit "Gibts Alternativen zu PHP in Browsergames" hätten diejenigen, die sich festgefahren an PHP klammern als gäbs nichts anderes den Thread vielleicht garnicht aufgemacht.

"Ich hab nu mal PHP gelernt und keine Zeit, mich mit was anderem zu befassen" ist in sich völlig schlüssig und in Ordnung. Entscheidet eh jeder selbst am Schluss. Aber ein kleiner Hinweis, dass man mit Pech spärer beim Refakturieren die eingesparte Zeit ganz locker auch wieder verbraten kann schadet finde ich überhaupt nicht.

Nebenbei ist es auch ausgebildeten Informatikern schon passiert, dass ihnen ein PHP Projekt aus dem Ruder gelaufen ist. Wie schwer das mit ner fordernden Community im Nacken ist, dann neu zu bauen, kannst du dir vielleicht vorstellen.

Knalli hat das ganz gut auf den Punkt gebracht, die Risiken bei PHP kommen vor allem zum tragen, wenn dein Projekt schon läuft, und du es erweitern oder verändern musst oder möchtest.

Die Diskussion gefällt mir, also bitte bitte nicht in die Standard-Phrasen zu PHP vs. Welt vs. Alles Böse abrutschen.

Danke!

Original von Tron

Was ich erreichen wollte, ist, dass argumentiert wird, WARUM so viele Bedenken haben, PHP in umfangreichen Projekten einzusetzen, und das ist finde ich prima gelungen. Ebenso hat der Titel des Threads funktioniert. Mit "Gibts Alternativen zu PHP in Browsergames" hätten diejenigen, die sich festgefahren an PHP klammern als gäbs nichts anderes den Thread vielleicht garnicht aufgemacht.

Ich finde die Argumentierung in Ordnung. Allerdings habe ich schon viele Alternativen probiert wie ASP.NET, Rails und Java Servlets. Hier mal ein paar subjektive Erfahrungswerte:

• ASP.NET hat schöne fertige Sachen wie der ganze Authentifizierungskram (Login, Registrierung etc.) allerdings sind die fertigen Sachen in Ihrer Umsetzung wenig optimal (Registrierung mit Sicherheitsfrage)
• Rails hat mit Ruby eine recht schöne Sprache, allerdings hab ich keine funktionierende IDE gefunden, Aptana RadRails beispielsweise hängt sich bei Updates nach einer Installation auf, NetBeans zeigt dauernd Fehlermeldungen an, dass manche Erweiterungen nicht aktuell sind, updated diese aber nicht
• Bei Java Servlets fand ich den Einstieg extrem schwierig, habe etwas mehr als ein Tag gebraucht bis ein "Hallo Welt" lief, die Serveradministration ist bald aufwendiger als die Entwicklung selbst

Jede Sprache bietet aber auch ihre Vorteile und Stärken, aber vom Gesamtkonzept her was Erlernbarkeit, Funktionalität, einfache Installation, Entwicklungsumgebung, einfache Hostingmöglichkeiten etc. angeht bin ich bisher mit Eclipse PDT + PHP + Zend Framework sehr gut gelaufen und überzeugt davon. Vom Design der Anwendung her gibt es dann auch keine großen Unterschiede mehr zwischen Rails und Zend Framework was MVC und OOP betrifft.

Original von DrakeL

• Rails hat mit Ruby eine recht schöne Sprache, allerdings hab ich keine funktionierende IDE gefunden, Aptana RadRails beispielsweise hängt sich bei Updates nach einer Installation auf, NetBeans zeigt dauernd Fehlermeldungen an, dass manche Erweiterungen nicht aktuell sind, updated diese aber nicht

Ich bin Netbeans ist in Version 6.5 ziemlich gut und ich persönlich hab keine Probleme mit Fehlermeldungen. Seit gut einer Woche Arbeite ich mit RubyMine und bin sehr zufrieden besonders da, das Deployment via SVN in meinen Augen besser ist als bei Aptana oder Netbeans.

In Kombination mit JRuby bietet es, in meinen Augen, sogar genug performance für ein Browsergame. Ich für mich werde mich fürs erste auf Ruby on  Rails für Browsergames konzentrieren, wie sinn voll das jetzt ist sei mal dahin gestellt. Ruby wird nicht die letzte Sprache sein die ich lerne, sie hat Vor und Nachteile und im Moment überwiegen in meinen Augen die Vorteile. Im Moment ist Ruby eine Favorit, wie lange das wird die Zeit zeigen.

@Tron ich hatte da eine Frage an dich...
> Was für Applikationen meinst du denn genau?
> Dein Egoshooterbeispiel oder ein CMS oder ein Blog oder Browsergames?
@knalli ich verstehe ja im Grunde worauf die hinaus willst,
aber wenn ich das mal ganz realistisch und betriebswirtschaftlich sehe,
kann ich mit einigen Punkten nicht konform gehen.
> Informatiker haben - bzw. sollten sie haben - eine Berufsethik.
Ich bin Betriebswirt.
> Tangiert dich sofort, wenn es um die E-Mail-Adresse und die notwendige Sicherheit geht
Ja klar, aber was hat das mit PHP zu tun?

> Solange schrauben, bis foo(bar)=abc ist.
Sorry das kann ich nicht nachvollziehen.
Ich musste noch nie "solange schrauben".

> Twitter hat funktioniert und funktioniert (und wird nach den Millionen wohl sogar noch ein paar Jahre funktionieren)..

Also ist doch alles top gelaufen für die Twitterentwickler.
> aber kein Mensch würde einen Porsche kaufen wollen, wenn er wüsste, das da ein Treckermotor drin ist.

Der Vergleich hinkt tatsächlich gewaltig.
> Kriegst du alles mit ohne OOP und Co hin.
Ich nutze OOP dort, wo es sinnvoll ist.
> Denn die Anwender wollen auch bei steigenden Userzahlen keine langsamen Seiten,
Ich sehe den Zusammenhang zu PHP nicht.
PHP kann wunderbar skalieren.
Durch das stateless request model warscheinlich sogar leichter als eine andere Anwendung.
> die wollen ständig Neuerungen
Es gibt genug Beispiele die sehr schön Plugins oder Hooks umgesetzt haben.

Original von Nerosmeel

Ich bin Netbeans ist in Version 6.5 ziemlich gut und ich persönlich hab keine Probleme mit Fehlermeldungen. Seit gut einer Woche Arbeite ich mit RubyMine und bin sehr zufrieden besonders da, das Deployment via SVN in meinen Augen besser ist als bei Aptana oder Netbeans.

Schaue ich mir gerne mal an, wobei der Vorteil für mich wenig bringt, da ich Bazaar nutze und das von keiner IDE unterstützt wird irgendwie. NetBeans bringt immer Fehler, dass RubyGems > 1.3.1 benötigt wird, beim Update ist dies aber nicht dabei.

In Kombination mit JRuby bietet es, in meinen Augen, sogar genug performance für ein Browsergame. Ich für mich werde mich fürs erste auf Ruby on  Rails für Browsergames konzentrieren, wie sinn voll das jetzt ist sei mal dahin gestellt. Ruby wird nicht die letzte Sprache sein die ich lerne, sie hat Vor und Nachteile und im Moment überwiegen in meinen Augen die Vorteile. Im Moment ist Ruby eine Favorit, wie lange das wird die Zeit zeigen.

Performance kann ich nichts sagen, denke da ist Ruby mit PHP vergleichbar.

Mir gefällt vor allem die saubere Sprache (also die oft bemängelte API von PHP ist in Ruby ja noch wie aus einem Guss) und der geringe Schreibaufwand (weniger Quellcode zu schreiben für gleiche Funktionalitäten). Ich fand Java schon immer zu streng wegen der Typensicherheit und PHP zu schwammig... :)

Original von DrakeL

Schaue ich mir gerne mal an, wobei der Vorteil für mich wenig bringt, da ich Bazaar nutze und das von keiner IDE unterstützt wird irgendwie. NetBeans bringt immer Fehler, dass RubyGems > 1.3.1 benötigt wird, beim Update ist dies aber nicht dabei.

Vll lag das bei mir daran das, als ich noch mit Netbeans gearbeitet habe, ich nicht das mitgelieferte Jruby genutzt habe.

Original von DrakeL

 NetBeans bringt immer Fehler, dass RubyGems > 1.3.1 benötigt wird, beim Update ist dies aber nicht dabei.

Versuchs mal mit gem update --system

dunwich.de läuft übrigens auch auf Rails :-)

Original von Amun Ra

Es gibt genug Beispiele die sehr schön Plugins oder Hooks umgesetzt haben.

Kann ich mir nicht vorstellen Es sei denn, man definiert "schön" als "das beste was die Sprache hergibt". Wie gesagt, die Sprachkonstrukte und Eleganz (oft auch als sexy code bezeichnet) die mit Ruby möglich sind und einem das Leben ungemein erleichtern und viele Vorgänge wie deployment und patches erträglicher machen sind mit PHP ganz einfach nicht möglich. Das hat nichts mit Hassen, Religion oder Bekehren zu tun.

Original von buhrmi

Original von DrakeL

 NetBeans bringt immer Fehler, dass RubyGems > 1.3.1 benötigt wird, beim Update ist dies aber nicht dabei.

Versuchs mal mit gem update --system

dunwich.de läuft übrigens auch auf Rails :-)

Ich mein das Problem hatte ich auch mal, hab dann auf den MRI gewechselt dann gings 

P.S. buhrmi welchen hoster hast du?

Amun Ra: Sorry, der Thread ist sehr aktiv, ich hatte die Frage überlesen.

Da das hier ein Browsergameforum ist bezieht sich der Thread auch auf Browsergames. Aber nicht nur auf Browsergames, wie sie sind, sondern auch wie sie sein könnten, und hier denke ich, dass man sich mit der beschränkung auf PHP Grenzen auferlegt. Nicht etwa Grenzen des prinzipiell Machbaren (turing complete ist turing complete, und ich kann in einer Lampp Umgebung im Zweifelsfall Pseudoeventhandling über die Datenbank emulieren, oder nach Schrödingers Katze postulieren, dass Events dann passieren, wenn jemand in die Kiste schaut).

Da sind wir auch schon an einem guten Beispiel, wo Lampp sicher nicht mehr das beste Werkzeug ist:

So bald meine Architektur eventbasierte Bereiche aufweist, oder falls bei der Datenbank connection pooling für Stabilität oder Performance, steh ich mit Lampp einfach im Wald. Für Zug- oder Ticbasierte Browsergames mag das nicht relevant sein, aber selbst bei diesen vergebe ich Potential in der Interaktion mit anderen Spielern.

Schön fand ich deinen Satz: "Ich benutze OOP wenn es sinnvoll ist". Persönlich halte ich in PHP OOP aus schon genannten Gründen nur für sinnvoll, um Daten mit Namespaces zu schützen, indem ich sie in Wrapper packe, nebst ein wenig Organisation in der Methodik, wenn im Team gearbeitet wird. Wenn man den maximalen Nutzen aus PHP-OOP ziehen will, dann nutzt man imo am besten die Klassen, um (PHP fehlende) Interfaces zu simulieren. Man setz voraus, das im Modeling die Klassen, Methoden und öffentliche Felder definiert, und danach möglichst nicht mehr geändert werden.

Das du das Stateless Request Model voraussetzt ist auch interessant. Ist das bei Browsergames (selbst bei existierenden) immer gegeben, oder wird auch fleissig darum herumgearbeitet?

DrakeL: Deine Erfahrung mit Java hätte nicht so frustrierend verlaufen müssen, das Problem bei Java ist sehr häufig, welche Bibliotheken ich wähle und was ich wirklich davon brauche.

Schau dir mal das Springframework an, gerade wenn mit Beanarchitektur gearbeitet wird, ist das ein sehr schönes Framework, was viele Arbeitsgänge tatsächlich vereinfacht statt zu verkomplizieren (Stichwort JdbcTemplate zum Beispiel)

Was strenge Typsicherheit bei Java angeht, die ist maximal solange lästig, wie du allein arbeitest, oder in sehr engem Kontakt mit den anderen Entwicklern deines Teams stehst. Ansonsten ist die Entwicklung gegen Interfaces und die Typsicherheit ein wahrer Segen.

Jap. Ich wüsste nicht, was man ohne Typen und Interfaces machen sollten. Selbst der schlimmste Entwickler kann keinen Vertragsbruch begehen, der gegen die Definition läuft. So soll es sein. Alles andere ist - es tut mir leid - hirnverbrannter Quarks. Natürlich ist das ein sowohl technischer als auch theoretischer Overhead, aber es zahlt sich aus. Nachhaltigkeit gibt es nicht nur in der Natur, sondern auch in einem Informatik-Ökosystem.

Rails hat mit Ruby eine recht schöne Sprache, allerdings hab ich keine funktionierende IDE gefunden, Aptana RadRails beispielsweise hängt sich bei Updates nach einer Installation auf, NetBeans zeigt dauernd Fehlermeldungen an, dass manche Erweiterungen nicht aktuell sind, updated diese aber nicht

Ich glaube, da programmiert eh eher weniger mit einer großen IDE als eher mit einem Editor, der das unterstützt. Für OSX bspw. TextMate zu empfehlen. Die agile bzw. rapid Entwicklung läßt das zu.. zumindestens ist mir das aufgefallen, als ich mal ein bisschen (!) mit RoR und CakePHP gearbeitet habe. Vielleicht fehlte auch die IDE.. fand TM mehr als ausreichend.

Bei Java Servlets fand ich den Einstieg extrem schwierig, habe etwas mehr als ein Tag gebraucht bis ein "Hallo Welt" lief, die Serveradministration ist bald aufwendiger als die Entwicklung selbst

Da kann man echt nur sagen: Für Hello World in der Tat total unbrauchbar :D Das benötigt wirklich viel Konfiguration - wenn auch seit Tomcat6/Eclipse3.3+? weniger - es zahlt sich halt später aus. Und bei kleinen Projekten komplette Fehlentscheidung. Kann man nur so zusammenfassen. Selbst als Java-Entwickler würde ich ne Mini-Anwendung nicht unbedingt damit machen.. das ist übertrieben.

> Informatiker haben - bzw. sollten sie haben - eine Berufsethik.
Ich bin Betriebswirt.

Sorry, aber worüber reden wir dann hier eigentlich? Du siehst dann also nur die kurzfristige Wirtschaftlichkeit und du willst die Funktionalität (funktionale Anforderung). Derjenige, der das entwickelt, der muss designen, formen, bauen, entscheiden.

Sicherheit war ein ethisches Beispiel, geht aber auch um Performance oder Wartbarkeit, state of the art/technique, über den Tellerrand gucken. Andere Entwickler müssen deinen Kram auch verstehen/verändern.

Also ist doch alles top gelaufen für die Twitterentwickler.

Da du das tatsächlich glaubst, hier die Antwort: Nein. Twitter hat immense Performanceprobleme vor einiger Zeit, zurückzuführen auf ihre Struktur (RoR). Nicht das RoR wahnsinnig schlecht sei (sie verwenden es afaik immer noch) - aber sie mussten sich umstellen. Es waren mit Sicherheit nicht "einfach nur ein paar neue Kisten Hardware".

PHP kann wunderbar skalieren.
Durch das stateless request model warscheinlich sogar leichter als eine andere Anwendung.

Also, PHP kann gut skalieren. Gute Beispiel ist und bleibt MediaWiki. Aber dein Zusatz "stateless" macht die ganze Aussage total sinnfrei. Stateless? Du brauchst doch eh wieder ne Session, eh wieder einen Benutzer, eh wieder dies und das.. ja, wirklich sehr stateless. Echt stateless sicher, damit sind wir dann wieder beim Ursprung von PHP.

Ich habe die meisten Antworten hier im Thread gelesen und es drängen sich mir folgende zwei Fragen auf:

• Wenn PHP unsinnig für Applikationen (insbesondere Browsergames) ist, welche sinnvolle Alternative gibt es?
• Wenn PHP aber sinnvoll ist oder es eine sinnvolle Alternative gibt, ist es überhaupt sinnvoll Browsergames für den Browser zu entwickeln?

Ich weiß, dass ich damit eigentlich ein neues Thema eröffne, aber da hier schon Begriffe wie OOP und MVC gefallen sind, erscheint mir die zweite Frage doch berechtigt. Denn wenn ja mein Browser nichts weiter tut, als eine Anfrage an den Server zu senden und eine Webseite zurückzugeben ist dies doch immer wieder der gleiche sequentielle Vorgang, der es dem Server erschwert, Sessiongebundene Daten zu halten (das Problem mit der Persistenz ist hier ja schon zur Genüge diskutiert worden). Wozu dann zum Beispiel eine große OO-Datenhaltung?

Meiner Meinung nach sollten Browserspiele in der Zukunft von diesem Request-Receive-Prinzip Abstand halten und statt dessen eine Umgebung für den Client schaffen, die Clientspezifische Daten selbst speichert und in der Lage ist, auf Events vom Server zu reagieren. Ganz wie es bei herkömmlichen Desktopspielen der Fall ist. Das ist allerdings mit der herkömmlichen Technik, nämlich Webseiten zu generieren, nur mit großem Aufwand möglich. Ich denke hier an Alternativen, wie Browser-Plugins oder Applets.

Ich denke also, dass nicht nur PHP, sondern auch jede andere Technik, die "nur" Webseiten generiert, ungeeignet für Browsergames ist.

p>Original von Progralixx

Meiner Meinung nach sollten Browserspiele in der Zukunft von diesem Request-Receive-Prinzip Abstand halten und statt dessen eine Umgebung für den Client schaffen, die Clientspezifische Daten selbst speichert und in der Lage ist, auf Events vom Server zu reagieren. Ganz wie es bei herkömmlichen Desktopspielen der Fall ist. Das ist allerdings mit der herkömmlichen Technik, nämlich Webseiten zu generieren, nur mit großem Aufwand möglich.

Financial-Rumors hat so funktioniert. HTML wurde vom Java-Script-Client aus JSON templates generiert. JSON hat den Vorteil, dass man z.B. Eingabge-Prüffunktionen mit einbetten konnte. Die Server-Technik war etwas wackelig, ich schreibe aber gerade an einer sehr soliden und performanten Lösung in C++. Ich habe mal recherchiert, was es so für Comet Lösungen am Markt gibt, wenn es Dich interessiert, kann ich Dir gerne mal die Liste zukommen lassen.

Wenn man die Technik hat, ist ihre Verwendung eigentlich recht einfach in der Regel wirst Du auf der Client-Seite eine Funktion haben, bei der Du callbacks anmelden kannst, um über Änderungen der Daten informiert zu werden. In Financial-Rumors sah die API so aus:

JavaScript:

var PubSub = {  
  subscription: function(subject_name, parameters, names) {}
  view: function(name, callback) {}

verwendet wird das dann so:

JavaScript:

PubSub.subscription("Warenmarkt", { "ware": 4, "ort": 5}, "view_name");
PubSub.view("view_name", function(data)
{
  alert("Juhu, Daten vom Server");
});

Ich denke hier an Alternativen, wie Browser-Plugins oder Applets.

Ich denke also, dass nicht nur PHP, sondern auch jede andere Technik, die "nur" Webseiten generiert, ungeeignet für Browsergames ist.

Die Vergangenheit hat ja gezeigt, dass sich nicht die technisch beste Lösung durchsetzt, sondern dass, was für den Nutzer am meisten Mehrwert hat. Mit den bestehenden Browser / Java-Script / HTTP Lösungen, kann man jedes Problem lösen und der Benutzer wird die Lösung bevorzugen, die mit dem was er jetzt hat seine Probleme löst. Er wird also kein Plugin installieren, wenn ihm jemand das gleiche anbieten kann und er dabei kein Plugin installieren muss.

mfg Torsten

Original von Progralixx

Ich habe die meisten Antworten hier im Thread gelesen und es drängen sich mir folgende zwei Fragen auf:

• Wenn PHP unsinnig für Applikationen (insbesondere Browsergames) ist, welche sinnvolle Alternative gibt es?
• Wenn PHP aber sinnvoll ist oder es eine sinnvolle Alternative gibt, ist es überhaupt sinnvoll Browsergames für den Browser zu entwickeln?

Ich weiß, dass ich damit eigentlich ein neues Thema eröffne, aber da hier schon Begriffe wie OOP und MVC gefallen sind, erscheint mir die zweite Frage doch berechtigt. Denn wenn ja mein Browser nichts weiter tut, als eine Anfrage an den Server zu senden und eine Webseite zurückzugeben ist dies doch immer wieder der gleiche sequentielle Vorgang, der es dem Server erschwert, Sessiongebundene Daten zu halten (das Problem mit der Persistenz ist hier ja schon zur Genüge diskutiert worden). Wozu dann zum Beispiel eine große OO-Datenhaltung?

Meiner Meinung nach sollten Browserspiele in der Zukunft von diesem Request-Receive-Prinzip Abstand halten und statt dessen eine Umgebung für den Client schaffen, die Clientspezifische Daten selbst speichert und in der Lage ist, auf Events vom Server zu reagieren. Ganz wie es bei herkömmlichen Desktopspielen der Fall ist. Das ist allerdings mit der herkömmlichen Technik, nämlich Webseiten zu generieren, nur mit großem Aufwand möglich. Ich denke hier an Alternativen, wie Browser-Plugins oder Applets.

Ich denke also, dass nicht nur PHP, sondern auch jede andere Technik, die "nur" Webseiten generiert, ungeeignet für Browsergames ist.

Gut geschrieben!

Ich verzichte an dieser Stelle auf die Frage nach den Alternativen zu PHP einzugehen und richte mich (auch wenn es ein bisschen Off-Topic ist) auf deine Bemerkung bzgl. der Browsergameenticklung.

Tatsächlich ist es so, dass ich im Rahmen meines Abitur zuerst ein gewöhnliches Browsergame entwickeln wollte, mich inzwischen jedoch auf die Programmierung eines (Browsegame-)Frameworks festgelegt habe. Da mein Abitur noch gut ein Jahr entfernt ist, liess ich mir die Idee nochmals durch den Kopf gehen und stiess dabei auf jene Fragen, die du in deinem Post weiter oben geäussert hast.

Die Idee hinter dem Framework, dass ich nun am entwickeln bin, geht genau darauf hinaus, von diesem Request/Response-Prinzip Abstand zu nehmen und dadurch vor allem Real-Time Browsergames zu ermöglichen, welche auf Events des Servers reagieren können.

Das Framework wird von mir in JavaScript für NodeJS (http://nodejs.org/) entwickelt werden, wobei die Client/Server Kommunikation mithilfe von socket.IO (http://socket.io/) realisiert werden wird.

NodeJS und socket.IO halte ich für die momentan beste Möglichkeit "mehr als nur einfache Webseiten generieren" zu lassen.

Schön und gut - aber wie soll das dann beim Benutzer=Spieler ankommen? NodeJS ist hier rein server-orientiert, und eine SocketIO gibt es früh Browser (wenn man mal von Plugins absieht) nur mit WebSockets, und deren Implementierung lässt bekanntlich noch etwas auf sich warten (geschweige denn, dass sie eine Verbreitung hätten).

Oder aber, du stellst beim Framework auch noch ein HTTP-Interface dar. Allerdings, und die Frage stelle ich jetzt mal in den Raum: Warum sollte man das tun? Weil es geht, oder hat das einen konkreten Nutzen gegenüber anderen Server-Lösungen?

Oder habe ich das ganz falsch verstanden, und NodeJS ist nur das Backend auf dem Server, d.h. da steckt noch ein normaler Webserver mit irgendwas davor?

Sieh dir bitte die Website zu socket.IO ( NodeJS plugin ) an: http://socket.io/

Ajo. Wahlweise WebSocket (gibt es derzeit de facto nicht), Plugins (Flash) oder eben ein aufgesetzter HTTP-Server*, welchen man zwingend für JSON(P) und Ajax benötigt.

Oder meintest du jetzt was anderes?

* Mir ist schon klar, dass man mit NodeJS auch eine HTTP-Schnittstelle konfigurieren kann (bzw. mit Modul auch fertig). Nur habe ich da noch nicht den Vorteil für ein BG gesehen, vor allem im Kontext einer "Applikation" (Thread). Darauf zielte meine Frage. ;)

Ah, tut mir Leid, da habe ich deinen Beitrag missverstanden.

Die Frage nach dem Vorteil ist fuer mich eigentlich relativ eindeutig: Die Entwicklung ist sehr viel angenehmer (sollte ein Framework doch ermoeglichen?) - Wenn ich zu einem beliebigen Zeitpunkt ein Event vom Server aus senden kann erspart mir das viel Arbeit.

Der Vorteil von socket.IO liegt dann zusaetzlich darin, dass verschiedene Transportmoeglichkeiten zur Verfuegung stehen, welche je nach Verfuegbarkeit und/oder Performance ausgewaehlt werden koennen. Ausserdem ist die Schnittestelle auf Server- und Clientseite sehr angenehm. (Angelehnt an die tatsaechliche WebSocket-Spec, sollte Letzteres also schlussendlich in grossem Rahmen implementiert werden, kann man auch auf socket.IO verzichten ohne viel Code umzuschreiben.)

Original von graczykr

Tatsächlich ist es so, dass ich im Rahmen meines Abitur zuerst ein gewöhnliches Browsergame entwickeln wollte, mich inzwischen jedoch auf die Programmierung eines (Browsegame-)Frameworks festgelegt habe.

 Das klingt für mich nach Schritt zwei vor Schritt eins.

mfg Torsten

 (der sich z.Z. mit einem gruseligem "Framework" von Berufsanfängern herumärgern muss)

gibt es eigentlich ein Websocket workaround für ältere Browser? Sprich irgend eine js lib die ich einbinden kann? weil ich habe heute das hier getestet

http://code.google.com/p/jquery-websocket/

leider sagte Firebug dass die klasse Websocket nicht vorhanden ist

Original von BlackScorp

gibt es eigentlich ein Websocket workaround für ältere Browser? Sprich irgend eine js lib die ich einbinden kann?

Guck dir mal den Link ein paar Posts weiter oben an. ;-)

Nun mir fehlt leider das  Informationstechnische Know-How, da meine Hauptprofession in einem anderen Bereich liegt. Jedoch frage ich mich (ohne alle Beiträge gelesen zu haben), ob PHP nicht doch recht sinnvoll für Browsergames ist. Denn, soweit ich mich erinnern kann war ein großer Vorteil der meisten gut-programmierten Browserspiele, dass sie kaum Anforderungen an den Rechner stellten auf dem sie gespielt wurden.

Sicherlich kann man viel darüber streiten welche Dinge zu den Grundvoraussetzungen gehören, die man wirklich erwarten kann. Kann ich von jedem User erwarten z.B. den Flash-Player installiert zu haben, oder dass Java Runtimes installiert sind etc. ?

Prinzipiell kann ein weniger aufwendiges Browsergame hier eindeutig punkten, oder? Gibt es Spiele die dynamisch mit den Bedingungen des User-Rechners umgehen?

MfG, Thomas

Ob du auf dem Server PHP einsetzt oder nicht hat absolut nichts damit zu tun ob du am Client Flash, Silverlight, Javascript oder plain HTMl einsetzt!

Grundsätzlich sollte man aber nur auf HTML und Javascript setzen beim client. Java-Appletts haben bei mir gleich verloren, Silverlight intelligent eingesetzt - ok, Flash - eher ungern.

Original von Dunedan

Original von BlackScorp

gibt es eigentlich ein Websocket workaround für ältere Browser? Sprich irgend eine js lib die ich einbinden kann?

Guck dir mal den Link ein paar Posts weiter oben an. ;-)

Kurz: Nein (für "irgend eine js lib"). Du hast scheinbar nicht verstanden, was Sockets sind -- oder ein Blick ins OSI wäre angebracht. :O)