[Pharo-users] Personal Programming onPharo

[Trygve Reenskaug]

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 objects collaborateto achieve 
a goal. /

Trygve Reenskaug mailto: tryg...@ifi.uio.no 
Morgedalsvn. 5A http://folk.uio.no/trygver/
N-0378 Oslo http://fullOO.info
Norway Tel: (+47) 22 49 57 27

Re: [Pharo-users] Personal Programming

[Marcus Denker]

Looks very interesting! I will read it (it arrives just in time to be part of 
the holiday reading pile…)

Marcus

> On 25 Jul 2019, at 11:29, Trygve  wrote:
> 
> Dear all,
> The final draft of my magnum opus about Personal Programming is now ready for 
> review:
> http://folk.uio.no/trygver/themes/Personal/PP-019%20-%20Copy%20(17).pdf 
> 
> 
> The article's main theme is Personal Programming for everybody with Loke, a 
> personal object computer. Its first purpose is to empower laypeople to take 
> control over their corner of the Net with its IoT. I have created a 
> proof-of-concept implementation as a non-intrusive extension of Squeak 
> version 3.10.2, and have used it to demonstrate how a novice uses the Loke 
> IDE to create a small and intuitive program.
> 
> The article describes the concepts behind Loke .The current Squeak 
> implementation should be ported to Pharo and can grow into the preferred 
> Pharo-based IDE for laypeople taking control over their information 
> environment. 
> 
> I will appreciate your possible comments before Aug. 31.
> Enjoy
> --Trygve
> 
> The article's 43 pages has several high points, I have included one of them 
> here:
> --- begin extract --
> C.7.We need a paradigm shift 
> 
> The history of Western astronomy shows a series of paradigm shifts from the 
> geocentric paradigm with its stationary Earth as the center of the Universe 
> with its epicycles and other bizarre explanations of what appeared to be 
> essential complexities. Astronomy evolved via the heliocentric to the current 
> distributed paradigm with its chunks of mass connected by gravity. What 
> appeared as essential complexity in one paradigm was easily resolved in the 
> next. 
> 
> It is tempting to look for similar paradigm shifts in computing. Mainstream 
> programming has based much of its theory and practice on the CPU-centric 
> paradigm exemplified by the von Neumann machine. A memory-centric paradigm 
> came in 1960 with the Autokon CAC/ CAM system and its central database 
> (Reenskaug, 1973). The solution was obvious, and there must have been many 
> similar initiatives without me being aware of them. 
> 
> It is time to realize that the first two paradigms do not meet our current 
> challenges: We are plagued with immensely large, complex, and insecure 
> systems that long ago left the realm of human understanding. A recent 
> example: Customers found that their bank charged them twice for the same 
> transaction. Several weeks after the problem was discovered, the bank 
> publicly admitted that they still didn't understand how the problem could 
> arise: The complexity of their system was clearly beyond human comprehension. 
> The bank has a staff of very competent experts, but they need a better 
> foundation for modeling and implementing their sophisticated requirements. 
> 
> Computers can transform, store, and communicate data, (Figure below). The 
> essence of the CPU-centric paradigm is that computers are primarily used to 
> transform data; they compute. The essence of the memory-centric paradigm is 
> that computers are used primarily to store data; they organize applications 
> around a shared database. The essence of the communication-centric paradigm 
> is that computers are primarily used to exchange messages with other 
> computers to make them collaborate to achieve a common goal. 
> 
> The three paradigms of computing 
> 
> It is time to heed Tony Hoare's plea for simplicity and achieve a better way 
> of separating concerns. Mainstream programming should shift to the 
> communication-centric paradigm exemplified by the object computer that is the 
> foundation for this article. 
> 
> The communication-centric paradigm has been on the horizon for many years. I 
> first met it in Prokon's idea of distributed computers (Reenskaug, 1977), but 
> there must have been many other initiatives. A newer example is 
> Service-Oriented Architectures (SOA) that, in essence, is 
> communication-centric. It didn't meet with immediate success, possibly 
> because people tried to apply it within the CPU-centric paradigm where it 
> doesn't belong. There are many other examples such as distributed computing. 
> And of course, DCI and the IoT itself are, by definition, 
> communication-centric.
> 
> --- end extract --
> 
> 
> 

Re: [Pharo-users] Personal Programming

[Cédrick Béler]

Me too !

And on the huge esug discussion points to have ^^

Cheers,

Cedrick 


> Le 25 juil. 2019 à 13:09, Marcus Denker  a écrit :
> 
> Looks very interesting! I will read it (it arrives just in time to be part of 
> the holiday reading pile…)
> 
>   Marcus
> 
>> On 25 Jul 2019, at 11:29, Trygve  wrote:
>> 
>> Dear all,
>> The final draft of my magnum opus about Personal Programming is now ready 
>> for review:
>> http://folk.uio.no/trygver/themes/Personal/PP-019%20-%20Copy%20(17).pdf
>> 
>> The article's main theme is Personal Programming for everybody with Loke, a 
>> personal object computer. Its first purpose is to empower laypeople to take 
>> control over their corner of the Net with its IoT. I have created a 
>> proof-of-concept implementation as a non-intrusive extension of Squeak 
>> version 3.10.2, and have used it to demonstrate how a novice uses the Loke 
>> IDE to create a small and intuitive program.
>> 
>> The article describes the concepts behind Loke .The current Squeak 
>> implementation should be ported to Pharo and can grow into the preferred 
>> Pharo-based IDE for laypeople taking control over their information 
>> environment. 
>> 
>> I will appreciate your possible comments before Aug. 31.
>> Enjoy
>> --Trygve
>> 
>> The article's 43 pages has several high points, I have included one of them 
>> here:
>> --- begin extract --
>> C.7.We need a paradigm shift 
>> 
>> The history of Western astronomy shows a series of paradigm shifts from the 
>> geocentric paradigm with its stationary Earth as the center of the Universe 
>> with its epicycles and other bizarre explanations of what appeared to be 
>> essential complexities. Astronomy evolved via the heliocentric to the 
>> current distributed paradigm with its chunks of mass connected by gravity. 
>> What appeared as essential complexity in one paradigm was easily resolved in 
>> the next. 
>> 
>> It is tempting to look for similar paradigm shifts in computing. Mainstream 
>> programming has based much of its theory and practice on the CPU-centric 
>> paradigm exemplified by the von Neumann machine. A memory-centric paradigm 
>> came in 1960 with the Autokon CAC/ CAM system and its central database 
>> (Reenskaug, 1973). The solution was obvious, and there must have been many 
>> similar initiatives without me being aware of them. 
>> 
>> It is time to realize that the first two paradigms do not meet our current 
>> challenges: We are plagued with immensely large, complex, and insecure 
>> systems that long ago left the realm of human understanding. A recent 
>> example: Customers found that their bank charged them twice for the same 
>> transaction. Several weeks after the problem was discovered, the bank 
>> publicly admitted that   they still didn't understand how the problem 
>> could arise: The complexity of their system was clearly beyond human 
>> comprehension. The bank has a staff of very competent experts, but they need 
>> a better foundation for modeling and implementing their sophisticated 
>> requirements. 
>> 
>> Computers can transform, store, and communicate data, (Figure below). The 
>> essence of the CPU-centric paradigm is that computers are primarily used to 
>> transform data; they compute. The essence of the memory-centric paradigm is 
>> that computers are used primarily to store data; they organize applications 
>> around a shared database. The essence of the communication-centric paradigm 
>> is that computers are primarily used to exchange messages with other 
>> computers to make them collaborate to achieve a common goal. 
>> 
>> The three paradigms of computing 
>> 
>> It is time to heed Tony Hoare's plea for simplicity and achieve a better way 
>> of separating concerns. Mainstream programming should shift to the 
>> communication-centric paradigm exemplified by the object computer that is 
>> the foundation for this article. 
>> 
>> The communication-centric paradigm has been on the horizon for many years. I 
>> first met it in Prokon's idea of distributed computers (Reenskaug, 1977), 
>> but there must have been many other initiatives. A newer example is 
>> Service-Oriented Architectures (SOA) that, in essence, is 
>> communication-centric. It didn't meet with immediate success, possibly 
>> because people tried to apply it within the CPU-centric paradigm where it 
>> doesn't belong. There are many other examples such as distributed computing. 
>> And of course, DCI and the IoT itself are, by definition, 
>> communication-centric.
>> 
>> --- end extract --
>> 
>> 
>> 
> 

