Ist PHP eine Programmiersprache?

[Henry]

Hallo,

ich hatte gerade eine Diskussion und muss sagen, bin selber nicht sicher.

Es geht darum, ob PHP eine Programmiersprache ist oder ein Scriptsprache, wo immer man hier auch den Unterschied festlegen will. Ein Kollege meint, solange man nichts kompilieren muss, ist das keine "echte" Programmiersprache. Da er aber nicht unbedingt erfahren ist, frage ich lieber mal euch. Wikipedia, scheint sich nämlich teilweise zu widersprechen, mal Scriptsprache, dann wieder Programmiersprache... Die englische Version, sagt es wäre Beides, na ja... Kann jemand Licht ins Dunkel bringen?

Gruss
Henry

[Auge]

Hallo

Es geht darum, ob PHP eine Programmiersprache ist oder ein Scriptsprache, wo immer man hier auch den Unterschied festlegen will.

Den Unterschied möchte ich auch einmal erklärt haben. Programmieren ist das Festlegen von Befehlsfolgen, die reproduzierbar abgearbeitet werden können. Das kann ich mit kompilierbaren und interpretierbaren Sprachen tun. In beiden Fällen handelt es sich somit um Programmiersprachen.

Ein Kollege meint, solange man nichts kompilieren muss, ist das keine "echte" Programmiersprache.

Ist das einer von der „alten Schule“?

Tschö, Auge

[Gunnar Bittersmann]

@@Auge

Programmieren ist das Festlegen von Befehlsfolgen

Spricht man bei Lisp, Prolog u.ä. von „Befehlen“?

Wenn nein, müste man das anders ausdrücken – und trotzdem Programmiersprachen von anderen Computersprachen wie HTML und CSS trennen.

LLAP 🖖

[Auge]

Hallo

Programmieren ist das Festlegen von Befehlsfolgen

Spricht man bei Lisp, Prolog u.ä. von „Befehlen“?

Keine Ahnung, wie in diesen Sprachen die Bezeichnungen lauten. Aber soweit ich das auf die Schnelle bei den Syntaxbeispielen auf der Wikipedia-Seite zu Lisp sehe, gibt es, wie in anderen Programmiersprachen auch, Anweisungen, die auszuführen sind. Meiner Meinung nach lassen die sich durchaus den Befehlen zurechnen, auch wenn die spracheneigene Konvention einen anderen Begriff verwenden sollte.

Interpretierbare Sprachen nur deshalb nicht zu Programmiersprachen zu zählen, weil sie eben interpretiert und nicht kompiliert werden, ist jedenfalls Humbug.

Tschö, Auge

[Gunnar Bittersmann]

@@Auge

Interpretierbare Sprachen nur deshalb nicht zu Programmiersprachen zu zählen, weil sie eben interpretiert und nicht kompiliert werden, ist jedenfalls Humbug.

Natürlich.

Kennt jemand noch BASIC?

Symbolbild:

(Seb Lee-Delisle beim IxDA Berlin)

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Kennt jemand noch BASIC?

Ich habe mit QBASIC meine ersten Schritte im Bereich programmieren gemacht… hihi. War die einzige Programmiersprache, zu der ich Zugang hatte. In diesem Fall in Form von dem QBASIC-Interpreter, der bei DOS dabei war, und der eingebauten Hilfe in der Entwicklungsumgebung.

LG,
CK

[Gunnar Bittersmann]

@@Christian Kruse

Ich habe mit QBASIC meine ersten Schritte im Bereich programmieren gemacht… hihi. War die einzige Programmiersprache, zu der ich Zugang hatte. In diesem Fall in Form von dem QBASIC-Interpreter, der bei DOS dabei war, und der eingebauten Hilfe in der Entwicklungsumgebung.

Jungspund! Ich hätte bei dir wennschon nicht C64 oder sowas aus der Zeit (ZX Spectrum, Schneider, Atari, …), dann wenigstens Amiga vermutet.

Meine ersten Schritte waren übrigens in BASIC mit Papier und Bleistift. Code, den nie ein Computer zu sehen bekam.

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Jungspund! Ich hätte bei dir wennschon nicht C64 oder sowas aus der Zeit (ZX Spectrum, Schneider, Atari, …), dann wenigstens Amiga vermutet.

Wir hatten nie einen Amiga. Mein Vater war der Meinung, dass die Plattform keine Zukunft hat. Er hat recht behalten 😉 Der erste Computer, auf den ich Zugriff hatte, war der 286er meines Vaters. Mein erster eigener Computer war ein 386er.

Meine ersten Schritte waren übrigens in BASIC mit Papier und Bleistift. Code, den nie ein Computer zu sehen bekam.

Dafür bin ich vermutlich zu jung. Oder kommt das daher, dass du im Osten aufgewachsen bist?

LG,
CK

[Gunnar Bittersmann]

@@Christian Kruse

Meine ersten Schritte waren übrigens in BASIC mit Papier und Bleistift. Code, den nie ein Computer zu sehen bekam.

Dafür bin ich vermutlich zu jung. Oder kommt das daher, dass du im Osten aufgewachsen bist?

Eher letzteres. Oder beides.

LLAP 🖖

[Pit]

Wir hatten nie einen Amiga. Mein Vater war der Meinung, dass die Plattform keine Zukunft hat. Er hat recht behalten 😉 Der erste Computer, auf den ich Zugriff hatte, war der 286er meines Vaters. Mein erster eigener Computer war ein 386er.

Immerhin schon ein AT, ich kannte noch XTs. Und natürlich C20/64/128 (mit Datasette) 😉

Pit

[klawischnigg]

Hi there,

Ich habe mit QBASIC meine ersten Schritte im Bereich programmieren gemacht… hihi. War die einzige Programmiersprache, zu der ich Zugang hatte. In diesem Fall in Form von dem QBASIC-Interpreter, der bei DOS dabei war, und der eingebauten Hilfe in der Entwicklungsumgebung.

<korinthen>

QBASIC war kein Interpreter, das war kompiliertes BASIC. Der am meisten genutzte Interpreter war auf den Nachbauten GWBASIC und auf Maschinen, die ein echtes IBM-ROM hatten, BASIC oder BASICA (letztere war der erweiterte Interpreter, der auch mit "hochaufgelöster" Graphik klarkam)…

</korinthen>

[Christian Kruse]

Hallo klawischnigg,

<korinthen>

QBASIC war kein Interpreter, das war kompiliertes BASIC.

Ich glaube du verwechselst QBASIC und QuickBASIC. QBASIC war ein reiner Interpreter, der keine Kompilate erzeugen konnte, keine Libraries konnte und IIRC auch keine Syscalls. Die abgespeckte Version von QuickBASIC.

LG,
CK

[klawischnigg]

Hi there,

Ich glaube du verwechselst QBASIC und QuickBASIC. QBASIC war ein reiner Interpreter, der keine Kompilate erzeugen konnte, keine Libraries konnte und IIRC auch keine Syscalls. Die abgespeckte Version von QuickBASIC.

Hast recht, das war irgend so eine "nicht fisch nicht fleisch"-Geschichte. Ich hab das verwechstauschelt…

[Auge]

Hallo

Kennt jemand noch BASIC?

Natürlich. Basic war in der Berufsschule meine erste Erfahrung auf dem KC85/2.

Rechner an, Geracord gestartet, 10 Minuten gewartet, bis der Basic-Interpreter von Kassette geladen wurde und schon waren von den 64 KByte RAM nur noch 31 KByte übrig.

Tschö, Auge

[JürgenB]

Hallo Gunnar,

Interpretierbare Sprachen nur deshalb nicht zu Programmiersprachen zu zählen, weil sie eben interpretiert und nicht kompiliert werden, ist jedenfalls Humbug.

Natürlich.

Kennt jemand noch BASIC?

wir hatten damals auf dem Apple II schon einen Basic-Compiler. Das Tennis war nach dem Übersetzen allerdings unspielbar schnell 😀

Gruß
Jürgen

[Gunnar Bittersmann]

@@JürgenB

damals auf dem Apple II … Das Tennis war nach dem Übersetzen allerdings unspielbar schnell 😀

Tennis? Du meinst Pong?

LLAP 🖖

[JürgenB]

Hallo Gunnar,

damals auf dem Apple II … Das Tennis war nach dem Übersetzen allerdings unspielbar schnell 😀

Tennis? Du meinst Pong?

kann sein, dass das so hieß. Es wurde mir den Drehknöpfen (Paddle?) gespielt. Wir haben irgendwann im Quelltext die Stelle mit den Ball- und den Paddle-Koordinaten gefunden und den Compi dann gegen sich selbst spielen lassen.

Gruß
Jürgen

[Gunnar Bittersmann]

@@JürgenB

Du meinst Pong?

kann sein, dass das so hieß. Es wurde mir den Drehknöpfen (Paddle?) gespielt.

In irgendeiner Fernsehsendung auch mit Mikrofonen – gesteuert durch die Läutstarke des Klatschens/Trampelns/Gröhlens einer Mannschaft.

Wir haben irgendwann im Quelltext die Stelle mit den Ball- und den Paddle-Koordinaten gefunden und den Compi dann gegen sich selbst spielen lassen.

Die Koordinate des Torwarts passt sich automatisch der des Balls an? Es werden noch Wetten angenommen, wer das erste Tor schießt. 😉

LLAP 🖖

[JürgenB]

Hallo Gunnar,

