"R. Baumann" baumann-garbsen@t-online.de writes:

Hallo Liste, Hallo Rüdeger

Danke für die Anregung; sie passt übrigens gut in die aktuelle Squeak-Scratch-Diskussion. Schon an dem scheinbar sehr einfachen Problem 1 kann viel Informatisches gelernt werden. Zunächst wird man ganz naiv vorgehen, die Folge von 1 bis zur gegebenen Grenze durchlaufen und die Zahlen, die der Bedingung genügen, aufsummieren. Einsendung des Ergebnisses ans Euler-Projekt vermittelt ein erstes Erfolgserlebnis.

Dieser auch von mir gewählte Ansatz genügt der Aufgabenstellung völlig. Ich habe das als Lösung A auf der Webseite eingefügt.

Sie hat auch den Vorteil, dass sie jedes Wort der Aufgabenstellung direkt in Smalltalk überführt. Das zeigt die Ausdrucksstärke von Squeak

Wenn man allerdings die Aufgabenstellung ändert und das Ergebnis für andere Obergrenzen sucht, muss man sich etwas einfallen lassen.

Dann wird man sich aber sagen (oder vom Lehrer sagen lassen) und durch Experimente herausbekommen, dass mit dieser Lösung eigentlich wenig gewonnen ist, da man bei anderen Größenordnungen der Grenze (Eingabedaten) zu lange auf das Ergebnis warten muss.

Bei der von mir vorgeschlagenen Lösung kommt noch der Speicherbedarf hinzu. Intervalle als Nachkomme von Collections lassen sehr schöne Formulierungen zu, sind aber speicherintensiv

Nun kommt Nachdenken (etwas Mathematik, etwa der „kleine Gauss“ mit seiner Summationsformel, die sich leicht verallgemeinern lässt) ins Spiel und das Verfahren wird verbessert und sodann implementiert.

Ich erwarte deine Einsendung zu Lösung B :)

Auf diese Weise bauen sich die Schüler ihr Squeak-System (an weiteren Aufgaben) allmählich zu einem schlagkräftigen Problemlöse-Instrument aus. Das ist Kreativität, lieber Ralf Romeike, jenseits von „Animationen und Spiele gestalten“ oder „Katze im Computer“!

Für mich ist es sehr schwer hier Position zu beziehen, weil ich nie im Team programmiert habe und deshalb selten Formalisierungen, Visualisierungen oder Flowcharts benutzen musste. Ich kann nicht beurteilen, ob eToys und Scratch den Einstieg in die Programmierung erleichtern. Ich vermute es, weil beim Entwurf beider Systeme entsprechende Studien durchgeführt wurden.

Hier mal ein Quote aus der Wikipedia zu Scratch

"Auch sehr junge Kinder oder Erwachsene ohne Computerkenntnisse, können mit Scratch motivierende Programmiererfahrungen machen, weil Schrift nicht die einzige Zugangsmöglichkeit ist, sehr wenig getippt werden muss (für einfache Programme gar nicht), keine Programmierbefehle gelernt werden müssen und viele potentielle Fehler (zum Beispiel Syntax-Fehler) gar nicht möglich sind."

Ähnliches gilt ja für eToys auch. Ich habe als 12-jähriger - wenn nicht noch früher - mein erstes größeres Programm geschrieben. Ohne Diagramme oder PAPs. Ich vermute, es sah furchtbar aus. Wenn der Einstieg mit eToys und Scratch später zu einem besseren Programmierstil führt, haben alle Beteiligten gewonnen.

An Scratch gefällt mir die Oberfläche. eToys sieht nicht so modern aus, ist aber besser in das aktuelle Squeak integriert. Ich würde mich freuen, wenn hier auf der Liste beide Seiten (ein und derselben Medaille) zu Wort kommen und konstruktiv diskutiert wird, damit ich mir ein Urteil erlauben kann.

Bis dann Enno

