3. Ist die Ausgabe 01/2010 "iX Spezial Programmieren heute" lesenswert?

Ist die Ausgabe 01/2010 "iX Spezial Programmieren heute" lesenswert?

  • ?

    Werdet doch mal konkret. Was findet ihr an PHP so schlecht, das es insgesamt zu einer schlechten Programmiersprache macht? 😕

    0
  • N

    Bemühe doch bitte mal Google. Das Internet ist voll mit Erläuterungen, warum PHP Mist ist.

    http://plasmasturm.org/log/393/
    http://www.steike.com/code/php-must-die/
    http://maurus.net/resources/programming-languages/php/
    http://webonastick.com/php.html
    http://www.bitstorm.org/edwin/en/php/
    …

    0
  • R

    An PHP ist einfach so vieles falsch. Sicher fing es als praktischer hack an. Man wollte etwas, was einfacher als C war und was man einfach auf einen Server hochladen konnte ohne damit alle anderen User abschießen zu können (damals gab es Virtualisierung in dem Maß noch nicht und Webspace hieß ja wirklich, dass man ein ~/user/webroot auf irgend einem Unixrechner hatte). Man wollte etwas was verständlicher als Perl war.

    Aber die Entwickler von PHP waren halt keine Sprachdesigner. Und es ist immer blöd, wenn wenig erfahrene Leute etwas in dem Bereich machen. Also haben die halt alles aus C, C++, Perl, Shellskript und anderen Sprachen zusammen gewürfelt, was sie finden konnten. Daher hat man diesen hässlich inkonsistenten Mix als Grundsprache. Das wurde natürlich noch schlimmer, weil man immer mehr Features dazugewürfelt hat. Vom Sprachdesign ist PHP also schon einmal unten durch.

    Die Bibliotheken sind ein wilder Mix: Alles im globalen Namespace und keine einheitliche Namenskonvention. Wie die Sprache an sich, einfach dazu gewürfelt, wenn man es mal gerade gebraucht hat. (Beispiel: Es gibt ein mysql_escape_string aber die API ist fehlerhaft. Also führt man ein mysql_real_escape_string ein und behält die alte Funktion bei...)

    Der Interpreter ist extrem mies. Die Firma hinter PHP lebt ja nicht umsonst davon, dass man einen Beschleuniger dafür verkauft. Aber wenn man sich anschaut, mit welcher "Kompetenz" dieser misst entwickelt wird...

    Was gibt "print 08;" in PHP aus? 0! Weil die Entwickler keine Ahnung von Octalzahlen und der richtigen Verwendung von man: strtol haben. http://www.steike.com/code/php-must-die/

    Schaut euch an, wie die Integeroverflows versuchen zu fixen: http://use.perl.org/~Aristotle/journal/33448 *aaaah* m(

    Solchen Code wollt ihr auf euren Servern laufen lassen? Den Leuten wollt ihr die Sicherheit eurer Firma anvertrauen?

    PHP ist ja auch nur oberflächlich einfach. Sicher kann damit auch jemand ohne größere Programmiererfahrung eine Webseite hinbekommen. Aber das reicht eben noch nicht. Man muss sich ja nur die ganzen Webseiten mit SQL Injection oder XSS Problemen anschauen... Wieviele Webseiten wurden schon gehackt, weil die einfach von einem Codemonkey mit PHP zusammengefrickelt wurde? PHP macht es vorallem leicht unsichere Webseiten zu schreiben.

    PHP ist die schlechteste Programmiersprache, mit der schlechtesten Library und der schlimmsten Implementierung und das alles von Leuten geschrieben, die man besser nicht einmal ein "Hello World" programmieren lässt.

    0
  • R

    nman schrieb:

    Bemühe doch bitte mal Google. Das Internet ist voll mit Erläuterungen, warum PHP Mist ist.

    http://plasmasturm.org/log/393/
    http://www.steike.com/code/php-must-die/
    http://maurus.net/resources/programming-languages/php/
    http://webonastick.com/php.html
    http://www.bitstorm.org/edwin/en/php/
    …

    👍
    Nette Sammlung.

    0
  • C

    Z schrieb:

    Werdet doch mal konkret. Was findet ihr an PHP so schlecht, das es insgesamt zu einer schlechten Programmiersprache macht? 😕

    Ich erlaube mir, Auszüge aus einem IRC-Channel (von verschiedenen Tagen in diesem Jahr) zu posten. Die Namen habe ich anonymisiert, weil die Gesprächspartner unwichtig ist. Alle Gesprächsteilnehmer sind Leute, die das Forum regelmäßig und seit langer Zeit besuchen.

    Man sieht deutlich den Frust, den die Sprache auslöst. 🙂

    <AAAA> auf Slashdot hat letztens jemand einen anderen Auszug aus der
        PHP-Doku gepostet.