Wir haben irgendwann im Quelltext die Stelle mit den Ball- und den Paddle-Koordinaten gefunden und den Compi dann gegen sich selbst spielen lassen.

Die Koordinate des Torwarts passt sich automatisch der des Balls an? Es werden noch Wetten angenommen, wer das erste Tor schießt. 😉

irgendwie ging das immer unentschieden aus, aber nach dem Übersetzten rasend schnell.

Gruß
Jürgen

[Maximilian Dötsch]

Ja ich hab noch so einen alten C64 ,ist noch voll funktionsfähig 😀

[ThomasM]

Hallo *,

Kennt jemand noch BASIC?

Klaro. Zunächst KC-BASIC (Robotron KC 85/x) im ersten Semester, dann auf einem ATARI 800 XL. Von dort her ging es schnell zu (Kyan) Pascal, damit weiter auf Robotron PC 1715 / A 7150. Danach längere Zeit Beschäftigung mit Visual Basic für Windows bis 6.0 (zeitweise auch VBDOS, es gab nur die ziemlich geniale Version 1.0).

Mit dem Netz kamen die Websachen mit JS und PHP und natürlich bis heute XSLT als wichtige Triebkraft für das nun 20 Jahre alte XML.

Grüße,
Thomas

[Robert B.]

Moin,

Programmieren ist das Festlegen von Befehlsfolgen

Spricht man bei Lisp, Prolog u.ä. von „Befehlen“?

Wie wäre es denn, wenn man die Touring-Vollständigkeit als Maßstab anlegt?

Wenn nein, müste man das anders ausdrücken – und trotzdem Programmiersprachen von anderen Computersprachen wie HTML und CSS trennen.

Nun ja, HTML ist eine Auszeichnungssprache 😉

Viele Grüße
Robert

[1unitedpower]

Moin,

Programmieren ist das Festlegen von Befehlsfolgen

Spricht man bei Lisp, Prolog u.ä. von „Befehlen“?

Wie wäre es denn, wenn man die Touring-Vollständigkeit als Maßstab anlegt?

Problematisch, LOOP ist eine nicht-turing-vollständige Programmiersprache. Auf der anderen Seite ist CSS3 in einer sehr verschrobenen Art turing-vollständig. Instinktiv sollte eine rein formale Definition Loop als Programmiersprache klassifizieren, CSS3 aber nicht. Ich glaube, es dürfte schon deshalb unmöglich sein eine rein formale Definition anzugeben, die alle intuitiven Merkmale berücksichtigt, weil den meisten Programmiersprache eine formale Grundlage fehlt.

Wenn nein, müste man das anders ausdrücken – und trotzdem Programmiersprachen von anderen Computersprachen wie HTML und CSS trennen.

Nun ja, HTML ist eine Auszeichnungssprache 😉

Auch Auszeichnungssprache und Programmiersprache schließen sich nicht gegenseitig aus - XSLT ist beides.

[pl]

Hi,

Programmieren ist das Festlegen von Befehlsfolgen

Spricht man bei Lisp, Prolog u.ä. von „Befehlen“?

Ich würde sagen ja. Befehl ist Befehl. In fakt habe ich es noch nie erlebt, daß mein PC gesagt hätte, nein ich mag jetzt noch nicht runterfahren.

MfG

[Gunnar Bittersmann]

@@pl

In fakt habe ich es noch nie erlebt, daß mein PC gesagt hätte, nein ich mag jetzt noch nicht runterfahren.

Für mich und die anderen Mac-Nutzer mal nachgefragt: Was ist das – „runterfahren“?

LLAP 🖖

[pl]

hi,

In fakt habe ich es noch nie erlebt, daß mein PC gesagt hätte, nein ich mag jetzt noch nicht runterfahren.

Für mich und die anderen Mac-Nutzer mal nachgefragt: Was ist das – „runterfahren“?

OOProgrammiertechnisch ausgedrückt ist das ein DESTROY Prozess 😉

[Rolf B]

Hallo pl,

nicht? Mein PC sagt das öfter mal. Er meint dann, da hätte noch irgendwer Ausführungsbedarf. Meistens der „Program Manager“. Find ich entlarvend, offenbar ist Win10 doch ein renoviertes Win3.1

Und wenn der nicht spuckt, dann dieses blöde Tool von meinem Drucker oder Windows Update. Muckenloses Herunterfahren hab ich eigentlich selten.

Ich könnte natürlich auch den Energiesparmodus nehmen. Aber ich glaube, echt Herunterfahren spart mehr.

Rolf

[pl]

Beim Runterfahren muckt wohl jede Kiste. Hauptursache: Daten zurück auf die Platte schreiben.

Für Win3.11 gabs mal PC Tools die haben das sogar vermeldet (sinngem.): Bitte gib Deinem Festplattencontroller ein paar Sekunden Zeit.. also nicht einfach so ausschalten.

OOProgrammierer können sich da in sub DESTROY{} am besten profilieren und so am User rächen 😉

[pl]

Hallo,

[..] Programmieren ist das Festlegen von Befehlsfolgen, die reproduzierbar abgearbeitet werden können.

Befehle sind keine Kann~Bestimmungen, wäre ja noch schöner 😉

6 Uhr aufstehen, 7 Uhr Frühstück, 12 Uhr Mittagessen ist auch ein Programm. Da muss es nur noch jemanden geben der das ausführt und jemandem der die Voraussetzungen dafür bietet damit es ausgeführt werden kann. Das heißt, es muss kommuniziert werden: Skript an die Wand nageln, fertig 😉

MfG

PS: Wer sich nicht an das Programm hält weil er die Skriptsprache nicht versteht, wird exekutiert und später ggf. exhumiert.

[Christian Kruse]

Hallo Henry,

eine Programmiersprache unterscheidet man nicht daran, ob sie kompiliert wird oder nicht. Auch Scriptsprachen sind Programmiersprachen. Eine Programmiersprache ist eine künstliche Sprache, um Algorithmen und Datenstrukturen zu formulieren. Check für PHP:

• ✅ künstliche & formalisierte Sprache
• ✅ man kann Algorithmen formulieren
• ✅ man kann Datenstrukturen formulieren

Qed: PHP ist eine Programmiersprache.

LG,
CK

[Christian Kruse]

Hallo Ingrid,

ob PHP kompiliert wird oder nicht ist übrigens durchaus streitbar. PHP wird in Opcodes übersetzt, die dann in der VM ausgeführt werden. Das ist vergleichbar mit dem Bytecode der JVM. Das ist durchaus ein Compile-Vorgang, nur halt nicht in Machinen-Code.

Und wenn du HHVM verwendest, dann stellt sich die Frage gar nicht mehr: HHVM verwendet JIT. Dort wird PHP dann ganz tatsächlich in Maschinencode übersetzt und nicht mehr auf einer VM interpretiert.

LG,
CK

[JürgenB]

Hallo,

ich unterscheide Programmiersprachen nicht nach „compilieren oder nicht“, sondern nach Scriptsprachen in Textform, z.B. Java, Javascript, PHP, und nach grafischen Programmiersprachen, z.B.LabVIEW.

Gruß
Jürgen

[Willi_derMeister]

Habe mir die Antworten angeschaut und schon direkt eine Gänsehaut von diesem Halbwissen bekommen geradewieder. Selbstverständlich ist PHP eine Skriptsprache. Eine sehr gute wohlgemerkt. Diese Diskussion gab es bereits zu genüge.....und immer mit dem gleichen Resultat. Also ihr Lieben, fragt doch mal Rasmus. Ich denke er weiß, was er programmiert hat ;)

P.S. Unwissenheit, ist kein Segen.

Gruß DerMeister

[Christian Kruse]

Hallo Willi_derMeister,

Selbstverständlich ist PHP eine Skriptsprache.

Das hat keiner abgestritten. Die Unterscheidung ist jedoch nicht „Programmiersprache“ oder „Scriptsprache,“ denn auch eine Scriptsprache ist eine Programmiersprache: die Kriterien für Programmiersprachen sind nicht kompiliert oder interpretiert. Das ist irrelevant.

LG,
CK

[Gunnar Bittersmann]

@@Willi_derMeister

Selbstverständlich ist PHP eine Skriptsprache. Eine sehr gute wohlgemerkt.

Gut an PHP ist die Verfügbarkeit.

Ansonsten fallen mir etliche Dinge ein, warum ich PHP eine sehr schlechte Sprache nennen würde.

LLAP 🖖

[Sentinel]

Selbstverständlich ist PHP eine Skriptsprache. Eine sehr gute wohlgemerkt.

Eine sehr gute? Woran machst du das fest? Ich persönliche finde PHP jetzt nicht schlecht, da überall verfügbar und relativ einfach. Aber das Sprachdesign ist katastrophal. Welcher Professor hat PHP mal einen "schrecklicken PERL-Klon" genannt?

[Henry]

Hallo Sentinel,

Eine sehr gute? Woran machst du das fest? Ich persönliche finde PHP jetzt nicht schlecht, da überall verfügbar und relativ einfach. Aber das Sprachdesign ist katastrophal. Welcher Professor hat PHP mal einen "schrecklicken PERL-Klon" genannt?

Glücklicherweise hat dieser Professor, wer auch immer, sich geirrt. Ich hasse Perl, liebe aber PHP 😉 Klingt nicht nach Klon.

Gruss
Henry

[Sentinel]

Perl ist eine absolut stringente Programmiersprache. Allerdings imho weniger für den Web-Einsatz, als für String-Operationen geeignet (obwohl ich das mittlerweile nur noch in Python mache).

