Hallo, Stefan!
Jaja, wo ist das Problem? In 5 Minuten stelle ich die verschiedenen Schleifen vor, und danach alles nur noch mit Iteratoren....
Ich habe einen Katalog mit 2300 Einträgen und soll die seitenweise zu je 20 Stück anzeigen. Nachdem das über 100 Seiten sind, soll es die Möglichkeit geben "schnell" zu blättern, d.h. 10 Seiten weiter. Das sieht dann so ähnlich aus wie die Navigation von xpdf.
Kann sein .... denke aber, daß PDF sicher nicht für riesige Listen gedacht war ...
Wie mach ich das mit Iteratoren so elegant wie mit einer Schleife?
firstIndex to: lastIndex do: [:index | (catalog at: index) showOn: aStream ]
Jetzt du!
Workspace öffnen:
'dies ist ein Beispiel' select: [:each | each isVowel ]. <ALT-P>
statt select kann man auch do oder collect schreiben ... siehe Handbuch.
*lach* 300 Mannjahre Entwicklungsarbeit in Squeak und "verstehen"?
Na aber sicher doch. Ich weiß nicht, wie viele Mannjahre hinter aktueller Mathematik (von mir aus auch Schulmathematik) stehen, aber trotzdem kann man sie verstehen. Der Witz an der Stelle ist, dass Nachfolger durch geschickte Aufzeichnungen der Vorgänger Abkürzungen nehmen können und nicht alles neu *erfinden* müssen. Aber verstehen können Sie's trotzdem.
*lach* Mathematik und logisch? Wo denn?
Berechne doch z.B. mal Inhalt und Oberfläche der Funktion von 1/x von 1 bis oo.
Inhalt: PI. Oberfläche: oo Wenn ich als so einen Behälter anmalen will (innen oder außen), brauche ich unendlich viel Farbe. Wenn ich aber Pi Liter Farbe hineinschütte, ist er perfekt angemalt. Den Rest kann ich wieder ausschütten. Viel Spaß beim Rätseln.
Logische Widersprüche in der Mathematik kenne ich zuhauf....
Wenn man das mentale Modell von Squeak sauber verinnerlicht hat, also komplett OO-Denke drauf hat, ist die Programmiersprache Smalltalk eh ein Witz, weil sie der menschlichen Sprache sehr ähnlich ist. Wenn ich da zurück denke, mit C++ oder Java .... grausts mich. Ich sehe S# mit Vergnügen entgegen, überlege, ob ich nicht mal ein Projekt anstoße, Squeak und EToys auf S# zu portieren..... Aber S# ist doch sehr viel anders, als Smalltalk (Ihhh, Mehrfachvererbung....)
Mehrfachvererbung mit "Ihhh" abzutun, macht auf mich keinen guten Eindruck.
Sorry.
In Common Lisp (CLOS) ist die Mehrfachvererbung sauber implementiert und sehr gut einsetzbar, da sie nicht nur eine Spezifikation der Schnittstellen enthält, sondern i.d.R. auch eine generische Implementation. Spart unheimlich viel Arbeit.
Lisp durchsucht bei Mehrfachvererbung ja die Klassenhierarchie in einer vordefinierten Reihenfolge. Die erste Oberklasse wird genommen. Bei C++ muß der Klassenname vorangestellt, also genau bestimmt werden. Unter bestimmten Voraussetzungen, gerade im Zusammenhang mit Grabage-Collection und Mehrprozessorsystemen gibt es gigantische Schwierigkeiten, auch beim Compilerbau ... daher -> Konzept wackelig. Außerdem kann es passieren, daß die Laufzeit des Programms explodiert, völlig unvorhergesehen, z.B. dann, wenn sich die Katze in den Schwanz beißt, sprich Oberklassen von Unterklassen umdefiniert werden.
Ich finde schon, dass Schüler auch mit herkömmlichen Textverarbeitungssystemen umgehen können sollten.
Ich persönlich wäre schon zufrieden, wenn die Schüler in der Lage wären, mit einem Nur-Text-Editor einen inhaltlich brauchbaren Text zu schreiben anstatt Stunden in die "richtige" Verzierung reinzubuttern.
Du urteilst ganz schön hart.
Fakt, jederzeit belegbar. Das begründet z.B. auch, warum Smalltalk Seaside und Ruby on Rails so einen durchschlagenden Erfolg haben.
Durchschlagend? Ruby on Rails hat Erfolg, weil es zur rechten Zeit am rechten Ort war und DHH marketingmäßig sehr geschickt ist. Technisch bin ich von RoR nicht beeindruckt. Zu viel Bloat.
Was bedeutet das?
Das mag aus deiner Sicht ja alles stimmen, aber im Schulsystem kann man nicht machen, was man will, selbst wenn man davon überzeugt ist, recht zu haben. Veränderungen erreicht man nur schrittweise, frag mal die Leute, die das seit Jahren versuchen!
Kein Problem. Da maile ich einfach mal durch, wer mir Ansprechpartner nenen kann, die im Kultusministerien in den Gremien sitzen, und genau denen schreibe ich dann ein kleines Pamphlet, mit Codebeispielen, und
Schon verloren. Entscheider lesen keinen Code, weil sie keinen Code lesen können. Entscheider lieben "Industriestandards", damit ein Praxisbezug gewährleistet ist. Verwende einen Industriestandard, da kannst du nichts falsch machen.
Ah, ok! "Leute, esst Scheiße, millionen Fliegen können nicht irren!"
Deswegen schminken sich Schauspieler auch selber, weil sie damit um Welten bessere Ergebnisse erzielen als mit einem professionellen Visagisten oder wie sich die Maler da nennen.
Schnellschussmetaphern gehen oft daneben, weil man gegen sie argumentieren kann ohne sich auf die Sache zu beziehen.
Stimmt, sollte auch nur die Idee dahinter erläutern.
Das ist für mich das Hauptproblem, zu vermitteln, was das Besondere an Squeak und Smalltalk ist, eben weil es so anders ist als alle anderen Sprachen und Werkzeuge.
Squeak und Smalltalk sind normal, alles andere ist "unnormal".
Squeak und Smalltalk passen gut in deine Welt, zu deinen Aufgabenstellungen und zu deinen Denkmustern. Deswegen sind sie noch lange nicht "normal".
Waschmaschine, Wäschetrockner, Geschirrspüler, Toaster, Kühlschrank, Staubsauger,.... nirgendswo ein Squeak zu sehen. Desktop-Applikationen sind vielleicht "laut", aber dafür selten. Genau wie Menschen im Vergleich zu Insekten.
Für die Programmierung oder auch nur den Ablauf mit minimalen Ressourcen ist fast jedes OO-System zu komplex und aufgebläht.
Nö, Squeak lief auch auf meinem ARM 250 MHz, 32 MByte RAM.... Apropos: Mein Win32 - Rechner, auf dem ich gerade tippe, zeigt mir 7.5 MByte RAM für Squeak.exe an ....
OO-Datenbank. Die Struturen kannst Du jederzeit ohne Datenverlust und irgendwelche Datenbank - Kenntnisse verändern. Anlernzeit - 10 Minuten.
Na schön, jetzt können die Kids mit Squeak das machen, was sie mit Bleistift und Papier machen können. Haben sie jetzt auch was über Datenbanken gelernt? Wie man seine Daten organisiert, um einen zuverlässigen Zugriff zu bekommen? Bei vielen Daten? Bei unscharfen Suchkriterien? Da steckt mehr dahinter als "10 Minuten" Einarbeitung.
Bei vielen Daten? So mit 800 MByte in 0.1 Sekunden nach beliebigen Suchstrings durchforsten? Siehe Anschluß an Gemstone/S, Magma und deren Performance.
Ich nehme dabbledb, das geht noch schneller. Aber was kann ich jetzt? Was hab ich dabei gelernt? Hab ich mich durch das Anklicken vorgefertigter Komponenten irgendwie weiterentwickelt?
Kenne ich leider nicht .... aber zur Weiterentwicklung - lohnt es perfekt runde Räder neu zu erfinden?
Wer braucht denn das überhaupt noch, angesichts OO-Datenbanken ud Fulltext - Index? Googles Technik mit fast 0!!! - Suchzeit in Pentabyte großen Datenbanken ist doch super erfolgreich. Dahinter steckt einfach nur - Glimpse. Siehe auch TRIES.
... und ein cleveres MapReduce-Verfahren und *tausende* gleichzeitig rädelnder PCs. Wenn ich diese Rechenleistung nicht habe, ist's vorbei mit der schönen neuen Welt.
Nenee. Probier mal Fulltext - Hash aus ... Suchzeit fast nur wenige Millisekunden..... auch bei 300 Gigabyte Datenbestände noch im Bereich von unter 1/10 Sekunde.
s.
Viele Grüße, Guido Stepken
stepken (13.03. 21:52):
Hallo, Stefan!
Jaja, wo ist das Problem? In 5 Minuten stelle ich die verschiedenen Schleifen vor, und danach alles nur noch mit Iteratoren....
Ich habe einen Katalog mit 2300 Einträgen und soll die seitenweise zu je 20 Stück anzeigen. Nachdem das über 100 Seiten sind, soll es die Möglichkeit geben "schnell" zu blättern, d.h. 10 Seiten weiter. Das sieht dann so ähnlich aus wie die Navigation von xpdf.
Kann sein .... denke aber, daß PDF sicher nicht für riesige Listen gedacht war ...
Hab ich auch nicht gesagt. Ich habe gesagt, dass das Benutzer-Interface so wie bei xpdf aussieht.
Wie mach ich das mit Iteratoren so elegant wie mit einer Schleife?
firstIndex to: lastIndex do: [:index | (catalog at: index) showOn: aStream ]
Jetzt du!
Workspace öffnen:
'dies ist ein Beispiel' select: [:each | each isVowel ]. <ALT-P>
nicht mogeln. Wie kriege ich mit einem Iterator die Einträge aus der Liste? Wenn ich deinem Beispiel folge, frage ich jeden Katalogartikel nach seiner Position. Die sollte der aber eigentlich nicht kennen, denn gemäß OO-Prinzip Verkapseln und Verstecken, weiß der einzelne Artikel nicht, dass er in einer Liste gesammelt ist.
statt select kann man auch do oder collect schreiben ... siehe Handbuch.
Ich weiß, welche Iteratoren Smalltalk zur Verfügung stellt. Ich wusste nicht, dass Squeak ein Handbuch hat, in dem so was steht :-)
*lach* 300 Mannjahre Entwicklungsarbeit in Squeak und "verstehen"?
Na aber sicher doch. Ich weiß nicht, wie viele Mannjahre hinter aktueller Mathematik (von mir aus auch Schulmathematik) stehen, aber trotzdem kann man sie verstehen. Der Witz an der Stelle ist, dass Nachfolger durch geschickte Aufzeichnungen der Vorgänger Abkürzungen nehmen können und nicht alles neu *erfinden* müssen. Aber verstehen können Sie's trotzdem.
*lach* Mathematik und logisch? Wo denn?
Berechne doch z.B. mal Inhalt und Oberfläche der Funktion von 1/x von 1 bis oo.
Ich bin in Bayern zur Schule gegangen und hab hier auch fürs Lehramt studiert. Mit mir musst du langsam reden. Was ist der Inhalt und die Oberfläche der Funktion 1/x?
Inhalt: PI. Oberfläche: oo Wenn ich als so einen Behälter anmalen will (innen oder außen), brauche ich unendlich viel Farbe. Wenn ich aber Pi Liter Farbe hineinschütte, ist er perfekt angemalt. Den Rest kann ich wieder ausschütten. Viel Spaß beim Rätseln.
Aha. Pi. Also lassen wir vermutlich 1/x um die x-Achse rotieren. Ich kann zwar auf Anhieb die Oberfläche eines Rotationskörpers nicht mehr ausrechnen, aber glaube das \infty einfach mal.
Wo ist das Problem? Du kannst die Farbe doch gar nicht reinschütten, weil - du nicht groß genug bist, um zur Öffnung "oben" raufzulangen - weil die Öffnung oben zu klein ist, als dass da Farbmoleküle durchpassen würden - wenn du "die Spitze nach unten" hältst, die eingefüllte Farbe nicht aus dem Gravitationstrichter der Erde rausläuft - es schwierig sein dürfte, das Einfüllen abzuwarten, wenn wir mal die Lichtgeschwindigkeit als Obergrenze für Bewegung nehmen. - der Behälter nicht ins (endliche) Universum passt
Ich kann auch flächenfüllende Kurven und raumfüllende Flächen finden, aber wo ist das Problem mit der Logik? Es gibt vielleicht ein Problem mit der Anschauung/persönlichen Erfahrung, aber die Logik spielt da keine Rolle. Logik heißt, konsequente Anwendung von Regeln, aufbauend auf Axiomen.
Logische Widersprüche in der Mathematik kenne ich zuhauf....
Wissen wir seit Gödel, dass es so was geben muss. Aber was hat das mit der Verstehbarkeit eines Systems zu tun, das du nie selbst erfinden könntest?
Wenn man das mentale Modell von Squeak sauber verinnerlicht hat, also komplett OO-Denke drauf hat, ist die Programmiersprache Smalltalk eh ein Witz, weil sie der menschlichen Sprache sehr ähnlich ist. Wenn ich da zurück denke, mit C++ oder Java .... grausts mich. Ich sehe S# mit Vergnügen entgegen, überlege, ob ich nicht mal ein Projekt anstoße, Squeak und EToys auf S# zu portieren..... Aber S# ist doch sehr viel anders, als Smalltalk (Ihhh, Mehrfachvererbung....)
Mehrfachvererbung mit "Ihhh" abzutun, macht auf mich keinen guten Eindruck.
Sorry.
In Common Lisp (CLOS) ist die Mehrfachvererbung sauber implementiert und sehr gut einsetzbar, da sie nicht nur eine Spezifikation der Schnittstellen enthält, sondern i.d.R. auch eine generische Implementation. Spart unheimlich viel Arbeit.
Lisp durchsucht bei Mehrfachvererbung ja die Klassenhierarchie in einer vordefinierten Reihenfolge. Die erste Oberklasse wird genommen.
Was meinst du damit? Wofür wird die "erste Oberklasse" genommen?
Bei C++ muß der Klassenname vorangestellt, also genau bestimmt werden. Unter bestimmten Voraussetzungen, gerade im Zusammenhang mit Grabage-Collection und Mehrprozessorsystemen gibt es gigantische Schwierigkeiten, auch beim Compilerbau ... daher -> Konzept wackelig.
1. Bei C++ oder Lisp? 2. Hab ich mit GC bei Einfachvererbungs-Sprachen wie Smalltalk nicht die gleichen Probleme? Was hat GC überhaupt mit Vererbung zu tun? 3. Nur weil die Implementation nichts taugt, muss ein Konzept nicht wackelig sein.
Außerdem kann es passieren, daß die Laufzeit des Programms explodiert, völlig unvorhergesehen, z.B. dann, wenn sich die Katze in den Schwanz beißt, sprich Oberklassen von Unterklassen umdefiniert werden.
Was heißt, dass Oberklassen von Unterklassen umdefiniert werden?
Durchschlagend? Ruby on Rails hat Erfolg, weil es zur rechten Zeit am rechten Ort war und DHH marketingmäßig sehr geschickt ist. Technisch bin ich von RoR nicht beeindruckt. Zu viel Bloat.
Was bedeutet das?
Viel Zeugs eben, das das System unheimlich langsam macht. Rails ist das Vista der Ruby-Webframeworks. Vor vielen Jahren hat Avi Bryant ein Framework namens IOWA in Ruby begonnen, das er Kirk Haines vererbt hat. In nächster Zeit wird's da endlich die offizielle Version 1.0 geben und von der Geschwindigkeit und dem Ressourcenbedarf her ist das um Klassen besser.
Das mag aus deiner Sicht ja alles stimmen, aber im Schulsystem kann man nicht machen, was man will, selbst wenn man davon überzeugt ist, recht zu haben. Veränderungen erreicht man nur schrittweise, frag mal die Leute, die das seit Jahren versuchen!
Kein Problem. Da maile ich einfach mal durch, wer mir Ansprechpartner nenen kann, die im Kultusministerien in den Gremien sitzen, und genau denen schreibe ich dann ein kleines Pamphlet, mit Codebeispielen, und
Schon verloren. Entscheider lesen keinen Code, weil sie keinen Code lesen können. Entscheider lieben "Industriestandards", damit ein Praxisbezug gewährleistet ist. Verwende einen Industriestandard, da kannst du nichts falsch machen.
Ah, ok! "Leute, esst Scheiße, millionen Fliegen können nicht irren!"
Nicht "Leute" und "Fliegen", sondern "Fliegen" und "Fliegen". Wenn man diese Diskrepanz aus dem Satz rausnimmt, ist er zwar immer noch unappetitlich, aber viel einleuchtender.
Es handelt sich halt um einen typischen Fall von CYA (cover your a55), mit dem ein potenzieller Schaden an der eigenen Karriere vermieden wird. "Ich folge dem Standard, also hab ich nicht grob fahrlässig gehandelt."
Das heißt nicht, dass ich diese Einstellung billige, aber das ist nun mal die vorherrschende Mentalität.
Für die Programmierung oder auch nur den Ablauf mit minimalen Ressourcen ist fast jedes OO-System zu komplex und aufgebläht.
Nö, Squeak lief auch auf meinem ARM 250 MHz, 32 MByte RAM....
250 MHz und 32 MB? Minimale Ressourcen sind eher x kHz und y kB, wobei x und y deutlich unter 100 liegen...
Na schön, jetzt können die Kids mit Squeak das machen, was sie mit Bleistift und Papier machen können. Haben sie jetzt auch was über Datenbanken gelernt? Wie man seine Daten organisiert, um einen zuverlässigen Zugriff zu bekommen? Bei vielen Daten? Bei unscharfen Suchkriterien? Da steckt mehr dahinter als "10 Minuten" Einarbeitung.
Bei vielen Daten? So mit 800 MByte in 0.1 Sekunden nach beliebigen Suchstrings durchforsten? Siehe Anschluß an Gemstone/S, Magma und deren Performance.
Gemstone war nicht ganz billig, als ich das letzte Mal nachgeschaut hab. Was mach ich, wenn ich das Geld nicht hab?
Ich nehme dabbledb, das geht noch schneller. Aber was kann ich jetzt? Was hab ich dabei gelernt? Hab ich mich durch das Anklicken vorgefertigter Komponenten irgendwie weiterentwickelt?
Kenne ich leider nicht
dabbledb.com, IIRC. Von Avi Bryant, baut auf Seaside auf.
.... aber zur Weiterentwicklung - lohnt es perfekt runde Räder neu zu erfinden?
Bitte lies doch, was ich schreibe. Hab ich *mich* weiterentwickelt?
Ich werde zwar zunehmend runder, aber ein perfektes Rad bin ich noch lange nicht. Ich muss mich auch nicht neu erfinden, sondern nur stetig verbessern. Wenn es da ein lokales Maximum geben sollte, hab ich es noch nicht erreicht. Wenn ich es erreicht habe, werd' ich hochbezahlter Manager und lehne alles Neue ab, was ich nicht schon immer so gemacht hab. Just kidding.
Wer braucht denn das überhaupt noch, angesichts OO-Datenbanken ud Fulltext - Index? Googles Technik mit fast 0!!! - Suchzeit in Pentabyte großen Datenbanken ist doch super erfolgreich. Dahinter steckt einfach nur - Glimpse. Siehe auch TRIES.
... und ein cleveres MapReduce-Verfahren und *tausende* gleichzeitig rädelnder PCs. Wenn ich diese Rechenleistung nicht habe, ist's vorbei mit der schönen neuen Welt.
Nenee. Probier mal Fulltext - Hash aus ... Suchzeit fast nur wenige Millisekunden..... auch bei 300 Gigabyte Datenbestände noch im Bereich von unter 1/10 Sekunde.
300 GB Textdaten? Unter 1/10 Sekunde? Mit Squeak? Cool. Wie groß ist denn da die Indexdatei?
s.
On Mar 13, 2007, at 22:51 , Stefan Schmiedl wrote:
Wie mach ich das mit Iteratoren so elegant wie mit einer Schleife?
firstIndex to: lastIndex do: [:index | (catalog at: index) showOn: aStream ]
Jetzt du!
Workspace öffnen:
'dies ist ein Beispiel' select: [:each | each isVowel ]. <ALT-P>
nicht mogeln. Wie kriege ich mit einem Iterator die Einträge aus der Liste?
<klugscheiß>
catalog atAll: (firstIndex to: lastIndex)
</klugscheiß>
Das Tolle an der Smalltalk-"For-Schleife" ist, dass sie nur ein Iterator über Zahlenintervalle ist. So wie man über normale Sammlungen iteriert (mit #do:, #collect:, #select: etc.) kann man das auch mit Intervallen machen:
(1 to: 5) do: [:i | ...] (1 to: 5) collect: [:i | ...] (1 to: 5) select: [:i | ...]
- Bert -
Bert Freudenberg (13.03. 23:12):
nicht mogeln. Wie kriege ich mit einem Iterator die Einträge aus der Liste?
<klugscheiß>
catalog atAll: (firstIndex to: lastIndex)
</klugscheiß>
Aber nicht doch ... gibt's atAll: wirklich? Boah! Jahrelang übersehen!
Danke!
Das Tolle an der Smalltalk-"For-Schleife" ist, dass sie nur ein Iterator über Zahlenintervalle ist.
Das ist richtig. Entspricht aber "vom Gefühl her" genau der alten BASIC/C-For-Schleife, weil "nur" über Zahlen iteriert wird, und die gelten anscheinend nicht als Objekte. Sonst wäre Guido nicht so versessen drauf, sie nicht zum Abarbeiten von Collections herzunehmen.
Ich wollte eigentlich darauf hinaus, dass Schleifen zu bestimmten Gelegenheiten durchaus sinnvoll sein können, und bin jetzt eines (hilfreichen) Besseren belehrt worden :-)
s.
On Mar 13, 2007, at 23:24 , Stefan Schmiedl wrote:
Bert Freudenberg (13.03. 23:12):
nicht mogeln. Wie kriege ich mit einem Iterator die Einträge aus der Liste?
<klugscheiß>
catalog atAll: (firstIndex to: lastIndex)
</klugscheiß>
Aber nicht doch ... gibt's atAll: wirklich? Boah! Jahrelang übersehen!
Wenn es das nicht gäbe, müsste man's erfinden ;)
Das Tolle an der Smalltalk-"For-Schleife" ist, dass sie nur ein Iterator über Zahlenintervalle ist.
Das ist richtig. Entspricht aber "vom Gefühl her" genau der alten BASIC/C-For-Schleife, weil "nur" über Zahlen iteriert wird, und die gelten anscheinend nicht als Objekte. Sonst wäre Guido nicht so versessen drauf, sie nicht zum Abarbeiten von Collections herzunehmen.
Naja, da hat er ja im Prinzip auch recht. Allzu oft sehe ich eben die Zahlschleifen, mit denen die Leute per #at: und #at:put: in den Objekten rumfuhrwerken. Das machen besonders gern diejenigen, die sich über die fehlende Indizierungssyntax aufregen, "a[i]" sieht eben zugegebenermaßen nicht halb so schlimm aus wie "a at: i". Dass das aber sofort viel besser lesbar und weniger fehleranfällig wird, wenn man nicht händisch Indizes generiert sondern einfach über die Objekte iteriert, ist schwer in die verbildeten Köpfe zu bekommen.
Insofern wäre es schon gut, eben *nicht* mit den Zählschleifen anzufangen. Leider kenne ich aber kein Informatikbuch, in dem Algorithmen nicht mit mathematischer Indexnotation eingeführt werden. Beispiel Sortieren - vor lauter Indexakrobatik sieht man doch da nie und nimmer das Prinzip! Vergleiche mal einen Quicksort-Algorithmus aus irgendeinem Buch mit dem hier:
qsort self isEmpty ifFalse: [ ^(self select: [:each | each < self first]) qsort , {self first} , (self select: [:each | each > self first]) qsort]
Natürlich gibt es manche Probleme bei denen man Indizes braucht, aber das sind weniger als man denkt. Das eigentliche Problem ist auch nicht die Zählschleife an sich, sondern dass sie an jeder passenden und noch mehr unpassenden Stellen eingesetzt wird. Das kommt von den Büchern, aber auch von Sprachen, die nichts besseres unterstützen.
- Bert -
Bert Freudenberg (14.03. 00:07):
Aber nicht doch ... gibt's atAll: wirklich? Boah! Jahrelang übersehen!
Wenn es das nicht gäbe, müsste man's erfinden ;)
ob man das dann noch verstehen kann? :-D
Das eigentliche Problem ist auch nicht die Zählschleife an sich, sondern dass sie an jeder passenden und noch mehr unpassenden Stellen eingesetzt wird.
Damit sind wir beim Kern der Sache angelangt, denke ich. Es ist eine Frage des Urteilsvermögens und des Vorwissens des Programmierenden. Und die "totale Abschaffung" der Zählschleife ist da genau so verkehrt wie die generelle Anwendung derselben.
Je mehr Werkzeug man hat, um so größer ist die Wahrscheinlichkeit (sich nicht an das richtige erinnern zu können) ein wirklich passendes zu finden.
Gute Nacht, allerseits.
s.
Das Tolle an der Smalltalk-"For-Schleife" ist, dass sie nur ein Iterator überZahlenintervalle ist. So wie man über normale Sammlungen iteriert (mit #do:, #collect:, #select: etc.) kann man das auch mit Intervallen machen:
(1 to: 5) do: [:i | ...] (1 to: 5) collect: [:i | ...] (1 to: 5) select: [:i | ...]
Super, *das* hatte ich auch schon verstanden! :)
Ad \infty und pi, physikfrei, Guido: Dann schreib pi doch mal hin und erklär bitte, was das mit 'endlich' zu tun hat? Es soll schließlich nicht zu viel Farbe sein, aber auch nicht zu wenig. (Entschuldige, aber das konnte ich mir nicht verkneifen.)
Markus ----------------------------------------------- Markus Schlager m.slg(at)gmx.de
squeak-ev@lists.squeakfoundation.org
-
Bert Freudenberg -
Markus Schlager -
Stefan Schmiedl -
stepken