[Self-interest] UK Smalltalk User Group Meeting - Wednesday 24 November

Wed Nov 17 10:15:04 UTC 2021

Hi David,

If I may butt into the conversation, it seems my slightly provocative tag-line for Objective-S has accomplished it purpose of being provocative, although of course I was going more for provoking curiosity as to why someone would make such an obviously and preposterously absurd claim and thus click the more info link, rather than anger.

So I might have to change that tag-line or couch it in some mitigating language, it was a spur-of-the moment inspiration.

The claim is certainly not intended to make Objective-S seem more grandiose than it is, because it certainly is very, very far from being grandiose or even grand, nor is it intended to denigrate what came before.  If that is what comes across, then it not just fails to communicate, but actively miscommunicates.

Coming to the claim:  I do believe it is actually true, and I am still figuring out how to properly communicate the claim, my most recent public attempt was here:

	https://2020.programming-conference.org/details/salon-2020-papers/5/Can-Programmers-Escape-the-Gentle-Tyranny-of-call-return- <https://2020.programming-conference.org/details/salon-2020-papers/5/Can-Programmers-Escape-the-Gentle-Tyranny-of-call-return->

It was only marginally successful.  So apologies for making you yet another guinea pig for me trying to figure out how to communicate this idea.

The Problem: Architectural Mismatch
------

The crux is that all mainstream and virtually all non-mainstream languages aren’t really general purpose, though we obviously think of them and use them that way.  They are DSLs for the domain of algorithms, for computing answers based on some inputs.  Obviously with many variations, but the essence is the same.  a := f(x).   Or a := x.f().  Or  a: x f.  And the algorithmic mechanism we have for computing answers is also our primary linguistic mechanism for structuring our programs: the procedure/function/method.  (Objects/classes/prototypes/modules are secondary mechanisms).

(see also:  the ALGOrithmic Language, predecessor to most of what we have, and allegedly an improvement on much of that).  

As long as our problems were also primarily algorithmic, this was perfectly fine.  But they no longer are, they are shifting more and more away from being algorithmic.  

For example, if you look at how we program user interfaces today, there hasn’t really been much progress since the early 80s or 90s. Arguably things have actually taken huge leaps backwards in many areas. I found this very puzzling, and the common explanation of “kids these days” seemed a bit too facile.  The problem became a bit clearer when I discovered Stéphane Chatty’s wonderful, and slightly provocatively named paper "Programs = Data + Algorithms + Architecture: consequences for interactive software engineering".

	https://dl.ifip.org/db/conf/ehci/ehci2007/Chatty07.pdf <https://dl.ifip.org/db/conf/ehci/ehci2007/Chatty07.pdf>

He explains very well, and compellingly, how our programming languages are architecturally mismatched for writing GUIs.  

Once you see it, it becomes really hard to un-see, and this problem of algorithmic programming languages, or in the architectural vernacular I prefer, call/return programming languages pops up everywhere.

Or how Guy Steele put it:

"Another weakness of procedural and functional programming is that their viewpoint assumes a process by which "inputs" are transformed into "outputs"; there is equal concern for correctness and for termination (and proofs thereof). But as we have connected millions of computers to form the Internet and the World Wide Web, as we have caused large independent sets of state to interact–I am speaking of databases, automated sensors, mobile devices, and (most of all) people–in this highly interactive, distributed setting, the procedural and functional models have failed, another reason why objects have become the dominant model. Ongoing behavior, not completion, is now of primary interest."

OO: The "Better Old Thing"
------

So what about OO in general, and Smalltalk and Self in particular, surely we have done better, haven’t we?  Well yes, sort of.  Continuing with Guy Steele again:

"Indeed, object-oriented programming had its origins in efforts to simulate the ongoing behavior of interacting real-world entities–thus the programming language SIMULA was born. [..] 

Now, objects don't solve all the problems of programming. For example, they don't provide polymorphic type abstraction (that is, generic types). They don't provide syntactic abstraction (that is, macros). Procedural programming still has its place in the coding of methods. But to say that objects have failed because they don't solve all possible problems is like saying carbohydrates have failed because you can't live on pure sugar. Object-oriented programming is like money, as the old joke has it: It's not everything, but it's way ahead of whatever's in second place.”

And of course we all like to repeat Alan’s famous quip from OOPSLA ’97:  ""I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind.”  Of course he went on to say:  “I have many of the same feelings about Smalltalk”.  

I don’t know what Alan had in mind, but to me the core issue is the one in the middle of Guy Steele’s paragraph above:  "Procedural programming still has its place in the coding of methods.”  I would contend that “coding methods” is our primary coding task, so “has its place in” resolves to “is the majority of"  William R. Cook explained the centrality of procedural abstraction in great detail in "On Understanding Data Abstraction, Revisited”.

	https://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf <https://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf>

However, these methods that we primarily code and that are the core of our object-oriented abstraction inherited all the problems of procedural programming that Guy Steele pointed out above.  Which leads to the following problem, explained by Andrew Black:

What I’ve learned from watching this process is that the program’s runtime behaviour is a powerful teaching tool. This is obvious if you view programs as existing to control computers, but perhaps less obvious if you view programs as static descriptions of a system, like a set of mathematical equations. As Dahl and Nygaard discovered, it is a program’s behaviour, not the program itself, that models the real-world system. The program’s text is a meta-description of the program behaviour, and it is not always easy to infer the behaviour from the meta-description.

