[dafor]

Es scheint, dass Sie den Punkt noch nicht ganz erfasst haben. Es ist leider wahr, dass in manchen Programmiersprachen Konventionen der Syntax beachtet werden müssen, die eigentlich lächerlich sind, wie etwa die Semikolons, von denen Sie sprachen. Das sind zwar unangenehme aber im Prinzip nebensächliche Probleme.

Schwierigere und bedeutendere Probleme, und damit würde ich dem Herrn Blogger teilweise recht geben, sind zum Beispiel:

(1) welche Funktionalität wird in einem bestimmten Bereich wirklich benötigt, und welche schadet?
(2) welche benötigte Funktionalität sollte per Computer Anwendung bereitgestellt werden, und welche nicht?
(3) auf welche Weise kann diese Funktionalität überhaupt mittels eines Computers bereitgestellt werden?
(4) in welcher Weise sollen Benutzer und Computer zusammenarbeiten um die bereitgestellte Funktionalität zu verwenden?
(5) wie schafft man es die Programme so zu machen, dass sie später gegebenenfalls weiterentwickelt oder an neue Gegebenheiten angepasst werden können?

Es gibt noch etliche andere Schwierigkeiten, die eigentlich viel wichtiger sind als die Semikolons etc. Trotzdem funktioniert ein Programm nicht, in dem die Syntaxkonventionen nicht beachtet worden sind. Es ist allerdings so, dass man die notwendige Priorisierung der Probleme erst erfahren kann, wenn man selber an länger andauernden und grösseren Projekten zur Entwicklung von Programmen teilgenommen hat und wenn man zudem noch die Gelegenheit hatte die praktischen Konsequenzen für Anwender wie Betreiber von Programmen zu erleben, die daher rühren, dass in der Entwicklung nicht gut gearbeitet wurde.

Ich fürchte, dass derartige Dinge im Prinzip außerhalb der Möglichkeiten der beschriebenen Lernumgebung liegen. Das Bild vom Programmieren, dass diese Umgebung vermittelt ist mit ziemlicher Sicherheit sehr vereinfacht, geschönt und verfälscht.

[flachatmer]

Es scheint, dass Sie den Punkt noch nicht ganz erfasst haben. Es ist leider wahr, dass in manchen Programmiersprachen Konventionen der Syntax beachtet werden müssen, die eigentlich lächerlich sind, wie etwa die Semikolons, von denen Sie sprachen. Das sind zwar unangenehme aber im Prinzip nebensächliche Probleme.

Schwierigere und bedeutendere Probleme, und damit würde ich dem Herrn Blogger teilweise recht geben, sind zum Beispiel:

(1) welche Funktionalität wird in einem bestimmten Bereich wirklich benötigt, und welche schadet?
(2) welche benötigte Funktionalität sollte per Computer Anwendung bereitgestellt werden, und welche nicht?
(3) auf welche Weise kann diese Funktionalität überhaupt mittels eines Computers bereitgestellt werden?
(4) in welcher Weise sollen Benutzer und Computer zusammenarbeiten um die bereitgestellte Funktionalität zu verwenden?
(5) wie schafft man es die Programme so zu machen, dass sie später gegebenenfalls weiterentwickelt oder an neue Gegebenheiten angepasst werden können?

Es gibt noch etliche andere Schwierigkeiten, die eigentlich viel wichtiger sind als die Semikolons etc. Trotzdem funktioniert ein Programm nicht, in dem die Syntaxkonventionen nicht beachtet worden sind. Es ist allerdings so, dass man die notwendige Priorisierung der Probleme erst erfahren kann, wenn man selber an länger andauernden und grösseren Projekten zur Entwicklung von Programmen teilgenommen hat und wenn man zudem noch die Gelegenheit hatte die praktischen Konsequenzen für Anwender wie Betreiber von Programmen zu erleben, die daher rühren, dass in der Entwicklung nicht gut gearbeitet wurde.

Ich fürchte, dass derartige Dinge im Prinzip außerhalb der Möglichkeiten der beschriebenen Lernumgebung liegen. Das Bild vom Programmieren, dass diese Umgebung vermittelt ist mit ziemlicher Sicherheit sehr vereinfacht, geschönt und verfälscht.

Ja, ganz schrecklich. Zum Glück sind die Bilder, die Spiele von Polizisten, Soldaten, Terroristen, Gangstern und Gitarristen zeichnen weitaus differenzierter.

[frigor]

Ich fürchte, dass derartige Dinge im Prinzip außerhalb der Möglichkeiten der beschriebenen Lernumgebung liegen. Das Bild vom Programmieren, dass diese Umgebung vermittelt ist mit ziemlicher Sicherheit sehr vereinfacht, geschönt und verfälscht.

... ein derart langes Blabla schreiben, hätten Sie diese Umgebung ja mal testen können.

[darksystem]

Ich fürchte, dass derartige Dinge im Prinzip außerhalb der Möglichkeiten der beschriebenen Lernumgebung liegen.

Derartige Dinge lernt man in einer Berufsausbildung oder in einem Studium. Hier geht es darum auf spielerische Art und Weise einen Einstieg in die Programmierung zu bekommen. Und eben bei diesem Einstieg sind die von Ihnen aufgezählten Dinge, so relevant sie für die "richtige" Programmierung auch sein mögen, absolut nebensächlich.