Re: [Pharo-users] Personal Programming

[Trygve]

I dream of a future with the release of a Loke 1.0 that is firmly 
embedded in Pharo. A Loke that is quickly becoming the computing 
environment of choice for millions of homeowners and schoolchildren.

Trygve

On 25.07.2019 18:34, Cédrick Béler wrote:

Me too !

And on the huge esug discussion points to have ^^

Cheers,

Cedrick


Le 25 juil. 2019 à 13:09, Marcus Denker > a écrit :


Looks very interesting! I will read it (it arrives just in time to be 
part of the holiday reading pile…)


Marcus

On 25 Jul 2019, at 11:29, Trygve > wrote:


Dear all,
The final draft of my magnum opus about Personal Programming is now 
ready for review:

http://folk.uio.no/trygver/themes/Personal/PP-019%20-%20Copy%20(17).pdf

The article's main theme is Personal Programming for everybody with 
/Loke/, a personal object computer. Its first purpose is to empower 
laypeople to take control over their corner of the Net with its IoT. 
I have created a proof-of-concept implementation as a non-intrusive 
extension of Squeak version 3.10.2, and have used it to demonstrate 
how a novice uses the Loke IDE to create a small and intuitive program.


The article describes the concepts behind Loke .The current Squeak 
implementation should be ported to Pharo and can grow into the 
preferred Pharo-based IDE for laypeople taking control over their 
information environment.


I will appreciate your possible comments before Aug. 31.
Enjoy
--Trygve

The article's 43 pages has several high points, I have included one 
of them here:

--- begin extract --


  C.7.We need a paradigm shift

The history of Western astronomy shows a series of paradigm shifts 
from the geocentric paradigm with its stationary Earth as the center 
of the Universe with its epicycles and other bizarre explanations of 
what appeared to be essential complexities. Astronomy evolved via 
the heliocentric to the current distributed paradigm with its chunks 
of mass connected by gravity. What appeared as essential complexity 
in one paradigm was easily resolved in the next.


It is tempting to look for similar paradigm shifts in computing. 
Mainstream programming has based much of its theory and practice on 
the CPU-centric paradigm exemplified by the von Neumann machine. A 
memory-centric paradigm came in 1960 with the Autokon CAC/ CAM 
system and its central database (Reenskaug, 1973). The solution was 
obvious, and there must have been many similar initiatives without 
me being aware of them.


It is time to realize that the first two paradigms do not meet our 
current challenges: We are plagued with immensely large, complex, 
and insecure systems that long ago left the realm of human 
understanding. A recent example: Customers found that their bank 
charged them twice for the same transaction. Several weeks after the 
problem was discovered, the bank publicly admitted that they still 
didn't understand how the problem could arise: The complexity of 
their system was clearly beyond human comprehension. The bank has a 
staff of very competent experts, but they need a better foundation 
for modeling and implementing their sophisticated requirements.


Computers can transform, store, and communicate data, (Figure 
below). The essence of the CPU-centric paradigm is that computers 
are primarily used to transform data; they compute. The essence of 
the memory-centric paradigm is that computers are used primarily to 
store data; they organize applications around a shared database. The 
essence of the communication-centric paradigm is that computers are 
primarily used to exchange messages with other computers to make 
them collaborate to achieve a common goal.


/The three paradigms of computing //
///
It is time to heed Tony Hoare's plea for simplicity and achieve a 
better way of separating concerns. Mainstream programming should 
shift to the communication-centric paradigm exemplified by the 
object computer that is the foundation for this article.


The communication-centric paradigm has been on the horizon for many 
years. I first met it in Prokon's idea of distributed computers 
(Reenskaug, 1977), but there must have been many other initiatives. 
A newer example is Service-Oriented Architectures (SOA) that, in 
essence, is communication-centric. It didn't meet with immediate 
success, possibly because people tried to apply it within the 
CPU-centric paradigm where it doesn't belong. There are many other 
examples such as distributed computing. And of course, DCI and the 
IoT itself are, by definition, communication-centric.


--- end extract --







--

/The essence of object orientation is that objects collaborateto achieve 
a goal. /

Trygve Reenskaug mailto: tryg...@ifi.uio.no 
Morgedalsvn. 5A http://folk.uio.no/trygver/
N-0378 Oslo http://fullOO.info
Norway Tel: (+47) 22 49 57 27

Re: [Pharo-users] Personal Programming

[Hilaire]

Hi Trygve,

Personal programming is something I always been fascinated by, since
decades, to empower users.

In the domain of teaching, the concept can go as far as giving the
ability to teachers to craft their own numeric tools in their respective
area.

This is for this exact reason I ported DrGeo to Squeak, then Pharo, in
2005. The end user programming gives the power to design very advanced
teaching models[1].

However, Smalltalk scripting can be tricky, so this is with profound
interest I will read your paper in the later days.

Hilaire

[1] http://blog.drgeo.eu/post/2019/The-Newton-Raphson-Method

Le 25/07/2019 à 11:29, Trygve a écrit :
> The final draft of my magnum opus about Personal Programming is now
> ready for review:
> http://folk.uio.no/trygver/themes/Personal/PP-019%20-%20Copy%20(17).pdf

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Personal Programming