Bert Freudenberg bert@freudenbergs.de writes:

Hallo Bert,

...

Ich erwarte deine Einsendung zu Lösung B :)

Du meinst, weil Lösung B auf unserer Website falsch ist? Demonstriert sehr schön die Gefahr, unnötigerweise mit Indizes rumzuhantieren.

Oops. Ist korrigiert. Danke für den Hinweis

Von diesem Fehler abgesehen kann man das auch kompakter schreiben:

(1 to: 999) inject: 0 into: [:sum :i | (i \ 3 = 0) | (i \ 5 = 0) ifTrue: [sum + i] ifFalse: [sum]] Das vermeidet trotzdem den exorbitanten Speicherverbrauch von Lösung A.

Das hatte ich tatsächlich zuerst auch so formuliert, fand es dann aber nicht so schön. Der hohe Speicherverbrauch von A ist mir erst später aufgefallen.

Noch knapper: (1 to: 999) detectSum: [:i | (i \ 3 = 0) | (i \ 5 = 0) ifTrue: [i] ifFalse: [0]]

Auch daran hatte ich gedacht, nur den false-Zweig vergessen, oder nicht hinbekommen. Genau weiss ich das nicht mehr. Ist schon zu lange her. Schön, das jetzt richtig formuliert zu sehen

Und wenn man Kontrollstrukturen vermeiden mag: (1 to: 999) detectSum: [:i | i * (#(0 0 1 0 1 1 0 0 1 1 0 1 0 0 1) atWrap: i)]

Ich nehme die Variante mit auf. Aber ganz ehrlich, das ist mir zu kompliziert. Das hat was von Obfuscation.

Man kommt über den goldenen Schnitt noch auf die Lösung. Vielleicht hat da mal jemand Lust.

Und ja, es macht Spaß :)

Enno

Bert Freudenberg schrieb:

On 06.11.2010, at 12:04, Enrico Schwass wrote:

...

Ich erwarte deine Einsendung zu Lösung B :)

Du meinst, weil Lösung B auf unserer Website falsch ist? Demonstriert sehr schön die Gefahr, unnötigerweise mit Indizes rumzuhantieren.

Von diesem Fehler abgesehen kann man das auch kompakter schreiben:

(1 to: 999) inject: 0 into: [:sum :i | (i \ 3 = 0) | (i \ 5 = 0) ifTrue: [sum + i] ifFalse: [sum]]

Das vermeidet trotzdem den exorbitanten Speicherverbrauch von Lösung A.

Noch knapper:

(1 to: 999) detectSum: [:i | (i \ 3 = 0) | (i \ 5 = 0) ifTrue: [i] ifFalse: [0]]

Und wenn man Kontrollstrukturen vermeiden mag:

(1 to: 999) detectSum: [:i | i * (#(0 0 1 0 1 1 0 0 1 1 0 1 0 0 1) atWrap: i)]

Macht Spaß :)

• Bert

Hat was! ;-) Wie messe ich denn am elegantesten den Speicherverbrauch deiner Lösungen?

Apropos: Muss dich nachträglich doch sehr loben für die Portierung von EToys auf iPad ... klasse Arbeit, hat mich begeistert! Ist das schon im Appstore oder hat Apple damit auch Probleme?

Have fun, Guido Stepken

Bert Freudenberg schrieb:

On 08.11.2010, at 14:49, Guido Stepken wrote:

...

Apropos: Muss dich nachträglich doch sehr loben für die Portierung von EToys auf iPad ... klasse Arbeit, hat mich begeistert! Ist das schon im Appstore oder hat Apple damit auch Probleme?

Das ist noch lange nicht reif für die Öffentlichkeit. Im Vergleich zu anderer iPad-Software ist die Oberfläche unbedienbar - wurde eben für die Maus entwickelt, nicht für den Finger. Hilfe ist willkommen.

