Hi Tzafrir 8-)
Tzafrir Cohen <[EMAIL PROTECTED]> wrote:
> (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. :-)
For people that already think of conditionals as sugar for a conditional
jump, thinking of it another way might seem complex. For most that have
no idea what conditionals are, the analogy to people is clear - "If
you're Tzafrir Cohen, please do this: ..." you and I would react
differently.
> This abstraction is nice, but explaining it in class before people know
> what loops, variables etc. are is not a good idea.
You're entitled to your opinion. But you do realize this means no more
rides back to TA, right? ;-)
[groupBy: example of extension]
> Oh, and now you have to start explaining what "equility" means for other
> object types. And what exactly they *must* implement.
Don't confuse my message - I didn't say that example is a good newbie
exercise. It shows the way advanced programmers can have powerful
results without needing more language concepts than we used to use
loops.
Furthermore, the topics you mention are essential to the problem - they
would exist in any implementation, in any language. What you're ignoring
is the fact that I was able to *explain only essentials*, and nothing
that is arbitrary technology required to work around language
weaknesses. Would this code be simpler with C++ Templates? maybe with
Java Generics? Can it even be done in Pascal? (I know it couldn't with
TP7.0, but things may have changed).
> > 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.
I didn't understand how using abstraction to hide complexity makes
debugging less pleasent, but I can tell you that it makes it far rarer -
you implement something once, and if it is right, it works. This is
better than hand coding the algorithms and data structures every time
you decide to apply an old idea to a new data type.
> 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. ;-)")
"Horrible complexity overhead" is very vague. Can you clarify this
point? anyway, having programmed in C, C++, Java and Smalltalk, I can
assure you it is quite delightful to write, very easy to read, and quite
efficient enough. But I'd have to have a specific example to address
your concerns more precisely.
Daniel
=================================================================
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]
