Eulerprobleme mit Squeak

Hallo Liste,

es gibt auf unserer Webseite einen Entwurf für ein neues Projekt, dass
stark auf eure Mithilfe angewiesen ist. Näheres findet ihr hier.

http://www.squeak.de/eulerprobleme-geloest

Rüdeger hat im letzten Monat bereits über 60 der Probleme gelöst und ich
habe trotz knapper Freizeit für 35 die Lösung gefunden. Das heisst aber
nicht, dass wir immer den "besten" aller Lösungswege benutzt haben.

Daher bitten wir euch um die Zusendung eurer Lösungen, damit wir sie
sammeln und besprechen können.

Viel Spaß beim Knobeln
Enno

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.

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. 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.

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“!

                                                                                                                             R. Baumann

"R. Baumann" <[hidden email]> 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

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

Guido Stepken <[hidden email]> writes:

Hallo Guido,

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

Eulerprobleme beschreiben oft Probleme der Zahlentheorie. Das ist
tatsächlich sehr mathematiklastig.

Aber vor allem übt das Lösen von Eulerproblemen ungemein die
Abstraktionsfähigkeit. Man hats dann leichter bei praktischen
Problemen. Zum anderen gibt es tatsächlich immer mal wieder Beispiele
mit Praxisbezug. Man muss ihn nur sehen.

Hier zum Beispiel
http://blog.functionalfun.net/2008/07/project-euler-problem-15-city-grids-and.html

Auch findet man bei vielen Problemen Verweise auf Knuths Bücher.

> Irgendwelche Beispiele, wo man das dringend braucht?

Ich bin kein Lehrer, kann also schlecht beurteilen, ab welchem Alter die
Schüler das praktisch anwenden können. Reihenentwicklung z.B. hab ich
erst im Studium gehabt. Möglicherweise wird das heute aber schon auf dem
Gymnasium gelehrt.

Baumsuche ist ein weiteres Beispiel.

Wer praktischere Probleme sucht findet vielleicht hier etwas

http://www.spoj.pl/problems/classical/

Ich bin aber der Meinung, dass man die Mathematik, die beim Projekt
Euler gebraucht/vermittelt wird, immer mal wieder braucht.

Problem 1 beispielsweise lässt sich über arithmetische Reihe

(n+1)(a+d*n/2)

lösen. Ich poste den Code im Laufe des Wochenendes.

ciao
Enno

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 -

Bert Freudenberg <[hidden email]> 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

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

Enrico Schwass <[hidden email]> writes:

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

Vergesst es. Da war ich in Gedanken schon bei Problem 2.

Enno

Markus Schlager schrieb:
> 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?
Hmmm, habt ihr euch nie Gedanken darüber gemacht, wie DIN-Möbel im
Format 30cm, 60cm, 90cm, 1.20m in LkW's mit 2.40m Breite und z.B. max.
16m Länge möglichst kompakt gestapelt werden können?

Und zack, haste eure "Eulerprobleme" am Hals!

Have fun, Guido Stepken

Bert Freudenberg schrieb: 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

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

Messen ... keine Ahnung. Da aber keine großen Collections erzeugt werden (im Gegensatz zu der Variante mit #select:) ist der Speicherverbrauch vernachlässigbar.

> 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.

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.

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

- Bert -

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

Guido Stepken <[hidden email]> writes:

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

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

Einen ersten Hinweis liefert vermutlich

MessageTally spyOn:[10 timesRepeat:[Euler1 new]]

Lösung A

**Memory**
        old +38,887,776 bytes
        young +19,820,616 bytes
        used +58,708,392 bytes
        free -505,648 bytes

Lösung X

**Memory**
        old +0 bytes
        young +616,076 bytes
        used +616,076 bytes
        free -616,076 bytes


Enno

On 09.11.2010, at 02:17, Guido Stepken wrote:

> 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.

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.

> 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.

> 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.

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.

>> 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?

Sicher kann man das, auch mit anderen Sprachen. Tut man aber nicht, wenn man nicht aus dem AppStore fliegen will.

- Bert -

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

On 09.11.2010, at 17:56, Guido Stepken wrote:

> Bert Freudenberg schrieb:
>> 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.

Wir haben es offensichtlich nicht geschafft, dir klar zu machen, was an Etoys besonders ist.

Ich habe jetzt aber auch keine Lust, das zu vertiefen.

- Bert -

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