Vom Sprachdesign her hat sich dieser Professor mit Sicherheit nicht geirrt. und klar lieben die Leute PHP, ist ja auch so herrlich einfach (und so herrlich unsicher, wenn man sich so manchen Code anschaut). PHP war und ist in Teilen immer noch die Web-Sprache für Nicht-Programmierer, eng verknüpft mit dem Erlernen von anderen Webtechniken wie HMTL oder CSS. Dass man mit PHP auch wirklich guten, sicheren, sauberen, skalierbaren Code schreiben kann, steht auf einem anderen Blatt.

[Henry]

Hallo Sentinel,

Allerdings imho weniger für den Web-Einsatz, als für String-Operationen geeignet (obwohl ich das mittlerweile nur noch in Python mache).

Wenn man unbedingt alles mit Regex lösen möchte anstatt vorgeferigte Funktionen, dann vielleicht 😉

Aber es wäre müßig hier nun eine Diskussion zu Perl anzufangen, denn das gab es schon und das war 2003, seitdem ging es nicht wirklich aufwärts mit Perl, sondern eher wie die Fachzeitschriften sagen, Perl kann den Rückstand zu PHP, Python, usw. nie mehr aufholen

Gruss
Henry

ps. Ist Sven Rautenberg hier nicht mehr aktiv? Wäre schade.

[Sentinel]

Wenn man unbedingt alles mit Regex lösen möchte anstatt vorgeferigte Funktionen, dann vielleicht

Ich weiß nicht, wovon du sprichst, sorry. Mitnichten muss man in Perl alles mit Regexen lösen. Und ich hatte zehn Jahre das Vergnügen, mich mit Perl im wissenschaftlichen Bereich (Bioinformatik) rumzuschlagen.

Perl sollte man dazu nutzen, wofür es da ist: für die Verarbeitung und Analyse von Strings. Das Einsatzgebiet von PHP ist ein völlig anderes, ebenso das von Python. Deshalb gibt es nichts aufzuholen. Übrigens: Fachzeitschriften sagen viel, wenn der Tag lang ist.

[Gunnar Bittersmann]

@@Sentinel

Perl sollte man dazu nutzen, wofür es da ist: für die Verarbeitung und Analyse von Strings.

Und für pl bricht eine Welt zusammen.

LLAP 🖖

[Sentinel]

Und für pl bricht eine Welt zusammen.

Da musst du mich aber jetzt bitte aufklären, @Gunnar Bittersmann

Wie dem auch sei, die Frage ist, ob PHP eine Programmiersprache ist. Ja, wer stellt denn sowas auch in Frage? Ein Trabbi ist (oder leider war) ja auch ein Auto. Irgendwie. Darf ich als Ossi sagen.

[Sentinel]

ah, Verstehe.

[pl]

Es kommt darauf an die eigentlichen Probleme zu erkennen die meistens weit jenseits von dem Liegen was auf heise, golem & Co verbreitet wird.

MfG

[1unitedpower]

Perl ist eine absolut stringente Programmiersprache.

Ansichtssache. Susanne Schmidt hat die Versäumnisse zum 30. Geburtstag von Perl im Dezember letzten Jahres schön pointiert:

Perl gilt als „Write once, never read again“-Sprache, gefüttert durch jahrelange „Obfuscated ist cool“-Kultur und durch die Propagierung der schlimmsten Seiten von Perl. Schlechter Stil ist weiterhin gängig – als ob jede Vernunft und jede Best Practice mit Perl aus dem Fenster gekippt wird. Das hat die Sprache eigentlich nicht verdient – aber eine Dekade von Versäumnissen der Community hat nichts zur Rufverbesserung beigetragen.

[Sentinel]

"Ansichtssache."

Kann ich nicht nachvollziehen. Nur weil Leute in PERL schlechten Stil pflegen, ist das Sprachdesign nicht stringent? Klar, PERL ist eine Sprache, die zum Hacken einlädt und war sicher nie als Websprache konzipiert. Wie sie ja auch später selbst schreibt:

"Die Verhöhnung als Write-once-Sprache ist natürlich Unsinn. Man kann problemlos sauberes, lesbares Perl schreiben. "

Das möchte ich aber meinen. Und als Sysadmin tut man gut daran, auch PERL zumindest lesen zu können. Wobei das Lesen von Perl schwerer ist, als das schreiben.

[pl]

moin,

Das möchte ich aber meinen. Und als Sysadmin tut man gut daran, auch PERL zumindest lesen zu können. Wobei das Lesen von Perl schwerer ist, als das schreiben.

Nachgefragt:

sub init{
    my $self = shift;
    my $dbh = $self->dbh('webdaten') or die $@;
    my $q   = q(
       SELECT url, count(url) as cnt 
       FROM log group by url 
       order by cnt desc limit 30
    );
    $self->{STASH}{slice} = $dbh->selectall_arrayref($q, { Slice => {}});

    if( $self->param() ){
        my $j = JSON->new;
        return $self->{CONTENT}  = $j->encode($self->{STASH}{slice});
    }
}
################################################
__DATA__
<!-- ~~~~~~~~~ HTML Template ~~~~~~~~~~~~~~~ -->
<table class="grid">
    <thead>
      <tr>
        <th>URL</th>
        <th>Aufrufe</th>
      </tr>
    </thead>
    <tbody>
    %loop_slice%
        <tr>
            <td>%url%</td>
            <td>%cnt%</td>
        </tr>
    %endloop%
    </tbody>
</table>

Der Code liefert eine Datenstruktur die sowohl mit JS verarbeitet als auch direkt in eine HTML Tabelle gerendert werden kann. Und ist sauber vom Layout getrennt. Weitere Spalten sind bei Bedarf im Handumdrehen hinzugefügt.

Was ist daran schwer lesbar?

MfG

[1unitedpower]

Was ist daran schwer lesbar?

Spielzeugprogramme eignen sich nur bedingt, um die Lesbarkeit einer Programmiersprache zu beurteilen. Zum Beispiel, würde ich nich wollen, dass ein Programm im Produktivbetrieb abstürtzt, wenn keine Datenbank-Verbindung aufgebaut werden kann. Noch weniger würde ich wollen, dass der Nutzer der Software eine kryptische Fehlermeldung zu sehen bekommt, die nur für Programmierer gedacht ist. Außerdem müsste man sich überlegen, was man dem Nutzer anzeigt, wenn die Datenbank-Abfrage fehlschlägt, zum Beispiel weil die Tabelle aus Gründen nicht mehr existiert. Was sollte der Nutzer zu sehen bekommen, wenn schlicht noch keine Daten in der Tabelle sind? Was wenn die Tabelle soviele Datensätze enthält, dass es unzumutbar wäre, sie in einer riesigen Tabelle anzuzeigen? Was wenn die Datenbank-Abfrage inakzeptabel lange dauert?

Dein Spielzeugprogramm ignoriert diese Fragestellungen. Das ist ein bißchen so, als versucht mir ein Ingeneur die Herausforderungen bei der Konstrutkion moderner Elektroautos zu erklären, und ich kontere, indem ich ihn mein Skateboard mit dem dummen Spruch "Siehst du. Vier Räder. Ganz einfach." unter diese Nase reibe.

Wenn du deinen eigenen Perl-Code gut lesen kannst, ist das gut für dich, wenn du fremden Perl-Code mühelos entziffern kannst, umso besser. Trotzdem macht das Perl nicht für alles und jeden zu einer gut lesbaren Programmiersprache - Perl ist, ohne da eine Wertung vornehmen zu wollen, eine sehr eigenwillige, polarisierende Sprache. Für meinen Geschmack hat Perl zu viele semantische Regeln und Ausnahmen von eben diesen, um mich darin präzise auszudrücken. Wenn ich auf Perl gucke, sehe ich Buchstabensuppe und kein Transkript menschlicher Gedankenstränge, das macht die Sprache für mich schwierig zu lesen.

[pl]

Was ist daran schwer lesbar?

Spielzeugprogramme eignen sich nur bedingt, um die Lesbarkeit einer Programmiersprache zu beurteilen. Zum Beispiel, würde ich nich wollen, dass ein Programm im Produktivbetrieb abstürtzt, wenn keine Datenbank-Verbindung aufgebaut werden kann.

Es stürzt nicht ab. Die Exception wird aufgefangen. Darum kümmert sich jedoch das darunterliegende Framework.

Noch weniger würde ich wollen, dass der Nutzer der Software eine kryptische Fehlermeldung zu sehen bekommt, die nur für Programmierer gedacht ist.

Nutzer bekommen eine Fehlermeldung die der Exception entspricht und die sie genauso wie sie ausgegeben wird an den Programmierer weitergeben können.

Außerdem müsste man sich überlegen, was man dem Nutzer anzeigt, wenn die Datenbank-Abfrage fehlschlägt, zum Beispiel weil die Tabelle aus Gründen nicht mehr existiert.

Auch das würde ein Execption werfen die vom FW aufgefangen wird und dem Nutzer eine verständliche Fehlermeldung zeigt.

Was sollte der Nutzer zu sehen bekommen, wenn schlicht noch keine Daten in der Tabelle sind?

Eine leere Tabelle was denn sonst.

Was wenn die Tabelle soviele Datensätze enthält, dass es unzumutbar wäre, sie in einer riesigen Tabelle anzuzeigen?