<AAAA> wie array-Indizes behandelt werden.
<AAAA> assoziative Arrays (d.h. string-indizes) und normale Arrays
        (int-Indizes) sind erstmal von vornherein derselbe Datentyp.
<AAAA> $a['8'] ist dasselbe wie $a[8]
<AAAA> $a['08'] ist nicht dasselbe wie $a[8]
<AAAA> wenn der Array-Index eine Fließkommazahl ist, wird diese
        stillschweigend (ohne Warnung!) konvertiert in einen int.

    Das habe ich übrigens getestet: Es stimmt.

    <AAAA> BBBB: hatte ich erwähnt, dass PHP furchtbar und ganz grässlich ist?
<AAAA> BBBB: typische Kommentare in der PHP-Doku sind "ach, übrigens,
        die Funktion macht eigentlich etwas völlig anderes als oben in
        der Doku steht, und zwar wie folgt: ..."
<BBBB> AAAA: das passt dann wenigstens zum verhalten der meisten in
        php geschriebenen software.
<AAAA> BBBB: ja, leider.
<AAAA> BBBB: ich hatte letztens das Vergnügen, die Funktion
        "escapeshellarg" in PHP zu sehen.
<AAAA> BBBB: http://php.net/manual/en/function.escapeshellarg.php
<AAAA> BBBB: die Doku klingt so, als wäre diese Funktion höchstens 5
        Zeilen lang
<AAAA> BBBB: man kann nun wirklich nicht viel falsch machen bei so
        einer Funktion, sollte man meinen.
<AAAA> eigentlich genügen zwei Zeilen: 1) ersetze ' durch '"'"' 2)
        return "'" + $result + "'";
<AAAA> quoting mit single-quotes für die Shell
<BBBB> und? wie haben die php-leute es geschafft?
<AAAA> BBBB: naja... das ist haarsträubend.
<AAAA> BBBB: diese Funktion wertet irgendeine Umgebungsvariable aus
        (vermutlich $LC_ALL). Wohlgemerkt, *nicht* die globale
        Variable von mb_internal_encoding(), die von anderen
        String-Funktionen verwendet wird.
<AAAA> BBBB: falls in dem Argument ein Zeichen vorkommt, das nicht
        repräsentierbar ist in diesem bestimmten Encoding, dann bricht
        die Funktion an dieser Stelle ab.
<AAAA> und liefert einen halbfertigen String zurück.
<AAAA> immerhin gequotet.
<BBBB> uff. debugging-schreikrampf ahoi. :)
<AAAA> oh ja.
<AAAA> vor allem, wenn mb_internal_encoding() auf "utf-8" steht und
        die Umgebungsvariable "LANG" auf en_US.UTF-8
<BBBB> naja, ich habe vor ein paar wochen ein interview mit dem
        erfinder von php gelesen, seitdem wundert mich das alles nicht
        mehr.
<AAAA> laut einem Kommentar in der Doku soll man LC_ALL setzen für den
        Apache-Prozess
<AAAA> um das zu fixen
<BBBB> aua. schmerzen.
<AAAA> so ein Fix ist super.
<AAAA> Wartbarkeit = 0
<AAAA> und beim nächsten Serverumzug bricht alles auseinander

    Es kann natürlich sein, dass AAAA hier einen Fehler gemacht hat: mb_internal_encoding() und die Umgebungsvariable LANG sind richtig gesetzt, aber vielleicht fehlt etwas anderes. In jedem Fall gilt, dass die PHP-Doku mehr als unzureichend ist, wenn so ein Versagen einer PHP-Funktion undokumentiert ist.

    <AAAA> ähnlich schlimm ist übrigens mb_encode_mimeheader
<AAAA> du weißt ja sicher grob, wie Umlaute in E-Mail-Headern kodiert
        werden