[Richard O'Keefe]

There are some spelling issues in the PDF one finds at the Newton-Raphson
link.
"bellow" and "below" mean different things and sound quite different
(BELL-owe vs b'-LOW).  In "In the sketch bellow" the one you want is
"below".
"bloc" and "block" sound the same but also mean different things, and
the Smalltalk [...] forms are "blocks" not "blocs".

Is writing these interactive documents as much work as it looks like?



On Sat, 27 Jul 2019 at 17:59, Hilaire  wrote:

> Hi Trygve,
>
> Personal programming is something I always been fascinated by, since
> decades, to empower users.
>
> In the domain of teaching, the concept can go as far as giving the
> ability to teachers to craft their own numeric tools in their respective
> area.
>
> This is for this exact reason I ported DrGeo to Squeak, then Pharo, in
> 2005. The end user programming gives the power to design very advanced
> teaching models[1].
>
> However, Smalltalk scripting can be tricky, so this is with profound
> interest I will read your paper in the later days.
>
> Hilaire
>
> [1] http://blog.drgeo.eu/post/2019/The-Newton-Raphson-Method
>
> Le 25/07/2019 à 11:29, Trygve a écrit :
> > The final draft of my magnum opus about Personal Programming is now
> > ready for review:
> > http://folk.uio.no/trygver/themes/Personal/PP-019%20-%20Copy%20(17).pdf
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>
>

Re: [Pharo-users] Personal Programming

[Hilaire]

Thanks Richard for your review of the article and your pedagogical
explanations.

For me writing these interactive documents are not that much work. But
it is true you need to know the DrGeo API. Which can be discovered by
exploring the DrGeoSketch class.

I am used to the DrGeo API, so my view is biased. A more user
discoverable programming interface will be easier. So the interest on
Trygve work.

I am finishing writing a textbook on DrGeo math programming for my
middle high school students. But the resources is in French :(

Le 27/07/2019 à 16:26, Richard O'Keefe a écrit :
> There are some spelling issues in the PDF one finds at the
> Newton-Raphson link.
> "bellow" and "below" mean different things and sound quite different
> (BELL-owe vs b'-LOW).  In "In the sketch bellow" the one you want is
> "below".
> "bloc" and "block" sound the same but also mean different things, and
> the Smalltalk [...] forms are "blocks" not "blocs".
>
> Is writing these interactive documents as much work as it looks like?
>
-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Personal Programming onPharo

[Norbert Hartl]

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 :
> 
> 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 objects collaborate  to achieve a 
> goal. 
> Trygve Reenskaug  mailto: tryg...@ifi.uio.no
> Morgedalsvn. 5A   http://folk.uio.no/trygver/
> N-0378 Oslo http://fullOO.info
> Norway Tel: (+47) 22 49 57 27

Re: [Pharo-users] Personal Programming onPharo

[Todd Blanchard]

OK, I have to push back at this.

When Pharo forked I was excited because Squeak was such a fast moving lab 
experiment that you couldn't build anything and expect it to work in a year.

Pharo was supposed to be the "business ready" fork leaving Squeak to be the 
crazy lab experiment.

From https://pharo.org/about

It says:

Pharo's goal is to deliver a clean, innovative, free and open-source immersive 
environment. 

By providing a stable and small core system, excellent developing tools, and 
maintained releases, Pharo is an attractive platform to build and deploy 
mission critical applications.

But you are telling me that Pharo is also a fast moving lab experiment that is 
too unstable for real work?

I understand this is hard but is there a definitive roadmap and plan to reach 
to stability?

> On May 6, 2018, at 4:00 AM, 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  >:
> 
>> 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 objects collaborate  to achieve a 
>> goal. 
>> Trygve Reenskaug  mailto: tryg...@ifi.uio.no 
>> 
>> Morgedalsvn. 5A   http://folk.uio.no/trygver/ 
>> 
>> N-0378 Oslo http://fullOO.info 
>> Norway Tel: (+47) 22 49 57 27 

Re: [Pharo-users] Personal Programming onPharo

[horrido]

I was thinking the same thing. Enterprises need to rely on a stable
distribution over a long period of time. That's why many Linux distros have
LTS versions.

That's why VisualWorks is the enterprise standard.



tblanchard wrote
> OK, I have to push back at this.
> 
> When Pharo forked I was excited because Squeak was such a fast moving lab
> experiment that you couldn't build anything and expect it to work in a
> year.
> 
> Pharo was supposed to be the "business ready" fork leaving Squeak to be
> the crazy lab experiment.
> 
> From https://pharo.org/about
> 
> It says:
> 
> Pharo's goal is to deliver a clean, innovative, free and open-source
> immersive environment. 
> 
> By providing a stable and small core system, excellent developing tools,
> and maintained releases, Pharo is an attractive platform to build and
> deploy mission critical applications.
> 
> But you are telling me that Pharo is also a fast moving lab experiment
> that is too unstable for real work?
> 
> I understand this is hard but is there a definitive roadmap and plan to
> reach to stability?
> 
>> On May 6, 2018, at 4:00 AM, Norbert Hartl <

> norbert@

> > 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@.uio

>   trygver@.uio

> >>:
>> 
>>> 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 objects collaborate  to
>>> achieve a goal. 
>>> Trygve Reenskaug  mailto: 

> trygver@.uio

>   20trygver@.uio

> >
>>> Morgedalsvn. 5A   http://folk.uio.no/trygver/
>>> ;
>>> N-0378 Oslo http://fullOO.info ;
>>> Norway Tel: (+47) 22 49 57 27





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Personal Programming onPharo

[Norbert Hartl]

As you are not biased to understand what I was saying can you please define 
what „stability“ means to you? 

After all those years I‘m fed up with people using terms like „stability“ or 
„scability“ as if the were self-explaining. The same goes for „enterprise 
needs“. They are not, they are defined within the scope if their requirements. 

I have more than 100 pharo images running and these are pretty stable. Why? 
Because pharo is stable enough and I am capable of doing the rest to make it 
right for my needs.

On the other hand if I were into writing UI based tools I know there will be a 
lot of changes in the coming years. So nothing to expect regarding stability.

If you work in an enterprise your definition of stability can be defined as 
static/non-moving stability. It just means you don‘t have to cope with everyday 
changes but the gap of your software to actual software gets bigger every day. 
And with every day it is more unlikely someone is brave enough to decide to 
move on and to catch up with the rest. 

etc. etc.

Norbert

> Am 06.05.2018 um 21:16 schrieb Todd Blanchard :
> 
> OK, I have to push back at this.
> 
> When Pharo forked I was excited because Squeak was such a fast moving lab 
> experiment that you couldn't build anything and expect it to work in a year.
> 
> Pharo was supposed to be the "business ready" fork leaving Squeak to be the 
> crazy lab experiment.
> 
> From https://pharo.org/about
> 
> It says:
> 
> Pharo's goal is to deliver a clean, innovative, free and open-source 
> immersive environment. 
> 
> By providing a stable and small core system, excellent developing tools, and 
> maintained releases, Pharo is an attractive platform to build and deploy 
> mission critical applications.
> 
> But you are telling me that Pharo is also a fast moving lab experiment that 
> is too unstable for real work?
> 
> I understand this is hard but is there a definitive roadmap and plan to reach 
> to stability?
> 
>> On May 6, 2018, at 4:00 AM, 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 :
>>> 
>>> 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 objects collaborate  to achieve a 
>>> goal. 
>>> Trygve Reenskaug  mailto: tryg...@ifi.uio.no
>>> Morgedalsvn. 5A   http://folk.uio.no/trygver/
>>> N-0378 Oslo http://fullOO.info
>>> Norway Tel: (+47) 22 49 57 27 
> 

Re: [Pharo-users] Personal Programming onPharo

[Trygve Reenskaug]

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 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 >:


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 objects collaborateto 
achieve a goal. /
Trygve Reenskaug mailto: tryg...@ifi.uio.no 


Morgedalsvn. 5A http://folk.uio.no/trygver/
N-0378 Oslo http://fullOO.info
Norway Tel: (+47) 22 49 57 27



--

/The essence of object orientation is that obje

Re: [Pharo-users] Personal Programming onPharo

[Norbert Hartl]

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 :
> 
> 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  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 

Re: [Pharo-users] Personal Programming onPharo

[Trygve Reenskaug]

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 >:


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 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

Re: [Pharo-users] Personal Programming onPharo

[Norbert Hartl]

> Am 07.05.2018 um 12:42 schrieb Trygve Reenskaug :
> 
> 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.
> 
If we talk about C/C++ the runtime is the operating system. Everytime I update 
it the linked libraries are suspect to be invalid from then. If you have in the 
same system update a new version of the C compiler you are doomed. You cannot 
link your binary with the new libs. And the new C compiler quirks about your 
code. So what you have then? Staying on an old C language standard? Statically 
link everything. Ah no that won’t work because you would have to care about all 
your dependencies being compilable with the new compiler. But you don’t update 
the compiler meaning you don’t update the operating system. It is the same as 
staying on pharo 3.

For Java the situation is slightly different because if you use new programming 
language features you can only do when switching the compiler to the new 
standard. There is a lot of effort that went into making the java vm recognize 
the language version and execute regarding that making version compatible. We 
are in sync here. I told you it is about manpower. Do you know how much 
manpower it needed and how long it took to add something like closures to the 
java language? Do you consider java closure to be en par with other languages?

We are sorry not everything is to your liking. It is not even to our own liking 
because we have dreams far beyond. But we will never get there if we don’t take 
the effort. And the point of open source (did I mention pharo is open source?? 
) is that the ones that do it decide what to do. Nuff said!

Norbert

> 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 >> >:
>>> 
>>> 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

Re: [Pharo-users] Personal Programming onPharo

[Stephan Eggermont]

Trygve Reenskaug  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.
> 

Oracle lists 24 behavioral incompatibilities between Java SE 7 and SE 6. 

Stephan

Re: [Pharo-users] Personal Programming onPharo

[Sean P. DeNigris]

Trygve Reenskaug wrote
> I am developing an IDE for non-programmers  called BabyIDE

I remember seeing this in a screencast - it was very cool!


Trygve Reenskaug wrote
> In your answer, I read that if I build BabyIDE on Pharo, I will be
> building on sand.

Sorry I took so long to reply to your OP. It does indeed *sound* like that
but AFAICT (myself included with dozens of projects), porting to new
versions has been relatively painless. That said, a project like you
described may have additional hurdles because it hooks so deeply into the
inner guts of the IDE. Also, there are continually new techniques to ease
these transitions. For example, there is now a deprecation message which
auto-rewrites sender on first send; this is even more powerful if one has
tests with good coverage because running the tests magically updates your
project.


Trygve Reenskaug wrote
> A tale from the future… drop whatever they are doing in 
> order to adapt their applications to the new Pharo so that you can start 
> serving your customers again.

It's a hard problem because we have a big vision, which means a natural
tension with backward compatibility. In fact, IMHO that was one of the major
reasons for the fork from Squeak, so I guess it's unfortunate that now
Squeak seems to be a moving target as well. Again, just to reiterate,
AFAICT, most of the changes are generally deep in the system and will not
affect the average customer facing project. Even then, there's no need to be
on the latest, greatest version if the cost doesn't seem worth it. There are
plenty of production systems happily running on Pharo 1.x.

Suggestions are very welcome about how to move toward a bright future with
minimum impact on existing users/projects!!



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Personal Programming onPharo

[Trygve Reenskaug]

Norbert,
I stand corrected because I have not followed the mainstream languages 
as well as I probably should. Thank you for your candid answer, it 
clearly outlines what I can and cannot expect from Pharo and any other 
ST project.


I go back to Alan Kay's vision of a Dynabook: A /personal /computer for 
children of all ages. It should contain all its owner's /personal /data, 
including  his or her /personal /programs, as they evolve through the 
years.  Continuity is a must; the owner shall never loose data.


Again, thank you for your answers. They have given invaluable 
contributions to my thinking.

--Trygve.


On 07.05.2018 14:14, Norbert Hartl wrote:


Am 07.05.2018 um 12:42 schrieb Trygve Reenskaug >:


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.


If we talk about C/C++ the runtime is the operating system. Everytime 
I update it the linked libraries are suspect to be invalid from then. 
If you have in the same system update a new version of the C compiler 
you are doomed. You cannot link your binary with the new libs. And the 
new C compiler quirks about your code. So what you have then? Staying 
on an old C language standard? Statically link everything. Ah no that 
won’t work because you would have to care about all your dependencies 
being compilable with the new compiler. But you don’t update the 
compiler meaning you don’t update the operating system. It is the same 
as staying on pharo 3.


For Java the situation is slightly different because if you use new 
programming language features you can only do when switching the 
compiler to the new standard. There is a lot of effort that went into 
making the java vm recognize the language version and execute 
regarding that making version compatible. We are in sync here. I told 
you it is about manpower. Do you know how much manpower it needed and 
how long it took to add something like closures to the java language? 
Do you consider java closure to be en par with other languages?


We are sorry not everything is to your liking. It is not even to our 
own liking because we have dreams far beyond. But we will never get 
there if we don’t take the effort. And the point of open source (did I 
mention pharo is open source?? ) is that the ones that do it decide 
what to do. Nuff said!


Norbert


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 

Re: [Pharo-users] Personal Programming onPharo

[Norbert Hartl]

> Am 08.05.2018 um 08:30 schrieb Trygve Reenskaug :
> 
> Norbert,
> I stand corrected because I have not followed the mainstream languages as 
> well as I probably should. Thank you for your candid answer, it clearly 
> outlines what I can and cannot expect from Pharo and any other ST project. 
> 
Ok, I didn’t want to sound too harsh but for me there is no benefit in telling 
something which is not true. And as a member of such community you get 
sometimes allergic to things that sound negative because that happens far too 
often. What I said about not upgrading is the thing we suffer from. While you 
find it that squeak has moved too fast we consider it that it didn’t move 
enough. That is why a lot of the sub-systems need to be replaced and that 
causes instability. For me the stability is outstanding if I look what is 
changed all the time. But that is another perspective. For a user of the 
platform it is simply annoying. We know that but not moving is not option for 
us so that’s why I say that frankly. And sadly the only thing that can 
compensate side-effects due to changes is to put a lot of man power onto it. 
The programming/software world has not much too say about how change should be 
done. 

> I go back to Alan Kay's vision of a Dynabook: A personal computer for 
> children of all ages. It should contain all its owner's  personaldata, 
> including  his or her personal programs, as they evolve through the years.  
> Continuity is a must; the owner shall never loose data. 
> 
We are onto it. If you look at the way we can work, model inspect etc. it is 
still an wonderful tool. And it is getting better every day while breaking 
things here and there. I can only repeat what I said earlier. The part of your 
IDE that copes with language details might break the least because that is the 
most stable part of the pharo system. But all of the UI system will be replaced 
in a non-compatible way. Morphic is great but it has grown into a hugly 
monster. And in this century you might not survive having bitmap based 
graphics. It might still make perfect sense to you. Because there will be some 
effort put into the ability to load it into pharo at wish. But I would suspect 
it won’t change much from there. 
But it cannot stay because to old-fashioned and not changeable. Maybe it is 
missing in the Dynabook vision that is not likely that children born after 2000 
still won’t too use a graphical interface designed in the 70s being unchanged. 
But I’m not sure if the Dynabook vision was supposed to be realized some day or 
just a vehicle to complain about everything.

> Again, thank you for your answers. They have given invaluable contributions 
> to my thinking.

I would have liked to say something more encouraging but ….

Norbert

> --Trygve.
> 
> 
> On 07.05.2018 14:14, Norbert Hartl wrote:
>> 
>>> Am 07.05.2018 um 12:42 schrieb Trygve Reenskaug >> >:
>>> 
>>> 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.
>>> 
>> If we talk about C/C++ the runtime is the operating system. Everytime I 
>> update it the linked libraries are suspect to be invalid from then. If you 
>> have in the same system update a new version of the C compiler you are 
>> doomed. You cannot link your binary with the new libs. And the new C 
>> compiler quirks about your code. So what you have then? Staying on an old C 
>> language standard? Statically link everything. Ah no that won’t work because 
>> you would have to care about all your dependencies being compilable with the 
>> new compiler. But you don’t update the compiler meaning you don’t update the 
>> operating system. It is the same as staying on pharo 3.
>> 
>> For Java the situation is slightly different because if you use new 
>> programming language features you can only do when switching the compiler to 
>> the new standard. There is a lot of effort that went into making the java vm 
>> recognize the language version and execute regarding that making version 
>> compatible. We are in sync here. I told you it is about manpower. Do you 
>> know how much manpower it needed and how long it took to add something like 
>> closures to the java language? Do you consider java closure to be en par 
>> with other languages?
>> 
>> We are sorry not everything is to your liking. It is not even to our own 
>> liking because we have dreams far beyond. But we will never get there if we 
>> don’t take the effort. And the point of open source (did I mention pharo is 
>> open source?? ) is that the ones that do it decide what to do. Nuff said!
>> 
>> Norbert
>> 
>>> 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 wan

Re: [Pharo-users] Personal Programming onPharo

[Tudor Girba]

Hi,

First, I concur with what Norbert said.

@Trygve: Could you describe what you would need in more details?

Cheers,
Doru


> On May 8, 2018, at 9:57 AM, Norbert Hartl  wrote:
> 
> 
> 
>> Am 08.05.2018 um 08:30 schrieb Trygve Reenskaug :
>> 
>> Norbert,
>> I stand corrected because I have not followed the mainstream languages as 
>> well as I probably should. Thank you for your candid answer, it clearly 
>> outlines what I can and cannot expect from Pharo and any other ST project. 
>> 
> Ok, I didn’t want to sound too harsh but for me there is no benefit in 
> telling something which is not true. And as a member of such community you 
> get sometimes allergic to things that sound negative because that happens far 
> too often. What I said about not upgrading is the thing we suffer from. While 
> you find it that squeak has moved too fast we consider it that it didn’t move 
> enough. That is why a lot of the sub-systems need to be replaced and that 
> causes instability. For me the stability is outstanding if I look what is 
> changed all the time. But that is another perspective. For a user of the 
> platform it is simply annoying. We know that but not moving is not option for 
> us so that’s why I say that frankly. And sadly the only thing that can 
> compensate side-effects due to changes is to put a lot of man power onto it. 
> The programming/software world has not much too say about how change should 
> be done. 
> 
>> I go back to Alan Kay's vision of a Dynabook: A personal computer for 
>> children of all ages. It should contain all its owner's  personaldata, 
>> including  his or her personal programs, as they evolve through the years.  
>> Continuity is a must; the owner shall never loose data. 
>> 
> We are onto it. If you look at the way we can work, model inspect etc. it is 
> still an wonderful tool. And it is getting better every day while breaking 
> things here and there. I can only repeat what I said earlier. The part of 
> your IDE that copes with language details might break the least because that 
> is the most stable part of the pharo system. But all of the UI system will be 
> replaced in a non-compatible way. Morphic is great but it has grown into a 
> hugly monster. And in this century you might not survive having bitmap based 
> graphics. It might still make perfect sense to you. Because there will be 
> some effort put into the ability to load it into pharo at wish. But I would 
> suspect it won’t change much from there. 
> But it cannot stay because to old-fashioned and not changeable. Maybe it is 
> missing in the Dynabook vision that is not likely that children born after 
> 2000 still won’t too use a graphical interface designed in the 70s being 
> unchanged. But I’m not sure if the Dynabook vision was supposed to be 
> realized some day or just a vehicle to complain about everything.
> 
>> Again, thank you for your answers. They have given invaluable contributions 
>> to my thinking.
> 
> I would have liked to say something more encouraging but ….
> 
> Norbert
> 
>> --Trygve.
>> 
>> 
>> On 07.05.2018 14:14, Norbert Hartl wrote:
>>> 
 Am 07.05.2018 um 12:42 schrieb Trygve Reenskaug :
 
 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.
 
>>> If we talk about C/C++ the runtime is the operating system. Everytime I 
>>> update it the linked libraries are suspect to be invalid from then. If you 
>>> have in the same system update a new version of the C compiler you are 
>>> doomed. You cannot link your binary with the new libs. And the new C 
>>> compiler quirks about your code. So what you have then? Staying on an old C 
>>> language standard? Statically link everything. Ah no that won’t work 
>>> because you would have to care about all your dependencies being compilable 
>>> with the new compiler. But you don’t update the compiler meaning you don’t 
>>> update the operating system. It is the same as staying on pharo 3.
>>> 
>>> For Java the situation is slightly different because if you use new 
>>> programming language features you can only do when switching the compiler 
>>> to the new standard. There is a lot of effort that went into making the 
>>> java vm recognize the language version and execute regarding that making 
>>> version compatible. We are in sync here. I told you it is about manpower. 
>>> Do you know how much manpower it needed and how long it took to add 
>>> something like closures to the java language? Do you consider java closure 
>>> to be en par with other languages?
>>> 
>>> We are sorry not everything is to your liking. It is not even to our own 
>>> liking because we have dreams far beyond. But we will never get there if we 
>>> don’t take the effort. And the point of open source (did I mention pharo is 
>>> open source?? ) is that the ones that do it d

Re: [Pharo-users] Personal Programming onPharo

[Dimitris Chloupis]

On Mon, May 7, 2018 at 1:43 PM Trygve Reenskaug  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.
>

1) C and C++ do not have runtime systems, only Java has. The closest to C
with a runtime system is C# that has .NET.
2) Pharo does not have a runtime system, it has a live coding enviroment
which goes far beyond the demands of a runtime system which is usually
compiler + intepreter + VM + standard library.
3) Pharo language changes even less often than C/C++ and Java. Even though
C/C++ and Java are too afraid to change because of the panic they will
cause to millions of developers too busy maintaining ugly highly unstable
code that those languages are so prone at. Pharo language changes even less
mainly because its far less minimal , you only need 6 lines of code to
describe the entire syntax the rest is implemented as libraries which also
rarely change as well.

99.9% of Pharo issues/bugs are IDE related or some advanced software
development tool and new library that goes far beyond the scope of the
language and its "standard" library.

So technically speaking if we were to compared Pharo with C/C++ and Java on
equal grounds as languages , plus stanard library , plus vm etc , Pharo is
stellar they are a big pile of mess which is rapidly replaced by dynamic
languages.

It was just 2 decades ago when C++ was the undisputed king of software
development and using another language besides VB was seen as nothing less
than insane. Nowdays people have long abandoned ship and VB is seen as
nothing more than an abomination.

Its ironic you mentioned Java because Java exist for one thing and one
thing only , to kill C++. Did not manage to succeed but it did manage to
steal away half of the developers on the premise alone that Java is far
less likely to create unstable code than C/C++.

The irony of course did not stop there and pretty much every modern dynamic
language (modern static languages are an extremely rare breed in
comparison) use the same argument or far more stable , much easier to debug
and maintaine code.

I have coded in Pharo for 6 years and nowdays I daily deal with C++ (mainly
because of graphics code through OpenGL, Cuda etc) and I can tell you
stability wise there is not even a comparison. Sure the language and its
library can be stable but what use is that to me when the code is so prone
to creating a ton of problem I have to ellude with the acrobatic skills of
spiderman ?

Pharo is far from perfect, if it was I would still be coding in it but none
the less, stability it definetly one of its main problems. Everything crash
and burns at some point and frankly Pharo does it far more elegantly than
any other language I have ever used and far less so.

Re: [Pharo-users] Personal Programming onPharo

[Dimitris Chloupis]

correction I mean to say
"Pharo is far from perfect, if it was I would still be coding in it but
none the less, stability is definetly NOT one of its main problems."

On Tue, May 8, 2018 at 2:37 PM Dimitris Chloupis 
wrote:

> On Mon, May 7, 2018 at 1:43 PM Trygve Reenskaug 
> 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.
>>
>
> 1) C and C++ do not have runtime systems, only Java has. The closest to C
> with a runtime system is C# that has .NET.
> 2) Pharo does not have a runtime system, it has a live coding enviroment
> which goes far beyond the demands of a runtime system which is usually
> compiler + intepreter + VM + standard library.
> 3) Pharo language changes even less often than C/C++ and Java. Even though
> C/C++ and Java are too afraid to change because of the panic they will
> cause to millions of developers too busy maintaining ugly highly unstable
> code that those languages are so prone at. Pharo language changes even less
> mainly because its far less minimal , you only need 6 lines of code to
> describe the entire syntax the rest is implemented as libraries which also
> rarely change as well.
>
> 99.9% of Pharo issues/bugs are IDE related or some advanced software
> development tool and new library that goes far beyond the scope of the
> language and its "standard" library.
>
> So technically speaking if we were to compared Pharo with C/C++ and Java
> on equal grounds as languages , plus stanard library , plus vm etc , Pharo
> is stellar they are a big pile of mess which is rapidly replaced by dynamic
> languages.
>
> It was just 2 decades ago when C++ was the undisputed king of software
> development and using another language besides VB was seen as nothing less
> than insane. Nowdays people have long abandoned ship and VB is seen as
> nothing more than an abomination.
>
> Its ironic you mentioned Java because Java exist for one thing and one
> thing only , to kill C++. Did not manage to succeed but it did manage to
> steal away half of the developers on the premise alone that Java is far
> less likely to create unstable code than C/C++.
>
> The irony of course did not stop there and pretty much every modern
> dynamic language (modern static languages are an extremely rare breed in
> comparison) use the same argument or far more stable , much easier to debug
> and maintaine code.
>
> I have coded in Pharo for 6 years and nowdays I daily deal with C++
> (mainly because of graphics code through OpenGL, Cuda etc) and I can tell
> you stability wise there is not even a comparison. Sure the language and
> its library can be stable but what use is that to me when the code is so
> prone to creating a ton of problem I have to ellude with the acrobatic
> skills of spiderman ?
>
> Pharo is far from perfect, if it was I would still be coding in it but
> none the less, stability it definetly one of its main problems. Everything
> crash and burns at some point and frankly Pharo does it far more elegantly
> than any other language I have ever used and far less so.
>

