Vor- und Nachteile von PHP

[mac_bobby]

Hallo zusammen.
Was kennt ihr für Nachteile, die sich bei PHP im Vergleich zu anderen Script- oder Programmiersprachen ergeben?

- Flache Lernkurve sorgt für große Mengen schlechten Codes.
 - PHP-Core-Team merkwürdig.
 - Inkonsistenten und Legacy an allen Ecken.
 - Kann nicht ordentlich mit Unicode.
 - Nicht durchgängig Thread-fähig.
 - Seltsames Security-Konzept.

[k00ni]

- Flache Lernkurve sorgt für große Mengen schlechten Codes.[/quote]
Würde ich nicht direkt als negativ bezeichnen. Die flache Lernkurve ist positiv, nur leider wird durch die \"Einfachheit\" der Sprache der eben angesprochene \"schlechte Code\" produziert. Ein etwas wager Punkt.
Was mich zum Beispiel noch stört, ist dass der Quellcode immer sichtbar ist. Somit wird vielen (nervigen und schlechten) Dingen Tor und Tür geöffnet.
 
Grüße

[mahe]

Original von Statler - Flache Lernkurve sorgt für große Mengen schlechten Codes.
[/quote]
Genau das bekomme ich bei dem Projekt wo ich \"reingestolpert\" bin zu spüren :ugly:

Würde ich nicht direkt als negativ bezeichnen. Die flache Lernkurve ist positiv, nur leider wird durch die \"Einfachheit\" der Sprache der eben angesprochene \"schlechte Code\" produziert. Ein etwas wager Punkt.[/quote]
Doch, ich bezeichne diesen Punkt als negativ. Stell dir J. Random Loser vor, der während der Sportstunde beschließt, k00ler Combuda-Hax0r zu werden. Er wird sich viele Sprachen anschauen und bei der einfachsten Sprache hängen bleiben - PHP. PHP ist sozusagen das Opferlamm, dass die Trottel großartig aus anderen Sprachen raushält.

Was mich zum Beispiel noch stört, ist dass der Quellcode immer sichtbar ist. Somit wird vielen (nervigen und schlechten) Dingen Tor und Tür geöffnet.[/quote]
Wie meinst Du das? Inwiefern sichtbar?

[k00ni]

Was mich zum Beispiel noch stört, ist dass der Quellcode immer sichtbar ist. Somit wird vielen (nervigen und schlechten) Dingen Tor und Tür geöffnet.[/quote]
Wie meinst Du das? Inwiefern sichtbar?
[/quote]
Sichtbar ist dafür der falsche Ausdruck gewesen. Ich meinte damit, dass man zu einer \"Software\" bzw. \"Skript\", die / dass man weiter gibt, auch immer den Quellcode mitliefert. Das halte ich gerade im kommerziellen Sektor für riskant, beispielsweise im Bezug auf \"Abkupfern\" oder auch dem Finden (und Ausnutzen) von Sicherheitslücken.

[...] k00ler Combuda-Hax0r [...] Er wird sich viele Sprachen anschauen und bei der einfachsten Sprache hängen bleiben - PHP[/quote]
 /uploads/emoticons/icon_e_surprised.gif.a8707b3f35a569cb4cfe563fc72ef78d.gif\" alt=\":-o\" /> Das mag sein, wobei noch einfacher dürfte da JavaScript sein. Wie schon gesagt, meiner Meinung nach ist das kein \"Nachteil\" von PHP. PHP ist sehr vielseitig und \"einfach\" strukturiert. Der Sinn von PHP wurde aber mit der Zeit zu sehr ausgedehnt; fast überdehnt. Schaue ich mir die Geschichte an, so war es eigentlich nur für die \"Dynamisierung\" der Seite gedacht und nicht dafür, riesige CMS oder Shop-Systeme zu entwickeln. So ähnlich verhält es sich doch auch mit der englischen Sprache. Die Lernkurve ist auch sehr niedrig; jeder denkt er \"könnte\" Englisch sprechen oder schreiben. Einbildung ist halt auch eine Bildung. Nur daran ist nicht die Sprache schuld.
Und nun stell dir mal vor, all diese \"Trottel\" gehe auf C#, C++ oder RUBY. Was meinst du, wie dann die IT-Welt aussehe? :ugly:
 
Grüße

