-
Notifications
You must be signed in to change notification settings - Fork 0
Bugs and Problems
Scratch ist in den Funktionalitäten sehr eingeschränkt, gegenüber konventionellen Sprachen. Beim Entwickeln des Programms fielen uns einige kuriose Dinge auf, die das Programmieren deutlich erschwerten. Einiges davon ist der Kompaktheit der Sprache zuzuschreiben, da mit „nur“ 115 verschiedenen Blöcken nicht die Komplexität einer Sprache wie bzw. Python abbilden kann. Zu diesen kleineren Aspekten gehören ua:
- Fehlen eines
return
bei Funktionen - Fehlender Tastsensorzustand
angestoßen
- Fehlen der Möglichkeit der Abfrage der Existenz von Elementen in einer Liste
- Fehlende Möglichkeit des Speichern von Listen in Listen
- Fehlen von
True
undFalse
als Blöcke
Diese Auswahl kleinerer Ärgernisse erschwert die Programmierung enorm, jedoch traten auch Fehler auf, die ein Arbeiten am Programm schier unmöglich machten.
Nach dem fertigstellen der BottomCorners Function wollten wir den Code testweise auf dem EV3 Stein ausführen. Jedoch bekamen wir die Meldung, dass Scratch nur eine begrenze Anzahl an Stapeln zulässt. Diese hatten wir mit 32 Stapeln überschritten. Wir überlegten, wo wir Stapel reduzieren konnten, doch dadurch, dass wir noch eine Menge an Funktionen benötigen würden und das Programm so groß war, dass wir merkten, dass es schon jetzt nicht möglich war, Funktionen zu löschen, entschieden wir uns die Programmierung zu verkleinern und uns ein kleineres Ziel zu setzen.
Nach vielen gemeisterten Hürden und gelösten Problemen hatten wir endlich ein passables Programm erarbeitet. Als wir dieses auf dem Lego-MindStorms abspielen wollten, kam aber die Meldung, dass dieses Programm nicht kompiliert werden könnte. Erst dachten wir, es wäre zu groß, da trotz Vereinfachung das Programm noch über 1000 Blöcke beinhaltete. Nach einigen unglücklichen Versuchen mit leistungsstärkeren Computern wussten wir nicht mehr weiter. Alledings scheint die vermeintlcihe Lösung des Problems noch korrioser. Beheben konten wir das Problem, indem wir alle Blöcke des Programms löschten und wiederherstellten. Danach schien dieses Problem gelöst und die Meldung tauchte nicht wieder auf.
Was uns ebenfalls auffiel war, dass dieses Problem schenbar nitgenswo im Internet oder der Programmhilfe dokumentiert zu sein scheint.
Ein weiteres Problem, welches mit fortschreitender Projektgröße immer bedeutender wurde, war der hohe Rechenaufwand. Ab ca. 1500 Blöcken ließ sich das Projekt nicht mehr auf dem IPad öffnen, weswegen wir gezwungen waren, es über einen PC herunterzuladen, der etwas leistungsstärker war. Dort traten traten nach kurzer Zeit Bildfehler auf, die das Bewegen im Programm ohne zu starkes Ruckeln nicht möglich machten. Auch der Zoom funktionierte nicht so, wie gewohnt. Meist zoomte das Programm nach wenigen Sekunden des Bearbeitens so weit heraus, dass es nicht mehr möglich war, die einzelnen Blöcke zu erkennen. Zum Schluss hin hat sich die Entwicklungsumgebung mehrmalig von alleine geschlossen bzw. fror mit einem weißen Bildschirm ein, was einen Verlust aller ungespeicherter Änderungen zur Folge hate. Diese Fehler sind wahrscheinlich auf die hohe Auslastung der Grafikkarte zurückzuführen. Abschließend hatten wir hier technische Obergrenze erreicht, was ebenfalls zur wahl eines kleineren Projekts beitrug.