Re: [Pharo-users] Personal Programming onPharo

[Trygve Reenskaug]

Hi Norbert,
This discussion has been very useful to me. Let me stress that I am not 
criticizing Pharo. I think Pharo is an exciting and promising project.  
But I  have set requirements for PP that Pharo can't fill. I have no 
idea how to fill them or if they can be filled at all. So here is a new 
research project that I look forward to digging into as soon as time 
permits.


Thanks
-Trygve

On 08.05.2018 09:57, Norbert Hartl wrote:



Am 08.05.2018 um 08:30 schrieb Trygve Reenskaug >:


Norbert,
I stand corrected because I have not followed the mainstream 
languages as well as I probably should. Thank you for your candid 
answer, it clearly outlines what I can and cannot expect from Pharo 
and any other ST project.


Ok, I didn’t want to sound too harsh but for me there is no benefit in 
telling something which is not true. And as a member of such community 
you get sometimes allergic to things that sound negative because that 
happens far too often. What I said about not upgrading is the thing we 
suffer from. While you find it that squeak has moved too fast we 
consider it that it didn’t move enough. That is why a lot of the 
sub-systems need to be replaced and that causes instability. For me 
the stability is outstanding if I look what is changed all the time. 
But that is another perspective. For a user of the platform it is 
simply annoying. We know that but not moving is not option for us so 
that’s why I say that frankly. And sadly the only thing that can 
compensate side-effects due to changes is to put a lot of man power 
onto it. The programming/software world has not much too say about how 
change should be done.


