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...
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.
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...
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
1
printf("\helloworld\");
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.
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...
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.
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
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.
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:
1
print 01234567;
2
print 012345678;
geben beide dasselbe aus. Ohne Warnung, ohne Fehlermeldung.
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.phpUhu 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.
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...
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.
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.
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...
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...
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...
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.
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.
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.
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.
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...
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.
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?
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.
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. :-)
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:
1
do outerloop forever
2
do forever
3
do forever
4
...
5
undo outerloop
6
...
7
end
8
...
9
end
10
end
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.