|
|
Forum: PC-Programmierung Merkwürdiger php-FehlerWas ist die Ursache für diesen merkwürdigen Syntaxfehler:
Wenn ich die auskommentierte Zeile 40:
lösche, ist der Fehler weg. Wie das? :
Verschoben durch User
Uhu Uhuhu schrieb: > Wie das? in der syntax.php scheint das ende zu fehlen, dafür steht eine VIM zeile drin. wenn eine Datei mit <?php anfängt, sollte sie auch mit ?> enden. Ich vermute mal, dass sich der Interpreter am ?> in Zeile 40 verschluckt. Bin schon seit Jahren raus aus PHP; erscheint allerdings schon seltsam. Probier mal sowas: ...?'.'>' Das Skelett ist mit dem Plugin-Wizard von Dokuwiki erzeugt - die fehlende ?> - Klammer ist original so. Sie einzufügen verschiebt nur die Zeilennummer, auf der php auf die Schnauze fällt. Das Weglassen der ?> - Klammer scheint ihm egal zu sein. Ich habe heute ein anderes kleines Plugin gebaut, ebenfalls mit generiertem Skelett und fehlenden Klammern in zwei Quellfeils - das funktioniert prächtig... Patrick schrieb: > Ich vermute mal, dass sich der Interpreter am ?> in Zeile 40 > verschluckt. Die Vermutung war gut. Wenn man eins von beiden Zeichen raus nimmt, oder ein Blank dazwischen packt, ists weg. Sowas habe ich in 40 Jahren Programmiererei nicht erlebt. Was ist das für eine elende Schrottsprache... :
Bearbeitet durch User
Hat jemand PHP 5.4 oder 5.5 greifbar und kann mal probieren, ob die Gurke damit auch auftritt? Für die 5.3, die ich hier auf Ubuntu 12.04 habe, nehmen sie keine Bugreports mehr an. Es reicht schon, diese Zeile irgendwo einzufügen:
Uhu Uhuhu schrieb: > Hat jemand PHP 5.4 oder 5.5 greifbar und kann mal probieren, ob die > Gurke damit auch auftritt? IN PHP Version 5.5.7-2 geht es auch nicht. Super... Ich mach einen Bugreport. Das Ganze läßt tief blicken, wie die ganze Kiste zusammengehackt ist. Kein Wunder, daß PHP bei Ganoven so beliebt ist. Auf den Logs meines Servers finden sich Seitenweise Einbruchsversuche gegen phpmyadmin. Uhu Uhuhu schrieb: > Super... Ich mach einen Bugreport. hatte ich wegen einem SQL Fehler auch schon mal gemacht, wurde nie gelöst weil es eventuell nicht mehr abwärtskompatiblen ist. Die Kerle haben tatsächlich die Stirn, das als "not a bug" mit Verweis auf die Dokumentation abzuweisen. Wirklich unglaublich. Uhu Uhuhu schrieb: > Wirklich unglaublich. Nun, wenn es tatsächlich so in der Dokumentation steht, ist es nicht unglaubich, sondern die einzig logische Konsequenz, dich auf jene zu verweisen. Dass man diese implementierung für Unschön erachten kann, ist natürlich eine andere Geschichte. vn nn schrieb: > Nun, wenn es tatsächlich so in der Dokumentation steht, ist es nicht > unglaubich, sondern die einzig logische Konsequenz, dich auf jene zu > verweisen. Ist das die neuste Bugfix-Technologie? So kann man alles abbügeln und hinterher wundern sich die Leute, warum in der Gebrauchsanweisung zur Mikrowelle steht, daß man keine nassen Katzen damit trocknen darf... Uhu Uhuhu schrieb: > Die Vermutung war gut. Wenn man eins von beiden Zeichen raus nimmt, oder > ein Blank dazwischen packt, ists weg. Hast du denn mal
Probiert? Uhu Uhuhu schrieb: > Was ist das für eine elende Schrottsprache... Ja C ist auch so eine Schrottsprache, nicht mal Helloworld klappt da ;-P
Mein Bugreport wurde frecherweise abgelehnt! Uhu Uhuhu schrieb: > phpmyadmin Was hat ein Userprogramm den nun wieder mit der Sprache zu tun... Nachtrag: gedit unter Linux hebt das sogar derart hervor, dass man den "Fehler" sogar optisch hervorgehoben sieht. Uhu Uhuhu schrieb: > warum in der Gebrauchsanweisung Ja weil die ständig Bugreports bekommen "Katze lässt sich nicht trocknen" schreiben die Das einfach in die Doku anstelle das mal zu "fixen"... komische Logik. :
Bearbeitet durch User
Läubi .. schrieb: > Was hat ein Userprogramm den nun wieder mit der Sprache zu tun... Ganz einfach: mit einer Schrottsprache, wie PHP, muß man die Programmierer nicht extra dazu anhalten, irgend welchen Mist zu programmieren - die Sprache legt ihn einfach nahe. Die Folge sind Programme mit Sicherheitslücken im Dutzend billiger und die Ganove freuen sich... Läubi .. schrieb: > Uhu Uhuhu schrieb: >> warum in der Gebrauchsanweisung > > Ja weil die ständig Bugreports bekommen "Katze lässt sich nicht > trocknen" schreiben die Das einfach in die Doku anstelle das mal zu > "fixen"... komische Logik. Da hast du einfach etwas zu kurz gedacht: Die Folge der Methode "Der letzte Schrott ist schon in Ordnung, wenn er nur irgendwo im Kleingedruckten erwähnt ist" sind letztendlich Gebrauchsanleitungen der genannten Art. Gesunder Menschenverstand? Wo kämen wir denn hin, wenn jeder verlangen würde, die Hose nicht mit der Kneifzange anzuziehen... :
Bearbeitet durch User
Und was genau ist daran Schrott? Wenn ich einen Parser mit nicht eindeutigen Zeichenketten füttere muss ich mich auch nicht wundern wenn er das macht was er vorgesetzt bekommt. Dummerweise muss man da auch mal Zeichen oder Zeichenketten maskieren. Das ist nun mal so. ...Die Folge sind Programme mit Sicherheitslücken im Dutzend billiger und die Ganove freuen sich... Bloß weil die Nutzer irgendwelche Scripte zusammenklöppeln die irgendwie laufen, aber unsicher wie Sau sind liegt das nicht an der Sprache die dazu benutzt wird. Wer darüber schimpft das er selber unsicher programmiert hat soviel Hirn wie ein Spatz Fleisch an der Kniescheibe. Einer der weiterhin PHP programmiert. PHP-Freund schrieb: > Und was genau ist daran Schrott? > Wenn ich einen Parser mit nicht eindeutigen Zeichenketten füttere muss Da hast du das Problem genau erkannt. PHP hatte (zumindest urprünglich) keinen Parser. Sondern ein "wir frickeln uns per String-Suche irgendwas ausführbares zusammen"-Chaos. Und später musste es halt immer kompatibel bleiben. Der Rest ist, wie man so schön sagt, Geschichte. Deshalb wird PHP in Informatik/Compilerbau-Vorlesungen gerne als Negativ-Beispiel genommen, weil bei PHP so ziemlich alles falsch gemacht worden ist, was sich auch nur irgendwie falsch machen lässt. Man muss PHP aber zugute halten, dass es sich viel Mühe gibt, das vor den Anwendern zu verstecken. Disclaimer: Fühl dich nicht angegriffen. PHP selbst ist sch****, nicht das was PHP-Freunde damit programmieren. Uhu Uhuhu schrieb: > Ist das die neuste Bugfix-Technologie? So kann man alles abbügeln und > hinterher wundern sich die Leute, warum in der Gebrauchsanweisung zur > Mikrowelle steht, daß man keine nassen Katzen damit trocknen darf... Bitte was? Dein hinkender Vergleich ändert auch nix dran, dass Dinge, die laut Doku so gedacht sind, offensichtlich keine Fehler sind (andernfalls würden sie ja nicht in der Doku vermerkt sein). Uhu Uhuhu schrieb: > Ganz einfach: mit einer Schrottsprache, wie PHP, muß man die > Programmierer nicht extra dazu anhalten, irgend welchen Mist zu > programmieren - die Sprache legt ihn einfach nahe. Süß. Uhu Uhuhu schrieb: > Da hast du einfach etwas zu kurz gedacht: > Die Folge der Methode "Der letzte Schrott ist schon in Ordnung, wenn er > nur irgendwo im Kleingedruckten erwähnt ist" sind letztendlich > Gebrauchsanleitungen der genannten Art. Gesunder Menschenverstand? Wo > kämen wir denn hin, wenn jeder verlangen würde, die Hose nicht mit der > Kneifzange anzuziehen... Nun geht der Zusammenhang deines Geschwafles mit der Problemstellung endgültig verloren. Εrnst B✶ schrieb: > Da hast du das Problem genau erkannt. > PHP hatte (zumindest urprünglich) keinen Parser. Sondern ein "wir > frickeln uns per String-Suche irgendwas ausführbares zusammen"-Chaos. > Und später musste es halt immer kompatibel bleiben. > Der Rest ist, wie man so schön sagt, Geschichte. > > Deshalb wird PHP in Informatik/Compilerbau-Vorlesungen gerne als > Negativ-Beispiel genommen, weil bei PHP so ziemlich alles falsch gemacht > worden ist, was sich auch nur irgendwie falsch machen lässt. > > Man muss PHP aber zugute halten, dass es sich viel Mühe gibt, das vor > den Anwendern zu verstecken. Bestreitet ja auch keiner (siehe mein erstes Posting). Aber sich zu beschweren, dass sie etwas als "not a bug" ablehnen, was so in der Doku erwähnt ist (und somit offensichtlich kein Bug ist, wenn auch nicht gerade elegant), ist echt lächerlich. Das ganze dann damit zu vergleichen, dass man auch keine Katze in die Mikrowelle steckt, setzt dem ganzen nur de Krone auf. vn nn schrieb: > Nun geht der Zusammenhang deines Geschwafles mit der Problemstellung > endgültig verloren. Nicht alles, was DU nicht verstehst, ist Unsinn... vn nn schrieb: > Bestreitet ja auch keiner (siehe mein erstes Posting). Aber sich zu > beschweren, dass sie etwas als "not a bug" ablehnen, was so in der Doku > erwähnt ist (und somit offensichtlich kein Bug ist, wenn auch nicht > gerade elegant), ist echt lächerlich. Na ja, was soll man da noch sagen. Den Kadavergehorsam mit Schöpflöffeln gefressen und das dann auch noch von anderen verlangen... vn nn schrieb: > Das ganze dann damit zu > vergleichen, dass man auch keine Katze in die Mikrowelle steckt, setzt > dem ganzen nur de Krone auf. Daß du von Vergleich schafelst, zeigt nur, daß du nix begriffen hast... Ist aber bei der Grundhaltung auch nicht anders zu erwarten. :
Bearbeitet durch User
Ich teile durchaus die Ansicht, dass PHP keine besonders gute Programmiersprache ist. Nur, wenn man sie so dermaßen nicht leiden kann - warum benutzt man sie dann? Ist ja nicht so, dass es keine geeigneten Alternativen gäbe. Zum Beispiel Python, Ruby on Rails, Scala zusammen mit dem Lift Framework, ... Auch zur Software DokuWiki gibt es genügend Alternativen: http://de.wikipedia.org/wiki/Liste_von_Wiki-Software :
Bearbeitet durch User
Mark Brandis schrieb: > Nur, wenn man sie so dermaßen nicht leiden kann - warum benutzt man sie > dann? Ist ja nicht so, dass es keine geeigneten Alternativen gäbe. Zum > Beispiel Python, Ruby on Rails, Scala zusammen mit dem Lift Framework, Ja muß man denn eine Programmiersprache, die man - aus welchen Gründen auch immer - gerade benutzt, deswegen gleich super-gut finden? Wenn du mal mit einem alten rostigen Klepper von Fahrrad unterwegs bist, weil du gerade kein anderes hast, lobst du das Vehikel doch auch nicht in den 7. Himmel... PHP ist definitiv der mit weitem Abstand übelste Hack, der mir in Jahrzehnten Softwareentwicklung untergekommen ist. Da wird man doch wohl noch "ein gewisses Erstaunen", auch in etwas drastischerer Art, äußern dürfen. Ich konnte mir bis vor einigen Tagen, als ich mit gutem Grund damit anfing, schlicht nicht vorstellen, daß es möglich ist, eine derartige Anhäufung von gröbsten Designfehlern als weidlich genutztes Werkzeug zu etablieren. Ich bin überzeugt, daß sehr viele Internetschwachstellen auf diesen Murks zurückzuführen ist - die seitenlangen Logs von Einbruchsversuchen gegen phpmyadmin auf meinem Server sprechen da eine sehr klare Sprache -, der auch mit den raffiniertesten nachgeschobenen Hacks niemals eine Struktur bekommen wird, die die ganze Kiste immer vorhersehbar reagieren läßt. Und was ich besonders übel finde: Mit diesem Scheißdreck werden Millionen unbedarfter Programmierer regelrecht verdorben, weil sie damit nur konditioniert, aber nicht in klar strukturiertem Denken geschult werden. Die PHP-Strategie, die irreparablen Schwächen mit irgendwelchen Flicken zu verbrämen, halte ich für grundsätzlich falsch. Der einzig sinnvolle Weg wäre ein Versionskonzept, mit dem alte Software weiter betrieben werden kann, aber Neuentwicklungen auf ein Konzept geleitet werden, das dem Stand der Technik zumindest sehr deutlich näher kommt, als das heutige PHP. :
Bearbeitet durch User
Uhu Uhuhu schrieb: > Ich konnte mir bis vor einigen Tagen, als ich mit gutem Grund damit > anfing, schlicht nicht vorstellen, daß es möglich ist, eine derartige > Anhäufung von gröbsten Designfehlern als weidlich genutztes Werkzeug zu > etablieren. Doch, das geht ;-) Die Zahl der Websites, die PHP kritisieren, ist Legion: Why PHP sucks http://webonastick.com/php.html PHP: a fractal of bad design http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ PHP Must Die http://www.steike.com/code/php-must-die/ Problems with PHP http://toykeeper.net/soapbox/php_problems/ I’m sorry, but PHP sucks https://maurus.net/resources/programming-languages/php/ What I don't like about PHP http://www.bitstorm.org/edwin/en/php/ Experiences of Using PHP in Large Websites http://www.ukuug.org/events/linux2002/papers/html/php/index.html und das sind bestimmt nicht alle ;-) Hallo PHP-Freund, PHP-Freund schrieb: > Und was genau ist daran Schrott? Der Parser. > Wenn ich einen Parser mit nicht eindeutigen Zeichenketten füttere muss > ich mich auch nicht wundern wenn er das macht was er vorgesetzt bekommt. Das stimmt. In diesem Falle ist die Zeichenkette aber absolut eindeutig. Offensichtlich ist PHP dämlich genug, Kommentare zu parsen statt sie zu ignorieren -- und parst das, was es gar nicht parsen sollte, dann auch noch falsch. > Bloß weil die Nutzer irgendwelche Scripte zusammenklöppeln die irgendwie > laufen, aber unsicher wie Sau sind liegt das nicht an der Sprache die > dazu benutzt wird. Wenn eine Sprache mehrere tausend Funktionen in den globalen Namensraum klöppelt, diese Funktionen inkonsistent benamst und parametriert sind (explode() und implode(), um nur ein Beispiel zu nennen) und obendrein etliche ähnliche, aber doch nicht gleiche Funktionen existieren, dann verführt die Sprache den Nutzer zu Fehlern und ist schrottig designt. Daß PHP bis vor Kurzem keine Namensräume konnte und jetzt die mit Abstand häßlichste Lösung aller Zeiten als Namensraumtrenner benutzt, liegt zudem nur daran, daß die PHP-Core-Entwickler ihren eigenen flex-basierten Parser nicht mehr verstehen. Wie man auf die Idee kommen kann, sichere Software auf so einer unverstandenen Basis zu implementieren, bleibt schleierhaft. Beste Grüße, Karl Hallo vn, vn nn schrieb: > Uhu Uhuhu schrieb: >> Ist das die neuste Bugfix-Technologie? So kann man alles abbügeln und >> hinterher wundern sich die Leute, warum in der Gebrauchsanweisung zur >> Mikrowelle steht, daß man keine nassen Katzen damit trocknen darf... > > Bitte was? Dein hinkender Vergleich ändert auch nix dran, dass Dinge, > die laut Doku so gedacht sind, offensichtlich keine Fehler sind > (andernfalls würden sie ja nicht in der Doku vermerkt sein). Genau das hat Uhu doch bemängelt. Das erinnert mich an einen alten Witz: Wieviele Microsoft-Programmierer braucht man, um eine Glühbirne zu wechseln? Antwort: keine, Dunkelheit wird zum Standard erklärt. Genauso machen es die PHP-Entwickler auch: anstatt den Fehler zu beheben, wird er dokumentiert und künftig auf die Dokumentation verwiesen. Aber wenn ein Interpreter einen Kommentar falsch interpretiert, dann ist das ein Fehler, und zwar ungeachtet der Frage, ob dieser dokumentiert ist. Beste Grüße, Karl Karl Käfer schrieb: > liegt zudem nur daran, daß die PHP-Core-Entwickler ihren eigenen > flex-basierten Parser nicht mehr verstehen. Richtig flex-basiert ist er auch nicht durchgängig :) Zahlen werden nicht (ganz) vom Flex gelesen, sondern flex sammelt alle chars zusammen, die zu einer Zahl gehören könnten, und dann wird das ganz einfach an strtol (o.ä) übergeben. Ohne Check, ob sich die beiden über die Anzahl der verwerteten Bytes einig sind. Netter Effekt:
geben beide dasselbe aus. Ohne Warnung, ohne Fehlermeldung. :
Bearbeitet durch User
Ich hatte auch noch so eine Merkwürdigkeit:
Als Tag für $data im Array würde ich syntax_variables_state erwarten. Tatsächlich stand in den Metadaten von Dokuwiki aber
Wenn man
ausführt, erhält man syntax_variables_state Nach solchem Scheißdreck kann man sich einen Wolf suchen... :
Bearbeitet durch User
Uhu Uhuhu schrieb: > Nach solchem Scheißdreck kann man sich einen Wolf suchen... Wie wärs einfach mal mit Doku lesen oder sich mal ein Buch dazu zu kaufen?! http://www.php.net/manual/de/language.constants.php Uhu Uhuhu schrieb: > MODULE_PREFIX = 'syntax_variables_"; Abgeschrieben oder Copy&Paste? Wenn das Copy&Paste ist, kein Wunder das das alles nicht so Funktioniert, wie du das gerne hättest. Kaj schrieb: > Wie wärs einfach mal mit Doku lesen oder sich mal ein Buch dazu zu > kaufen?! > http://www.php.net/manual/de/language.constants.php Ehe du hier groß das Maul aufreißt, lies selber die Doku: http://de3.php.net/manual/de/language.oop5.constants.php Uhu auch wenn das möglicherweise frustrierend ist muß hier nicht der Thread zu einer Schimpftriade ausarten! Der Verweis war insofern korrekt, als das du (wenn auch unbeabsichtigt) solche eine Konstante genutzt hast, und höchstwahrscheinlich sogar eine Warnung darüber im log finden wirst (oder in deinem Output falls du das nun aktiviert hast) obwohl du eine Klassenkonstante nutzen wolltest. Daher nochmal von mir der Tipp, das Error Reporting hochzustellen und alle Warnungen zu beheben! Also bitte sachlich bleiben. Defintiv nur mit error_reporting E_ALL entwickeln! Das erspart später viel Ärger Aber das const MODULE_PREFIX = 'syntax_variables_"; keine Fehlermeldung liefert verwundert mich gerade doch ein wenig?! Auch das mit dem parsen der Kommentare war bei mir bisher kein Problem. Zumindest bin ich über das Verhalten nie gestolpert. Es scheint aber tatsächlich so zu sein, dass das "?>" auch in Kommentaren geparsed wird http://www.php.net/manual/en/language.basic-syntax.comments.php A. B. schrieb: > Defintiv nur mit error_reporting E_ALL entwickeln! > Das erspart später viel Ärger Besser: error_reporting(-1); E_ALL ist (Je nach PHP-Version) nicht "Alles", auch wenn der Name das suggeriert. A. B. schrieb: > Auch das mit dem parsen der Kommentare war bei mir bisher kein Problem. > Zumindest bin ich über das Verhalten nie gestolpert. Patternmatching und html-Tags - da rennt man ganz schnell in die Falle, wenn man das nicht weiß. Εrnst B✶ schrieb: > E_ALL ist (Je nach PHP-Version) nicht "Alles", auch wenn der Name das > suggeriert. PHP wäre nicht PHP, wenn es anders wäre... :
Bearbeitet durch User
Phpmyamin scheint für die Hacker wirklich unwiderstehlich zu sein. Ich hatte einen Angriffsversuch, der innerhalb von 4 Sekunden 1534 Anfragen nach irgend welchen Namen/Pfaden niederprasseln ließ, hinter denen sie phpmyadmin erhoffen. Sowas geht schon in Richtung Denial of Service. :
Bearbeitet durch User
Ich denke, man muß PHP mit Humor und bei Bedarf gewürzt mit einer ordentlichen Priese Spott nehmen. Einen Verein, an dem 50 Jahre Informatik spurlos vorbei gegangen sind, muß man nicht ernst nehmen. Bleibt also der mehr als ärgerliche Aspekt, daß PHP wohl zu einem erheblichen Teil die Grundlage für die Sicherheitprobleme im Web bildet. :
Bearbeitet durch User
Uhu Uhuhu schrieb: > Ich denke, man muß PHP mit Humor und bei Bedarf gewürzt mit einer > ordentlichen Priese Spott nehmen. Einen Verein, an dem 50 Jahre > Informatik spurlos vorbei gegangen sind, muß man nicht ernst nehmen. > > Bleibt also der mehr als ärgerliche Aspekt, daß PHP wohl zu einem > erheblichen Teil die Grundlage für die Sicherheitprobleme im Web bildet. Ich mag auch kein PHP und ja, Serversicherheit ist durch PHP nicht optimal. Aber das Problem des Buffer Overflow mitdem auch aus dem Web die Computer angegriffem werden ist ein klassischer C designfehler. dadada schrieb: > Ich mag auch kein PHP und ja, Serversicherheit ist durch PHP nicht > optimal. Aber das Problem des Buffer Overflow mitdem auch aus dem Web > die Computer angegriffem werden ist ein klassischer C designfehler. Den man vermeiden kann, indem man: -nicht einfach sofort drauflosschreibt, sondern erst prüft wieviele Bytes denn geschrieben werden sollen (in ein Array etc.) -statische Codeanalyse durchführt -statt sprintf snprintf verwendet usw. dadada schrieb: > Ich mag auch kein PHP und ja, Serversicherheit ist durch PHP nicht > optimal. Das ist sehr freundlich ausgedrückt. Ich würde sagen, daß in diesem Bereich des Softwareuniversums - man könnte ihn auch Softwarehölle nennen - der Begriff "Optimum" noch so weit unter dem Horizont ist, daß man darüber weder reden kann, noch muß... > Aber das Problem des Buffer Overflow mitdem auch aus dem Web > die Computer angegriffem werden ist ein klassischer C designfehler. Du weißt, wie alt diese "klassische" Herangehensweise von C ist? Anfang der 1970-er Jahre wurde es entwickelt. Und seither wurde C stetig weiterentwickelt, um diese alten Schwächen zu entschärfen und die Sprache handlicher zu machen. Und dabei hat man sie noch weitgehend kompatibel zu älteren Versionen gehalten - deswegen kann man noch heute mit den alten Funktionen den alten Mist machen, erhält aber von den meisten Compilern eindringliche Warnungen, die nicht in irgend welchen Serverlogs verschwinden. (Diese simplen Funktionen waren übrigens nicht reiner Übermut, sondern der Leistungsfähigkeit damaliger Computer geschuldet. Diese Kisten liefen z.T. noch im kHz-Bereich der Taktfrequenzen und ein einziges Speicherbit kostete einen deutlichen Dollar-Betrag.) Im Gegensatz dazu PHP: entstanden ist es als Hack, um die mühsame HTML-Programmiererei etwas zu erleichtern, gebastelt von Leuten, die von Compilerbau keinen blassen Dunst hatten. Seither gab man sich hemmungslos der Featuritis ohne Perspektive, Weit- und Überblick hin und Macken, die ruchbar wurden, wurden notdürftig mit irgend welchen alten Putzlumpen gestopft. Sprachentwicklung ist halt doch etwas mehr, als ein neues Dutzend Funktionen in die Bibliothek reinzuwurschteln, immer ängstlich darauf bedacht, den Nutzer nicht durch zu viel Gleichförmigkeit in den Interfaces zu langweilen... :
Bearbeitet durch User
Behauptete da nicht jemand, bei PHP gäbe es keinen "Compiler"?
Quelle: http://php.net/manual/de/function.error-reporting.php :
Bearbeitet durch User
Uhu Uhuhu schrieb: > Behauptete da nicht jemand, bei PHP gäbe es keinen Compiler? nein, hat nie jemand behauptet. Es wurde nur behauptet das ein Interpreter kein Compiler ist. Du hast behauptet das ein Interpreter Maschinencode erzeugt und das stimmt nun mal nicht. Peter II schrieb: > Du hast > behauptet das ein Interpreter Maschinencode erzeugt und das stimmt nun > mal nicht. Habe ich nicht. Der Unterschied zwischen einem Comiler und einem Interpreter ist im Wesentlichen nur, was mit dem vom Compile-Paß erzeugten Code passiert: Der Compiler konserviert ihn zu späterer, vielfacher Ausführung in einer Datei, während ein Interpreter seinen Zwischencode auf einer realen Maschine ausführt - also letztlich Befehle für die reale CPU daraus macht, die sofort ausgeführt werden. Die Übergänge sind jedoch fließend: Compiler können alles von einem der Quellsprache sehr ähnlichen Zwischencode - z.B. tokenised text -, bis zu echtem Maschinencode erzeugen. Wo man die jeweilige Ausgabesprache ansiedelt, ist meist das Ergebnis von Effizienzüberlegungen. Interpreter können fest mit dem Comiler verbunden sein - so bei PHP - oder eine vom Compler getrennt erzeugte Zwischencodedatei einlesen - Java, Python. Bei Java gibt es noch eine Spezialvariante: der Compiler erzeugt einen maschinen-unabhängigen Zwischencode, der von einem Compiler-Paß im Interpreter - oft sogar "just in time" - in Maschinencode der Zielmaschine umgesetzt wird, der sogar zur Wiederverwendung aufgehoben werden kann. Und zuguterletzt ist eine CPU auch nur ein Interpreter in Hardware, der aus dem Maschinencode Schaltwerke/Netze zusammenschaltet und so die Ausgaben erzeugt, mit denen die ganze Kiste überhaupt erst mit der Umwelt in Interaktion treten kann. Uhu Uhuhu schrieb: > also letztlich Befehle für die reale CPU daraus > macht, die sofort ausgeführt werden du hast es immer noch nicht verstanden. Ein Interpreter macht keinen code. Er interpretiert den Code und abhängig davon führt er einen Befehl aus. Es wird dabei aber kein Code erzeugt. Der Code ist also schon immer vorhanden. Nachtrag: Beispiel µC Atmel. Der Code liegt dort im Flash (also erstmal Readonly) damit kann man also keinen Compiler auf so einen System schreiben der etwas ausführt. Einen Interpreter kann man aber schreiben. Also der Fehler ist eigendlich wirklich eindeutig. Nach
$this->Lexer->addSpecialPattern('<smallcaps.*
ist für den Interpreter Schluss und da fehlt ihm halt wenigstens ein ');
Was jetzt die Geschichte von PHP damit zu tun hat (die ich auch nicht
optimal finde) verstehe ich jedoch nicht.
Man muss sich halt klar machen, was PHP ist und wie der Code
abgearbeitet wird. Hier wird natürlich erstmal der zu interpretierende
Code gesucht. Und dieser alleine betrachtet ist halt falsch.
Da finde ich die inkonsistente Namensgebung oder Parameteranordnung in
PHP eher problematisch... man kann dennoch in einem abgesteckten Rahmen
damit Enterprise Lösungen herstellen.
Ps: Da ich mein Geld mit PHP verdiene sehe ich das ganze aber vielleicht
auch nicht wie jemand anders. Es ist halt auch nur ein Werkzeug. Hammer
<=> Schraube
Peter II schrieb: > du hast es immer noch nicht verstanden. Oh Mann... > Ein Interpreter macht keinen code. Er füttert die CPU mit einem Codestrom, der dem Programm entspricht (und zusätzlich mit dem Code, den der Interpreter "für sich selbst" braucht). Ob der Strom aus einem ROM kommt, oder sonst woher, ist für die Logik völlig egal. Interpretation aus Sicht des Interpreters bedeutet, der CPU Laufzeitroutinen und Parameter zum Fraß vorzuwerfen - diesen "Fraß" könnte man in ein riesiges RAM sequentiell so abspeichern, wie sie vom Befehlsdecodierer der CPU gesehen werden - das ist der Codestrom, den der Interpreter erzeugt. > Der Code ist also schon immer vorhanden. Ja und? Der Code, den ein Compiler erzeugen kann, steht mit Definition der Sprache und seiner Implementierung fest und ist - auch wenn die Menge riesig, auf einer realen Maschine ist sie endlich - sozusagen auch schon vorhanden und ein konkreter Quelltext macht aus dieser Riesenmenge nur eine Auswahl. Aus dieser Perspektive ist der Compiler eine Suchmaschine, die aus dem (virtuellen) Fundus entsprechend dem Quelltext das Richtige raussucht. Stryker_2k schrieb: > Ps: Da ich mein Geld mit PHP verdiene sehe ich das ganze aber vielleicht > auch nicht wie jemand anders. Es ist halt auch nur ein Werkzeug. Hammer > <=> Schraube Das ist ja auch richtig so. Aber du hast dich womöglich auch schon über einen vermurksten Seitenschneider, oder einen wackligen Hammer geärgert. Uhu Uhuhu schrieb: > Aus dieser Perspektive ist der Compiler eine > Suchmaschine, die aus dem (virtuellen) Fundus entsprechend dem Quelltext > das Richtige raussucht. Nachtrag: Das ist das alte Informatikspielchen "Zeit gegen Speicher". Fakt ist, PHP ist inzwischen so verbreitet, dass es sich noch viele Jahre halten wird. Da gibts wirklich nur die Variante, damit zu leben oder eine andere Sprache zu nehmen. Man muss auch mal die Vorteile sehen; es geht mit PHP schon sehr einfach, Daten aus einer Datenbank abzufragen und dann eine HTML-Ausgabe zu generieren. Johnny B. schrieb: > Man muss auch mal die Vorteile sehen; es geht mit PHP schon sehr > einfach, Daten aus einer Datenbank abzufragen und dann eine HTML-Ausgabe > zu generieren. mit welcher Websprache geht es denn nicht einfach? Perl Java ASP Pyton Ich denke nicht, das es bei diesen sprachen aufwendiger ist. Peter II schrieb: > Ich denke nicht, das es bei diesen sprachen aufwendiger ist. Naja, wenn man PHP "sauber" schreibt und Frameworks nutzt, dann ist es nicht mehr viel einfacher bzw. wengier aufwaendig.. aber schnell "hinrotzten" geht offensichtlich sehr schnell mit PHP, kein Wunder dass es die verbreiteste Sprache fuer dyn. Webseiten ist. Boese Zungen behaupten, PHP waere keine Programmiersprache, sondern nur eine Ansammlung von schlechten Praktiken aus anderen Programmiersprachen. Andere wiederum sagen, PHP waere ein Aprilsscherz... naja, jedem das seine, meines wird PHP nie. Es gibt auch so etwas wie Compiler für PHP: siehe http://en.wikipedia.org/wiki/HipHop_for_PHP zum Beispiel, aber das nur am Rande um es noch ein wenig verworrener zu machen ;) Ich habe länger nichts mehr mit PHP gemacht und Beginne gerade wieder, aber was mir da auffält: die Sprache ist ziemlich im Wandel. Vieles was vor 3 Jahren ging ist mittlerweile abgekündigt, entfernt oder wird in einem der nächsten Releases entfernt Uhu Uhuhu schrieb: >> E_ALL ist (Je nach PHP-Version) nicht "Alles", auch wenn der Name das >> suggeriert. > > PHP wäre nicht PHP, wenn es anders wäre... So wie in C, nämlich -Wall beim gcc... Stefan Rand schrieb: > So wie in C, nämlich -Wall beim gcc... Das ist gcc, nicht C. Für C gibt es viele Compiler, PHP dagegen ist einmalig und es findet sich auch garantiert keiner, nichtmal ein Verrückter, der dieses Chaos nachimplementiert... :
Bearbeitet durch User
Hallo Mladen, Mladen G. schrieb: > Naja, wenn man PHP "sauber" schreibt und Frameworks nutzt, dann ist es > nicht mehr viel einfacher bzw. wengier aufwaendig.. aber schnell > "hinrotzten" geht offensichtlich sehr schnell mit PHP, kein Wunder dass > es die verbreiteste Sprache fuer dyn. Webseiten ist. Die Verbreitung erklärt sich nicht mit der Sprache, sondern mit dem Ausführungsmodell und der Verfügbarkeit. Um CGI-Programme zu schreiben, muß man sie in einen bestimmten Ordner (cgi-bin) packen und Ausführrechte setzen. Das ist für viele (auch angeblich professionelle) PHP-Benutzer schon viel zu kompliziert. PHP ist da einfacher: einfach eine Datei mit der entsprechenden Dateinamenerweiterung hochladen, schon läufts. Das ist kein Verdienst der Sprache PHP, sondern ein Verdienst der Tatsache, daß es zu Anfang als eine Art "erweitertes SSI" angesehen und deswegen von allen möglichen Webhostern standardmäßig installiert wurde. Liebe Grüße, Karl PHP-Freund schrieb: > Und was genau ist daran Schrott? > Wenn ich einen Parser mit nicht eindeutigen Zeichenketten füttere muss > ich mich auch nicht wundern wenn er das macht was er vorgesetzt bekommt. > Dummerweise muss man da auch mal Zeichen oder Zeichenketten maskieren. Vielleicht bin ich doof, aber was ist an "Der Scheiß, der jetzt kommt hat Dich nicht zu interessieren, das ist ein verfickter Kommentar!" uneindeutig? 42m Peter II schrieb: > du hast es immer noch nicht verstanden. Ein Interpreter macht > keinen code. > > Er interpretiert den Code und abhängig davon führt er einen Befehl aus. > Es wird dabei aber kein Code erzeugt. Der Code ist also schon immer > vorhanden. > Nachtrag: > > Beispiel µC Atmel. Der Code liegt dort im Flash (also erstmal Readonly) > damit kann man also keinen Compiler auf so einen System schreiben der > etwas ausführt. Einen Interpreter kann man aber schreiben. Öh, also macht ein Compiler Code (Maschinencode), der dann von der Maschine abgearbeitet wird. Und der Interpreter macht aus dem interpretierten Code ... auch irgendwie Maschinencode. Ist demnach ein Interpreter nicht auch ein Compiler? Ich würde ja sagen, ein Interpreter ist ein Laufzeitcompiler. 42m Michael Krauth schrieb: > Vielleicht bin ich doof, aber und was ist so schwer daran zu kapieren, das PHP kein perfektes PHP formatiertes File sondern ein eher recht als schlecht zusammengehacktes HTML bekommt und dort alles was zwischen <?php ?> steht, ungeachtet von Zeilenumbrüchen etc verarbeiten muss/soll/darf/.... Es ist halt so. In nahezu jeder Programiersprache ist es nicht möglich innerhalb eines Block-Kommentars das Kommentarendezeichen zu verwenden, trotzdem stört sich da niemand sondern empfindet das als "normal". Es ist doch müßig sich über solche Sachen zu echauffieren, die Lösung liegt doch auf der Hand: a) Alternative Sprache nutzen die "besser" ist b) sich sein eigenes PHP kompilieren was diesen "Bug" nicht hat Karl Käfer schrieb: > einfach eine Datei mit der entsprechenden Dateinamenerweiterung > hochladen, schon läuft Quatsch, auch das muss aktiv sein, ebenso wie man den Server konfigurieren muss ein oder alle Verzeichnisse für CGI zuzulassen. Der Unterschied ist nur, das CGI muss für den Server passend kompiliert werden, PHP kann ich "einfach" überall laufen lassen wo PHP zur Verfügung steht. Karl Käfer schrieb: > eine Art "erweitertes SSI" angesehen ist es doch auch, PHP ist im prinzip nur interpretiertes HTML und ganz stark daran ausgerichtet, was halt nicht unbedingt zum Vorteil von PHP gereicht. Läubi .. schrieb: > Es ist halt so. In nahezu jeder Programiersprache ist es nicht möglich > innerhalb eines Block-Kommentars das Kommentarendezeichen zu verwenden, > trotzdem stört sich da niemand sondern empfindet das als "normal". Nicht alles, was hinkt, ist ein Vergleich. ?> ist kein Kommentarendezeichen. Auch in PHP nicht. Uhu Uhuhu schrieb: > Nicht alles, was hinkt, ist ein Vergleich. ?> ist kein > Kommentarendezeichen. Auch in PHP nicht. Doch, im Prinzip schon. Es ist das Zeichen, welches den PHP von dem "HTML-Mode" in der "Interpreter-Mode" schaltet, ebenso wie ein Compiler vom "Parser-Mode" in den "Kommentar-Mode" schaltet. Auch wenn ich langsam denke du willst das garnicht verstehen sondern einfach nur deinen Frust loswerden, PHP hat nicht als Input ein "plain php skript" sondern ein Textfile (idr. HTML) welches keine, eine oder mehrere <?php ?> (und in bestimmten Modi sogar <% %> und <? ?>) enthalten kann. Außerhalb wird alles 1:1 durchgereicht und innerhalb halt als PHP interpretiert, um um dieses inlining zu unterstützen wird halt auch kein extra Umbruch eingefügt, und auch nicht Umbrüche benötigt. Das das jetzt in ganz speziellen Sonderfällen zu Problemen führt ist halt so und lässt sich aber (s.o.) relativ einfach umgehen indem man diese Steuerzeichenfolge "aufbricht". Läubi .. schrieb: > Doch, im Prinzip schon. Es ist das Zeichen, welches den PHP von dem > "HTML-Mode" in der "Interpreter-Mode" schaltet, ebenso wie ein Compiler > vom "Parser-Mode" in den "Kommentar-Mode" schaltet. Daß es das tut, ist offensichtlich. Daß das Ganze ein kapitaler Design-Fehler ist, aber auch... > Auch wenn ich langsam denke du willst das garnicht verstehen sondern > einfach nur deinen Frust loswerden Frust? Nein, ich amüsiere mich darüber nur noch. Dazu muß man sich wirklich nicht in den geistigen Morast derer begeben, die diesen Unsinn verbrochen haben. Es reicht, die gröbsten Schoten zu kennen, um relativ schnell auf die Idee zu kommen, daß bei dieser Sprache sowieso alles anders ist, als man denket. Ohne Sinn und Verstand irgendwas zusammenzuwursteln ist keine Kunst und gutes Design¹ zeichnet sich dadurch aus, daß es den für den Anwender notwendigen Regelsatz klein und konsistent hält. Das Auswendiglernen von Konvoluten von Qualität und Umfang eines Großstadt-Telefonbuchs ist ziemlich ineffizient und lenkt vor allem von dem ab, was man eigentlich vor hat. ----------------- ¹) Yukihiro Matsumoto hat mal irgendwo sehr schön beschrieben, dass es ihm sehr wichtig ist, Ruby möglichst intuitiv zu gestalten. Dazu wird experimentiert und vor allem viel nachgedacht. Im Suff mal eben wieder 3 Dutzend "Neuerungen" über über der werten Anwenderschaft auszukippen, geht einfach nicht... :
Bearbeitet durch User
Mark Brandis schrieb: > Wie gesagt, PHP kann man verwenden, muss man aber nicht. Du irrst. Wenn man für Dokuwiki Plugins schreiben will, hat man kaum eine andere Wahl... Uhu Uhuhu schrieb: > Wenn man für Dokuwiki Plugins schreiben will, hat man kaum > eine andere Wahl... Ja nun, auch zu Dokuwiki gibt es Alternativen. Wenn es beruflich ist und vom Arbeitgeber so vorgegeben dass PHP benutzt werden muss, nun gut. Dann macht man es halt. Mark Brandis schrieb: > Ja nun, auch zu Dokuwiki gibt es Alternativen. Wenn man jeden Morgen aufs neue vor dem Nichts steht, mag das stimmen... :
Bearbeitet durch User
Uhu Uhuhu schrieb: > Läubi .. schrieb: >> Doch, im Prinzip schon. Es ist das Zeichen, welches den PHP von dem >> "HTML-Mode" in der "Interpreter-Mode" schaltet, ebenso wie ein Compiler >> vom "Parser-Mode" in den "Kommentar-Mode" schaltet. > > Daß es das tut, ist offensichtlich. Daß das Ganze ein kapitaler > Design-Fehler ist, aber auch... In dem Moment, wo PHP die HTML-Datei nach den Tags <? und ?> durchsucht, wird noch kein PHP geparst, ganz einfach. gaast schrieb: > In dem Moment, wo PHP die HTML-Datei nach den Tags <? und ?> durchsucht, > wird noch kein PHP geparst, ganz einfach. Du must nich versuchen, den Mist zu entschuldigen. Der ist unentschuldbar... Hatte ich auch nicht. Von dir verlangt ja auch keiner, dass du dich dafür entschuldigst, dass du nicht begreifst dass der Parser in dem Moment, in dem er HTML durchsucht, noch gar kein PHP parst, weil das wiederum andere Seiteneffekte haben könnte. gaast schrieb: > weil das wiederum andere Seiteneffekte haben könnte. Tja, das hätte man sich als allererstes überlegen müssen, als PHP konzipiert wurde... Da aber nichts konzipiert wurde, sondern einfauch drauflos gefrickelt, konnte halt nicht viel Gescheites dabei rauskommen. Daß der Frickler von Compilerbau nicht den Schimmer von einer Ahnung hatte, ist Voraussetzung. gaast schrieb: > Hatte ich auch nicht. Von dir verlangt ja auch keiner, dass du dich > dafür entschuldigst, dass du nicht begreifst dass der Parser in dem > Moment, in dem er HTML durchsucht, noch gar kein PHP parst, weil das > wiederum andere Seiteneffekte haben könnte. Mag ja sein. Allerdings ist die Bezeichnung 'Parser' etwas sehr hoch gegriffen, wenn er in
ein in einem String stehendes ?> als sein Ende Zeichen erkennt, das zu allem Überfluss auch noch auskommentiert ist. 'Parser' würde ich sowas nun wirklich nicht nennen wollen. Murx schon eher. :
Bearbeitet durch User
Nun fang du auch noch an! :-P Der PHP "Parser" kommt doch zu dem Zeitpunkt noch überhaupt nicht ins Spiel! Es gibt da auch noch keine Kommentare... Das ganze wird vermutlich einfach als Stream gelesen und wenn das "php-anfang" Zeichen kommt dem Parser gereicht und beim "phph-ende" Zeichen beendet... Fertig. Das ist nurn wirklich ein dermaßen seltener Spezialfall, das die meisten PHP Entwickler nie in ihrem Leben nur in die Verlegenheit kommen das wissen zu müssen. Und selbst wenn werden diese dann wohl einfach den Workaround dafür nutzen anstatt da nun tagelang drüber zu lamentieren und sich aufzuspielen man selber hätte das ja alles viel besser gemacht. Nachtrag: Um mal zu seigen was man alles "böses" mit PHP machen kann: http://www.onlamp.com/pub/a/php/2001/05/03/php_foundations.html besonders der letzte teil mit den gesplitteten if/for Bedingungen innerhalb eines HTML Dokumentes! Praktisch kann das alles sein, XML, Text, CSS, theoretisch würde vermutlich sogar eingeschränkt Binärdaten funktionieren. Man muss sich einfach mal davon verabschieden, das PHP "nur" PHP Skript zu Gesicht bekommt. :
Bearbeitet durch User
Läubi .. schrieb: > Nun fang du auch noch an! :-P :-) Ich wusste von all dem nichts. Aber als ich die weiter oben verlinkten 'Warum PHP Murks ist' Seiten angefangen habe zu lesen, da sind mir ehrlich die Grausbirnen aufgestiegen. Den letzten Rest gaben mir dann noch einige Zitat, die ich vom Erfinder von PHP gelesen habe. Der könnte sich nahtlos in so manche Arduino Fraktion hier einreihen (Tschuldigung, das soll kein neues Arduino-Bashing werden) > Der PHP "Parser" kommt doch zu dem Zeitpunkt noch überhaupt nicht ins > Spiel! Es gibt da auch noch keine Kommentare... Das ganze wird > vermutlich einfach als Stream gelesen und wenn das "php-anfang" Zeichen > kommt dem Parser gereicht und beim "phph-ende" Zeichen beendet... > Fertig. So wirds wahrscheinlich sein. Aber selbst der C-Präprozessor, der nun wirklich nicht so wahnsinnig viel von C versteht, ist immerhin soweit, dass er aus Strings die Nase raushält. Auf jeden Fall hab ich jetzt gute Argumente, wenn ich in die nächste "PHP ist super, C ist Scheisse" Konfrontation gehe. :-) Karl Heinz schrieb: > "PHP ist super, C ist Scheisse" Was soll das den sein? Jedes Werkzeug für seinen Zweck. PHP und C haben nun doch ganz andere Einsatzgebiete... Läubi .. schrieb: > Jedes Werkzeug für seinen Zweck. Ja, PHP zur Produktion von Schwachstellen im Internet, damit Mafia und ihr legal-schattiger Arm immer genug Gelegenheiten finden, "ihren Job zu machen"... Naja, also "dos and donts" gibt es in jeder Programmiersprache. Auch in C kann ich z.B. mit goto rumfuhrwerken, wobei man auch in jedem Programmierlehrbuch liest, das man dies tunlichst lassen soll. Und hier mit Beispielen von 2001 anzukommen ist da auch nicht wirklich fair. Heute würde sowas niemand mehr machen, da man versucht Code und HTML zu trennen indem man Template Systeme verwendet. Jedem Neuling hier wird in den Arsch geblasen er solle doch gefälligst ein C Buch lesen. Das gleiche könnte man für PHP ja auch empfehlen. Sicher gibts bei PHP viel Murks, was ich auch überhaupt nicht schönreden will, aber das sich hier nun jeder als PHP Crack empfindet nur weil er zwei Links zu PHP überflogen hat, finde ich schon etwas sehr überheblich. Der grosse Vorteil der geringen Einstiegshürde von PHP ist gleichzeitig auch der grösste Nachteil, da jeder 08/15 Mist zusammenhacken und online stellen kann. Mit C Pufferüberläufe, Crashs und sonstigen Scheiss zu produzieren ist auch überhaupt kein Problem, nur bekommt davon der Rest der Welt eben nix mit. So, jetzt kommt die Stunde der PHP-Cracks: Warum schmeißt PHP den Löffel, wenn es diese Zeile siht:
aber nicht, wenn es diese sieht:
http://xref.dokuwiki.org/reference/dokuwiki/nav.html?_functions/addspecialpattern.html "Perl style regex. Must be UTF-8 encoded. ..." Dann kodiere deine SearchPatterns doch mal entsprechend. Steht alles in der Doku ;) Und was bedeutet "gibt den Löffel ab"? Fehlermeldung? Errorlogs? Und gewöhn dich einfach daran, das "?>" ne spezielle Bedeutung hat und verschwende nicht deine Zeit mit irgendwelchen Patterns die nun den "Grenzbereich" ausloten. Genausogut kannst du "?" mit "{0,1}" ersetzen und hast das problem nicht mehr. Aber das wäre wahrscheinlich zu einfach und zu langweilig und man könnte sich nicht über das beschissene PHP aufregen siehe auch: http://stackoverflow.com/questions/15219815/convert-php-closing-tag-into-comment A. B. schrieb: > "Perl style regex. Must be UTF-8 encoded. ..." Sind sie. Zudem ist die Codierung von '<smallcaps.*?>' in ansi und UTF-8 gleich. > Und was bedeutet "gibt den Löffel ab"? PHP beendet einfach die Bearbeitung der Seite, wenn es ?> sieht - egal, ob in einem String, oder gar einem auskommentiertzen String, oder sonstwo. Aber offenbar auch nicht immer. Die stackoverflow-Seite ist lustig - zu jedem Hack den passenden Gegenhack und die Welt ist wieder in Ordnung... Was passiert wenn du
verwendest? Ändert das etwas? "PHP only honours the ?> tag outside a string context. Putting it in a string just works as expected. In other words, you cannot break out of PHP mode from inside a string literal." PHP unterscheidet ja zwischen single und double quoted und nur double quoted sind "richtige" Strings. A. B. schrieb: > Ändert das etwas? Nichts - alles schon ausprobiert. > PHP unterscheidet ja zwischen single und double quoted und nur double > quoted sind "richtige" Strings. Strings in "" werden interpoliert, Strings in '' nicht - wie in der Shell, und bei ruby. Von "richtigen" und "nicht richtigen" Strings würde ich da nicht sprechen. Beide haben ihre Berechtigung und die '' sind sicherlich etwas effizienter zu behandeln, weil sie nicht durchsucht werden müssen. Uhu Uhuhu schrieb: > Ja, PHP zur Produktion von Schwachstellen im Internet, damit Mafia und > ihr legal-schattiger Arm immer genug Gelegenheiten finden, "ihren Job zu > machen"... Uhu das ist doch Quatsch... Ja es gibt unsichere Skripte. Genauso wie es Million und abermillionen unsicher anderer Software gibt, da kann aber die Verwendete Sprache nix für. Und ja es gibt/gab einige besonders Problematische Funktionen und Configparameter, wie es z.B. auch im C Standard problematische Funktionen gibt die heute nicht mehr empfohlen werden zu nutzen. Das es häufiger Exploits für bekannte PHP Skripte gibt, liegt einfach an der Verbreitung und dem Erfolg. Und wie gesagt, niemand hält dich davon ab dir ein "besseres" PHP zu kompilieren, du müsstest dann halt nur die nicht mehr gewährleistete Rückwärtzkompatibilität ggf. in den von dir verwendeten Skripten halt kurz ausgleichen. Für einen derart versierten Entwickler der sich anmaßt die Arbeit und de Erfolg anderer derart herabzuwürdigen sollte das ja kein Problem sein. Läubi .. schrieb: > Für einen derart versierten Entwickler der sich anmaßt die Arbeit und de > Erfolg anderer derart herabzuwürdigen sollte das ja kein Problem sein. Au Mann... Es geht mir nicht darum, irgendwelche "Erfolge" herabzuwürdigen. Es gibt längst Besseres, um PHP zu ersetzen, das schon bei seiner "Entwicklung" Lichtjahre hinter dem Stand der Technik herwatschelte, ohne ihn auch nur zur Kenntnis genommen zu haben. Der Teufel scheißt bekanntlich immer auf den größten Haufen und Naivität und Trägheit läßt es ihm die Leute nachmachen. Aber wer sagt, daß der Kaiser nackt da steht, ist natürlich böse, wie immer... Phyton gabs z.B. schon früher als PHP. Ruby ist zu einem ähnlichen Zeitpunkt wie PHP entwickelt wurden. Wieso haben die sich dann nicht durchgesetzt wenn sie so viel besser sind? Das sind jetzt mal die einzigen beiden Alternativen die mir da fürs Web einfallen auf die schnelle. Java ist mit deutlich mehr Aufwand verbunden. Oder was kommt dir als Alternative in den Sinn? Weil Ruby erst Jahre später außerhalb Japans bekanntgeworden ist. Ruby ist ja bis heute noch extrem japanisch durchsetzt. Ja, die Haupt-Entwickler haben mittlerweile zugesagt, sich um englische Kommunikation zu bemühen. Fred schrieb: > Ruby ist ja bis heute noch extrem japanisch durchsetzt. Ja, die > Haupt-Entwickler haben mittlerweile zugesagt, sich um englische > Kommunikation zu bemühen. Ich habe vor ein paar Jahren ein Projekt mit Rails gemacht. Über Probleme mit Japanischen Texten kann ich mich nicht beklagen; die ganze Dokumentation liegt in Englisch vor. A. B. schrieb: > Oder was kommt dir als Alternative in den Sinn? Python. Rails hat einen zu komplizierten Ansatz mit seinen vielen Automatismen, kann aber auf der anderen Seite die Produktivität bei anspruchsvolleren Projekten gehörig steigern. :
Bearbeitet durch User
Mich schrecken bei Python die fehlenden Klammern ab. Ich finde das hochgradig beschissen, darüber mein Programm strukturieren zu müssen. Wie funktioniert das so im Programmieralltag? Oder ist das im Endeffekt gar kein so grosses Ding, wie es mir erscheint? Ich mag es auch nicht sonderlich, aber es man kann sich durchaus daran gewöhnen. Vorteil von Python ist seine Mächtigkeit und Effizienz. A. B. schrieb: > Mich schrecken bei Python die fehlenden Klammern ab. Ich finde das > hochgradig beschissen, darüber mein Programm strukturieren zu müssen. Du meinst über die Einrückung zu Beginn einer Programmzeile? Ja, das nervt echt kolossal an Python. So toll die Sprache ansonsten auch sein mag, aber das halte ich IMHO für einen Designfehler. Uhu Uhuhu schrieb: >> Ruby ist ja bis heute noch extrem japanisch durchsetzt. Ja, die >> Haupt-Entwickler haben mittlerweile zugesagt, sich um englische >> Kommunikation zu bemühen. > > Ich habe vor ein paar Jahren ein Projekt mit Rails gemacht. Über > Probleme mit Japanischen Texten kann ich mich nicht beklagen; die ganze > Dokumentation liegt in Englisch vor. Davon redet niemand. Die Ruby-Entwicklung fand ausschließlich auf japanischsprachigen MLs statt. Fred schrieb: > Die Ruby-Entwicklung fand ausschließlich auf japanischsprachigen MLs > statt. Und was ist daran jetzt schlecht? Mark Brandis schrieb: > A. B. schrieb: >> Mich schrecken bei Python die fehlenden Klammern ab. Ich finde das >> hochgradig beschissen, darüber mein Programm strukturieren zu müssen. > > Du meinst über die Einrückung zu Beginn einer Programmzeile? Ja, das > nervt echt kolossal an Python. So toll die Sprache ansonsten auch sein > mag, aber das halte ich IMHO für einen Designfehler. Das ist doch blödsinn. Ich weiß ja nicht wie ihr so Programmiert, aber ich rücke meinen Code eh immer ein (C/C++, PHP, .NET oder was auch immer). Also, wo sollte da jetzt das Problem sein? Ob der Code nun zwischen klammern steht und dann eingerückt wird, oder ohne Klammern eingerückt wird... Wer jetzt mit " Ja aber wenn die einrückung nicht stimmt..." kommt... Ja, das ist genau das selbe Problem, als wenn du die Klammer falsch setzt! Das Strukturieren des Codes über die Einrückungen ist meiner Meinung nach das beste überhaupt. Da lernen die Leute ihren Code mal vernünftig einzurücken, und nicht solche "1000 Zeilen Code und das alles ohne Einrückung"-Dateien zu fabrizieren. Andere Sprache -> Andere Syntax ganz einfach. Grüße Kaj schrieb: > Das ist doch blödsinn. Ich weiß ja nicht wie ihr so Programmiert, aber > ich rücke meinen Code eh immer ein (C/C++, PHP, .NET oder was auch > immer). Also, wo sollte da jetzt das Problem sein? Ob der Code nun > zwischen klammern steht und dann eingerückt wird, oder ohne Klammern > eingerückt wird... Natürlich rückt man seinen Code ein. Aber der Grund dafür ist die Lesbarkeit für den Menschen, und eben nicht dass man damit etwas über den Kontrollfluss aussagen will. Da hat der Guido van Rossum etwas missverstanden. ;-) Außerdem gibt es für C, C++, Java, JavaScript, C# und viele andere Sprachen auch Beautifier-Tools, die das Einrücken automatisch richtig machen. Bitte zeig mir so ein Tool für Python. :-) Wie ich gerade sehe, hat man dies von Python 2 auf Python 3 verbessert (man kann nicht mehr Spaces und Tabs mischen), was nichts anderes bedeutet als dass es in Python 2 schrottig war. ;-) http://regebro.wordpress.com/2008/05/30/python-indendation-rocks-and-sucks-a-little-bit/ A. B. schrieb: > Auch in C kann ich z.B. mit goto rumfuhrwerken, wobei man auch in jedem > Programmierlehrbuch liest, das man dies tunlichst lassen soll. Das ist zu kurz gedacht. Ein "guter" Anwendungsfall ist das Abbrechen eines verschachtelten Schleifenkonstruktes mit einem Sprung hinter die äußere Schleife. Man könnte das natürlich auch dadurch dadurch lösen, daß man die Schleifen in eine Funktion verpackt und mit return verläßt, wenn man ein break ganz raus haben will. Ob das aber immer der Übersichtlichkeit dient, möchte ich bezweifeln. Eine nette Lösung für das Problem, mit der sich kein Schindluder wie mit goto treiben läßt, hatte Burroughs in seiner Sprache SDL, in der v.a Betriebssysteme geschrieben wurden:
outerloop ist der (frei wählbare) Name der Schleife, die durch undo
beendet wird und forever heißt, daß es sich um eine Schleife ohne
Endekriterium im Schleifenkonstrukt handelt - entspricht while(true) in
C.
goto gab es nicht und do ... end war ein einfacher Block, wie { } in C.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.
|
|
Thread beobachten
Seitenaufteilung abschalten