I go back to Alan Kay's vision of a Dynabook: A/personal/computer for 
children of all ages. It should contain all its owner's 
/personal/data, including  his or her/personal/programs, as they 
evolve through the years.  Continuity is a must; the owner shall 
never loose data.


We are onto it. If you look at the way we can work, model inspect etc. 
it is still an wonderful tool. And it is getting better every day 
while breaking things here and there. I can only repeat what I said 
earlier. The part of your IDE that copes with language details might 
break the least because that is the most stable part of the pharo 
system. But all of the UI system will be replaced in a non-compatible 
way. Morphic is great but it has grown into a hugly monster. And in 
this century you might not survive having bitmap based graphics. It 
might still make perfect sense to you. Because there will be some 
effort put into the ability to load it into pharo at wish. But I would 
suspect it won’t change much from there.
But it cannot stay because to old-fashioned and not changeable. Maybe 
it is missing in the Dynabook vision that is not likely that children 
born after 2000 still won’t too use a graphical interface designed in 
the 70s being unchanged. But I’m not sure if the Dynabook vision was 
supposed to be realized some day or just a vehicle to complain about 
everything.


Again, thank you for your answers. They have given invaluable 
contributions to my thinking.


I would have liked to say something more encouraging but ….

Norbert


--Trygve.


