PHP contra Perl

[Blue-Tiger]

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*

[nman]

Na und?

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

[o_O]

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

[nman]

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

[CarstenJ]

o_O schrieb:

Pearl is was anderes als CGI

Und Pearl ist was anderes als Perl.

[o_O]

ups...

naja kann ja mal passieren

[o_O]

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

[Gast]

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

[Windoof]

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

[DrGreenthumb]

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

[Windoof]

DrGreenthumb schrieb:

In C++ schreibst du ja auch nicht

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

Du etwa nicht?

[Gast]

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.

[DrGreenthumb]

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.

[Gast]

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.

[DrGreenthumb]

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.

[Gast]

Was meinst du jetzt mit 'Wert' ? Den Wert als Zahl? Warum schlägt dann der Vergleich "abc" == "xyz" fehl? Weil das keine Zahlen sind? Warum trifft dann der Vergleich "abc" == 0 zu? Ne, das ist IMHO nicht konsequent.

Und ich erwarte von einem op==, dass er transitiv ist. Sprich:

Es sei x == y und y == z
=> x == z

[supertux]

Optimizer schrieb:

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

der Grund, warum das false liefert, ist weil der Inhalt von !abc" nicht gleich wie der von "xyz". Ich verstehe was du meinst, aber du solltest auch besser wissen, was php macht. PHP macht keine Typunwandlung rein willkürlich, sondern wenn es erfordelich ist. Wenn du "abc"=="cde" hast, dann weiß PHP, dass sowohl links als auch Rechts ein string steht und somit ist eine Typumwandlung überflüssig. Bei 0=="abc" ist es so, das PHP sieht, dass 0 ein int ist und abc ein string, so wandelt "abc" in ein int um, oder umgekehrt, das 0 in einem string. Die Typumwandlung erfolgt nur, wenn links und rechts ungleiche Typs stehen.

Aber "abc"==$var1 ist tatsäclich riskant, deshalb bietet PHP Funktionen wie is_int, is_string, is_scalar,... und sollte davor benutzt werden.

[Gast]

supertux schrieb:

Aber "abc"==$var1 ist tatsäclich riskant, deshalb bietet PHP Funktionen wie is_int, is_string, is_scalar,... und sollte davor benutzt werden.

Ja, klar, das bringt das nicht-Typsystem sowieso mit sich. Deiner obigen Logik kann ich auch folgen. Ich habe nur folgendes Problem: Wenn ich deine Logik weiterspinne, komme ich zu diesem Fall:

"10.0" == "000010"

Ich möchte das jetzt unter deinem Gesichtspunkt betrachten:

Wenn du "abc"=="cde" hast, dann weiß PHP, dass sowohl links als auch Rechts ein string steht und somit ist eine Typumwandlung überflüssig.

Ich weiß jetzt, dass ich links und rechts einen String habe, denn ich habe ihn in schönen Anführungszeichen gesetzt. Trotzdem verhält sich PHP nicht so, wie es deiner (und meiner) Logik entspricht.

Leider bist du auch nicht auf das Problem mit der Transitivität eingegangen. Der Operator == wird in der PHP Dokumentation als "Gleichheitsoperator" bezeichnet. "Gleichheit" ist, wie man weiß, in jeder beliebigen M (also Elementtyp beliebig!!) eine Äquivalenzrelation. Äquivalenzrelationen müssen folgende Bedingungen erfüllen:
- Reflexivität
- Symmetrie
- Transitivität

Und letzteres erfüllt der op== in PHP nicht. Diese Sprache ist damit mit der Logik (und ich rede hier nicht von meiner Logik, sondern der formal korrekten Logik) nicht greifbar. Und mich stört sowas, wenn ein op== keine Äquivalenzrelation ist.

[supertux]

oh Mann... wenn du eine Äquivlenzrelation haben willst, dann nim ein Baltt Papier und beweise die Übunsgaufgaben von Lineare Algebra
Im Ernst, ich verstehe was du meinst, aber ich glaube nicht, dass die PHP Entwickler daran gedacht haben, dass es eine Äquivalenzrelation sein soll.

Außerdem machst du einen Fehler. Auch bei Sprachen, die == als Äquivalenzrelation haben, liefert == einen greifbaren Wert zurück, wie TRUE/FALSE, 0 oder 1 oder was weiß ich. Eine richtige Äquivalenzrelation tut sowas nicht, weil sie eine Äquivrel. und keine Funktion ist. Aber ist == in keiner Sprache wirklich eine Äquivalenzrelation. Und du weißt, eine Äquivalrel. stellt Beziehungen zwischen Elementen einer Menge, bildet sie aber niergendswo ab.

[Gast]

Außerdem machst du einen Fehler. Auch bei Sprachen, die == als Äquivalenzrelation haben, liefert == einen greifbaren Wert zurück, wie TRUE/FALSE, 0 oder 1 oder was weiß ich. Eine richtige Äquivalenzrelation tut sowas nicht, weil sie eine Äquivrel. und keine Funktion ist.

Hmmmm, kann ich nicht ganz nachvollziehen. In C++ ist == eine Äquivalenzrelation, außer du implementierst ihn für deine eigenen Typen falsch. In Java/C# auch.
Und es ist ja keine Abbildung. Der Rückgabewert true oder false gibt ja nur an, ob die Aussage wahr oder falsch ist. Jede Relationale Aussage kann wahr oder falsch sein, ich würde das jetzt nicht als Funktion auffassen.

Ich kann mir jetzt nirgendwo in besagten Sprachen einen Fall vorstellen, wo x == y und y == z wahre Aussagen sind, x == z dagegen falsch. In C++ ist es natürlich möglich, aber standardmäßig ist das Verhalten auch dort korrekt.

Und wenn dir das Beispiel nicht zusagt, können wir ja wieder zu "10.0" == "000010" bzw. "sodosih" == "skudgf" wechseln.
Hier ist das Verhalten des Operators vom Wert der Operanden abhängig. Also ne Logik kann ich da nicht entdecken.