Oh, "unbedienbar"? Dein Video auf Youtube sah aber schon vielversprechend aus. Insbesondere das Malen mit allen Fingern funktionierte schon bestens.

Ich bin ein immer größerer Anhänger von Pharo, insbesondere haben die (ausser dem Kern von Squeak) das Look And Feel enorm verbessert, "SimpleMorphic" eingeführt, sodass sich damit schon feine Applikationen für iPad gestalten liessen.

Ich habe in der letzten Zeit auch einige Android Tablets über mehrere Stunden angeschaut, WePad, Smartbook Surfer (170€!!!), Samsung Pad. Es schaut so aus, dass in wenigen Monaten brauchbare Tablets für weniger als 150€ auf den Markt geschmissen werden, welche mit GPS und kapazitivem Multitouch - Bildschirm für unter 200€ locker möglich sind.

Die Vorarbeit, die Du geleistet hast oder noch geleistet wird in die Bedienbarkeit, fliesst natürlich auch direkt in die /kommenden) Android Versionen. Portierung ist recht einfach. Leider aber unterstützt das Samsung Tablet (habe es getestet) aus irgendwelchen Gründen nur max. 5 Finger - Gesten.

Ich sehe da einen riesigen Markt für hoch intelligente Lernsoftware, basierend auf Squeak. Schneller und wartungsärmer kann man, glaube ich, solche Software nicht schreiben, als mit Smalltalk.

Wie siehst Du das?

Davon abgesehen ist Etoys für den AppStore zu mächtig. Apple tritt ja als Kurator auf. Als Benutzer einer App aus dem AppStore verlässt man sich darauf, dass die App auch das tut, was sie verspricht. Wenn nun beliebiger Code nachgeladen wird, kann Apple das nicht testen. Deswegen verbieten die AppStore-Richtlinien Applikationen, Code nachzuladen. Da Etoysprojekte aber Code enthalten, würde Etoys derzeit nicht zugelassen. Im Prinzip könnte man ja, wenn das im AppStore wäre, eigene Applikationen als Etoys-Projekt verpacken, und somit Apple als Kurator umgehen.

Möglicherweise wird Apple aber Ausnahmen zulassen, Bildung ist ein guter Grund. Gespräche dazu sind jedenfalls im Gange.

Klingt gut.

Davon unbetroffen sind reguläre in Squeak geschriebene Anwendungen. Von denen sind ja schon einige im AppStore.

Upps, verstehe ich nicht ... könnten die nicht prinzipiell über die Hintertür auch Code nachladen? Irgendwelche geheimen Gesten könnten doch den Programmier-Modus aktivieren?

Viele liebe Grüsse, Guido

Bert Freudenberg schrieb:

...

Oh, "unbedienbar"? Dein Video auf Youtube sah aber schon vielversprechend aus. Insbesondere das Malen mit allen Fingern funktionierte schon bestens.

Probiere es doch einfach aus. Ja ich habe damit schon ganze Projekte gebaut, aber man muss schon sehr genau zielen bis man das trifft, was man möchte.

Das iPad wurde sicherlich auch nur für Kinder mit schlankerern Fingern konzipiert! ;-)

...

Ich bin ein immer größerer Anhänger von Pharo, insbesondere haben die (ausser dem Kern von Squeak) das Look And Feel enorm verbessert, "SimpleMorphic" eingeführt, sodass sich damit schon feine Applikationen für iPad gestalten liessen.

Ich habe in der letzten Zeit auch einige Android Tablets über mehrere Stunden angeschaut, WePad, Smartbook Surfer (170€!!!), Samsung Pad. Es schaut so aus, dass in wenigen Monaten brauchbare Tablets für weniger als 150€ auf den Markt geschmissen werden, welche mit GPS und kapazitivem Multitouch - Bildschirm für unter 200€ locker möglich sind.

