On Wed, Jun 11, 2003 at 11:36:35PM +0200, Daniel Vainsencher wrote:
> Hmm, informed discourse... ok, I'm tempted back.
>
> Beni Cherniavsky <[EMAIL PROTECTED]> wrote:
> > First-class functions are quite simple. Polymorphic classes - a bit
> > harder. Yet doing loops and conditionals with them *is* harder to
> > comprehend than::
> >
> > for i in [1, 2, 3]:
> > if i != 2:
> > print i
>
> I beg to differ. I'm sure the following won't seem that strange -
> #(1 2 3) do: [:i |
> (i ~= 2) ifTrue: [Transcript show: i]]
>
> Loops are messages to collections or numbers or blocks (anonymous
> functions - code between []s). Conditions are messages to booleans (the
> two of which, true and false, respond differently of course).
Still, you have a basic construct of a conditional. Please explain, in
play language, how does:
(i ~= 2) ifTrue: [Transcript show: i]]
Actually, this is implemented as:
There are two types of booleans: "true" and "false". When "true" gets
the message 'ifTrue' it runs whatever code comes with the message. When
false gets the message 'ifTrue' it does nothing.
For the message 'isFalse' the roles change. Now 'false' runs the code
and true does nothing. Generally you can't know in advance which of
the two you'll get.
This was an attempt to avoid the simple and standard explanation of
"conditional". I figure most students wouldn't have survived it. :-)
This abstraction is nice, but explaining it in class before people know
what loops, variables etc. are is not a good idea.
> Since
> loops aren't syntax, but constructed, you can extend the libraries with
> new constructs that you find yourself repeating. For example, if you
> know SQL, you can guess what this does:
> #(1 2 3 4 5 6) groupBy: [:num | num even]
>
> Never mind that the same code, implemented once, works on all kinds of
> collections, all kinds of stored objects, all keying functions - [:num |
> num rem: 2]
Oh, and now you have to start explaining what "equility" means for other
object types. And what exactly they *must* implement.
> would have a very simiar effect, despite returning objects
> of a different type).
Great. But how long would it take me to figure just what my program
does? This abstrction hides complexity, that makes debugging a less
pleasent experince.
Also, from what I reacall of SmallTalk, many of the non-trivial
introductory examples managed to achive a horrible complexity overhead
due to abstruction ("sure, an array can implement a dictionary. ;-)")
--
Tzafrir Cohen +---------------------------+
http://www.technion.ac.il/~tzafrir/ |vim is a mutt's best friend|
mailto:[EMAIL PROTECTED] +---------------------------+
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
