Re: 'isa' keyword

phil hunt wrote: 
On Sat, 03 Sep 2005 00:45:19 -0500, Steve Holden <steve@xxxxxxxxxxxxx> wrote:

I'm not talking about a change in *paradigm* merely a change in *syntax*; this:

  receiver selector argument

would mean the same as the current Python:

  receiver.selector(argument)


Aah, I see. I had assumed that "selector" was always going to be an operator. 3 . (+ 4) does indeed seem very "SmallTalkative". I don't think that Python method (or attribute) selection bears any relationship to SmallTalk message-passing, but I hope you will feel free to enlighten me. 


Let's consider the Python example first.

You have two classes A and B. Each has a method called 'selector'.

When the line of code above is executed, the Python virtual machine decides whether (receiver) is a member of A or B, and then executed one of A.selector() or B.selector() depending on which it is. Whichever function is executed, it is passed with (reciever) as the "self" argument so that the correct data is operated on.

And now let's consider the Smalltalk example. How does it do it? Essentially it does *exactly the same thing*.

(Yes, I know there are many differneces in detail between how Snalltalk and Python work, but they are only *details*; the fundamental idea governing how these two object-oriented languages work is the same).

It's the differences we are talking about. All you have said above is that Python and SmallTalk both use late-binding to resolve names, allowing them to implement polymorphic behavior.


would necessarily benefit Python at this stage. Some people are still under the misapprehension that message-passing is a fundamental of object-oriented programming because of Smalltalk, but they are wrong.


I don't see how it can reasonably said that STK has "message-passing" but other OOPLs don't. Consider these code fragments:

Smalltalk:
  receiver selector: argument

C++ or Java:
  receiver.selector(argument);

Python:
  receiver.selector(argument)

PHP:
  $receiver->selector($argument)

(I'm not sure if the last one is right since I've not done much OO stuff in PHP)

These all mean essentially the same thing so how can one be "message passing" and the others not?

Sorry, they don't all mean "essentially the same thing" at all. It seems to me you are looking at SmallTalk in entirely too superficial a light.


OK, allow me to reprase it. Imagine a language ith the semantics of Python but the syntax of C++ or PHP or Smalltalk (or Lisp for that matter). It would still basically be Python, wouldn't it?

I'm not sure I understand this. You appear to be saying, in essence, "they are all programming languages, so despite the fact that they work slightly differently the similarity is we can write programs in them all".


In SmallTalk, control structures aren't syntactic primitives, they are also examples of message-passing, so code blocks are sent as messages to objects. Python eschews such obscurity and (IMHO) gains clarity by so doing. But that is, of course, a matter of opinion.


I agree, that's a major point of departure between Python and Smalltalk.

Right, but it's precisely SmallTalk's message-passing techniques that allow this to work. Of course Python can create code blocks with compiler.compile(), but this is not mainstream, and Python has so many more-useful mechanisms to implement program control that using code objects as data is correctly regarded as being ion the boundaries of language voodoo.


Also, remember that just because two expressions in different languages "mean the same thing "doesn't mean they are implemented using the same techniques.


Of course not.

CPython and JPython are different implementations, but they are still the same language (mostly).

That we can agree on. But both differ substantially from SmallTalk.

I would contend (if backed into a corner) that there is a significant difference between passing the arguments 3 and 4 to a "+" operator (which is what Python and most other languages implementing standard ideas of operator precedence do) and sending the message "+ 4" to the integer 3 (which is effectively what SmallTalk does).


In both python and smalltalk you can override the operator to mean what you want, so I disagree that there is any fundamental difference. Why do you think there is?

Because in Python the interpreter has hard-wired code associated with each operator. This code examines the left- and right-hand operands, calling various methods on them if they exist.

In SmallTalk the operator is the first element of a message sent to the left-hand operand, and if the object (or one of its superclasses) has no method corresponding with the operator then a "don't understand operator" exception is raised.

In other words, the differences aren't purely syntactic.

Of course, I realise that you can argue that the two are equivalent in the sense that they perform the same computation. But SmallTalk's choice led to the loss of operator precedence, which is something that is pretty fundamental to mathematics.


Surely that's a separate issue, one purely of syntax. Imagine two languages:

   (* (+ a b) c)

and:

   (a + b) * c

These both mean the same thing, they just say it differently.