<AAAA> (das ist auch schon furchtbar, unabhängig von PHP, aber egal)
<AAAA> mb_encode_mimeheader nimmt zwei wichtige Parameter: 1) "the
        string being encoded" und 2) charset
<AAAA> Dokumentation für den zweiten Parameter: charset specifies the
        name of the character set in which str is represented in. The
        default value is determined by the current NLS setting
        (mbstring.language). mb_internal_encoding() should be set to
        same encoding.
<AAAA> da frag ich mich sofort: Wenn das sowieso dasselbe sein soll
        wie mb_internal_encoding(), *warum* muss ich den übergeben?
<BBBB> wtf?
<AAAA> naja, interessant ist das Verhalten, wenn das nicht dasselbe
        ist. Das ist offensichtlich undokumentiert, stört
        mb_encode_mimeheader aber wenig.
<AAAA> die Doku ist sowieso völlig daneben
<AAAA> der zweite Parameter gibt *nicht* das encoding an, in dem str
        (der erste Parameter) repräsentiert ist.
<AAAA> es gibt das encoding an, das im E-Mail-Header verwendet soll,
        also quasi das Ziel-Encoding.
<AAAA> ist ja auch fast dasselbe wie das Quell-Encoding, so ein Detail
        kann schonmal unter den Tisch fallen.
<AAAA> naja, das Quell-Encoding holt sich die Funktion dann aber
        woher?
<AAAA> natürlich aus mb_internal_encoding()
<AAAA> und wenn das nicht übereinstimmt mit dem zweiten Parameter,
        dann kodiert die Funktion den String um.
<AAAA> das, was normalerweise Bibliotheken wie iconv machen würden.
<AAAA> diese Schmerzen.
<AAAA> achso, das umkodieren sieht auch so aus, das nicht
        repräsentierbare Zeichen einfach übersprungen werden, ohne
        Warnung, ohne Fehlermeldung.
<AAAA> aber das wundert bestimmt niemanden mehr.
<BBBB> naja, ich habe vor kurzem mit einem bekannten gesprochen, der
        utf-8-taugliche software in php schreiben muss. ich bemitleide
        den armen kerl.
<AAAA> oh ja.
<AAAA> das ist ein einziger Krampf.
<AAAA> achso, mb_encode_mimeheader hat laut einiger Kommentare einige
        ziemlich übliche Bugs gehabt, was escaping und encoding
        etc. angeht.
<AAAA> keine Ahnung, wie viele davon noch aktuell sind.
<AAAA> besonders cool finde ich ich das Beispiel bei
        mb_encode_mimeheader() in der Doku
<AAAA> $name = ""; // kanji
<AAAA> nur steht da halt kein Kanji :)
<AAAA> als ob das Framework, in dem die Doku geschrieben wurde, nicht
        unicode-safe ist
<BBBB> pff, wenn das locale vom webserver von php.net auch nicht
        richtig gesetzt ist...

    <AAAA> BBBB: kennst du die Funktion utf8_decode()? :)
<AAAA> BBBB: die zeigt deutlich den Weitblick der PHP-Entwickler.
<BBBB> AAAA: nein, mein php-wissen ist irgendwann um 2003 sowas
        stehengeblieben. damals war ich ueberzeugt, dass die sprache
        nicht reparierbar ist.
<AAAA> BBBB: utf8_decode macht folgendes.
<AAAA> BBBB: "This function decodes $data, assumed to be UTF-8
        encoded, to ISO-8859-1."
<AAAA> praktisch, wenn man in Westeuropa lebt und kein Euro-Symbol
        braucht.
<BBBB> oh, also nicht 8859-15, sondern wirklich 8859-1. :)
<BBBB> wenigstens passt die doku. :)
<AAAA> BBBB: kA
<AAAA> BBBB: würde mich ehrlich gesagt auch nicht wundern, wenn die
        Funktion in Wirklichkeit nach -15 konvertiert.
<AAAA> BBBB: aber dieser Weitblick ist doch unglaublich.
<BBBB> AAAA: und das euro-zeichen woanders kaputtgeht? :)
<BBBB> AAAA: wie gesagt, wundert mich alles lange nicht mehr.

    <AAAA> BBBB: wo ich vor Jahren mal drauf gestoßen bin:
        http://pear.php.net/bugs/bug.php?id=11238
