Jump to content
Sign in to follow this  
mac_bobby

Vor- und Nachteile von PHP

Recommended Posts

Guest

- 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.

Share this post


Link to post
Share on other sites
- Flache Lernkurve sorgt für große Mengen schlechten Codes.


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

Share this post


Link to post
Share on other sites
Original von Statler

- Flache Lernkurve sorgt für große Mengen schlechten Codes.


Genau das bekomme ich bei dem Projekt wo ich "reingestolpert" bin zu spüren :ugly:

Share this post


Link to post
Share on other sites
Guest
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.

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.

Wie meinst Du das? Inwiefern sichtbar?

Share this post


Link to post
Share on other sites
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.

Wie meinst Du das? Inwiefern sichtbar?



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


:-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

Share this post


Link to post
Share on other sites
Guest
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.

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.

Share this post


Link to post
Share on other sites

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 ;-)

Share this post


Link to post
Share on other sites

Die es leider bisher in den php Plänen nicht gibt. Wieso eigentlich nicht.... ist schade. Sowas kann ja sogar Basic :-o

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites
Guest
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...


Ja. Aber es ist eben einfacher, wenn der Typ nicht mehr änderbar ist. Spart die Tests und das zugehörige Fehlerhandling.

Share this post


Link to post
Share on other sites

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! :P

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
Guest
sry, aber wenn du php kompilierst, dann kannst doch eh gewisse sachen weglassen?

Ja. Aber selbst wenn man alles was geht shared baut bringt PHP doch gleich ca. 800 Funktionen mit. Mein (hochoptimiertes) PHP-Binary hat eine Speichersignatur von ca. 3,6 MB! Das Perl-Binary aber nur 1,1MB - unbehandelt. Ein ebenfalls hochoptimiertes Apache-Filter-Modul bringt es sogar auf 4,3MB. Ich habe aber auch schon welche gesehen, die unbehandelt 15 oder gar 20 MB groß waren.


Noch mehr weg?

Nicht weg, sondern shared. Einige Extensions kann man immernoch nicht shared bauen. Man könnte beispielsweise nur eine handvoll Interna mitbringen - Funktions- und Klassenhandling bspw. - und den Rest in Module auslagern.

Share this post


Link to post
Share on other sites
Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...