Das Bild vom Programmieren, dass diese Umgebung vermittelt ist mit ziemlicher Sicherheit sehr vereinfacht, geschönt und verfälscht.

Und jeder Guitar Hero Spieler kann nach dem Spielen perfekt Gitarre spielen und hat den vollen Durchblick wie viel Lernarbeit, Talent und Können "echte" Spieler aufbringen müssen, ja ne is klar ;):

[ctrlaltdel]

... ein derart langes Blabla schreiben, hätten Sie diese Umgebung ja mal testen können.

testen geht nicht, die Jungs haben auf dem Demo Eingangsfenster das "registrieren" vergessen :-(((

[titule]

Sorry, aber Kanonen und Ballern als pädagogische Lockvögel sind ein Armutszeugnis für die Entwickler des Spiels und für die, die sich davon ködern lassen. (Solche Leute sollten vielleicht wirklich nicht Programmieren lernen.)

Man könnte ja auch die zum Programmieren notwendige Kreativität, Spaß am Knacken von Rätseln, die Freude am Verstehen der Welt und die Modellbildung als Motivation nutzen, aber es muss stumpfe Destruktion herhalten. Da scheint mir die Zielgruppe diejenigen zu sein, die am Computer sonst zocken. Die aber kommen sowieso eher mit Programmierung in Berührung, wenn sie ihre Games modden.

Kommt das aus Amerika?

[Whitejack]

Ich fürchte, dass derartige Dinge im Prinzip außerhalb der Möglichkeiten der beschriebenen Lernumgebung liegen. Das Bild vom Programmieren, dass diese Umgebung vermittelt ist mit ziemlicher Sicherheit sehr vereinfacht, geschönt und verfälscht.

Da haben Sie sicherlich Recht. Andererseits dürfte das für die meisten Berufe gelten. Wenn man z.B. über Forschungsarbeiten in der wissenschaftlichen Welt spricht, dann wird immer viel darüber erzählt, welche Ideen die Forscher gehabt haben. Dass aber der größte Teil der Zeit dafür draufgeht, z.B. Instrumente zu justieren, irgendwelche Schwingungen in den Messergebnissen zu minimieren oder falsche Ideen zu verfolgen, wird fast nie erwähnt. In der offiziellen Darstellung haben Wissenschaftler keine schlechten Ideen und die Apparaturen funktionieren permanent und liefern Traum-Ergebnisse.

Entsprechend seltsam sind dann auch die Vorstellungen von Nicht-Forschern über den Arbeitsalltag von Forschern und Entwicklern. Aber vermutlich ist das auch in so etlichen anderen Arbeitsbereichen nicht viel anders.

[SignorMacchina]

Es scheint, dass Sie den Punkt noch nicht ganz erfasst haben. Es ist leider wahr, dass in manchen Programmiersprachen Konventionen der Syntax beachtet werden müssen, die eigentlich lächerlich sind, wie etwa die Semikolons, von denen Sie sprachen. Das sind zwar unangenehme aber im Prinzip nebensächliche Probleme.

Schwierigere und bedeutendere Probleme, und damit würde ich dem Herrn Blogger teilweise recht geben, sind zum Beispiel:

(1) welche Funktionalität wird in einem bestimmten Bereich wirklich benötigt, und welche schadet?
(2) welche benötigte Funktionalität sollte per Computer Anwendung bereitgestellt werden, und welche nicht?
(3) auf welche Weise kann diese Funktionalität überhaupt mittels eines Computers bereitgestellt werden?
(4) in welcher Weise sollen Benutzer und Computer zusammenarbeiten um die bereitgestellte Funktionalität zu verwenden?
(5) wie schafft man es die Programme so zu machen, dass sie später gegebenenfalls weiterentwickelt oder an neue Gegebenheiten angepasst werden können?

Es gibt noch etliche andere Schwierigkeiten, die eigentlich viel wichtiger sind als die Semikolons etc. Trotzdem funktioniert ein Programm nicht, in dem die Syntaxkonventionen nicht beachtet worden sind. Es ist allerdings so, dass man die notwendige Priorisierung der Probleme erst erfahren kann, wenn man selber an länger andauernden und grösseren Projekten zur Entwicklung von Programmen teilgenommen hat und wenn man zudem noch die Gelegenheit hatte die praktischen Konsequenzen für Anwender wie Betreiber von Programmen zu erleben, die daher rühren, dass in der Entwicklung nicht gut gearbeitet wurde.

Ich fürchte, dass derartige Dinge im Prinzip außerhalb der Möglichkeiten der beschriebenen Lernumgebung liegen. Das Bild vom Programmieren, dass diese Umgebung vermittelt ist mit ziemlicher Sicherheit sehr vereinfacht, geschönt und verfälscht.

Coding ist nur ein Teilgebiet des Entwicklungsprozesses von Software.
Beim Software-Engineering geht es darum, Lösungen zu gestellten/vorhandenen Anforderungen/Problemstellungen zu entwickeln, welche dann anschließend in Code verewigt werden.
Dort werden dann zuerst die Fragen 1-4 behandelt, bevor zwecks Programmieren "in die Tasten gehauen" wird.

Die Antwort auf Frage 5 wird durch die Verwendung von Vorgehensmodellen und "Patterns", also (mehr oder weniger) groben Richtlinien beim Entwickeln & Coden, erreicht.