<AAAA> BBBB: inzwischen (seit knapp 2 Monaten) ist es "fixed in SVN"
<AAAA> nach 2,5 Jahren.
<AAAA> BBBB: dieser Bug sagt im Endeffekt: Empfänger wie "Herr Müller
        <mueller@example.com>" sind in PEAR::mail broken.
<AAAA> BBBB: nicht-ascii-Zeichen im Empfänger-Namen sind broken.
<AAAA> das ist ja auch total abwegig, dass man sowas brauchen würde.
<BBBB> und das war eine regression offensichtlich?
<BBBB> laut bugreport zumindestens.
<AAAA> nicht nur Empfänger-Name, sondern auch Absender, natürlich. Das
        betraf alle Header, die E-Mail-Adressen enthalten.
<AAAA> BBBB: hm, stimmt.
<AAAA> BBBB: dann ist es noch weniger entschuldbar, dass der Bug 2,5
        Jahre offen war.
<CCCC> lolol

    Mir ist klar, dass in den Rants oben ein wenig übertrieben wird. Die Fakten sollten, soweit ich sie geprüft habe, aber alle korrekt sein.
    Das sind jedenfalls alles sehr konkrete Fälle, wo PHP einfach kaputt, unzureichend dokumentiert oder beides ist.

    0
  • S

    Das mit dem Euro-Zeichen hat mir auch sehr viel Spaß gemacht: Hat mir auch 6,5h Entwicklungszeit gekostet 😞

    MfG SideWinder

    0
  • R

    @Christoph
    *Popcorn hol* Woooww, Coool, 🕶 gibt es dazu eine Fortsetzung? Scheint interessant zu sein 🙂

    ~kleine Offtopic Frage:~

    Sind wir überhaupt noch On-Topic????

    ^oder sind wir in einen zugegebenermaßen interessanten und begründeten PHP-Bashing / Blamewar abgeglitten?^
    🙄

    0
  • C

    Rhombicosidodecahedron schrieb:

    Woooww, Coool, 🕶 gibt es dazu eine Fortsetzung? Scheint interessant zu sein 🙂

    Das geht ganz einfach: http://www.php.net/

    Dort steht auf der Startseite z.B.: "PHP 5.3.2 Released!". Etwas weiter unten steht:
    # Fixed bug #50847 (strip_tags() removes all tags greater then 1023 bytes long).

    Ok, eine willkürliche 1023-Bytes-Grenze ist schonmal verdächtig. Mal schauen, was strip_tags eigentlich macht: http://www.php.net/manual/en/function.strip-tags.php

    Offizielle Doku schrieb:

    This function tries to return a string with all NUL bytes, HTML and PHP tags stripped from a given str .

    Bis hierher klingt es vernünftig. Wobei, "tries"? Aber egal, vielleicht gibt die Funktion einfach ihr bestes.

    Offizielle Doku schrieb:

    It uses the same tag stripping state machine as the fgetss() function.

    Bitte was, state machine? Regexp nenn ich normalerweise nicht "state machine", obwohl es das theoretisch sein mag. Also ist die Funktion vielleicht gar kein Einzeiler, der nur eine regexp anwendet?

    Das Rätsel lüftet sich, wenn man zum zweiten Parameter kommt:

    Offizielle Doku schrieb:

    allowable_tags You can use the optional second parameter to specify tags which should not be stripped.

    Ok, in diesem Parameter können wir also Tags spezifizieren, die nicht entfernt werden sollen. Spezifizieren... nur wie? Laut Signatur ist der zweite Parameter ein string. Wie sollen wir dort Tags spezifizieren ohne Angabe des erwarteten Formats? Zum Glück gibt es ein Beispiel:
    strip_tags($text, '<p><a>'); // Allow <p> and <a>
    Wenn $text der String '<p>Test paragraph.</p> <a href="#fragment">Other text</a>' ist, dann wird dort nichts entfernt, weil <p> und <a> erlaubt sind. Dafür ist der zweite Parameter also da. Warum der zweite Parameter nicht einfach ein Array von Strings ist, bleibt weiterhin ein Rätsel.

    Mal überlegen, wofür man diese Funktion vermutlich einsetzen würde, wenn man sie zum ersten Mal sieht und nicht weiß, was PHP sonst so hat. Tags strippen, aber bestimmte Tags erlauben. Klingt nach einer billigen Variante, um vom User eingebene Texte zu validieren. Leider ist strip_tags dafür vollkommen unbrauchbar, wie die dicke rote Warnung weiter unten schreibt:

    Offizielle Doku schrieb:

    Warning This function does not modify any attributes on the tags that you allow using allowable_tags, including the style and onmouseover attributes that a mischievous user may abuse when posting text that will be shown to other users.

    Mit anderen Worten: Wenn wir den zweiten Parameter weglassen und einfach alle Tags strippen, dann kann man vielleicht (vielleicht) damit Input validieren. Wenn man den zweiten Parameter nutzt, ist es völlig vorbei, weil man in einem onmouseover-Attribut so ziemlich alles anstellen kann.

    Das Problem ist: Die Existenz des zweiten Parameters verkompliziert die ganze Implementierung von strip_tags um Größenordnungen. Würde strip_tags einfach das machen, was der Name sagt, würde es keinen zweiten Parameter geben und die Implementierung wäre relativ überschaubar, hätte also weniger Bugs.

    Das Verhalten von strip_tags bei nicht-wohlgeformten HTML ist übrigens undokumentiert, aber das war eh zu erwarten. Das einzige, was die Doku dazu sagt, ist "das kann schiefgehen".

    Wenn das alles nicht wirklich in der offiziellen Doku stehen würde, ich würde denken, da hätte jemand eine Satire-Seite aufgezogen. So traurig ist das.

    Wenn irgendjemand nochmal bezweifelt, dass PHP eine schlechte Sprache ist: Einfach auf die offizielle Doku verweisen.

    p.s.: Easteregg.

    0
  • S

    👍

    BTW: Bald wird PHP6 ja alles richten...

    MfG SideWinder

    0
  • M

    Und zum Thema Geschwindigkeit von PHP: Facebook benutzt ja PHP (dämlich, das). PHP ist so langsam, dass die Leute von Facebook sich entschieden haben, einen eigenen Compiler dafür zu schreiben.

    http://developers.facebook.com/hiphop-php/

    🤡

    0
  • ?

    Oha, erstmal Danke für eure vielen Antworten. 😮

    OK, ihr habt PHP ziemlich zerrissen und viele Bugs aufgedeckt. Ich muss zugeben, dass ich mich mit PHP nicht so ausgiebig beschäftigt habe, um derart in die Tiefe zu gehen. Für mich war PHP bisher ein einfach zu handhabendes System für dynamische Webseiten, aber offensichtlich ist es für Größeres ungeeignet.

    Ich meine nur: es gibt viel scheinbar gute Software in PHP, Content Management Systeme wie z.B. Typo-Light (damit arbeite ich manchmal und es gefällt mir eigentlich recht gut) oder dieses Forum hier. Meint ihr, das taugt alles nichts oder macht auf längere Sicht nur Probleme?

    Was ist eurer Meinung nach sinnvoller als PHP? Flash vielleicht?

    0
  • S

    Z schrieb:

    Ich meine nur: es gibt viel scheinbar gute Software in PHP, Content Management Systeme wie z.B. Typo-Light (damit arbeite ich manchmal und es gefällt mir eigentlich recht gut) oder dieses Forum hier. Meint ihr, das taugt alles nichts oder macht auf längere Sicht nur Probleme?

    Viele gute Webseiten sind in PHP geschrieben. PHP ist nur ein Werkzeug. Man kann auch mit schlechten Werkzeugen tolle Sachen bauen.

    Was ist eurer Meinung nach sinnvoller als PHP? Flash vielleicht?

    Flash ist eine komplett andere Baustelle.
    Defakto gibt es keine Alternative zu PHP.

    Manche werden jetzt vielleicht Python oder Ruby nenne andere vielleicht ASP - aber im Prinzip gibt es nur PHP.

    0
  • M

    Z schrieb:

    Was ist eurer Meinung nach sinnvoller als PHP? Flash vielleicht?

    Lisp?
    🙂

    0
  • ?

    Shade Of Mine schrieb:

    Viele gute Webseiten sind in PHP geschrieben. PHP ist nur ein Werkzeug. Man kann auch mit schlechten Werkzeugen tolle Sachen bauen.
    ...
    Defakto gibt es keine Alternative zu PHP.

    Das beruhigt mich. 😉

    Wie gesagt, hatte ich bisher einen ziemlich positiven Eindruck von PHP, aber ich habe PHP auch noch nie voll ausgereizt, so dass mir gravierende Fehler offenbar wurden.

    Schauen wir mal, was aus PHP noch wird. Weiterentwickelt wird es noch. Ich denke, keine Programmiersprache war von anfang an perfekt.

    Für "richtige" Programme haben wir ja unser annähernd perfektes C++ und das ist, glaube ich, schon 30 Jahre alt. C++ hatte am Anfang sicherlich auch einige Mängel.

    0
  • A

    Shade Of Mine schrieb:

    Defakto gibt es keine Alternative zu PHP.

    Du redest aber nur von Hobbyfricklern, oder? Für kommerzielle Nutzer ist ASP.NET durchaus eine Alternative.

    Z schrieb:

    Für "richtige" Programme haben wir ja unser annähernd perfektes C++

    Tellerrand? 🙂

    0
  • ?

    Shade Of Mine schrieb:

    Was ist eurer Meinung nach sinnvoller als PHP? Flash vielleicht?

    Flash ist eine komplett andere Baustelle.
    Defakto gibt es keine Alternative zu PHP.

    ABAP und SAP R/3 😃

    0
  • ?

    audacia schrieb:

    Z schrieb:

    Für "richtige" Programme haben wir ja unser annähernd perfektes C++

    Tellerrand? 🙂

    Ja ich gestehe. 😉
    Ausser PHP und C++ habe ich bisher nur Java, Visual Basic und C# kennengelernt. Wobei mir die drei letzteren absolut nicht gefallen haben. Ich habe mit C++ angefangen und werde wohl auch dabei bleiben, jedenfall ist nichts in Sicht, das meiner Meinung nach C++ das Wasser reichen könnte.

    0
  • S

    Das kommt wohl stark auf die Einsatzdomäne an...

    RAD-Prototypen würde ich wohl nicht mit C++ entwickeln wollen...

    MfG SideWinder

    0
  • N

    Shade Of Mine schrieb:

    Defakto gibt es keine Alternative zu PHP.

    Manche werden jetzt vielleicht Python oder Ruby nenne andere vielleicht ASP - aber im Prinzip gibt es nur PHP.

    Warum?

    Nur weil für Kleinstunternehmen PHP die Norm ist, weil die ganzen Billighoster managed LAMP-Server für einen Apfel und ein Ei haben?

    Für Python gibt es Django und CherryPy, für Ruby Rails, Sinatra und einiges dazwischen und einige andere Sprachen holen auch auf.

    An Hostern gibt es mittlerweile eine Riesenmenge brauchbare VPS, Amazon EC2, Heroku, Google AppEngine etc., also auch für fast jeden Anwendungsfall was passendes.

    Ich habe schon ein paar Webapps für Firmen unterschiedlichster Größe geschrieben, aber PHP musste ich dafür zum Glück seit 2003 nicht mehr verwenden.

    Schauen wir mal, was aus PHP noch wird. Weiterentwickelt wird es noch. Ich denke, keine Programmiersprache war von anfang an perfekt.

    Aus PHP wird überhaupt nichts mehr. Christoph hat doch auf die offizielle Doku verlinkt, schau Dir mal an, was für Leute daran entwickeln. PHP hat auch nicht einfach eine leicht verbesserungsbedürftige Standardlibrary oder so, es ist von Grund auf kaputt. Durch Weiterentwicklung verbessern sich nur Sprachen, die a) realistischerweise rettbar sind, ohne die komplette Userbase zu vergraulen und b) Entwickler und Designer haben, die kompetent genug sind, um auch tatsächlich was retten zu können und die c) sehen, wie furchtbar kaputt ihr Projekt ist und motiviert sind, dagegen etwas zu tun.

    Ich sehe bei PHP keinen dieser Punkte erfüllt und in der Zwischenzeit erstarken Python und Ruby für Webanwendungen immer mehr. PHP wird nicht einfach sterben, aber es wird auch nicht in absehbarer Zeit zu einer akzeptablen oder gar guten Sprache werden.

    0
  • ?

    Mit was wurde Wikipedia gemacht? Mit was werden Webseiten für Banken gemacht?

    0
Anmelden zum Antworten