4. PHP contra Perl

PHP contra Perl

  • B

    Shade Of Mine schrieb:

    Blue-Tiger schrieb:

    uhm.... PHP ist im eine Weiterentwicklung von Perl 😉

    Ne. Dazu fehlen zu essentielle Perl Konzepte.

    *g* ok, ich meinte auch eher "Spezialisierung", die sich auf die Web-Komponenten von Perl konzentriert 😉

    dass es einfach mal als einfacheres Perl fuer Webentwicklung geschrieben wurde, merkt man nur noch zum Teil.

    Wo denn zB?

    Ich hab den Eindruck manchmal einfach... z. B. (dummes Beispiel) beim $ vor den Variablen, wie sie auch Perl vor den Skalaren hat, vielen Designprinzipien (z. B. das Weak-Typing), aehnliche Funktionen (im Sinne von: heissen gleich, funktionieren gleich, nehmen z. T. gleiche oder sehr aehnliche Parameter)...

    0
  • N

    Blue-Tiger schrieb:

    z. B. (dummes Beispiel) beim $ vor den Variablen, wie sie auch Perl vor den Skalaren hat, vielen Designprinzipien (z. B. das Weak-Typing)

    Gibts alles schon seit der bourne-Shell.

    0
  • S
    Mod

    Blue-Tiger schrieb:

    Ich hab den Eindruck manchmal einfach... z. B. (dummes Beispiel) beim $ vor den Variablen, wie sie auch Perl vor den Skalaren hat

    Und schon einen essentiellen unterschied entdeckt:
    PHP hat nur $ - was sehr gängig ist, Perl hat hier viel mehr.

    vielen Designprinzipien (z. B. das Weak-Typing),

    wie fast alle script sprachen

    aehnliche Funktionen (im Sinne von: heissen gleich, funktionieren gleich, nehmen z. T. gleiche oder sehr aehnliche Parameter)...

    beispiele?
    PHP hat Funktionen von überall geerbt, zB die meisten C string funktionen.
    natürlich wird PHP auch einiges von Perl geerbt haben, aber die unterschiede zwischen Perl und PHP sind einfach zu gravierend.

    die syntax ist natürlich ähnlich, aber die ist bei allen C ähnlichen Sprachen so...

    0
  • B

    ok... dann aender ich meine Meinung auf "man erkennt NICHT mehr, dass PHPs Wurzeln bei Perl liegen" 😉

    0
  • N

    Blue-Tiger schrieb:

    ok... dann aender ich meine Meinung auf "man erkennt NICHT mehr, dass PHPs Wurzeln bei Perl liegen" 😉

    Ändere Deine Meinung lieber auf "PHP hat seine Wurzeln nicht bei PERL".

    0
  • B

    nman schrieb:

    Blue-Tiger schrieb:

    ok... dann aender ich meine Meinung auf "man erkennt NICHT mehr, dass PHPs Wurzeln bei Perl liegen" 😉

    Ändere Deine Meinung lieber auf "PHP hat seine Wurzeln nicht bei PERL".

    http://de.wikipedia.org/wiki/PHP unter "Geschichte":

    PHP wurde 1995 von Rasmus Lerdorf entwickelt. PHP stand damals noch für Personal Home Page Tools und war ursprünglich eine Sammlung von Perl-Skripten. Bald schrieb er jedoch eine größere Umsetzung in C, worin PHP auch heute noch geschrieben ist. Das schließlich veröffentlichte PHP/FI (FI stand für Form Interpreter) war Perl sehr ähnlich, wenn auch viel eingeschränkter, einfach, und ziemlich inkonsistent.

    oder siehe ebenfalls: Das PHP-Handbuch, Anhang A: "Die Geschichte von PHP und verwandten Projekten"
    http://it.php.net/manual/de/history.php

    (ich spar mir das quoten, weil der Wikipedia-Eintrag offensichtlich grossteils ohne Aenderung von dieser Page stammt)

    :p

    *rechthabenwill* 😉

    0
  • N

    Na und?

    Emacs war auch mal eine Sammlung von TECO-Makros, trotzdem behauptet niemand ernsthaft, Emacs stamme von TECO ab.

    0
  • ?

    Das würde für mich in erster Linie erstmal heissen, das jemand von Pearl die schnauze voll hatte und was eigenes machen wollte.

    Und das die Idee zu PHP aus einer SAMMLUNG von Pearl funktionen is, heisst net, das die Sprache deshalb auch darauf basieren muss.

    in Wiefern sie das nun wirklich tut, kann nur der PHP Author selbst sagen 😎

    0
  • N

    Ich korrigiere normalerweise keine Rechtschreibfehler, aber die Sprache heißt PERL, nicht Pearl.
    "Practical Extraction & Report Language".

    0
  • C

    o_O schrieb:

    Pearl is was anderes als CGI

    Und Pearl ist was anderes als Perl.

    0
  • ?

    ups...

    naja kann ja mal passieren 🙄

    0
  • ?

    nachtrag:
    naja kann auch mehr als einmal passieren -.-"

    0
  • ?

    In Perl hab ich noch nie gearbeitet. Aber kann es wirklich schlimmer werden als PHP??

    For converted Perl programmers: use strict comparison operators (===, !==) in place of string comparison operators (eq, ne). Don't use the simple equality operators (==, !=), because ($a == b)willreturnTRUEinmanysituationswhere(b) will return TRUE in many situations where (a eq $b) would return FALSE.

    For instance...
    "mary" == "fred" is FALSE, but
    "+010" == "10.0" is TRUE (!)

    *seufz*

    Auch hab ich mal nen Fehler gesucht, weil strpos FALSE liefert wenn er was nicht findet und ich wunder mich warum er es nicht findet. Die Auflösung war, dass er es an der Stelle 0 findet, was korrekt ist, aber leider zu einer klitzekleinen Komplikation geführt hat. 🙄

    if( 0 == "sdkufg" )   // Ergibt true

    😃 👍

    0
  • W

    Optimizer schrieb:

    if( 0 == "sdkufg" )   // Ergibt true

    Das glaube ich dir nicht. Was aber sein kann, und wovon ich ausgehe, dass du es meinst:

    0==strpos("asdfghjkl","e");

    - Das gibt dann true zurück, weil false auch den wert 0 hat... aber macht man das hier:

    0===strpos("asdfghjkl","e");

    liefert es false zurück, weil hier wirklich exakt darauf geachtet wird, dass es 0 und nicht false ist. Für mich eine gute Logik, sodass es dem Programmierer vorbehalten bleibt, es so zu sehen, dass 0=false ist (Wie in C/C++) oder eben nicht. Ich weiß nicht, wieso du dich darüber aufregst... mein gott... macht man halt ein gleichheitszeichen mehr rein...

    0
  • D

    Optimizer schrieb:

    In Perl hab ich noch nie gearbeitet. Aber kann es wirklich schlimmer werden als PHP??

    For converted Perl programmers: use strict comparison operators (===, !==) in place of string comparison operators (eq, ne). Don't use the simple equality operators (==, !=), because ($a == b)willreturnTRUEinmanysituationswhere(b) will return TRUE in many situations where (a eq $b) would return FALSE.

    For instance...
    "mary" == "fred" is FALSE, but
    "+010" == "10.0" is TRUE (!)

    *seufz*

    sehe da kein problem, dass ist doch nur definitions-sache und man muss halt wissen welchen operator man wo verwendet.
    In C++ schreibst du ja auch nicht

    char a[10], b[10];
    if(a == b);

    0
  • W

    DrGreenthumb schrieb:

    In C++ schreibst du ja auch nicht

    char a[10], b[10];
    if(a == b);

    Du etwa nicht? 😃

    0
  • ?

    Windoof schrieb:

    Optimizer schrieb:

    if( 0 == "sdkufg" )   // Ergibt true

    Das glaube ich dir nicht.

    Dann probier es doch aus. Glauben hilft dir hier nicht weiter. PHP wandelt bei solchen vergleichen den String implizit in ein int um.
    Es gibt nur eines was noch schlimmer ist als eine untypisierte Sprache: Ein untypisierte Sprache die völlig sinnlose Konvertierungen implizit durchführt.

    DrGreenthumb schrieb:

    char a[10], b[10];
    if(a == b);

    Ich sehe den Zusammenhang nicht.

    "+010" == "10.0"
    sollte IMHO ein Stringvergleich sein (also wenn dann a und b vom Typ std::string), stattdessen werden beide Seiten (die beide Strings sind !!!) implizit in Zahlen konvertiert (obwohl eins auch noch Ganzzahl und das andere FP ist) und verglichen. Während der Pointer-Vergleich bei C++ selten sinnvoll aber wenigstens logisch ist, werden hier irgendwelchen völlig unsinnigen Konvertierungen durchgeführt.
    Das ist affig. Da kannst du mir erzählen was du willst. Und wie gesagt, ich sehe den Zusammenhang nicht zu deinem Code.

    0
  • D

    Optimizer schrieb:

    Ich sehe den Zusammenhang nicht.

    In beiden Fällen muss man wissen, was == bedeutet. Wenn man PHP programmiert, muss man halt wissen, dass Zeichenketten mit eq (oder was auch immer) verglichen werden und == eine andere Bedeutung hat, so wie du in C strcmp nehmen musst und es in C++ bei stringobjekten auf einmal doch wieder mit == geht.

    Vielleicht wird so ein "wischiwaschi-Vergleich" im Kontext der Webprogrammierung viel häufiger benötigt als der genaue Zeichenkettenvergleich.

    Ich kenne weder Perl noch PHP genauer aber nur weils ungewohnt erscheint, muss es ja nicht unlogisch sein.

    0
  • ?

    Also, um nochmal hervorzuheben, was ich unlogisch finde:

    Ich finde es nicht unlogisch, dass wenn ich in C++ zwei Pointer vergleiche, dass nicht der Stringinhalt verglichen wird. Ich finde es nicht unlogisch, wenn bei std::string der Inhalt verglichen wird.

    Ich finde es unlogisch, wenn ich etwas dieser Form habe:
    einString == nochEinString

    dass beide Strings implizit in Zahlen konvertiert werden. Insbesondere, wenn es sich um Strings wie "sodiufh" handelt. DAS ist unlogisch. "dsuokfg" ist keine Zahl. Das ist auch nicht 0. 0 ist auch nicht das selbe wie "keine Zahl". Sowas gehört geschlagen.

    Du musst das Ganze jetzt noch unter dem Aspekt sehen, dass es so etwas wie Typen in PHP nicht direkt gibt. Du hast keine Möglichkeit, dich gegen so ein Verhalten zu wehren, weil _alles_ irgendwie in _alles_ umgewandelt wird. Ich finde es aber unlogisch, wenn ich links und rechts zwei gleiche Typen habe, dass beide umgewandelt werden. Weiter. Wenn also "soduhfölisgh" in 0 umgewandelt wird und mit der Zahl 0 verglichen true ergibt.
    Warum gibt dann eigentlich

    "sgdukf" == "skudgfkusgd"

    nicht

    0 == 0

    sondern liefert dann auf einmal false?

    Fragen über Fragen. Die man sicher irgendwo nachlesen kann. Aber das System ist Schrott. Es ist halt nirgendwo konsequent.

    "abc" == 0 ➡ true
    "xyz" == 0 ➡ true
    "abc" == "xyz" ➡ false
    macht schon keinen Sinn mehr. Der Vergleichsoperator ist damit nicht transitiv.
    "10.0" == "000010" ➡ true

    und jetzt dafür wieder das. 🙄

    0
  • D

    Optimizer schrieb:

    Es ist halt nirgendwo konsequent.

    "abc" == 0 ➡ true
    "xyz" == 0 ➡ true
    "abc" == "xyz" ➡ false
    macht schon keinen Sinn mehr. Der Vergleichsoperator ist damit nicht transitiv.
    "10.0" == "000010" ➡ true

    und jetzt dafür wieder das. 🙄

    also, wie gesagt, ich kenne PHP nicht, aber ich sehe hier schon konsequenz.
    So wie du bei "string" einen Pointer oder eine Zeichenkette siehst, sieht der ==-Operator eben einfach den Wert, also nicht die Repräsentation im Computer sondern eher das, was man auch als Mensch sieht.

    Woanders würde man sich dafür vielleicht eine Funktion human_compare(T, T) schreiben. Hier braucht man das jetzt offenbar so oft, dass es gleich ein Operator dafür gibt. Wieso nicht.

    0
Anmelden zum Antworten