On 07.05.2018 14:14, Norbert Hartl wrote:


Am 07.05.2018 um 12:42 schrieb Trygve Reenskaug >:


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.


If we talk about C/C++ the runtime is the operating system. 
Everytime I update it the linked libraries are suspect to be invalid 
from then. If you have in the same system update a new version of 
the C compiler you are doomed. You cannot link your binary with the 
new libs. And the new C compiler quirks about your code. So what you 
have then? Staying on an old C language standard? Statically link 
everything. Ah no that won’t work because you would have to care 
about all your dependencies being compilable with the new compiler. 
But you don’t update the compiler meaning you don’t update the 
operating system. It is the same as staying on pharo 3.


For Java the situation is slightly different because if you use new 
programming language features you can only do when switching the 
compiler to the new standard. There is a lot of effort that went 
into making the java vm recognize the language version and execute 
regarding that making version compatible. We are in sync here. I 
told you it is about manpower. Do you know how much manpower it 
needed and how long it took to add something like closures to the 
java language? Do you consider java closure to be en par with other 
languages?


We are sorry not everything is to your liking. It is not even to our 
own liking because we have dreams far beyond. But we will never get 
there if we don’t take the effort. And the point of open sour

Re: [Pharo-users] Personal Programming onPharo

[Marcus Denker]