Das regelt die Query: Limit 30 was ja auch dem Ziel der Anwendung entspricht.

Was wenn die Datenbank-Abfrage inakzeptabel lange dauert?

Dann wird mit dem konfigurierten Timeout eine Exception geworfen und das dem Nutzer entsprechend kommuniniziert.

Dein Spielzeugprogramm ignoriert diese Fragestellungen.

Keineswegs. Es mag aussehen wie ein Spielzeug. Kann aber wesentlich mehr und auf jeden Fall all das was Du bemängelt hast.

Das ist ein bißchen so, als versucht mir ein Ingeneur die Herausforderungen bei der Konstrutkion moderner Elektroautos zu erklären, und ich kontere, indem ich ihn mein Skateboard mit dem dummen Spruch "Siehst du. Vier Räder. Ganz einfach." unter diese Nase reibe.

Nun, der gezeigte Code erhebt keinen Anspruch darauf das ganze Framework erklären zu müssen. Das hat der Entwickler im Hinterkopf und das ist mit anderen FW genauso.

Wenn du deinen eigenen Perl-Code gut lesen kannst,

Es ist Sinn und Zweck eines Frameworks, Anwendungen mit gut verständlichen und wenigen Code Zeilen erstellen zu können. Und zwar so, daß man das schon mit ein paar Grundkenntnissen tun und sich dabei auf das Wesentliche konzentrieren kann.

Genau das wollte ich hier mal zeigen, nicht mehr und nicht weniger. Hier der Link zur Anwendung 😉

MfG

[1unitedpower]

Es stürzt nicht ab. Die Exception wird aufgefangen. Darum kümmert sich jedoch das darunterliegende Framework.

Ah, okay. die in Perl wirft also eine Exception, die, wenn sie gefangen wird, nicht zum Programmabsturz führt. Das macht dein Programm für mich aber auch nicht besser verständlich: Wieso wirft die Methode init die Exception und nicht dbh? Kommt mir komisch vor. Und daraus ergeben sich direkt zwei weitere Probleme: Zum einen sehe ich dem Ausschnitt nicht an, ob die Exception von einer niedrigeren Programmschicht abgefangen wird und Perl kann AFAIK auch keine Garantie dafür geben. Im Zweifelsfall, habe ich davon auszugehen, dass das vom Programmierer nicht bedacht wurde, also ein Bug ist. Zum anderen verlierst du wichtige Kontextinformationen, wenn man einen Fehler nicht an Ort und Stelle behandelt, sondern auf einer niedrigeren Schicht. Auf der niedrigeren Schicht kannst du dann nur noch eine allgemeine Fehlerbehandlung abwickeln.

Nutzer bekommen eine Fehlermeldung die der Exception entspricht und die sie genauso wie sie ausgegeben wird an den Programmierer weitergeben können.

Das finde ich aus Usability-Sicht inakzeptabel. Du kannst nicht davon ausgehen, dass deine NutzerInnen wissen, was sie mit einer kryptischen Fehlermeldung anzufangen haben. Selbst wenndu so viel Glück hast sie die Fehlermeldung interpretieren können, wieso glaubst du, sollten sie damit an die ProgrammirerInnen herantreten? Dem oder der NutzerIn sollte eine Fehlermeldung zu sehen bekommen, die er bzw. sie verstehen kann. Die ProgrammiererInnen können auch von einem Monitor-Serivce benachrichtigt werden und sich die Fehlermeldungen aus dem Errorlog holen.

Auch das würde ein Execption werfen die vom FW aufgefangen wird und dem Nutzer eine verständliche Fehlermeldung zeigt.

Wir haben da offenbar unterschiedliche Interpretationen von "verständlich".

Eine leere Tabelle was denn sonst.

Eine leere Tabelle kann zwei Ursachen haben: Es gibt tatsächlich keine Datensätze oder das Programm ist kaputt. Um den AnwenderInnen klar zu machen, dass ersteres der Fall ist, sollte ihnen auch die entsprechende Information mitgeteilt werden.

Was wenn die Tabelle soviele Datensätze enthält, dass es unzumutbar wäre, sie in einer riesigen Tabelle anzuzeigen?

Das regelt die Query: Limit 30 was ja auch dem Ziel der Anwendung entspricht.

Stimmt, das hab ich übersehen. Der Fall kann also hier nicht eintreten.

Was wenn die Datenbank-Abfrage inakzeptabel lange dauert?

Dann wird mit dem konfigurierten Timeout eine Exception geworfen und das dem Nutzer entsprechend kommuniniziert.

Ja, das wäre eine Möglichkeit. Das Problem ist: Dem Code sehe ich nicht an, dass da irgendwas in diese Richtung implementiert ist. Auch hier gilt wieder: Im Zweifelsfall hab ich davon auszugehen, dass das von den ProgrammiererInnen vergessen wurde.

Dein Spielzeugprogramm ignoriert diese Fragestellungen.

Keineswegs. Es mag aussehen wie ein Spielzeug. Kann aber wesentlich mehr und auf jeden Fall all das was Du bemängelt hast.

Selbst wenn es das könnte, wäre der Code für mich immer noch unverständlich, weil die relevanten Informationen dafür nicht aus dem Programmtext ersichtlich sind. Du hast dein Framework selber geschrieben, du weißt was da abgefangen wird und was nicht. Ich lese nur einen Beispielcode und muss mich fragen, was da passiert. Was mir vorenthalten wird, kann ich mir nicht aus dem Ärmel schütteln. Das ist jetzt kein rein Perl-spezfisches Problem, sondern eher ein Problem mit deinem API-Design.

Nun, der gezeigte Code erhebt keinen Anspruch darauf das ganze Framework erklären zu müssen. Das hat der Entwickler im Hinterkopf und das ist mit anderen FW genauso.

Du hast das Framework vielleicht im Hinterkopf, ich nicht. Und ich will auch als Framework-Anwender nicht alle Details im Hinterkopf haben müssen, was, wann, wie, wo angefangen und behandelt wird. Ich will an Ort und Stelle alle relevanten Informationen haben. Irgendwo auf unterster Ebene einen try-catch-Block zu haben, der alle Fehler abfängt und in generischer Weise darauf reagiert, ist für mich kein gangbarer Weg und endet auch in schlechter UX: Man kann dem oder der AnwenderIn vielleicht noch mitteilen "Irgendwas ist schief gelaufen", eine das ist doch sehr unbefriedigend für alle Beteiligten. Wenn man schon mit Exceptions arbeitet, dann ist es eine gute Faustregel, einen Fehler nie weiter als eine Programmschicht weiter oben (im Stacktrace) zu behandeln. Behandeln kann auch heißen, eine Exception abzufangen, und eine neue aussagekräftigere Exception zu werfen.

Wenn du deinen eigenen Perl-Code gut lesen kannst,

Es ist Sinn und Zweck eines Frameworks, Anwendungen mit gut verständlichen und wenigen Code Zeilen erstellen zu können. Und zwar so, daß man das schon mit ein paar Grundkenntnissen tun und sich dabei auf das Wesentliche konzentrieren kann.

Fehlerbehandlung gehört für mich zum Wesentlichen, aber ich weiß, dass wir da auf keinen grünen Zweig kommen.

Genau das wollte ich hier mal zeigen, nicht mehr und nicht weniger.

Mich hast du damit zumindest nicht überzeugen können.

[pl]

Es stürzt nicht ab. Die Exception wird aufgefangen. Darum kümmert sich jedoch das darunterliegende Framework.

Ah, okay. die in Perl wirft also eine Exception, die, wenn sie gefangen wird, nicht zum Programmabsturz führt. Das macht dein Programm für mich aber auch nicht besser verständlich: Wieso wirft die Methode init die Exception und nicht dbh?

Im Prinzip ist das egal. Z.Z. wird die Ex in dbh() bereits gefangen und per $@ nur durchgereicht. Die Meldung in $@ ist auf jeden Fall für den Anwender verständlich und diese Art von Exceptions sind schließlich Nicht auf fehlerhafte Benutzereingaben zurückzuführen sondern auf Fehler im System (keine Verbindung, DNS kaput, timeout, Daten korrupt usw.)

Zum anderen verlierst du wichtige Kontextinformationen, wenn man einen Fehler nicht an Ort und Stelle behandelt, sondern auf einer niedrigeren Schicht. Auf der niedrigeren Schicht kannst du dann nur noch eine allgemeine Fehlerbehandlung abwickeln.

Da bist Du falsch infomiert. Sobald in Perl eine Ex gefallen ist, steht in $@ die Ursache und wenn man das entspechend einrichtet auch ein Backtrace. Man kann also $@ ohne Informationsverlust auch später befragen nämlich dann wenn der Puffer zurück zum Webserver/User geht.

Dem oder der NutzerIn sollte eine Fehlermeldung zu sehen bekommen, die er bzw. sie verstehen kann.

Kriegen sie auch.

Die ProgrammiererInnen können auch von einem Monitor-Serivce benachrichtigt werden und sich die Fehlermeldungen aus dem Errorlog holen.

Das Errorlog meines FW ist leer: Weil alle Exceptions aufgefangen werden.

Eskalationsprozesse Mail, SMS, .. sind konfigurierbar.

Eine leere Tabelle was denn sonst.

Eine leere Tabelle kann zwei Ursachen haben: Es gibt tatsächlich keine Datensätze oder das Programm ist kaputt. Um den AnwenderInnen klar zu machen, dass ersteres der Fall ist, sollte ihnen auch die entsprechende Information mitgeteilt werden.

