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