Ich sehe noch nicht, dass in nächster Zeit mit dem iPad Vergleichbares billiger verkauft wird. Zukünftig sicher schon. Das künftige OLPC-Tablett war ja mein Hauptgrund, Etoys zu portieren, so dass man es schon mal testen kann.

Hoffentlich Besseres! ;-) Marvell liefert ja das neue OLPC Tablet. Wird sicherlich sehr interessant, zumal da mehrere ARM Prozessoren drin sein werden. Im neuen iPad2 ja auch, wie ich hörte. Die Lizenzgebühren für WLAN-N, MPEG, UMTS, GPS, Multitouch fressen ja bald das halbe Tablet auf.

...

Die Vorarbeit, die Du geleistet hast oder noch geleistet wird in die Bedienbarkeit, fliesst natürlich auch direkt in die /kommenden) Android Versionen. Portierung ist recht einfach. Leider aber unterstützt das Samsung Tablet (habe es getestet) aus irgendwelchen Gründen nur max. 5 Finger - Gesten.

Ich sehe da einen riesigen Markt für hoch intelligente Lernsoftware, basierend auf Squeak. Schneller und wartungsärmer kann man, glaube ich, solche Software nicht schreiben, als mit Smalltalk.

Wie siehst Du das?

Derzeit ist es wesentlich einfacher, eine iPhone-App mit Apple's Werkzeugen zu schreiben. In Squeak implementierte Apps dürften auch bei der Akku-Laufzeit schlechter abschneiden. Ein Interpreter tut nunmal viel mehr, und JIT-Compiler à la Cog funktionieren nicht.

Das liegt IMHO an mangelnder Integration in das darunter liegende Powermanagement. Wenn Squeak seinen Leistungsbedarf wenigstens ermitteln könnte, könnten das OS die Taktfrequenz dynamisch regeln. Hat IMHO nix mit Interpreter oder Compiler zu tun.

Wenn man eine sehr komplexe Anwendung baut, oder existierenden Code weiterverwenden möchte, oder eben Smalltalk aus Spaß an der Sache nehmen will, dann liegt der Schwerpunkt natürlich anders. So wie bei Etoys, das wird kaum jemand komplett nachprogrammieren.

Schon lange passiert. Ich kann in C, Python bereits Etoys haben, also das Bewegen von Grafikobjekten mit Logikkacheln und Mausschubsen. Einfach mal googeln.

Have fun, Guido Stepken

Irgendwie habe ich den Eindruck, dass auch Lehrer (ich gehe auch gelegentlich ehrenamtlich an Schulen) inzwischen etwas ernüchtert sind. Hier mein Eindruck, Dinge, die mir aufgefallen sind:

Kein vernünftiges Qualitätsmanagement: Dinge, die früher mal funktionierten, laufen heute nicht mehr. Z.B. Text auf einer Kurve laufen lassen (Follow owners curve). Nicht nur, dass die Entwickler keine eigenen Tests machen, nein, die Lehrer, die das bemerken, verzichten inzwischen darauf, ein Ticket zu öffnen, weil sich eh keiner darum kümmert ...

Schüler haben selber den Eindruck, es mit Anfängersoftware im Alpha-Stadium zu tun zu haben. Dauernd öffnet sich ein Debug-Fenster wegen irgendeinem Scheiß. Für Lehrer, die entgegen vielerlei Widerstände dennoch Etoys lehren, ein echtes Problem. Scratch und BYOB laufen da im Unterricht "runder", problemloser.

Immer wieder Kompatibilitätsprobleme mit dem .pr - Format ... was läuft jetzt überhaupt noch unter welcher Etoys Version? Viele Projekte konnte ich wegschmeissen, weil ich sie in irgendeiner Etoys Version mal generiert habe, die ein zu neueren Versionen inkompatibles .pr Format erzeugt haben. Diese Inkompatibilitäten dürfen nicht sein.

Die Plugin's für Browser ... hmmm ... funktionierten auch mal, ... inzwischen aber nicht mehr. Warum?