Die Anwendung zeigt Statistiken. Wenn bis zum Rendern der Tabelle keine Ex gefallen ist, steht da auch was drin.

Ja, das wäre eine Möglichkeit. Das Problem ist: Dem Code sehe ich nicht an, dass da irgendwas in diese Richtung implementiert ist. Auch hier gilt wieder: Im Zweifelsfall hab ich davon auszugehen, dass das von den ProgrammiererInnen vergessen wurde.

Ich habe das bei meinem ersten Post nicht erwähnt daß sich das FW um die Fehlermeldung kümmert. Weil es gar nicht darum ging sondern um die Frage ob Perlcode schwer lesbar ist. Hier die Zusammenfassung unseres heutigen Meetings

Es ist Sinn und Zweck eines Frameworks, Anwendungen mit gut verständlichen und wenigen Code Zeilen erstellen zu können. Und zwar so, daß man das schon mit ein paar Grundkenntnissen tun und sich dabei auf das Wesentliche konzentrieren kann.

Genau das ist die Kernaussage.

Und Übrigens: Diese Anwendung wickelt fehlerhafte Eingaben über Exceptions ab. Du kannst Dir den ganzen Code anschauen, hier ein Auszug

my $d = Scaliger->new( julidate => $julidate ) or 
  return $self->errorP( title => "Eingabefehler", descr => "$@");    

Ein Backtrace wir da nicht ausgegeben aber das kannst Du ja auch selber testen.

MfG

[1unitedpower]

Es stürzt nicht ab. Die Exception wird aufgefangen. Darum kümmert sich jedoch das darunterliegende Framework.

Ah, okay. die in Perl wirft also eine Exception, die, wenn sie gefangen wird, nicht zum Programmabsturz führt. Das macht dein Programm für mich aber auch nicht besser verständlich: Wieso wirft die Methode init die Exception und nicht dbh?

Im Prinzip ist das egal. Z.Z. wird die Ex in dbh() bereits gefangen und per $@ nur durchgereicht.

Sieht für mich nach Cargo-Kult-Prgrammierung aus. Wieso eine Exception fangen und nicht behandeln, nur um dann bei jedem Aufruf daran denken zu müssen, eine neue Exception zu schmeißen, damit sie letztendlich von irgendeinem try-catch-Block in deinem Framework gefangen wird und dort nicht behandlet wird?

Die Meldung in $@ ist auf jeden Fall für den Anwender verständlich und diese Art von Exceptions sind schließlich Nicht auf fehlerhafte Benutzereingaben zurückzuführen sondern auf Fehler im System (keine Verbindung, DNS kaput, timeout, Daten korrupt usw.)

Eben, was kümmern die Nutzer die technischen Details?

Zum anderen verlierst du wichtige Kontextinformationen, wenn man einen Fehler nicht an Ort und Stelle behandelt, sondern auf einer niedrigeren Schicht. Auf der niedrigeren Schicht kannst du dann nur noch eine allgemeine Fehlerbehandlung abwickeln.

Da bist Du falsch infomiert. Sobald in Perl eine Ex gefallen ist, steht in $@ die Ursache und wenn man das entspechend einrichtet auch ein Backtrace.

Der Stacktrace ist eine Momentaufnahme, die nur die Rücksprung-Adressen des Aufruf-Stapels uns einige Meta-Informationen, wie Dateiname, Zeilen- und Spaltennummer enthält. Die Inhalte der Variablen werden aber aus Kapazitätsgründen nicht im Stacktrace gespeichert. Im Stacktrace stehen also nur noch Informationen über den Kontrollfluss, die Zustände des Speichers stehen da nicht drin. Der Stacktrace ist ein Debuggin-Werkzeug: Der Programmierer sieht wo der Fehler aufgetreten ist, aber nicht weshalb ein Fehler aufgetreten ist. Das ist bei der Fehlersuche insofern hilfreich, als das der Programmierer nun weiß, an welcher Stelle er einen Breakpoint setzen muss. Es ist aber in der Regel nicht ausreichend, um zur Laufzeit eine aussagekräfitge Fehlerbehandlung durchzuführen, die sich an den Nutzer richtet: Dafür ist nämich das Warum wichtig und das hängt maßgeblich von den Inhalten der Variablen ab. Deshalb ja die Faustregel: Exceptions immer an Ort und Stelle behandeln, und nicht erst irgendwann später, wo die relevanten Informationen nicht mehr zur Verfügung stehen.

Dem oder der NutzerIn sollte eine Fehlermeldung zu sehen bekommen, die er bzw. sie verstehen kann.

Kriegen sie auch.

Findest du.

Die ProgrammiererInnen können auch von einem Monitor-Serivce benachrichtigt werden und sich die Fehlermeldungen aus dem Errorlog holen.

Das Errorlog meines FW ist leer: Weil alle Exceptions aufgefangen werden.

Aus dem Auge aus dem Sinn. Exceptions abfangen ist einfach, dazu reicht ein try-catch-Block. Exception-Handling ist aber was anderes.

Eine leere Tabelle was denn sonst.

Eine leere Tabelle kann zwei Ursachen haben: Es gibt tatsächlich keine Datensätze oder das Programm ist kaputt. Um den AnwenderInnen klar zu machen, dass ersteres der Fall ist, sollte ihnen auch die entsprechende Information mitgeteilt werden.

Die Anwendung zeigt Statistiken. Wenn bis zum Rendern der Tabelle keine Ex gefallen ist, steht da auch was drin.

Vogelstrauß-Prinzip.

Ich habe das bei meinem ersten Post nicht erwähnt daß sich das FW um die Fehlermeldung kümmert. Weil es gar nicht darum ging sondern um die Frage ob Perlcode schwer lesbar ist.

Ich bin nach wie vor der Meinung, dass dein Programm wesentliche Aspekte robuster Software-Entwicklung einfach vermissen lässt und deshalb ungeeignet ist, um die Lesbarkeit von Perl zu demonstrieren. Die ständigen Hinweise darauf, dass da unter der Haube irgendwas vielleicht passiert, dass ich dem Code aber nicht entnehmen kann, bekräftigt mich eher in meiner Einschätzung, dass ich den Code überhaupt nicht verstehen kann, ohne die Details deines Frameworks zu kennen.

Und Übrigens: Diese Anwendung wickelt fehlerhafte Eingaben über Exceptions ab. Du kannst Dir den ganzen Code anschauen, hier ein Auszug

my $d = Scaliger->new( julidate => $julidate ) or 
  return $self->errorP( title => "Eingabefehler", descr => "$@");    

Ein Backtrace wir da nicht ausgegeben aber das kannst Du ja auch selber testen.

Eherlich gesagt, bestätigt das so ein wenig meinen Eindruck, dass Usability dir nicht besonders am Herzen liegt. Wenn ich 12/31/2017 eintippe kriege ich eine nichts-sagende Fehlermeldung "Format Datum nach Julianischen Kalender ungültig", das kann ich wohl darauf zurückführen, dass du du <input type="text"> benutzt, wo ein ein <input type="date">" hätte stehen müssen. Ganz davon abgesehen, dass da kein keine <label>`-Elemente am Formular zu finden sind. Du denkst halt, das ist ein Bedienfehler, ich denke das ist ein Bug in deiner Software.

[pl]

Moin,

Die ProgrammiererInnen können auch von einem Monitor-Serivce benachrichtigt werden und sich die Fehlermeldungen aus dem Errorlog holen.

Das Errorlog meines FW ist leer: Weil alle Exceptions aufgefangen werden.

Aus dem Auge aus dem Sinn. Exceptions abfangen ist einfach, dazu reicht ein try-catch-Block. Exception-Handling ist aber was anderes.

Du hast Perl's Exception Modell nicht verstanden. Also informiere Dich bitte.

Im Übrigen: Das error_log ist definitiv kein Entwicklerwerkzeug

Darüber hinaus kann man auch mit Perl sämtliche Warnungen in den Status einer Exception erheben, was dazu führt, daß Anwendungen auch im Produktivbetrieb sauber laufen weil Fehler gleich beim Entwickeln also frühzeitig bemerkt werden. Das macht ein ErrorLog im Grunde genommen überflüssig.

Exceptions zur Fehlerbehandlung von Benutzereingaben: Ja, man kann. Nämlich bereits beim Entwicklen von Modulen in denen Benutzereingaben zu verarbeiten sind. Mein Scaliger Modul ist ein schönes Beispiel hierzu, nämlich daß die Fehlerbehandlung bereits da beginnt wo noch gar nicht feststeht wie das User~Interface beschaffen ist.

MfG

[Mitleser]

Im Übrigen: Das error_log ist definitiv kein Entwicklerwerkzeug

Ich werde einen Teufel tun, hier in die konkrete Diskussion einzusteigen, aber ich habe mir Deinen Link gerade mal gegeben... Du scheinst den Sinn und Zweck des error.log nicht verstanden zu haben.

Letzter Satz aus obigem Link: "Am Ende bleibt das error_log eine leere Datei...und ist sowohl für Programmierer als auch für den Technischen Leiter (CTO) uninteressant."

Das error.log sollte immer unter Beobachtung sein. Da können wichtige Sachen drin stehen, die mit der jeweiligen Applikation nicht einmal was zu tun haben müssen.

[beatovich]

hallo

Das error.log sollte immer unter Beobachtung sein. Da können wichtige Sachen drin stehen, die mit der jeweiligen Applikation nicht einmal was zu tun haben müssen.