> 
> 
>> I go back to Alan Kay's vision of a Dynabook: A personal computer for 
>> children of all ages. It should contain all its owner's  personaldata, 
>> including  his or her personal programs, as they evolve through the years.  
>> Continuity is a must; the owner shall never loose data. 
>> 
> 

Do you really expect that the dynabook will be 100% backward compatible to 
Smalltalk-80? 

Marcus

Re: [Pharo-users] Personal Programming onPharo

[Trygve Reenskaug]

Of course not. But one of my goals is that future dynabooks will be 
backwards compatible. Recent discussions have shown me that this goal is 
a research project.

--Trygve
On 09.05.2018 12:19, Marcus Denker wrote:



I go back to Alan Kay's vision of a Dynabook: A/personal/computer 
for children of all ages. It should contain all its owner's 
/personal/data, including  his or her/personal/programs, as they 
evolve through the years.  Continuity is a must; the owner shall 
never loose data.






Do you really expect that the dynabook will be 100% backward 
compatible to Smalltalk-80?


Marcus


--

/The essence of object orientation is that objects collaborateto achieve 
a goal. /

Trygve Reenskaug mailto: tryg...@ifi.uio.no 
Morgedalsvn. 5A http://folk.uio.no/trygver/
N-0378 Oslo http://fullOO.info
Norway Tel: (+47) 22 49 57 27

Re: [Pharo-users] Personal Programming onPharo

[H. Hirzel]

On 5/9/18, Trygve Reenskaug  wrote:
> Of course not. But one of my goals is that future dynabooks will be
> backwards compatible. Recent discussions have shown me that this goal is
> a research project.
> --Trygve

Indeed [1]. And a very interesting one!

Found and read your overview
http://folk.uio.no/trygver/themes/Personal/PP-NIK.pdf

And also the more elaborate draft of a description (50 pages) [2]

http://folk.uio.no/trygver/themes/Personal/pp-index.html
links to
http://folk.uio.no/trygver/themes/Personal/PersonalProgramming.233.zip


For my personal programming needs in Squeak so far I realized that the
'data' part is the easiest one to tackle in terms of backward
compatibility.

And some success in converting data to code forth and back to ease
compatibility. It would be nicer of course to have a homoiconic
notation [3] but still very doable. In particular as the new VMs have
lifted the size constraint for the source code of in methods.

--Hannes


[1] An example is about the work involved to get a 17 year old
'Dynamic essay' from Squeak 3.2 to read in properly into a Squeak 6.0a
trunk image

http://forum.world.st/Dynamic-essay-project-MorphLayoutArticle-on-Bob-s-SuperSwiki-tc5075374.html

Quite some effort and not a full result yet...

Though Squeak has some mechanisms to update classes and objects.

In that thread Edgar de Cleene outlined  the idea of a recursive DNU
mechanism to check out earlier messages from the web

http://forum.world.st/Dynamic-essay-project-MorphLayoutArticle-on-Bob-s-SuperSwiki-tp5075374p5075625.html

Needs much more elaboration ...
---
[2]  Abstract

Computer programming celebrates its platinum jubilee on the 21st of
June, 2018. Exactly 70 years ago, the world's first programmer wrote
the world's first program and then stored and executed it in the
world's first stored program computer; affectionately known as Baby.
The solitary Baby has morphed into billions of computers that are
loosely connected into a single, global machine. Baby's control panel
has morphed into graphical user interfaces (GUI) that empower
everybody to augment their intellect. The consequences are deeply
radical for individuals and society alike. A significant side effect
of the GUI is that the computer has faded into the background and the
user focuses on the immediate needs.

We present DCI, a new programming paradigm that targets structures of
communicating computers. Its goal is readable code that is so
intuitive that everybody can grok it and so comprehensive that expert
programmers will enjoy using it. DCI programming has been tested on
real-life problems. A set of controlled experiments showed that DCI
code is more readable than Java code.

A new programming environment, BabyIDE, targets the single, global
machine. Different GUIs support programmers having different mental
models depending on their interests and proficiency. An MVC system
architecture makes the program fade into the background and lets the
user concentrate on satisfying his or her immediate needs. My approach
is experimental. Smalltalk's universe of objects imitates the single,
global machine and is my proving ground.We give two examples: one for
experts and another for novices. A video1 illustrates the novice IDE.

Our approach is experimental. The universe of objects found in
Smalltalk's image imitates a computer network and is our proving
ground. Squeak 3.10.2 is our laboratory where we experiment with
various versions of BabyIDE.

