Hello Trygve

I think you have written an excellent summary about the challenge
presented by object-oriented programming.

GOF book on Design Patterns

    …, it's clear that code won't reveal everything about how a system
will work. [ibid.p.23]

And the development of Pharo and Squeak the last 10..15 years
exemplifies  that this is indeed still a challenge though there are
some examples and ideas how to cope with it.

So is this a case for promoting DCI and related tools (which by itself
goes back 10 years)?

--Hannes

On 5/10/18, Trygve Reenskaug <trygver at ifi.uio.no> wrote:
> At 87, I'm an old man. I'm told that I don't understand modern software,
> which is true. I use some programs daily: WIN7, Pharo, Thunderbird, ...
>  From time to time, I am told that a new version of the program that
> fixes bugs and improves security is available. Press the button to
> install it.  So I wonder: Is modern software out of control? Does
> /anybody /understand it, or is it so complicated that it is beyond human
> comprehension? Why didn't they get it right the first time? Most of us
> have the GOF book on Design Patterns on our bookshelf.  In the
> introduction, they write:
>
>     /An object-oriented program's runtime structure often bears little
>     resemblance to its code structure. The code structure is frozen at
>     compile-time; it consists of classes in fixed inheritance
>     relationships. The runtime structure consists of rapidly changing
>     networks of communicating objects.[GOF-95] p. 22./
>
>   and
>
>     /…, it's clear that code won't reveal everything about how a system
>     will work. [ibid.p.23]/
>
> Modern programmers are thus reduced to relying on testing the code. In
> the words of Edsger Dijstra:
>
>     /"Program testing can be used to show the presence of bugs, but
>     never to show their absence!"[REF] /
>
> Modern programmers know all this but accept it as an unavoidable part of
> progress. Some may have seen it as a challenge, but they are up against
> the enormous inertia of a community who haven't changed their
> fundamental model of programming since the advent of the von Neumann
> stored program computer in 1948.
>
> I can't resist another quote; this time from Tony Hoare's TuringAward
> lecture:
>
>     /“There are two ways of constructing a software design: One way is
>     to make it so simple that there are obviously no deficiencies and
>     the other is to make it so complicated that there are no obvious
>     deficiencies. The first method is far more difficult. …[Hoare-81]/
>
> In the lecture, Hoare was bemoaning his unsuccessful fight for
> simplicity. Developers, particularly committees  of developers, seem to
> love complexity for its own sake. I have never accepted that bugs are an
> unavoidable part of software.(See "2.    Get it Right the First Time"
> in the draft article). Bugs are parts of the facts of life but they are
> not an acceptable part of it. Ideally, my software should be /so simple
> that there are obviously no deficiencies. /One of my attempts at coming
> to grips with the problem is the DCI programming paradigm. Here, /the
> runtime structure of rapidly changing networks of communicating objects/
> is specified in explicit code that says (almost) everything about what
> happens at runtime. Wouldn't it be wonderful if Pharo were to become
> first to overcome the GOF limitation? I challenge you to play with
> BabyIDE on Squeak  and become convinced that it is a step in the right
> direction.
>
> I won't reread this message before I  send it. I suppose it's
> controversial and should probably delete some or all of it to avoid
> angry answers. Another reason why I probably shouldn't send it is that I
> do not have time to engage in a discussion. I /must /give priority to
> finishing my article on DCI and PP. (A ~50 page draft is on my home
> page; it will be updated from time to time)
>
> I press the SEND button with a shaking hand
> --Trygve
>
>
>
> On 09.05.2018 15:53, Richard O'Keefe wrote:
>> ​I have a C++ program written in the late 80s by someone
>> else.  It used to run fine under cfront 2.0 and early g++.
>> Ten years after it was written it was impossible to compile.
>>
>> *Since* that there have been changes to streams and strings,
>> amongst other things.
>>
>> The 1989 C standard changed the semantics of mixed signed/unsigned
>> integer arithmetic.  It also inadvertently rendered illegal a
>> widely used technique.  It is notoriously the case these days
>> that compilers taking the C standards literally have "broken"
>> quite a lot of code that worked with less ambitious compilers.
>> I have been watching this phenomenon with considerable
>> nervousness.  See for example
>> http://www.eng.utah.edu/~cs5785/slides-f10/Dangerous+Optimizations.pdf
>> <http://www.eng.utah.edu/%7Ecs5785/slides-f10/Dangerous+Optimizations.pdf>
>>
>> I have certainly had previously acceptable C89 code be rejected
>> by compilers as not being legal C11.  It is true that compilers
>> tend to have command line/IDE switches to ask that old code be
>> compiled under old rules, but you cannot say that *in* the program.
>> There is no way to mark the language version, no
>>     #pragma stdc version iso99
>>
>>
>>
>> As for Java, I could rant about the floods of deprecation warnings
>> from old code.  I shall content myself with one observation.
>> Read http://java-performance.info/changes-to-string-java-1-7-0_06/
>> Before Java 1.7, the substring operation in Java took O(1) time
>> and space.  From Java 1.7 on, it takes time and space linear in the
>> size of the result.  The syntax and abstract semantics did not
>> change but the pragmatics did.  Code that had adequate performance
>> could suddenly start crawling.
>>
>> Oracle do a tolerably thorough job of describing compatibility
>> issues between JDK releases.  See for example
>> http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html#A999198
>> where we learned that the 'apt' tool was gone, the JDBC-ODBC bridge
>> was gone, 32-bit Solaris support (and yes, I was still using 32-bit
>> code in SPARC Solaris and Intel Solaris) was gone, and the type
>> inference algorithm had changed in a way that could break things.
>> I am still somewhat peeved about some of the rewriting I've had to
>> do over the last several releases.
>>
>> Then there is the simple fact that porting code from one release of
>> an OS to another can be a pain.  Solaris 10 to OpenSolaris was easy.
>> OpenSolaris to Solaris 11 was not as painless.  Solaris 11 to
>> OpenIndiana was not a happy time for me.  OpenBSD changes forced
>> rework.  I'd finally got my program to port smoothly between Solaris,
>> Darwin, and Linux.  And then I had trouble porting to the next major
>> release of Linux.  And with Ubuntu 17, I've got another problem I
>> still haven't tracked down.  All of this in a C program that gets
>> regularly (sp)linted and checked all sorts of ways, written with
>> the intention of producing portable code.
>>
>> EVERYTHING BREAKS.
>>
>>
>> On 7 May 2018 at 22:42, Trygve Reenskaug <trygver at ifi.uio.no
>> <mailto:trygver at ifi.uio.no>> wrote:
>>
>>     Please tell me when Java, C, C++, etc programs stopped working
>>     because their runtime systems had changed.
>>     Please tell me when Java, C, C++, etc compilers stopped compiling
>>     old code because the languages had changed.
>>
>>
>>     On 07.05.2018 11:57, Norbert Hartl wrote:
>>>     I understand what you are saying but it contains some
>>>     misconceptions about the modern software world.
>>>
>>>     „The earth is not stopping to turn just because you want to stay
>>>     on the sunny side“
>>>
>>>     There is two funny concepts going on in the modern software
>>>     industry. The one tells you that because you want to do a product
>>>     everything else around you should come to a full stop so can
>>>     comfortably build your software not disturbed by other things.
>>>     The second one tells you that you _have to upgrade_ … there is
>>>     this magical force preventing you from staying where you are.
>>>     Both notions are funny alone but they come combined and then they
>>>     turn out to be a non-sensical monster.
>>>
>>>     Let’s take a different approach. Put in everything you say about
>>>     software, libraries, etc the word version. So you can build upon
>>>     Pharo version 3 your own product. You can stay at that version
>>>     and it won’t change. If the software you sell is not 80% pharo
>>>     but your own you should not have a problem just to stay on that
>>>     version because you develop your own stuff. But still the world
>>>     did not stop turning and there is pharo 4. You decide there are a
>>>     few nice features but the work to adjust is too big to take the
>>>     risk. Then there is pharo 5 and you … nahhh not this time….Then
>>>     there is pharo6 and they not only changed the image but also the
>>>     way source code is managed. That prevents you further from
>>>     adjusting. But hey you can still be happy with pharo3 and it does
>>>     not change.
>>>
>>>     So what is the real problem? Yes, money/time is not enough. I
>>>     think there are a lot of people risking their health to promote
>>>     pharo and now we have a consortium that can pay engineers to do
>>>     work on pharo. So let me tell you a future story:
>>>
>>>     You see what pharo is doing and you think it is good. You can
>>>     also see that there are too less resources to proceed in the way
>>>     you need it to go. So you decide to show pharo to the world
>>>     inspiring people with some kind of a vision. The result is that
>>>     more people pay into the consortium and we hire more engineers.
>>>     And then one day the consortium has enough money to pay engineers
>>>     that can care about a LTS (long term support) version of pharo.
>>>     So you can stay on pharo version 3 and still get those annoying
>>>     bugs fixed. And hey this team has also enough time to provide you
>>>     with tools that make a migration to pharo version 4 more easy and
>>>     less annoying for you. And then you have your own product based
>>>     on pharo version 4. And then for version 5, version 6,…. Sounds
>>>     like a dream…but hey…it is indeed realistic. It just depends on
>>>     how the people approach it
>>>
>>>     How does this sound?
>>>
>>>     Norbert
>>>
>>>>     Am 07.05.2018 um 11:31 schrieb Trygve Reenskaug
>>>>     <trygver at ifi.uio.no <mailto:trygver at ifi.uio.no>>:
>>>>
>>>>     Thanks for your quick answer.  I have only a fleeting knowledge
>>>>     of Pharo but liked what I saw. The Squeak class library has seen
>>>>     organic growth since 1978 or earlier. Pharo gave it a thorough
>>>>     overhaul. At the Pharo kernel was a minimal image with a minimal
>>>>     class library. The rest of the functionality was partitioned
>>>>     into packages that could be added to the kernel image as
>>>>     required. Beautiful. But only my dream?
>>>>
>>>>         /Matthew 7:24-27: And the rain fell, and the floods came,
>>>>         and the winds blew and beat on that house, but it did not
>>>>         fall, because it had been founded on the rock. And everyone
>>>>         who hears these words of mine and does not do them will be
>>>>         like a foolish man who built his house on the sand."/
>>>>
>>>>     I am developing an IDE for non-programmers called BabyIDE, a
>>>>     non-intrusive extension of Squeak. Where the Class Browser in
>>>>     Squeak is used to work with one class at the time, the BabyIDE
>>>>     browser is used to work with structures of collaborating
>>>>     objects, ignoring their classes. I would like to develop a
>>>>     BabyIDE image that gets broad usage and long life. I'm looking
>>>>     for a rock to build on and hoped it could be what I thought was
>>>>     the Pharo kernel+ a few selected packages. In your answer, I
>>>>     read that if I build BabyIDE on Pharo, I will be building on sand.
>>>>
>>>>     pharo.org <http://pharo.org/>writes: "/Pharo is a pure
>>>>     object-oriented programming language.../". The only language I
>>>>     can see is defined by the release image. A Pharo programmer
>>>>     builds application programs in this language. He or she can add
>>>>     new classes, change existing ones, subclass them, add or change
>>>>     methods, change the Smalltalk dictionary, etc. etc.  An
>>>>     extremely flexible and powerful language.
>>>>
>>>>     A tale from the future when Pharo is a mainstream
>>>>     language:Business customers benefit from end users using
>>>>     applications that are written by Pharo programmers who built on
>>>>     the Pharo language and environment that had been developed by
>>>>     the Pharo community. One day there is a happy announcement: A
>>>>     new version of Pharo will be launched tomorrow. It is truly cool
>>>>     and includes any number of improvements, some of them
>>>>     documented. And, by the way, applications written in the current
>>>>     Pharo will no longer work. So please inform your customers that
>>>>     you will not be able to serve them for a while. We are confident
>>>>     that all your application programmers will be happy to drop
>>>>     whatever they are doing in order to adapt their applications to
>>>>     the new Pharo so that you can start serving your customers again.
>>>>
>>>>     Cheers
>>>>     --Trygve
>>>>
>>>>
>>>>
>>>>     On 06.05.2018 13:00, Norbert Hartl wrote:
>>>>>     Can you elaborate on what you consider as a kernel? There are
>>>>>     always things moving in the pharo world. The last years the
>>>>>     virtual machine got some iterations and it is still not fully
>>>>>     stable. For pharo it is hard to have it stable because we feel
>>>>>     the need that a lot of the existing parts need to be replaced
>>>>>     to be useful in these times. Furthermore pharo is also
>>>>>     prototyping platform for programming language features. All of
>>>>>     these are counter-stability measures. So if you need a stable
>>>>>     kernel from native ground up to UI pharo won‘t be that thing
>>>>>     you are looking for the coming years (if at all). You always
>>>>>     need to adopt to change so you need to define your required
>>>>>     scope better in order to get an estimate.
>>>>>
>>>>>     Norbert
>>>>>
>>>>>     Am 06.05.2018 um 11:31 schrieb Trygve Reenskaug
>>>>>     <trygver at ifi.uio.no <mailto:trygver at ifi.uio.no>>:
>>>>>
>>>>>>     I'm working on a programing paradigm and IDE for the personal
>>>>>>     programmer who wants to control his or her IoT. The size of
>>>>>>     the target audience I have in mind is >100 million. I gave up
>>>>>>     Squeak long ago as a platform because they obsolete my code
>>>>>>     faster than I can write it.  I have now frozen Squeak 3.10.2
>>>>>>     and hope its runtime will survive until I find a better
>>>>>>     foundation. My hope is that Pharo has a stable kernel that I
>>>>>>     can build on.  According to Stephan, this is not so. Is there
>>>>>>     any plan for creating a stable Pharo kernel that people can
>>>>>>     use for building software of lasting value for millions of
>>>>>>     non-expert users?
>>>>>>     --Thanks, Trygve
>>>>>>
>>>>>>     On 05.05.2018 13:53, Stephan Eggermont wrote:
>>>>>>>     I’ve taken a look at what would be needed to
>>>>>>>     support magma on pharo a few years ago. Chris always told us he
>>>>>>> uses it
>>>>>>>     professionally on squeak and/*has not enough capacity to keep up
>>>>>>> with changes in pharo
>>>>>>>     without having a customer/maintainer for it.*/  Twice a year
>>>>>>>     or so someone asks about magma on pharo and takes a look. AFAIK
>>>>>>> there are
>>>>>>>     no real obstacles to a port, but magma uses a lot of deep
>>>>>>> implementation
>>>>>>>     specifics that will take an experienced smalltalker to deal with,
>>>>>>> and a lot
>>>>>>>     of mailing list archeology as pharo changed a lot since magma
>>>>>>> worked on
>>>>>>>     pharo last
>>>>>>>
>>>>>>>     Stephan
>>>>>>
>>>>>>     --
>>>>>>     /The essence of object orientation is that
>>>>>>     objectscollaboratetoachieve a goal./
>>>>>>     TrygveReenskaug mailto: trygver at ifi.uio.no
>>>>>>     <mailto:%20trygver at ifi.uio.no>
>>>>>>     Morgedalsvn. 5A http://folk.uio.no/trygver/
>>>>>>     <http://folk.uio.no/trygver/>
>>>>>>     N-0378 Oslo http://fullOO.info <http://fulloo.info/>
>>>>>>     Norway Tel: (+47) 22 49 57 27
>>>>
>>>>     --
>>>>     /The essence of object orientation is that
>>>>     objectscollaboratetoachieve a goal./
>>>>     TrygveReenskaug mailto: trygver at ifi.uio.no
>>>>     <mailto:%20trygver at ifi.uio.no>
>>>>     Morgedalsvn. 5A http://folk.uio.no/trygver/
>>>>     <http://folk.uio.no/trygver/>
>>>>     N-0378 Oslo http://fullOO.info <http://fulloo.info/>
>>>>     Norway Tel: (+47) 22 49 57 27
>>>
>>
>>     --
>>
>>     /The essence of object orientation is that objects collaborateto
>>     achieve a goal. /
>>     Trygve Reenskaug mailto: trygver at ifi.uio.no
>>     <mailto:%20trygver at ifi.uio.no>
>>     Morgedalsvn. 5A http://folk.uio.no/trygver/
>>     <http://folk.uio.no/trygver/>
>>     N-0378 Oslo http://fullOO.info <http://fullOO.info>
>>     Norway Tel: (+47) 22 49 57 27
>>
>>
>
> --
>
> /The essence of object orientation is that objects collaborateto achieve
> a goal. /
> Trygve Reenskaug mailto: trygver at ifi.uio.no <mailto:%20trygver at ifi.uio.no>
> Morgedalsvn. 5A http://folk.uio.no/trygver/
> N-0378 Oslo http://fullOO.info
> Norway                     Tel: (+47) 22 49 57 27
>
>