Sichtbar ist dafür der falsche Ausdruck gewesen. Ich meinte damit, dass man zu einer \\\\\"Software\\\\\" bzw. \\\\\"Skript\\\\\", die / dass man weiter gibt, auch immer den Quellcode mitliefert. Das halte ich gerade im kommerziellen Sektor für riskant, beispielsweise im Bezug auf \\\\\"Abkupfern\\\\\" oder auch dem Finden (und Ausnutzen) von Sicherheitslücken.[/quote]
Achso. Naja. Ich kaufe selbst öfter Software kommerziell ein und halte genau dies für einen Vorteil. Sieh es so: Als Kunde möchte ich nicht von einem Dienstleister abhängig sein. Deswegen will ich Software haben, die ich auch von jemand anderem weiterpflegen lassen kann. Bei Kompilaten sind das dann eben auch die Sourcen.
Was Sicherheitslücken angeht wurde diese Quelloffenheit schon breit und erschöpfend ausdiskutiert. Stichworte sind \"Security by Obscurity\" und Kerckhoffs\\\' Prinzip. ESR meinte mal: \"Any security software design that doesn\\\'t assume the enemy possesses the source code is already untrustworthy; therefore, *never trust closed source*.\"
Ich kann das nur unterschreiben.

[k00ni]

Was mir noch fehlt ist die Möglichkeit, bestimmte Variablen so zu setzen, dass deren Typ nicht änderbar ist. Es ist zwar wunderbar, wenn ich in Variable A eine Zahl, dann ein Array und dann wieder einen String reinlegen kann, aber oft ist es aus Sicht der Wartung her besser, Variablen für einen Typ festmachen zu können. Dass heißt, lege ich bei der Variablendefinition den Typ integer fest, so können dort nur noch integer-Werte gespeichert werden; keine String-, Boolean oder Array-Werte mehr /uploads/emoticons/icon_e_wink.gif.3167d127940f44558fbf1ccd9b6d60a9.gif\" alt=\";-)\" />

Strikte Typisierung nennt man das.

[Powie]

Die es leider bisher in den php Plänen nicht gibt. Wieso eigentlich nicht.... ist schade. Sowas kann ja sogar Basic  /uploads/emoticons/icon_e_surprised.gif.a8707b3f35a569cb4cfe563fc72ef78d.gif\" alt=\":-o\" />

Wieso eigentlich nicht[/quote]
Rasmus wollte das halt nicht.

[raiser]

naja, zum Typisieren kannst doch auch, wenn auch zu aufwendig, immer den Typ prüfen,
an den Stellen, wo man den Typ ändern könnte...
is_int, is_float.....
Nachteil:
kein App-Server möglich
OOP verbessungswürdig
der eben erwähnte Typenzwang
Speicherverwaltung
 

naja, zum Typisieren kannst doch auch, wenn auch zu aufwendig, immer den Typ prüfen,an den Stellen, wo man den Typ ändern könnte...
[/quote]
Ja. Aber es ist eben einfacher, wenn der Typ nicht mehr änderbar ist. Spart die Tests und das zugehörige Fehlerhandling.

[sir robin]

Für\'n paar Sachen kannste ja TypeHints machen, wenn auch nicht für alles, das stimmt, wäre echt angebracht die auch für den Rest der Datentypen zu machen
Namespaces und vollständiger Unicode-Support kommen ja mit PHP6, schade ist, dass sie im Gegensatz zu Py3k nicht den Legacy-Code aufräumen und mal wirklich den Code sinnvoll anpacken und ausbessern (gerade die Inkonsistenzen in der Funktionsbenennung/Paramterreihenfolge nerven). Bei Py3k machen sie das, und da stört es, auch dank der 2.6er Zwischenversion, niemanden so recht.
Was mich viel mehr nervt als das oben beschriebene, ist das es kein konsequentes Exceptionhandling gibt und noch immer jede Funktion selbst entscheidet was sie mit den Fehlern macht. (Okay, das kann man abfangen über set_error_handler etc.)
Und zu guter Letzt find ich es immer noch schade, dass so viele Funktionen im Core drin sind und den ziemlich aufblähen. Mag ja sein, dass dies für Massenhoster interessant ist, aber für mich wäre es angenehm, wenn ich den Core abspecken könnte.
Ansonsten hat Statler  das meiste gesagt, die olle Labertasche.
P.S.: Statler, komm mal wieder nach Berlin! /uploads/emoticons/icon_razz.gif.dc5ac4073cd5f86a6626a9cd898df525.gif\" alt=\":P\" />

[raiser]

sry, aber wenn du php kompilierst, dann kannst doch eh gewisse sachen weglassen?
Noch mehr weg?
Dann sag mal mal, was für dich zum Core nicht dazu gehört?