Of course the point of Reverse Polish notation is precisely to avoid the need for parentheses, but we'll overlook that. I've tried to explain that SmallTalk expressions don;t have precedence because there is no way in the language to implement operator precedence, and that's because of the underlying message-passing paradigm of the SmallTalk virtual machine.

Also Python allows much more flexibility by hard-wiring operators and allowing alternatives to be considered (if the left operand doesn't have an "__add__" method then try to use the right operand's "__radd__" method). SmallTalk doesn't have any parallel to this that I can think of. 


You're right; in Smalltalk you'd have to code that functionality in
the method for the left-hand object.

Correct!

Of course it isn't only mathematicians who are taught to us the precedence rules, so I contend that SmallTalk would seem counter-intuitive in a "Programming for Everyone" context as well.


Probably.

However consider that a language (e.g. C++) may have lots of operators, e.g: & && | || << >> <= >= < > ^ % etc. Is there an obvious natural order of precedence for all these? I suspect that many C++ programmers couldn't put all its operators in the correect order.

Indeed, and that's why the use of explicit parentheses is a good defensive technique. But your average consumer of CP4E is going to be confused if the try to print 3 + 4 * 5 and get 35 instead of 23. Unless arithmetic teaching has changed so radically since my schooling that people don't understand BODMAS (Brackets, Of, Division, Multiplication, Addition, Subtraction) or the various other acronyms used to teach basic precedence.

I speak as one who was partly, and in a minor way, responsible for implementing the SmallTalk system on the Perq architecture back in the 1980's. 


What's Perq?

It was an early workstation built by the Three Rivers company. Bit-mapped graphics, many of the characteristics of the Xerox Dorado, but at a price researchers could afford. Its original operating system had many similarities with Mac OS9 (no pre-emptive scheduling!), but in the UK ICL produced a UNIX port called Pnix for it, and it was used by many projects funded by the Science Research Council.

The Burroughs disk drive was infamous because the drive belt (this 30MB drive was around 2 feet in diameter ...) would periodically slip off the motor, and you'd have to open up the cabinet to reposition it.

The Perq eventually became so despised by the computer science community in the UK, despite its advanced design, for the trouble it caused - the problem above was only one of its many unreliabilities, that after I left Manchester University and went to work for Sun Microsystems the Comp Sci department invited me back to play the John Cleese role in a sketch that began "I would like to complain about this Perq, what I purchased from this very Research Council not half an hour ago," and ended up with me smashing the machine with a mallet, and remarking "Now that's what I call a dead Perq". You can imagine the rest.


(Mario Wolczko did the real work). So it's not that I've just looked at SmallTalk and find it odd. It's just that it treats expressions in a way which ultimately appear to seem counter-intuitive in contexts like arithmetic expressions.


I personally didn't find it odd, it felt quite natural to me.

Maybe it's you that's odd, then. Or me :-) But you've convinced me you know enough about SmallTalk to understand that there are indeed some significant differences between it and Python.

regards
 Steve
--
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC             http://www.holdenweb.com/

.

Relevant Pages

  • Re: New to Python: Features
    ... > Python is not a functional programming language. ... but it import the same way "import" does in Python. ... Smalltalk has no static typing either. ... I gave a goddamn code example, grief. ...
    (comp.lang.python)
  • Re: Writing a simple assembler
    ... type (Python, Smalltalk, whatever). ... OOP would be a good idea for such a task. ... and can be a useful language - but not for a task such as this. ... There are plenty of other options that may or may not be good fits - I don't know them well enough (such as Java, Smalltalk, OCAML, Ruby). ...
    (comp.arch.embedded)
  • Re: Three wishes of a wannabe developer
    ... systems programming language like C, or a glue language like Perl. ... it's a long time since I've used Smalltalk. ... into Ruby, ... other custom mix of Python building blocks. ...
    (freebsd-questions)
  • re: loose methods: Smalltalk asPython
    ... strong design goal of Python. ... not to enhance OOP to the detriment of other, more important goals. ... the language definition is there. ... that Smalltalk and Ruby do this at least suggests that it won't ...
    (comp.lang.python)
  • Re: isa keyword
    ... >> receiver selector argument ... >think that Python method selection bears any relationship ... And now let's consider the Smalltalk example. ... remember that just because two expressions in different languages ...
    (comp.lang.python)