Meine Bewertung war recht streng, also nicht wundern, wenn ihr überraschend wenig Punkte gekriegt hat. Ich habe insbesondere darauf geachtet, ob es irgendetwas gibt, was man anhand der Spezifikation sinnvoll erwarten könnte (z.B. dass Winkel unter 0,1° funktionieren, dass man beliebig groß zeichnen kann oder dass der Interpreter schlau genug ist, die Farbcodes sinnvoll zu verwenden). Wenn das nicht gegeben war, gab's Abzüge.
Ich habe außerdem in meiner Tabelle den jeweils höchsten Wert in jeder Spalte hervorgehoben.
Name
Interpreter
Bild
Umsetzung
Sonstiges
SummeCornix csg Ineluki nudelsalat Whiz-zarD
Hier meine Notizen zu den Beiträgen. Die Notizen sind nicht alle Gedanken, die ich dazu hatte, aber wohl die wichtigeren. Insbesondere gibt es in der Regel keine Zeilen zu bestandenen Tests; ich setze das Bestehen von Tests als Normalzustand voraus.
Zeilen mit einem + vorne sind positiv in die Wertung eingeflossen; solche mit einem - negativ. Zeilen mit einem ~ vorne sind neutral. In der Regel tauchen sie in der Reihenfolge +, ~, - auf.
Cornix
Interpreter 3/5
~ Da die Mac-Version des Interpreters auf meinem Rechner nicht lauffähig ist und ich die Windows-Version nicht herunterladen konnte, konnte ich den Interpreter nicht testen. Ich habe daher diesen Abschnitt im Wesentlichen übersprungen und 2,5 Punkte vergeben.
+ 0,5 Punkte Bonus gibt es, weil der Siemensstern demonstriert hat, dass zumindest Winkel offenbar mit sinnvollen Fließkommazahlen implementiert sind und man so nicht auf Mindestwinkel achten muß. Ich gehe mal davon aus, daß das auch auf Längen zutrifft.
Bild 2/5
~ Sofern ich aus dem Beitragspost ersehen konnte, scheint es um Rekursion mit gelegentliche Zufallswerten zu gehen. Nicht uninteressant, wenn auch durch die (vorgegebene) Farbpalette etwas augenunfreundlich.
+ Der Siemensstern ist auch Augenkrebs (wie es sich für einen richtigen Siemensstern gehört), aber eine gute Idee. Einfache Mittel, großer Effekt.
Idee/Umsetzung/Sonstiges 2/5
~ Der verwendete Filehoster konnte von mir nicht verwendet werden, um tatsächlich Dateien herunterzuladen. Zum Glück hatte DFYX noch Kopien vom Quelltext und der Mac-Binary.
- Die OS X-Version ist auf meinem Mac (Mid 2012 MBP, OS X 10.8.3, OpenJDK 1.7.0-internal-b00) nicht lauffähig, wenn der Aufruf wie in der README angegeben erfolgt. Das liegt nicht an den Kompatibilitätsproblemen zwischen lwjgl und Java 1.7 (die in den neuesten Versionen behoben sein sollte), sondern daran: java.lang.UnsatisfiedLinkError: no lwjgl in java.library.path
csg
Interpreter 3/5
- Der Interpreter hat undokumentierte Einschränkungen oder Abweichungen gegenüber der Sprachdefinition:
- //////////**********F sollte eine Linie der Länge 1 zeichnen. Statt dessen kommt nichts; offenbar wurde zwischendurch die Länge auf 0 reduziert. Warum wurde die Länge nicht in einem IEEE Float gespeichert?
- <<<<<>>>>>+F sollte einen rechten Winkel zeichnen; statt dessen wird ein ca. 60°-Winkel gezeichnet. Ich vermute, dass hier ebenfalls mit einem nicht hinreichend präzisen Datentyp gearbeitet wurde.
- Der Code ist kaum dokumentiert und damit nicht ganz einfach zu durchschauen.
Bild 2/5
+ Das Bild ist recht nett...
- ...aber du hättest den erzeugenden Code beilegen sollen.
Idee/Umsetzung/Sonstiges 4/5
+ Unterprogramme sind eine coole Idee.
Ineluki
Interpreter 3/5
+ Der Blending-Renderer fasst Linien wenn möglich zusammen. FF ergibt eine Linie, nicht zwei.
~ Der Code ist nicht ganz leicht zu durchschauen, aber das liegt eher daran, wie awk funktioniert.
~ Der Painting-Renderer ist von Haus aus mit BSD sed inkompatibel. Man kann allerdings Kompatibilität herstellen, indem man das sed -r durch sed -E ersetzt. Hier wäre vielleicht der Einsatz von Autoconf/Automake sinnvoll gewesen, um die jeweils korrekte Invokation zu gewährleisten. Alternativ hätte man auf ein Tool mit bekannt homogener Implementierung von regulären Ausdrücken zurückgreifen können wie z.B. Perl.
~ /usr/bin/awk ist hardcoded? Was spricht gegen #!/usr/bin/env awk? Es ist im Unix-Standard und dürfte auch in POSIX sein. Zugegeben, das könnte auch auf die Position von awk zutreffen.
- Der Interpreter skaliert das Bild nicht; es ist Aufgabe des Benutzers, dafür zu sorgen, dass das Bild im Koordinatensystem auf beiden Achsen im Bereich ±1 liegt.
Bild 4/5
+ Die Mona Lisa demonstriert gut, dass der Interpreter auch mit sehr großen Dokumenten klar kommt.
+ Das Mandelbrot-Bild tut das auch und sieht dabei auch noch gut aus.
Idee/Umsetzung/Sonstiges 4,5/5
+ Ausführliche Dokumentation macht den Bewerter glücklich.
+Drei verschiedene Renderer?Zwei Renderer und ein Konverter? Cool. Die Idee, den Zeichenvorgang zu animieren, hat auch was.
+ Mandelbrot als Turtle-Grafik hat was.
~ Ich habe den Kram, wie die Mona Lisa in Turtle-Grafik übersetzt wurde, ignoriert. Interessant wird's erst, als der Turtle-Code auftaucht.
nudelsalat
Interpreter 4/5
+ Dem Interpreter sind absolute Größen egal; es wird skaliert, wie es in den Viewport paßt.
+ Soweit meine groben Tests das erkennen konnten, wurde die Spezifikation vollständig eingehalten.
+ Die Libraries sind gut eingesetzt und der eigentliche Quellcode ist erfrischend übersichtlich. Gut, bis auf die unten erwähnte Klasse AABB.
~ Es wäre nett gewesen, wenn man um mehr als eine Achse rotieren könnte. Ich hatte schon eine Abweichung gegenüber der Spezifikation notiert, bis ich gesehen habe, dass der Effekt durch Perspektivische Verzerrung hervorgerufen wurde.
- Was zum Teufel ist die AABB-Klasse und warum ist sie nicht dokumentiert?
Bild 4,5/5
+ Mehrere Bilder sind schon mal ein Bonus.
+ Die Beispiele sind gut gewählt. Jeder kommt darauf, mit L-Systemen Bäume zu zeichnen, aber der Kreis und die Sprungfeder waren unerwartet.
+ Die Beispiele sind schlicht, aber schick.
Idee/Umsetzung/Sonstiges 4/5
+ 3D. Cool.
+ L-Systeme sind bei Turtlegrafik zwar offensichtlich, aber trotzdem nett.
- Wenn man ein Toolfenster schließt, kriegt man es nicht wieder auf.
Whiz-zarD
Interpreter 1,75/5
+ Der SVG-Export ist gut. Die erzeugten Dateien sind zwar nicht die kompaktesten, aber wenn man bedenkt, dass das Entwicklungsziel das Anzeigen von regenbogenfarbenen Zykloiden war (was enorm viele Farbverläufe bedingt), ist das schon in Ordnung.
~ Die Farbverläufe verstoßen zwar gegen die Sprachspezifikation (1F2F sollte zwei verschiedenfarbige Linien erzeugen, nicht einen Varbverlauf), sind aber hübsch.
~ Ich weiß, das ist in Java so üblich, aber wow, sind das viele Klassen für so ein kleines Programm.
- Mehr Dokumentation wäre eine gute Idee gewesen. Gerade der kritische OGLTurtleRenderer ist ohne die Dokumentation im Wesentlichen magischer Code, der halt irgendwas macht.
- Warum separate Eingabefelder für den gerade ausgeführten Code und den auszuführenden Code? Warum kann man nicht einfach den gerade ausgeführten Code bearbeiten?
- Warum nur so ein kleines Eingabefeld für Code?
- Der Interpreter hat undokumentierte Einschränkungen oder Abweichungen gegenüber der Sprachdefinition:
- >>>><<<< sollte eine Nulloperation sein. Statt dessen gibt es eine "Invalide Statusänderung: Winkel = 0". Warum nimmt dieses Programm den Winkel modulo 360 und warum ist das nirgends dokumentiert?
- //////////********** sollte eine Nichtoperation sein. Statt dessen gibt es eine "Invalide Statusänderung: Länge = 0". Warum wird die Länge in einem Format gespeichert, das bereits bei 0,01 eine so geringe Auflösung hat, dass der Unterschied zu 0 nicht mehr repräsentiert werden kann? Warum keine IEEE Floats?
F+F sollte eine Linie nach oben zeichnen, von der eine Linie nach rechts abgeht. In diesem Fall geht die zweite Linie aber nach links ab; das Koordinatensystem ist horizontal gespiegelt.Ich sehe gerade, dass das so spezifiziert war. Da war die Spezifikation wohl etwas unintuitiv; die Hälfte der Teilnehmer hat nämlich + und - vertauscht. Dafür, dass du hier aufgepasst hast, schreibe ich noch mal 0,25 Punkte gut.
Bild 3/5
+ Netter Zykloid. Einfach, aber hübsch.
Idee/Umsetzung/Sonstiges 2/5
~ Insgesamt eine recht normale Umsetzung der Spezifikation. Die Farbverläufe sind ein netter touch, auch wenn ich mir da einen neuen Befehl für gewünscht hätte, um nicht gegen die Spezifikation zu verstoßen. Da der Code sehr modular aufgebaut ist, sollte das Einfügen eines entsprechenden Befehls an sich trivial sein.
- Beim GUI hätte darauf geachtet werden sollen, dass wenigstens die Anleitung ohne Zeilenumbrüche dargestellt werden kann. (Offenbar wurde hier nicht spezifiziert, welche Schriftart dieses Textfeld verwendet; unter OS X ist die verwendete Schriftart so breit, dass einige Zeilen umgebrochen werden.)
- Eine Zoomfunktion für Bilder, die größer als die Zeichenfläche sind, wäre nett gewesen.
Der Vollständigkeit halber möchte ich noch diese Sache posten, die mir beim Testen meines eigenen Codes aufgefallen ist.
Jesus_666
Interpreter —
- *****1F<+>2F+3F<+>4F+/!*5F sollte ein krudes, buntes Haus zeichnen. Der Interpreter verwendet aber nur die letzte Farbe, weil ich offenbar bei den Farbbefehlen die Anweisungen für das Ändern der Farbe und für das Anfangen eines neuen Pfades in der falschen Reihenfolge habe.
Zitieren
Großes Lob an das Team dafür!
