Trygve, Thank you for pressing the SEND button with a shaking hand. I am inspired by your words. But I am only 22 years younger than you, and I hope that others are reading and appreciating what you have to say.
Dave On Thu, May 10, 2018 at 12:02:44PM +0200, Trygve Reenskaug 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 <tryg...@ifi.uio.no > ><mailto:tryg...@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 > >>> <tryg...@ifi.uio.no <mailto:tryg...@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 > >>>> <tryg...@ifi.uio.no <mailto:tryg...@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: tryg...@ifi.uio.no > >>>>> <mailto:%20tryg...@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: tryg...@ifi.uio.no > >>> <mailto:%20tryg...@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: tryg...@ifi.uio.no > > <mailto:%20tryg...@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: tryg...@ifi.uio.no <mailto:%20tryg...@ifi.uio.no> > Morgedalsvn. 5A http://folk.uio.no/trygver/ > N-0378 Oslo http://fullOO.info > Norway??????????????????????????????????????????Tel: (+47) 22 49 57 27 >
