Messaging vs. subroutines (Re: Thinking about a better UI)

agree at carltonfields.com agree at carltonfields.com
Tue May 18 14:57:04 UTC 1999


Joachim writes:

> BTW is protest my terminology being called "argot". I'm well > within the bounds of standard OO nomenclature (even if it doesn't agree with
> Smalltalk nomenclature). The Smalltalk community doesn't have a monopoly
> on OO conepts, even though many in it seem to regret that.

As I noted earlier, this "debate" has devolved into mere wordplay.  Accordingly, I am not inclined to take it much further.  My use of the phrase "argot" was to point out precisely that we were arguing only about nomenclature -- Joachim has already admitted and acknowledged that there are differences and different concepts exist, though he hasn't detailed what he felt were those differences.

Joachim announces the correctness of his result by mere assertion.  In fact, terminology in this discussion has shifted meaning several times throughout this thread, beginning with the assertion that Smalltalk messages are "just procedure calls," albeit acknowledging differences and different concepts were used.  It was suggested that this isn't a terribly meaningful statement without more, and examples were given of ways in which methods performed things that, apart from the Turing sense, are not ordinarily done in imperative languages such as C.

Put simply, I am not sure why Joachim's statement isn't true of EVERY programming construct and paradigm, since all computable programs can be implemented by appropriate procedure calls.  As he waves his hands with his procedure call PLUS a selection process definition, I am inclined to think that he has made a statement that really doesn't amount to much.  Either its true of everything ("Control structures are just procedure calls, after all, why do they need to introduce new terminology"  "Structures are, after all just DDEFS, why do we need to introduce new terminology") or its only true in the sense of Turing equivalence (each can be implemented in the other).

Thereafter, Joachim announced that he was using the term procedure call quite broadly, but never defined what he meant.  In response to examples, he finessed particular examples (#ifThen:, plural dispatch, obscure uses of message sends such as that which was used in Dan's way cool progress bar), either by ignoring the example, making simple assertions, or by expanding and extending "just a procedure" call to incorporate more and more functionality.  Ultimately, he acknowledges that coroutines are not subroutines, but he didn't see how Squeak supported a coroutine-like facility.

Joachim insists that *his* view of what is "OO concepts" controls.  In this regard, he is mistaken.  Joachim does not seem to apprehend that Smalltalk, in many ways *defined*, and certainly inspired modern OO.  But whatever words he chooses to call these concepts, his naming of them does not make them different from what they are.  Nor will it assist him in communicating with those who call it something else.  It has been explained to him, and he has admitted, that there *are* different concepts here, and it has been suggested that thinking in terms of those different concepts helps in coding.  He remains steadfast in his assertion.

We simply cannot be sure what he means by the words he has used, because he has not defined them upon request or answered specifically the objections that have been interposed.  It appears to those of us who disagree with him that he is using these words in either an unusual (obscure or overbroad definition) or trivial (meaning only Turing-equivalents) sense, but we do not know because he has not told us.  Since he hasn't defined his meanings, his assertions remain nonfalsifiable.  For example, the simple question was posed to explain without equivocation purely from the semantics of procedures, how the definition of "messages" as "plain old functions with a selection process" explains why the following:

	ifTrueOne(self, block) {return block()}

	ifTrueTwo(self, block) {nil}

adequately specifies an if-then statement.  In Smalltalk, that "procedure selection process" imparts an important semantic meaning, which even granting a definition of procedure in the Algol (functions as first-class parameterizable objects), does not adequately account for.  This is what makes possible, without having to think outside the box, things like plural dispatch and Dan's clever progress bar -- because Smalltalk gives programmers a bigger box in which to think!  Joachim wants me to think inside the smaller box, using occasional brilliancies and detailed hacks to make procedures do what I mean, and I dissent.  

As noted earlier, when Joachim is free to hand-wave the "selection process," he can specify anything, including noncomputable functions as mere function calls.  After all, the halting problem for a given program is solved by the function pair

	haltsOne(program, data) {return true}

	haltsTwo(program, data) {return false}

with an "appropriate procedure selection process."  As with all simple definitions, the devil (or oracle) is in the details.  It is that flexibility that suggests to me that he is using these words in a sense different from the ordinary argot -- I'm still quite sure that the halting problem remains undecidable, even in an imperative OO language, notwithstanding the "power of procedures."





More information about the Squeak-dev mailing list