Das wäre dann ein error.log configuration error.

[Mitleser]

Das error.log sollte immer unter Beobachtung sein. Da können wichtige Sachen drin stehen, die mit der jeweiligen Applikation nicht einmal was zu tun haben müssen.

Das wäre dann ein error.log configuration error.

Bahnhof? Erklär mal, bitte ;-)

[beatovich]

hallo

Das error.log sollte immer unter Beobachtung sein. Da können wichtige Sachen drin stehen, die mit der jeweiligen Applikation nicht einmal was zu tun haben müssen.

Das wäre dann ein error.log configuration error.

Bahnhof? Erklär mal, bitte ;-)

Entweder Fehler stehen in einer Ursachenbeziehung zu einem Prozess, oder es liegt ein Konfigurationsfehler vor. Im Übrigen ist es aber tatsächlich besser server.error.logs von script error.logs zu trennen. Allein schon der Lesbarkeit halber.

[pl]

Perl ist eine absolut stringente Programmiersprache. Allerdings imho weniger für den Web-Einsatz, als für String-Operationen geeignet (obwohl ich das mittlerweile nur noch in Python mache).

So ein Quatsch. Ich habe ein ganzes Web~Framework in Perl entwickelt was man auf diegleiche Art und Weise bzw, mit demselben OO Aufbau auch in PHP umsetzen kann.

MfG

[Sentinel]

So ein Quatsch. Ich habe ein ganzes Web~Framework in Perl entwickelt was man auf diegleiche Art und Weise bzw, mit demselben OO Aufbau auch in PHP umsetzen kann.

Man kann jede Sprache für Webdingsbums missbrauchen, auch C. Mag ja sein, dass man mit PERL so tolle Webframeworks hinbekommt, wie mit PHP. Aber... sind PHP-Frameworks denn so gut, dass man damit vergleichen sollte?

[beatovich]

hallo

So ein Quatsch. Ich habe ein ganzes Web~Framework in Perl entwickelt was man auf diegleiche Art und Weise bzw, mit demselben OO Aufbau auch in PHP umsetzen kann.

Man kann jede Sprache für Webdingsbums missbrauchen, auch C. Mag ja sein, dass man mit PERL so tolle Webframeworks hinbekommt, wie mit PHP. Aber... sind PHP-Frameworks denn so gut, dass man damit vergleichen sollte?

cgi.pm ist der Sargdeckel. Und die Perlentwickler haben an diesem Epitaph nichts geändert. Das ist auch ein Statement.

[pl]

hallo

So ein Quatsch. Ich habe ein ganzes Web~Framework in Perl entwickelt was man auf diegleiche Art und Weise bzw, mit demselben OO Aufbau auch in PHP umsetzen kann.

Man kann jede Sprache für Webdingsbums missbrauchen, auch C. Mag ja sein, dass man mit PERL so tolle Webframeworks hinbekommt, wie mit PHP. Aber... sind PHP-Frameworks denn so gut, dass man damit vergleichen sollte?

cgi.pm ist der Sargdeckel.

Das Modul wurde zu einem Solchen gemacht. Siehe auch hierzu rostis Beiträge

Und die Perlentwickler haben an diesem Epitaph nichts geändert.

Lüge! Gründs für Eigenentwicklungen gab es schon immer. Ich habe mich schon relativ frühzeitig von CGI.pm getrennt weil das einfach nicht mehr zeitgemäß war. D.h., in CGI.pm ist eine Logik verbaut die Weiterentwicklungen verhindert.

Die eigentlichen Unzulänglichkeiten liegen in den Legacy Enctypes application/x-www-form-urlencoded und multipart/form-data begründet. Für mich der Hauptgrund, einen eigenen Parser zu entwickeln der auf einem erweiterbaren Schichtenmodell aufsetzt.

Ansonsten haben hierzu nicht die Perlentwickler die Zeit verpennt sondern die Kollegen von IEEE, W3Org und IETF!

MfG

PS: Man kann auch mit den vorhandenen Enctypes so programmieren, daß keine Sicherheitslücken entstehen. Z.B. indem man Schlüsselparameter sauber trennt von Parametern die der Datenübertragung dienen. Genau das konnte man auch schon mit CGI.pm tun indem man davon ausgeht daß param() auch eine Liste liefern kann und wenn man das nicht haben will, mit scalar den scalaren Kontext erzwingt.

Entweder haben das die Kollegen von CCC nicht gewußt oder mit fragwürdigen Absichten falsch in Szene gesetzt. Die Behauptung daß CGI.pm in dieser Hinsicht ein Sicherheitsproblem darstellt ist unsinnig!

[pl]

Selbstverständlich ist PHP eine Skriptsprache. Eine sehr gute wohlgemerkt.

Eine sehr gute? Woran machst du das fest? Ich persönliche finde PHP jetzt nicht schlecht, da überall verfügbar und relativ einfach. Aber das Sprachdesign ist katastrophal. Welcher Professor hat PHP mal einen "schrecklicken PERL-Klon" genannt?

Eher ein Praktiker. Siehe auch hier.

Ich zitiere mich mal sebst:

Und überhaupt ist Perl im MjRel. 5 dermaßen weit entwickelt, da könnten sich sämtliche anderen Programmiersprachen eine dicke Scheibe abschneiden. In Sachen Unicode-Unterstützung liegt PHP gegenüber Perl in der Steinzeit!

Code in HTML einzubetten, das hat man in Perl auch versucht und: Es hat sich als untauglich erwiesen beim Entwicklen moderner Anwendungen. PHP hingegen ist auf diesem Niveau stehengeblieben!

Perl hat rund 100 Built-in-Funktionen, PHP vielleicht 1000? Ein Konzept was Perl unglaublich flexibel macht, PHP jedoch nicht. Perl erlaubt das Einbetten von Code anderer Programmiersprachen wie z.B. c, das macht Perl einzigartig. Perl kann damit erweitert werden ohne daß ein neues Release eingespielt werden muss. Was PHP sich in dieser Hinsicht leistet ist im Grunde genommen eine Katastrophe, am laufenden Meter werden da Funktionen als deprecated getaggt -- ein unhaltbarer Zustand, den es in Perl so nicht gibt.

Insgesamt steht die Entwicklung von PHP auf dermaßen wackeligen Beinen, dass stand sie schon immer und ausgerechnet diese Programmiersprache wurde als diejenige auserwählt mit der man die Zukunft meistern soll!? Das ist mehr als lächerlich!!!

Perls Zukunft hingegen hat mit Version 5 begonnen, das war 1998//99 und seit dieser Zeit unterstützt Perl OOP.

.

[klawischnigg]

Hi there,

Ein Kollege meint, solange man nichts kompilieren muss, ist das keine "echte" Programmiersprache.

Kollegen gibts auch bei der Müllabfuhr...(scnr;)

Zusätzlich zu dem von den Anderen bereits richtig Gesagtem - wenn das wirklich ein Kriterium für "echte" Programmiersprachen wäre (äh - was sind "echte" Programmiersprachen?), dann wäre PHP nach dieser "Logik" eine echte Programmiersprache, weil es Compiler für PHP gibt.

Zudem ist der Unterschied Skriptsprache - Programmiersprache unter anderem für den, der ein Programm (oder Skript) schreibt, ziemlich bedeutungslos. Der entsteht vor allem durch die Umgebung, in der das Programm oder Skript läuft. Auf keinen Fall aber kann diese (ohnehin eher sinnlose) Einteilung irgendeine Art von Wertung darstellen…

[beatovich]

hallo

Kollegen gibts auch bei der Müllabfuhr...(scnr;)

Code-Recycler, wird das mal ne Branche?

[Robert B.]

Moin @beatovich,

Kollegen gibts auch bei der Müllabfuhr...(scnr;)

Code-Recycler, wird das mal ne Branche?

+1 und eingereicht als Zitat :D

Viele Grüße
Robert

[klawischnigg]

Hi there,

Kollegen gibts auch bei der Müllabfuhr...(scnr;)

Code-Recycler, wird das mal ne Branche?

Nein, das ist die Branche…

[Gunnar Bittersmann]

@@klawischnigg

Code-Recycler, wird das mal ne Branche?

Nein, das ist die Branche…

*g* und *seufz*

Gibt es heutzutage eigentlich noch Entwickler oder gibt es nur noch solche, die sich von Stackoverflow die zweitbeste Lösung holen?

LLAP 🖖

[Rolf B]

Hallo Gunnar,

Erfahrene Entwickler recyclen ihren eigenen Code.
Unerfahrene Entwickler recyclen den Code anderer, z.B. von Stackoverflow oder SelfHTML 😂

Schlaue Entwickler lernen aus fremdem Code.
Dumme Entwickler recyclen Code, ohne darüber nachzudenken. Und wenn das nicht funktioniert, beschimpfen sie gerne noch den Poster.

Achsen im Entwickler-Qualitätsraum-Koordinatensystem gibt's viele. Und nicht alle sind orthogonal.

Welches Label Entwickler bekommen sollten, die ihren Code bei SO oder SH posten? Hm.

Rolf

[Willi_derMeister]

Kollegen gibts auch bei der Müllabfuhr...(scnr;)

die sorgsam den Müll beseitigen, den andere verzapfen. Also nichts gegen Müllmänner!