Schaut man sich die Mailingliste von Pharo an, was die alles an Fehlern in Squeak beseitigt haben, im Laufe der letzten zwei Jahre, so gewinnt man den Eindruck, dass hier so einiges im Argen liegt. Programmiersprachen, Dialekte, e.t.c. überleben nur durch Killer-Apps. So z.B. wäre Ruby ohne Rails auch schon tot. Ruby wird weiter gepflegt, weil es eine große Schar von Professionellen gibt, die Interesse an der Pflege und Weiterentwicklung der Libs, von Ruby selber haben. Bei Squeak sehe ich da schwarz. Einige verzweifelte Anstrengungen mit CMSBOX o.ä., wofür sich aber auch kaum jemand interessiert. Webhoster können mit einem Interpreter, dessen Speicherverbrauch nicht zu kalkulieren ist, nix anfangen. Die Vhosting Server fliegen denen um die Ohren. Also weg mit serverseitigem Squeak!

Auch gibt es keinen fliessenden Übergang zu professionellen Lösungen, die höhere Verbreitung hätten. Klar gibt es "professionelle Lösungen" in Squeak, aber die Kunden kann man an zwei Händen zählen, die das einsetzen wollen. Der Rest setzt auf Mainstream - Lösungen und Programmiersprachen, wo sicher ist, dass die in ein paar Jahren noch existieren werden (Typo3, Rails, Plone, e.t.c.)

Finanzierung: Niemand bezahlt für Verbesserungen, der Verein selber scheint auch nicht in der Lage zu sein, neue Sponsoren zu finden ... kein PayPal - Button auf der Homepage zu finden ... ;-(

Und soweit ich informiert bin, verlassen sogar die Scratch Programmierer das Boot. Scratch soll in Flash neu implementiert werden ... kein Wunder ... damit könnte man Unterricht "out of the box" machen, ohne Plugins vorher installieren zu müssen, e.t.c.

Grüsse, Guido Stepken

Und wie vermittelt ihr euren Schülern, wofür die Lösung von Eulerproblemen in der alltäglichen Praxis wo gut ist?

Irgendwelche Beispiele, wo man das dringend braucht?

Viele liebe Grüsse, Guido Stepken

Hallo Guido,

On Sat, 6 Nov 2010, Guido Stepken wrote:

Und wie vermittelt ihr euren Schülern, wofür die Lösung von Eulerproblemen in der alltäglichen Praxis wo gut ist?

Berechtigter Einwand, aber im Grunde ist das die genau die gleiche Frage wie die, wie man den Schülern vermittelt, wozu der gesamte Mathematikunterricht der Mittelstufe in der Praxis gut sein soll. Wozu geometrische Beweise führen und irrationale Zahlen kennelernen - die ja doch alle nur 12 Nachkommastellen haben? Offenbar gibt es eine gesellschaftliche Übereinkunft, daß das eben gut, richtig und wichtig ist - finde ich ja auch :)

Sehr verwandt dazu ist die Frage, wie man Schüler dazu bringt, an Mathematik-Wettbewerben teilzunehmen. Praktischer Nutzen: "Du darfst dann in ein Mathe-Camp fahren und kannst letztlich einmal ein Vollstipendium gewinnen."

Manchen macht es einfach Spaß - manchen, und die sind hier auf der Liste natürlich überproportional vertreten. Die anderen fragen sich eher, warum sie Lösungen zu Problemen, die sie nicht verstehen und für die sich zu begeistern ihnen ehrlich schwer fällt, auch noch in einer (Programmier-)Sprache aufschreiben sollen, die sie eigentlich auch nicht interessiert.

Daher lasse ich sie lieber Probleme der Art lösen, warum ein Ball einfach durch einen Schläger hindurchfliegt und wie man ihn vom Gegenteil überzeugen könnte. Die guten können dann noch zusehen, daß das auch noch physikalisch einigermaßen "richtig" aussieht.

Markus