Experienced OO practitioners know this, of course, which is why we insist on immersive programming environments that let us interact with those actual objects that encode the program’s behavior.  And we pat ourselves on the back and look down on those unenlightened Java programmers who do class-oriented programming of dead code in their text editors and Just Don’t Get It™.  With some justification, yes, but to me it seems like our victory lap is a bit premature, because we haven’t actually solved the problem, we “just” have a good workaround.

This problem of the gap between the text and a program's run-time behavior is not new, it was remarked on quite some time ago:

My first remark is that, although the programmer's activity ends
when he has constructed a correct program, the process taking place
under control of his program is the true subject matter of his
activity, for it is this process that has to accomplish the
desired effect; it is this process that in its dynamic behavior
has to satisfy the desired specifications.

The follow-on problems caused by this problem are also spelled out:

My second remark is that our intellectual powers are rather
geared to master static relations and that our powers to
visualize processes evolving in time are relatively poorly
developed. For that reason we should do (as wise programmers
aware of our limitations) our utmost to shorten the conceptual
gap between the static program and the dynamic process, to make
the correspondence between the program (spread out in text space)
and the process (spread out in time) as trivial as possible

Yes, that’s Dijkstra’s “goto statement considered harmful”.  And I think his analysis is still spot on:  while it makes perfect sense to create tooling in order to get better insight into the running program, we should also strive to reduce the gap between the static program text and the dynamic process that unfolds.  We have done a lot of the former, and very little of the latter.

Shortening the Conceptual Gap
------

So in order to shorten this conceptual gap between static program text and executing program for domains other than algorithms, in order to avoid having to write procedural meta-descriptions that don’t reflect what goes on in the running program, we need new linguistic mechanisms that go beyond procedures. 

We obviously still want the tooling, but we should not need it quite so desperately to have a chance of understanding what’s going on.

So that’s what Objective-S tries to provide, new linguistic mechanisms that go beyond procedures.  And it does this by generalising from objects and messages to components and connectors.  More details in the talk.

Cheers,

Marcel

> On 17. Nov 2021, at 08:53, David Ungar <ungar at mac.com> wrote:
> 
> Thank you. What claim, exactly?
> 
>> On Nov 16, 2021, at 11:12 PM, Colin Sare-Soar <colin.saresoar at terrashape.co.uk> wrote:
>> 
>> After reading your comment and seeing the reactions from others, I felt compelled to look further into the subject.
>> I found the website interesting and thought others might want to see what his claim was based on and not dismiss it out of hand because of that statement.
>>> On 17/11/2021 13:23 David Ungar <ungar at mac.com> wrote:
>>> 
>>> 
>>> I must confess I lost trust and stopped reading after reading that his was the first general purpose programming language. Thank you for pointing out the elaboration on the other page, but what was your purpose?
>>> 
>>>> On Nov 16, 2021, at 9:57 PM, Colin Sare-Soar <colin.saresoar at terrashape.co.uk> wrote:
>>>> 
>>>> That quote is from the home page, he does elaborate on the term on the about page.
>>>>> On 17/11/2021 01:21 David Ungar <ungar at mac.com> wrote:
>>>>> 
>>>>> 
>>>>> I followed the link http://objective.st/ and read: "Objective-S is the first general purpose programming language." Were the others chopped liver?

Begin forwarded message:

> From: Tobias Pape <tobias at netshed.de>
> Subject: Re: [Self-interest] UK Smalltalk User Group Meeting - Wednesday 24 November
> Date: 17. November 2021 at 08:37:23 CET
> To: Marcel Weiher <marcel at metaobject.com>
> 
> Du findest das zeug alles hier:
> 	http://lists.selflanguage.org/pipermail/self-interest/2021-November/thread.html
> 
> Soviel hin und her war lange nicht :D
> 
> Gruß
> 	-tobias
> 
>> On 17. Nov 2021, at 07:31, Marcel Weiher <marcel at metaobject.com> wrote:
>> 
>> Gerne. :)
>> 
>> Danke!
>> 
>> Marcel
>> 
>> 
>>> On 16. Nov 2021, at 20:12, Tobias Pape <tobias at netshed.de> wrote:
>>> 
>>> falls du antworten willst, kann ich das für dich relayen.
>>> 
>>> GRuß
>>> 	-Tobias
>>> 
>>>> Begin forwarded message:
>>>> 
>>>> From: David Ungar <ungar at mac.com>
>>>> Subject: Re: [Self-interest] UK Smalltalk User Group Meeting - Wednesday 24	November
>>>> Date: 16. November 2021 at 19:21:20 CET
>>>> To: Giovanni Corriga <giovanni at corriga.net>, Self-interest <self-interest at lists.selflanguage.org>
>>>> Delivered-To: self-interest at mail.squeak.org
>>>> X-Mailer: Apple Mail (2.3693.40.0.1.52)
>>>> Envelope-To: <Das.Linux at gmx.de>
>>>> 
>>>> I followed the link http://objective.st/ and read: "Objective-S is the first general purpose programming language." Were the others chopped liver?
>> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.selflanguage.org/pipermail/self-interest/attachments/20211117/388566b4/attachment-0001.html>