Zudem ist der Unterschied Skriptsprache - Programmiersprache unter anderem für den, der ein Programm (oder Skript) schreibt, ziemlich bedeutungslos. Der entsteht vor allem durch die Umgebung, in der das Programm oder Skript läuft. Auf keinen Fall aber kann diese (ohnehin eher sinnlose) Einteilung irgendeine Art von Wertung darstellen…

Das war auch nicht die Frage. Aber wieso schreibt nicht jemand den Entwickler von PHP nach dessen Meinung was genau PHP ist. Dann gebe es doch die Antwort. Ganz einfach. Alles andere ist hier, doch bedeutungslos.

[Auge]

Hallo

Zudem ist der Unterschied Skriptsprache - Programmiersprache unter anderem für den, der ein Programm (oder Skript) schreibt, ziemlich bedeutungslos. Der entsteht vor allem durch die Umgebung, in der das Programm oder Skript läuft. Auf keinen Fall aber kann diese (ohnehin eher sinnlose) Einteilung irgendeine Art von Wertung darstellen…

Das war auch nicht die Frage.

Doch, genau das war die Frage. Sie lautete „Ist PHP eine Programmiersprache?“ mit der zusätzlichen Erklärung, dass es da jemanden gäbe, der nur kompilierte Sprachen als Programmiersprachen anerkennt.

Zitat aus dem Eröffnungsposting:

Ein Kollege meint, solange man nichts kompilieren muss, ist das keine "echte" Programmiersprache.

Tschö, Auge

[Rolf B]

Hallo Auge,

...dass es da jemanden gäbe, der nur kompilierte Sprachen als Programmiersprachen anerkennt.

Mein Intel Core Prozessor führt keine „Maschinenbefehle“ aus. Er interpretiert die Instruktionen per Microcode-Firmware. Und mehr noch, er sortiert sie um, spiegelt ihnen ein Registermodell vor, dass mit seiner internen Hardware GAR nichts zu tun hat, lässt ein paar Befehle probehalber laufen und schmeißt das Ergebnis weg (und manchmal geistert es dann herum). Mein guter alter 6502 aus dem Atari 800 würde sich im Sockel herumdrehen. Vor allem wenn er merkt, dass er von dem Intel-Monster soeben schneller emuliert wird als er jemals in Silizium gelaufen ist.

Ist C++ jetzt keine Programmiersprache mehr?

Rolf

[Auge]

Hallo

Mein Intel Core Prozessor führt keine „Maschinenbefehle“ aus. Er interpretiert die Instruktionen per Microcode-Firmware. Und mehr noch, er sortiert sie um, spiegelt ihnen ein Registermodell vor, dass mit seiner internen Hardware GAR nichts zu tun hat, lässt ein paar Befehle probehalber laufen und schmeißt das Ergebnis weg (und manchmal geistert es dann herum). Mein guter alter 6502 aus dem Atari 800 würde sich im Sockel herumdrehen. Vor allem wenn er merkt, dass er von dem Intel-Monster soeben schneller emuliert wird als er jemals in Silizium gelaufen ist.

Ist C++ jetzt keine Programmiersprache mehr?

Nie und nimmer nicht! 😉

Tschö, Auge

[Christian Kruse]

Hallo Rolf,

Mein Intel Core Prozessor führt keine „Maschinenbefehle“ aus. Er interpretiert die Instruktionen per Microcode-Firmware. Und mehr noch, er sortiert sie um, spiegelt ihnen ein Registermodell vor, dass mit seiner internen Hardware GAR nichts zu tun hat, lässt ein paar Befehle probehalber laufen und schmeißt das Ergebnis weg (und manchmal geistert es dann herum).

Noch schlimmer: er formt die CISC-Befehle um in einen internen RISC-Befehlssatz, sozusagen eine Art compiling. 🤯😆

LG,
CK

[Rolf B]

Hallo Christian,

ja, das meinte ich. Er implementiert das CISC Gedöne als RISC. Dass die NetBurst-Öfchen das RISC-Instructionset für eine CISC-Instruktion cachen konnten, hatte ich nicht im Sinn.

Aber ist das ein Compile-Vorgang, in dem Sinne, dass das für ein gegebenes x86/x64 Programm EINMAL gemacht und dann gespeichert wird? Der Cache spart Zeit, aber letztlich macht es der Tausendfüßler mit jedem Befehl auf's Neue.

Rolf

[Christian Kruse]

Hallo Rolf,

Aber ist das ein Compile-Vorgang, in dem Sinne, dass das für ein gegebenes x86/x64 Programm EINMAL gemacht und dann gespeichert wird? Der Cache spart Zeit, aber letztlich macht es der Tausendfüßler mit jedem Befehl auf's Neue.

Ja, nein, das passiert on the fly, da wird jenseits des Caches nichts gespeichert.

LG,
CK

[Gunnar Bittersmann]

@@Willi_derMeister

die sorgsam den Müll beseitigen, den andere verzapfen

Bei Zapf soll nichts beseitigt werden; das Zeug soll ankommen!

LLAP 🖖

[Rolf B]

Hallo Willi_derMeister,

Rasmus braucht keiner mehr zu fragen, der hat sich schon klar geäußert. Die englische Wikipedia zitiert ihn mit:

"I don’t know how to stop it, there was never any intent to write a programming language […] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way."

Das Ding hieß ja zuerst "Forms Interpreter", und heute erinnert es an die Golden Gate Bridge in „Alternate Carbon“...

Rolf

[Sentinel]

Das Ding hieß ja zuerst "Forms Interpreter", und heute erinnert es an die Golden Gate Bridge in „Alternate Carbon“...

Altered Carbon. War irgendwie ganz nett, die Serie zumindest. Das Buch habe ich nicht gelesen.

[Rolf B]

Hallo Sentinel,

verdammt, ich weiß doch, dass "Alternate" falsch ist. Aber den Fehler krieg ich nicht mehr aus dem Kopf. Muss ein Defekt in meinen Stack sein.

Nachdem ich die Serie in 3 Abenden gebinged hatte, habe ich mir direkt das Buch gekauft. Im Buch ist die Brücke unbebaut; die Serie ist ohnehin an einigen Stellen deutlich geändert.

Rolf

[MaxiDoe]

Es ist eine Serversprache aber so genau weiß ich das auch nicht 😀

[Henry]

Hallo,

grrr… schon wieder… Hatte schon einen halben Roman geschrieben und wieder alles weg, ärgerlich. Na ja, schreibs jetzt nochmal, aber weniger detailiert.

Ich habe heute mehrere Leute hier, einige wollen gerade HTML lernen. Also habe ich denen das Wiki gezeigt und da toben sie sich auch gerade aus. Ist schon faszinierend zu sehen, welche Fragen dabei entstehen über die unsereins so gar nicht mehr nachdenkt…

Einiges ist aber auch ärgerlich, Beispiel:

Der Anfänger arbeitet sich durch die Kapitel. Bereits in Kapitel 2 geht es um Überschriften, ist war nicht ausführlich erklärt aber einen Verweis zu den Details. Dort liest der Anfänger und probiert es(mit eigener Datei) aus. Es will aber bei ihm nicht so aussehen wie der "angebliche" Code im Frickl. Also denkt er, er würde was falsch machen. Er wäre vielleicht auch ohne meine Hilfe auf die Ursache gekommen, wenn Frickl nicht nur den Bodybereich als Quelltext(warum eigentlich nicht das ganze DOC?) zeigt oder es hätte gar kein Missverständnis gegeben, wenn der Quelltext hier mit der einleitenden Erklärung zu diesem Beispiel( sollte m.m.n. sowieso immer sein) übereinstimmen würde. Denn letztendlich entstand die Verwirrung durch die(für einen Anfänger unsichtbar bzw. nichtssagenden) CSS Anweisungen, die hier gar nicht zum Thema passen. Na ja, wollte es mal gesagt haben, sitze ja hier in der ersten Reihe, mal sehen was noch lustiges passiert…

Gruss
Henry

[Matthias Apsel]

Hallo Henry,

Danke für deine Rückmeldungen.

Der Anfänger arbeitet sich durch die Kapitel. Bereits in Kapitel 2 geht es um Überschriften, ist war nicht ausführlich erklärt aber einen Verweis zu den Details. Dort liest der Anfänger und probiert es(mit eigener Datei) aus. Es will aber bei ihm nicht so aussehen wie der "angebliche" Code im Frickl. Also denkt er, er würde was falsch machen.

Kannst du hier sagen, was verändert werden sollte?

Er wäre vielleicht auch ohne meine Hilfe auf die Ursache gekommen, wenn Frickl nicht nur den Bodybereich als Quelltext(warum eigentlich nicht das ganze DOC?)

in Anlehnung an die anderen Sandkästen (codepen, dablett, …)

zeigt oder es hätte gar kein Missverständnis gegeben, wenn der Quelltext hier mit der einleitenden Erklärung zu diesem Beispiel( sollte m.m.n. sowieso immer sein) übereinstimmen würde.

Tut es doch?

Denn letztendlich entstand die Verwirrung durch die(für einen Anfänger unsichtbar bzw. nichtssagenden) CSS Anweisungen, die hier gar nicht zum Thema passen.

??

Bis demnächst
Matthias

[Henry]

Hallo Matthias,

Danke für deine Rückmeldungen.

jederzeit, wenn gewünscht.

Kannst du hier sagen, was verändert werden sollte?

Ja, weg mit den CSS-Angaben, solange es nur HTML betrifft. Oder eben dem unbedarften Leser die Info geben, dass dieses Aussehen erst durch das CSS entsteht.