A great deal of work remains to make BabyIDE generally available and
we are searching for a trailblazer who will take charge of it and take
it out into the world.

Keywords:
Personal Programming,
Novice Programming,
Single Global Machine,
IOT,
Smart Home,
MVC,
DCI,
BabyIDE,
Smalltalk,
Object Orientation

[3]
http://goran.krampe.se/2016/07/19/spry-is-a-smalltalk/


> On 09.05.2018 12:19, Marcus Denker wrote:
>>>
>>>
 I go back to Alan Kay's vision of a Dynabook: A/personal/computer
 for children of all ages. It should contain all its owner's
 /personal/data, including  his or her/personal/programs, as they
 evolve through the years.  Continuity is a must; the owner shall
 never loose data.

>>>
>>
>> Do you really expect that the dynabook will be 100% backward
>> compatible to Smalltalk-80?
>>
>> Marcus
>
> --
>
> /The essence of object orientation is that objects collaborateto achieve
> a goal. /
> Trygve Reenskaug mailto: tryg...@ifi.uio.no 
> Morgedalsvn. 5A http://folk.uio.no/trygver/
> N-0378 Oslo http://fullOO.info
> Norway Tel: (+47) 22 49 57 27
>
>

Re: [Pharo-users] Personal Programming onPharo

[Richard O'Keefe]

​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

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  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

Re: [Pharo-users] Personal Programming onPharo

[Dimitris Chloupis]

Cross platform support has always been a can of worms in any language. As
soon as one tries to do something that is not so popular it usually results
into several issues that may be there for years if not decades. Especially
in the case of third party libraries.

This is also one of the big reasons why many large project today are made
in multiple programming languages.

In my case, I battle with lack of good documentation about OpenGL which I
find very surprising, considering how popular as a library it is. In
theory, I should not experience such an issue but practice tends to always
have a different opinion.

Indeed, everything breaks and everything has its own issues which become
apparent as soon as you make heavy usage of the thing. Then of course you
have the case where the language or the library as you already mentioned
break compatibility intentionally. So instabilities are part of coding, you
learn to live with them and evade them to a reasonable degree.

On Wed, May 9, 2018 at 4:54 PM 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
>
> 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  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 d

Re: [Pharo-users] Personal Programming onPharo

[Trygve Reenskaug]

Hi Hannes,
It's great that you consider spending time on BabyIDE. Porting BabyIDE 
to Pharo needs to be done sooner or later, but it may be harder to find 
somebody who will actually use the results.(BabyIDE was first released 
10 years ago. AFAIK I am still the only user of the ST version.)


A plan for creating an alpha version of PP could be

1. Establish a project with funding and people (including project
   manager and lead programmer).
2. Use present BabyIDE to create a new and clean Squeak version with
   DCI architecture.
3. Port new BabyIDE to Pharo.
4. ...

We will then have a platform that extends Pharo with the new 
programming  paradigm for programming system behavior (use cases). This 
will be a valuable addition to Pharo as a tool for professional 
programmers. We will also have a platform for building an alpha version 
of PP.


/But before I do anything else, I have to finish my PP documentation on 
my home page

http://folk.uio.no/trygver/
 ./

More about DCI at
http://fulloo.info
http://fulloo.info/Examples/SqueakExamples/index.html    Includes code 
for examples
http://fulloo.info/Downloads/BabyIDE.zip     Includes Squeak BabyIDE 
image and Win7-VM.
  I'll update the ZIP if anybody is interested in 
actually running BabyIDE

--Trygve




On 08.05.2018 20:06, H. Hirzel wrote:

On 5/6/18, Trygve Reenskaug  wrote:

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.

Hello Tryge

Good to see that you reconsider to use Smalltalk in 2018, this time Pharo.

Am I assuming correctly that you want to continue to work on your IDE
which the supports the DCI (Data-Context-Interaction) programming
style [1]? The IDE was called "BabyIDE" [2].

In 2015 you wrote to the Squeak mailing  list that you are abandoning
Squeak (Squeak 3.8, 4.5 or 4.6 at that time and Smalltalk as a whole)
in favour of JavaScript, a mainstream language. That you now at least
reconsider to use Smalltalk (Pharo) is an interesting result as it
reinforces the idea that doing things the Smalltalk way is more
promising than going for JavaScript directly [6].

As for loading the BabyIDE into Squeak: It is noteworthy that after 10
years (done around Squeak version 3.8) of maintaining a fork the
Squeakland (Etoys) image has been merged back into Squeak 6.0a trunk.
[5]

I could actually load some of your tools last year into Squeak 6.0a
with very modest fixes last year. [2].

It seems that splitting your IDE enhancements into different parts
which can be treated independently will probably help.

And in addition helpful would be  IMHO to write HOW you construct
these tools and WHY you do it. These will help people to maintain your
code even if the underlying system changes.

It seems worthwhile to try out how it goes with the most recent Squeak
version, Squeak 6.0a trunk [8].

Another option is to wait a few months and look for the bootstrap
version of Pharo 7.
All the code is in readable format on github and various types of
image files may be built  build from it [7].

And the third option is to check out if Cuis (the third Smalltalk
which runs on the OpenSmalltalk [3] VM) suits your needs. [4]


Kind regards

Hannes Hirzel


---

[1] Data-Context-Interactionhttp://wiki.squeak.org/squeak/6048
[2] BabySREhttp://wiki.squeak.org/squeak/2550
[3]http://www.opensmalltalk.org/
[4] Cuis Smalltalk
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev  ; there is a Cuis
mailing list.
[5] Etoys in 2017http://wiki.squeak.org/squeak/6531
[6] Of course these days JavaScript cannot be avoided. But it is
preferable to generate it with a Smalltalk tool.
[7] The file format used in Pharo 7 is called Tonel (no exclamation marks!)
[8] Squeak 6.0a trunk downloadhttp://files.squeak.org/6.0alpha/




--

/The essence of object orientation is that objects collaborateto achieve 
a goal. /

Trygve Reenskaug mailto: tryg...@ifi.uio.no 
Morgedalsvn. 5A http://folk.uio.no/trygver/
N-0378 Oslo http://fullOO.info
Norway Tel: (+47) 22 49 57 27

Re: [Pharo-users] Personal Programming onPharo

[Trygve Reenskaug]

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 



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 tole

Re: [Pharo-users] Personal Programming onPharo

[David T. Lewis]

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 
> >
> >
> >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 is

Re: [Pharo-users] Personal Programming onPharo

[Travis Ayres]

There is no way to mark the language version, no
#pragma stdc version iso99


Delphi:

{$IF CompilerVersion >= 17.0}


Freepascal:


{$if FPC_VERSION > 2}



No make files: the compiler handles that trash for you.


Compatibility: Freepascal supports Delphi, Object Pascal, and has
various switches for all kinds of things should you need it.


Supports Windows, Linux, Mac, Android, Amiga (...seriously) and a
multitude of other systems.




On Wed, May 9, 2018, 6:54 AM 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
>
> 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  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 th