Er wäre vielleicht auch ohne meine Hilfe auf die Ursache gekommen, wenn Frickl nicht nur den Bodybereich als Quelltext(warum eigentlich nicht das ganze DOC?)

in Anlehnung an die anderen Sandkästen (codepen, dablett, …)

Würde schon reichen das komplette DOC inkl. HEAD in einem Editorfeld anzuzeigen, aber klar sowas wie Codepen(obwohl nicht unbedingt, ich hasse es) wäre noch besser, doch das Thema hatten wir hier schon mal, dass dies zur Zeit zu viel Aufwand bedeuten würde. Mein Favorit wäre dann aber eher der tryeditor von w3schools.com. Das Wiki Beispiel dort.

zeigt oder es hätte gar kein Missverständnis gegeben, wenn der Quelltext hier mit der einleitenden Erklärung zu diesem Beispiel( sollte m.m.n. sowieso immer sein) übereinstimmen würde.

Tut es doch?

Eben nicht, der Neuling will was über Überschriften sehen, liest dann was in dem Beispiel und auch im frickl steht und schreibt/kopiert es in seinen Editor. Vorher, in Kapitel 1, hat er was zum Grundgerüst gelesen und umgesetzt, so dass er jetzt nicht erwartet, dass hier auf einmal andere Anweisungen/CSS das Bild verändern könnten. Geht ja auch schließlich um Überschriften, nicht CSS, so weit ist er noch nicht. Also begreift er nicht, warum zb. beim frickl alles eingerückt ist und bei seinem Versuch nicht.

Denn letztendlich entstand die Verwirrung durch die(für einen Anfänger unsichtbar bzw. nichtssagenden) CSS Anweisungen, die hier gar nicht zum Thema passen.

??

Schau mal, das was den Neuling verwirrt hat, war 2.1 Hierarchien. Von CSS kennt er noch nichts, kommt erst in Kapitel 5 (Mal nebenbei, das Tutorial als Ganzes finde ich großartig). Warum also hier CSS einsetzen. Ab 3.1 ist das was anderes.

Kann aber sein, dass ich das unnötig kompliziert erkläre. Falls noch nicht klar, dann beim nächsten Mal mit Screenshots 😉

Gruss
Henry

[Matthias Apsel]

Hallo Henry,

Danke für deine Rückmeldungen.

jederzeit, wenn gewünscht.

Jederzeit.

Kannst du hier sagen, was verändert werden sollte?

Ja, weg mit den CSS-Angaben, solange es nur HTML betrifft. Oder eben dem unbedarften Leser die Info geben, dass dieses Aussehen erst durch das CSS entsteht.

Also reden wir von dem Tutorial und nicht von der Seite "HTML/Textstrukturierung/Überschrift"?

Würde schon reichen das komplette DOC inkl. HEAD in einem Editorfeld anzuzeigen, aber klar sowas wie Codepen(obwohl nicht unbedingt, ich hasse es) wäre noch besser, doch das Thema hatten wir hier schon mal, dass dies zur Zeit zu viel Aufwand bedeuten würde. Mein Favorit wäre dann aber eher der tryeditor von w3schools.com. Das Wiki Beispiel dort.

Wir haben aber Niemanden, der das programmieren könnte.

zeigt oder es hätte gar kein Missverständnis gegeben, wenn der Quelltext hier mit der einleitenden Erklärung zu diesem Beispiel( sollte m.m.n. sowieso immer sein) übereinstimmen würde.

Tut es doch?

Eben nicht, der Neuling will was über Überschriften sehen, liest dann was in dem Beispiel und auch im frickl steht und schreibt/kopiert es in seinen Editor. Vorher, in Kapitel 1, hat er was zum Grundgerüst gelesen und umgesetzt, so dass er jetzt nicht erwartet, dass hier auf einmal andere Anweisungen/CSS das Bild verändern könnten. Geht ja auch schließlich um Überschriften, nicht CSS, so weit ist er noch nicht. Also begreift er nicht, warum zb. beim frickl alles eingerückt ist und bei seinem Versuch nicht.

Also reden wir von dem Tutorial und nicht von der Seite "HTML/Textstrukturierung/Überschrift".

Denn letztendlich entstand die Verwirrung durch die(für einen Anfänger unsichtbar bzw. nichtssagenden) CSS Anweisungen, die hier gar nicht zum Thema passen.

??

Schau mal, das was den Neuling verwirrt hat, war 2.1 Hierarchien. Von CSS kennt er noch nichts, kommt erst in Kapitel 5 (Mal nebenbei, das Tutorial als Ganzes finde ich großartig). Warum also hier CSS einsetzen. Ab 3.1 ist das was anderes.

Also reden wir von dem Tutorial und nicht von der Seite "HTML/Textstrukturierung/Überschrift"!

EDIT: aber da gibt es keine Styleangaben??

Bis demnächst
Matthias

[Henry]

Hallo Matthias,

Ja, weg mit den CSS-Angaben, solange es nur HTML betrifft. Oder eben dem unbedarften Leser die Info geben, dass dieses Aussehen erst durch das CSS entsteht.

Also reden wir von dem Tutorial und nicht von der Seite "HTML/Textstrukturierung/Überschrift"?

Doch, beides. Im Tutorial, liest der Neuling etwas zu Überschriften, die Info reicht ihm nicht, doch es gibt ja im Tutorial den Link zu "HTML/Textstrukturierung/Überschrift", also schaut er sich das an. Und da es hier nur um HTML geht, auch nur den Bereich Hierarchien. Er sieht den Code aus dem Body im Beispiel und klickt es an, natürlich in der Erwartung, dass die Umsetzung bei ihm genauso wäre. Nur, hat er CSS nicht beachtet, wieso auch, schließlich kennt er das noch nicht und geht ja hier nur um HTML.

Würde schon reichen das komplette DOC inkl. HEAD in einem Editorfeld anzuzeigen, aber klar sowas wie Codepen(obwohl nicht unbedingt, ich hasse es) wäre noch besser, doch das Thema hatten wir hier schon mal, dass dies zur Zeit zu viel Aufwand bedeuten würde. Mein Favorit wäre dann aber eher der tryeditor von w3schools.com. Das Wiki Beispiel dort.

Wir haben aber Niemanden, der das programmieren könnte.

Sagte ich ja bereits, was aber immer noch nicht erklärt warum frickle nicht zumindest alles in einem Feld zeigt. (Oder meintest du das mit, da wäre im Moment auch keiner für da das zu ändern?)

Also reden wir von dem Tutorial und nicht von der Seite "HTML/Textstrukturierung/Überschrift".

Beides, wenn das eine nicht in der Form für einen Neuling geeignet ist, müsste es geändert oder eben der Link im Tutorial, der dorthin führt entfernt, um der Verwirrung zu entgehen.

Also reden wir von dem Tutorial und nicht von der Seite "HTML/Textstrukturierung/Überschrift"!

Beides 😉

Gruss
Henry

[Matthias Apsel]

Hallo Henry,

Doch, beides. Im Tutorial, liest der Neuling etwas zu Überschriften, die Info reicht ihm nicht, doch es gibt ja im Tutorial den Link zu "HTML/Textstrukturierung/Überschrift",

gab.

Wir haben aber Niemanden, der das programmieren könnte.

Sagte ich ja bereits, was aber immer noch nicht erklärt warum frickle nicht zumindest alles in einem Feld zeigt. (Oder meintest du das mit, da wäre im Moment auch keiner für da das zu ändern?)

This. Und wir haben uns auch keine Meinung dazu gebildet, ob das wirklich besser ist.

Beides, wenn das eine nicht in der Form für einen Neuling geeignet ist, müsste es geändert oder eben der Link im Tutorial, der dorthin führt entfernt, um der Verwirrung zu entgehen.

s.o.

Bis demnächst
Matthias

[beatovich]

hallo

Es geht darum, ob PHP eine Programmiersprache ist oder ein Scriptsprache, wo immer man hier auch den Unterschied festlegen will. Ein Kollege meint, solange man nichts kompilieren muss, ist das keine "echte" Programmiersprache. Da er aber nicht unbedingt erfahren ist, frage ich lieber mal euch. Wikipedia, scheint sich nämlich teilweise zu widersprechen, mal Scriptsprache, dann wieder Programmiersprache... Die englische Version, sagt es wäre Beides, na ja... Kann jemand Licht ins Dunkel bringen?

Es gibt vielleicht eine interessantere Diskussion. Was macht einen zum echten Programmierer, und wann ist man lediglich Stratege oder Logistiker, also Anwender bereits vorhandener Instruktionen, die man bedienen kann?

Ganz sicher sind die Entwickler von PHP als Programmierer zu verstehen. Allerdings sollte man sich selber nicht gleich Programmierer nennen, nur weil man gelernt hat eine Sprache anzuwenden.

[MudGuard]

Hi,

Ein Kollege meint, solange man nichts kompilieren muss, ist das keine "echte" Programmiersprache.

bei einer "echten" Programmiersprache wird assembliert, nicht kompiliert!

cu,
Andreas a/k/a MudGuard

[Rolf B]

Hallo Andreas,

Mag sein, aber ein echter Programmierer schreibt

COPY CON APP.EXE

Rolf

[Tanka]

Hallo! Haben wir hier die Philosophie-Lektion?) Ich arbeite mit PHP und finde, das ist reine Programmiersprache. Seltsame Frage.