Saving a Smalltalk Project
I received the following message: *We started off doing a small project in conservation in South Africa that involved tracking Rhinos in a remote GPS denied environment and ended up with some impressive building blocks for a Big Data Platform for IoT. The platform includes its own GIS subsystem and parts of an Expert System. Due to the choice made by my business partner and handful of contractors the platform ended up being built in Smalltalk on Squeak VM and the Magma Object Database. We now believe we may have the beginning of a commercial platform however its notoriously difficult to find Smalltalk developers so I am in half minds to migrate to a platform which uses a more mainstream language (Java / Python) as I have been getting some strange reactions from Angel Investors / VCs and mainstream developers. ... I wanted to ask you if you have information on how big the Smalltalk community is and whether its better to migrate to Pharo from Squeak and what types of recent industrial projects youve come across that use Smalltalk? Also I wondered if you know of any active smalltalk group in Silicon Valley and what are the best forums for professional SmallTalk development.* I would very much like to save their project as a Smalltalk project. The principal issue seems to be finding enough Smalltalk developers. I don't know if they need on-site developers or if remote developers can pass muster. I strongly suspect the former. How hard would it be to find Smalltalkers willing to work in Silicon Valley, or South Africa? What is the best response to this person? Thanks. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
If they are interested, we can get in touch. We are working on IoT for environmental monitoring and Iâm working in Cameroon. Regards, Envoyé de mon iPad
Le 2 mai 2018 à 19:21, horrido <horrido.hobbies@gmail.com> a écrit :
I received the following message:
*We started off doing a small project in conservation in South Africa that involved tracking Rhinos in a remote GPS denied environment and ended up with some impressive building blocks for a Big Data Platform for IoT. The platform includes its own GIS subsystem and parts of an Expert System.
Due to the choice made by my business partner and handful of contractors the platform ended up being built in Smalltalk on Squeak VM and the Magma Object Database.
We now believe we may have the beginning of a commercial platform however its notoriously difficult to find Smalltalk developers so I am in half minds to migrate to a platform which uses a more mainstream language (Java / Python) as I have been getting some strange reactions from Angel Investors / VCs and mainstream developers.
...
I wanted to ask you if you have information on how big the Smalltalk community is and whether its better to migrate to Pharo from Squeak and what types of recent industrial projects youve come across that use Smalltalk?
Also I wondered if you know of any active smalltalk group in Silicon Valley and what are the best forums for professional SmallTalk development.*
I would very much like to save their project as a Smalltalk project. The principal issue seems to be finding enough Smalltalk developers. I don't know if they need on-site developers or if remote developers can pass muster. I strongly suspect the former.
How hard would it be to find Smalltalkers willing to work in Silicon Valley, or South Africa?
What is the best response to this person? Thanks.
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
OK, so I'm curious what hardware platforms you guys use for your "things"? Been doing things with Particle lately. Interested to try their new mesh offering.
On May 2, 2018, at 12:30 PM, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
If they are interested, we can get in touch. We are working on IoT for environmental monitoring and Iâm working in Cameroon.
Regards,
Envoyé de mon iPad
Le 2 mai 2018 à 19:21, horrido <horrido.hobbies@gmail.com> a écrit :
I received the following message:
*We started off doing a small project in conservation in South Africa that involved tracking Rhinos in a remote GPS denied environment and ended up with some impressive building blocks for a Big Data Platform for IoT. The platform includes its own GIS subsystem and parts of an Expert System.
Due to the choice made by my business partner and handful of contractors the platform ended up being built in Smalltalk on Squeak VM and the Magma Object Database.
We now believe we may have the beginning of a commercial platform however its notoriously difficult to find Smalltalk developers so I am in half minds to migrate to a platform which uses a more mainstream language (Java / Python) as I have been getting some strange reactions from Angel Investors / VCs and mainstream developers.
...
I wanted to ask you if you have information on how big the Smalltalk community is and whether its better to migrate to Pharo from Squeak and what types of recent industrial projects youve come across that use Smalltalk?
Also I wondered if you know of any active smalltalk group in Silicon Valley and what are the best forums for professional SmallTalk development.*
I would very much like to save their project as a Smalltalk project. The principal issue seems to be finding enough Smalltalk developers. I don't know if they need on-site developers or if remote developers can pass muster. I strongly suspect the former.
How hard would it be to find Smalltalkers willing to work in Silicon Valley, or South Africa?
What is the best response to this person? Thanks.
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Arduinos&Raspberry boards + Lora radio board Envoyé de mon iPhone
Le 3 mai 2018 à 02:40, Todd Blanchard <tblanchard@mac.com> a écrit :
OK, so I'm curious what hardware platforms you guys use for your "things"?
Been doing things with Particle lately. Interested to try their new mesh offering.
On May 2, 2018, at 12:30 PM, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
If they are interested, we can get in touch. We are working on IoT for environmental monitoring and Iâm working in Cameroon.
Regards,
Envoyé de mon iPad
Le 2 mai 2018 à 19:21, horrido <horrido.hobbies@gmail.com> a écrit :
I received the following message:
*We started off doing a small project in conservation in South Africa that involved tracking Rhinos in a remote GPS denied environment and ended up with some impressive building blocks for a Big Data Platform for IoT. The platform includes its own GIS subsystem and parts of an Expert System.
Due to the choice made by my business partner and handful of contractors the platform ended up being built in Smalltalk on Squeak VM and the Magma Object Database.
We now believe we may have the beginning of a commercial platform however its notoriously difficult to find Smalltalk developers so I am in half minds to migrate to a platform which uses a more mainstream language (Java / Python) as I have been getting some strange reactions from Angel Investors / VCs and mainstream developers.
...
I wanted to ask you if you have information on how big the Smalltalk community is and whether its better to migrate to Pharo from Squeak and what types of recent industrial projects youve come across that use Smalltalk?
Also I wondered if you know of any active smalltalk group in Silicon Valley and what are the best forums for professional SmallTalk development.*
I would very much like to save their project as a Smalltalk project. The principal issue seems to be finding enough Smalltalk developers. I don't know if they need on-site developers or if remote developers can pass muster. I strongly suspect the former.
How hard would it be to find Smalltalkers willing to work in Silicon Valley, or South Africa?
What is the best response to this person? Thanks.
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
horrido wrote
what types of recent industrial projects youve come across that use Smalltalk?
One that immediately comes to mind is Lam Research: https://pharo.org/success/LAMRC ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
That is the answer I would give: Biggest Smalltalk community in Silicon valley is likely the Lam Research one (dozens of devs). On my blog post talking about Smalltalk, I have 2k views per Smalltalk community-wide audience post, so the community is at least that big. Smalltalk conferences (Smalltalks and Esug) have usually around 200 attendees. To hire Smalltalk developers, a job offer mail through esug or pharo mailing list is one of the best way to get people to apply, other solutions include giving a 10 min talk at ESUG (Europe) or Smalltalks (Argentina) conference and say loud and clear you are hiring (people may be able to move to other countries). Getting a few developers should not be that hard if you accept remote positions. Migrating from Squeak to Pharo is something to discuss with the developers you hire, things like IoT and Magma DB support might not be easy to port, so it is difficult to tell with the little information provided. Pharo's community is likely the easiest to hire new Smalltalk developers though, and you can check the Pharo consortium website for support and success stories to ease communication with your investors and partners. On Wed, May 2, 2018, 20:21 horrido <horrido.hobbies@gmail.com> wrote:
I received the following message:
*We started off doing a small project in conservation in South Africa that involved tracking Rhinos in a remote GPS denied environment and ended up with some impressive building blocks for a Big Data Platform for IoT. The platform includes its own GIS subsystem and parts of an Expert System.
Due to the choice made by my business partner and handful of contractors the platform ended up being built in Smalltalk on Squeak VM and the Magma Object Database.
We now believe we may have the beginning of a commercial platform however its notoriously difficult to find Smalltalk developers so I am in half minds to migrate to a platform which uses a more mainstream language (Java / Python) as I have been getting some strange reactions from Angel Investors / VCs and mainstream developers.
...
I wanted to ask you if you have information on how big the Smalltalk community is and whether its better to migrate to Pharo from Squeak and what types of recent industrial projects youve come across that use Smalltalk?
Also I wondered if you know of any active smalltalk group in Silicon Valley and what are the best forums for professional SmallTalk development.*
I would very much like to save their project as a Smalltalk project. The principal issue seems to be finding enough Smalltalk developers. I don't know if they need on-site developers or if remote developers can pass muster. I strongly suspect the former.
How hard would it be to find Smalltalkers willing to work in Silicon Valley, or South Africa?
What is the best response to this person? Thanks.
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
horrido <horrido.hobbies@gmail.com> wrote:.
How hard would it be to find Smalltalkers willing to work in Silicon Valley, or South Africa?
What is the best response to this person? Thanks.
AFAIK it is not difficult at all to find Smalltalk developers. There are lots of them here, on the other smalltalk mailing lists and on our Discord. Pharo has a larger community, but HPI each year teaches Squeak to lots (80?) of students. It should not be difficult at all to find developers willing to work in Silicon Valley as long as youâd be able to afford them. I assume they would be at least three times as expensive there as in South Africa. The Smalltalkers youâll be able to find will most likely be either just graduated or very experienced. Stephan
Iâm a 20 year Smalltalker in Cleveland Ohio USA that would love to work another smalltalk project. It would have to be remote as Iâm unable to move due to family commitments, Brad Selfridge 913-269-2385
On May 4, 2018, at 12:03 PM, Stephan Eggermont <stephan@stack.nl> wrote:
horrido <horrido.hobbies@gmail.com> wrote:.
How hard would it be to find Smalltalkers willing to work in Silicon Valley, or South Africa?
What is the best response to this person? Thanks.
AFAIK it is not difficult at all to find Smalltalk developers. There are lots of them here, on the other smalltalk mailing lists and on our Discord. Pharo has a larger community, but HPI each year teaches Squeak to lots (80?) of students. It should not be difficult at all to find developers willing to work in Silicon Valley as long as youâd be able to afford them. I assume they would be at least three times as expensive there as in South Africa. The Smalltalkers youâll be able to find will most likely be either just graduated or very experienced.
Stephan
Precision Systems in Houston specializes in finding/placing Smalltalk developers in the U.S. Andrew -----Original Message----- From: Pharo-users <pharo-users-bounces@lists.pharo.org> On Behalf Of Brad Sent: Friday, May 4, 2018 1:15 PM To: Any question about pharo is welcome <pharo-users@lists.pharo.org> Subject: Re: [Pharo-users] Saving a Smalltalk Project Iâm a 20 year Smalltalker in Cleveland Ohio USA that would love to work another smalltalk project. It would have to be remote as Iâm unable to move due to family commitments, Brad Selfridge 913-269-2385
On May 4, 2018, at 12:03 PM, Stephan Eggermont <stephan@stack.nl> wrote:
horrido <horrido.hobbies@gmail.com> wrote:.
How hard would it be to find Smalltalkers willing to work in Silicon Valley, or South Africa?
What is the best response to this person? Thanks.
AFAIK it is not difficult at all to find Smalltalk developers. There are lots of them here, on the other smalltalk mailing lists and on our Discord. Pharo has a larger community, but HPI each year teaches Squeak to lots (80?) of students. It should not be difficult at all to find developers willing to work in Silicon Valley as long as youâd be able to afford them. I assume they would be at least three times as expensive there as in South Africa. The Smalltalkers youâll be able to find will most likely be either just graduated or very experienced.
Stephan
horrido <horrido.hobbies@gmail.com> wrote:
What is the best response to this person? Thanks.
Also, this is a project done by Chris Muller. He knows smalltalkers. https://news.squeak.org/2016/05/12/squeak-in-action/ That means the question has a political background. Why not ask him directly? Stephan
horrido wrote
I am in half minds to migrate to a platform which uses a more mainstream language (Java / Python) as I have been getting some strange reactions from Angel Investors / VCs and mainstream developers.
OT: It's ironic that Smalltalkers are often accused of NIH syndrome, but the first reaction of people from less "productive" languages/systems is to rewrite a working Smalltalk app in their language of comfort⦠----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Sean P. DeNigris <sean@clipperadams.com> wrote:
OT: It's ironic that Smalltalkers are often accused of NIH syndrome, but the first reaction of people from less "productive" languages/systems is to rewrite a working Smalltalk app in their language of comfortâ¦
Indeed. And rewriting something that also uses an OODB is going to kill productivity even more. 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
Stephan Eggermont wrote:
Sean P. DeNigris <sean@clipperadams.com> wrote:
OT: It's ironic that Smalltalkers are often accused of NIH syndrome, but the first reaction of people from less "productive" languages/systems is to rewrite a working Smalltalk app in their language of comfortâ¦
Indeed. And rewriting something that also uses an OODB is going to kill productivity even more. 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
Idealistic / naive question: is there a test suite for magma on squeak? Is it hard to port just this test suite as the first step to pharo?
Stephan
Herbert VojÄÃk <herby@mailbox.sk> wrote:
Idealistic / naive question: is there a test suite for magma on squeak? Is it hard to port just this test suite as the first step to pharo?
There is an extensive test suite. On the magma mailing list there have been enough discussions describing what is needed Stephan
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: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway                     Tel: (+47) 22 49 57 27
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@ifi.uio.no>:
I'm working on a programing paradigm and IDE for the personal programmer who wants to control his or her IoT. The size of the target audience I have in mind is >100 million. I gave up Squeak long ago as a platform because they obsolete my code faster than I can write it. I have now frozen Squeak 3.10.2 and hope its runtime will survive until I find a better foundation. My hope is that Pharo has a stable kernel that I can build on. According to Stephan, this is not so. Is there any plan for creating a stable Pharo kernel that people can use for building software of lasting value for millions of non-expert users? --Thanks, Trygve
On 05.05.2018 13:53, Stephan Eggermont wrote: Iâve taken a look at what would be needed to support magma on pharo a few years ago. Chris always told us he uses it professionally on squeak and has not enough capacity to keep up with changes in pharo without having a customer/maintainer for it. Twice a year or so someone asks about magma on pharo and takes a look. AFAIK there are no real obstacles to a port, but magma uses a lot of deep implementation specifics that will take an experienced smalltalker to deal with, and a lot of mailing list archeology as pharo changed a lot since magma worked on pharo last
Stephan
-- The essence of object orientation is that objects collaborate to achieve a goal. Trygve Reenskaug mailto: trygver@ifi.uio.no Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway Tel: (+47) 22 49 57 27
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.
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@hartl.name> 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@ifi.uio.no <mailto:trygver@ifi.uio.no>>:
I'm working on a programing paradigm and IDE for the personal programmer who wants to control his or her IoT. The size of the target audience I have in mind is >100 million. I gave up Squeak long ago as a platform because they obsolete my code faster than I can write it. I have now frozen Squeak 3.10.2 and hope its runtime will survive until I find a better foundation. My hope is that Pharo has a stable kernel that I can build on. According to Stephan, this is not so. Is there any plan for creating a stable Pharo kernel that people can use for building software of lasting value for millions of non-expert users? --Thanks, Trygve
On 05.05.2018 13:53, Stephan Eggermont wrote:
Iâve taken a look at what would be needed to support magma on pharo a few years ago. Chris always told us he uses it professionally on squeak and has not enough capacity to keep up with changes in pharo without having a customer/maintainer for it. Twice a year or so someone asks about magma on pharo and takes a look. AFAIK there are no real obstacles to a port, but magma uses a lot of deep implementation specifics that will take an experienced smalltalker to deal with, and a lot of mailing list archeology as pharo changed a lot since magma worked on pharo last
Stephan
-- The essence of object orientation is that objects collaborate to achieve a goal. Trygve Reenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ <http://folk.uio.no/trygver/> N-0378 Oslo http://fullOO.info <http://fulloo.info/> Norway Tel: (+47) 22 49 57 27
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.
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
<mailto:
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
<mailto:%
20trygver@.uio
>
Morgedalsvn. 5A http://folk.uio.no/trygver/ <http://folk.uio.no/trygver/>; N-0378 Oslo http://fullOO.info <http://fulloo.info/>; Norway Tel: (+47) 22 49 57 27
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
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 <tblanchard@mac.com>:
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.
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@hartl.name> 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@ifi.uio.no>:
I'm working on a programing paradigm and IDE for the personal programmer who wants to control his or her IoT. The size of the target audience I have in mind is >100 million. I gave up Squeak long ago as a platform because they obsolete my code faster than I can write it. I have now frozen Squeak 3.10.2 and hope its runtime will survive until I find a better foundation. My hope is that Pharo has a stable kernel that I can build on. According to Stephan, this is not so. Is there any plan for creating a stable Pharo kernel that people can use for building software of lasting value for millions of non-expert users? --Thanks, Trygve
On 05.05.2018 13:53, Stephan Eggermont wrote: Iâve taken a look at what would be needed to support magma on pharo a few years ago. Chris always told us he uses it professionally on squeak and has not enough capacity to keep up with changes in pharo without having a customer/maintainer for it. Twice a year or so someone asks about magma on pharo and takes a look. AFAIK there are no real obstacles to a port, but magma uses a lot of deep implementation specifics that will take an experienced smalltalker to deal with, and a lot of mailing list archeology as pharo changed a lot since magma worked on pharo last
Stephan
-- The essence of object orientation is that objects collaborate to achieve a goal. Trygve Reenskaug mailto: trygver@ifi.uio.no Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway Tel: (+47) 22 49 57 27
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 <trygver@ifi.uio.no <mailto:trygver@ifi.uio.no>>:
I'm working on a programing paradigm and IDE for the personal programmer who wants to control his or her IoT. The size of the target audience I have in mind is >100 million. I gave up Squeak long ago as a platform because they obsolete my code faster than I can write it. I have now frozen Squeak 3.10.2 and hope its runtime will survive until I find a better foundation. My hope is that Pharo has a stable kernel that I can build on. According to Stephan, this is not so. Is there any plan for creating a stable Pharo kernel that people can use for building software of lasting value for millions of non-expert users? --Thanks, Trygve
On 05.05.2018 13:53, Stephan Eggermont wrote:
Iâve taken a look at what would be needed to support magma on pharo a few years ago. Chris always told us he uses it professionally on squeak and/*has not enough capacity to keep up with changes in pharo without having a customer/maintainer for it.*/ Twice a year or so someone asks about magma on pharo and takes a look. AFAIK there are no real obstacles to a port, but magma uses a lot of deep implementation specifics that will take an experienced smalltalker to deal with, and a lot of mailing list archeology as pharo changed a lot since magma worked on pharo last
Stephan
--
/The essence of object orientation is that objects collaborateto achieve a goal. / Trygve Reenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@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 objects collaborateto achieve a goal. / Trygve Reenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway                     Tel: (+47) 22 49 57 27
I understand what you are saying but it contains some misconceptions about the modern software world. âThe earth is not stopping to turn just because you want to stay on the sunny sideâ There is two funny concepts going on in the modern software industry. The one tells you that because you want to do a product everything else around you should come to a full stop so can comfortably build your software not disturbed by other things. The second one tells you that you _have to upgrade_ ⦠there is this magical force preventing you from staying where you are. Both notions are funny alone but they come combined and then they turn out to be a non-sensical monster. Letâs take a different approach. Put in everything you say about software, libraries, etc the word version. So you can build upon Pharo version 3 your own product. You can stay at that version and it wonât change. If the software you sell is not 80% pharo but your own you should not have a problem just to stay on that version because you develop your own stuff. But still the world did not stop turning and there is pharo 4. You decide there are a few nice features but the work to adjust is too big to take the risk. Then there is pharo 5 and you ⦠nahhh not this timeâ¦.Then there is pharo6 and they not only changed the image but also the way source code is managed. That prevents you further from adjusting. But hey you can still be happy with pharo3 and it does not change. So what is the real problem? Yes, money/time is not enough. I think there are a lot of people risking their health to promote pharo and now we have a consortium that can pay engineers to do work on pharo. So let me tell you a future story: You see what pharo is doing and you think it is good. You can also see that there are too less resources to proceed in the way you need it to go. So you decide to show pharo to the world inspiring people with some kind of a vision. The result is that more people pay into the consortium and we hire more engineers. And then one day the consortium has enough money to pay engineers that can care about a LTS (long term support) version of pharo. So you can stay on pharo version 3 and still get those annoying bugs fixed. And hey this team has also enough time to provide you with tools that make a migration to pharo version 4 more easy and less annoying for you. And then you have your own product based on pharo version 4. And then for version 5, version 6,â¦. Sounds like a dreamâ¦but heyâ¦it is indeed realistic. It just depends on how the people approach it How does this sound? Norbert
Am 07.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver@ifi.uio.no>:
Thanks for your quick answer. I have only a fleeting knowledge of Pharo but liked what I saw. The Squeak class library has seen organic growth since 1978 or earlier. Pharo gave it a thorough overhaul. At the Pharo kernel was a minimal image with a minimal class library. The rest of the functionality was partitioned into packages that could be added to the kernel image as required. Beautiful. But only my dream? Matthew 7:24-27: And the rain fell, and the floods came, and the winds blew and beat on that house, but it did not fall, because it had been founded on the rock. And everyone who hears these words of mine and does not do them will be like a foolish man who built his house on the sand." I am developing an IDE for non-programmers called BabyIDE, a non-intrusive extension of Squeak. Where the Class Browser in Squeak is used to work with one class at the time, the BabyIDE browser is used to work with structures of collaborating objects, ignoring their classes. I would like to develop a BabyIDE image that gets broad usage and long life. I'm looking for a rock to build on and hoped it could be what I thought was the Pharo kernel+ a few selected packages. In your answer, I read that if I build BabyIDE on Pharo, I will be building on sand.
pharo.org <http://pharo.org/> writes: "Pharo is a pure object-oriented programming language...". The only language I can see is defined by the release image. A Pharo programmer builds application programs in this language. He or she can add new classes, change existing ones, subclass them, add or change methods, change the Smalltalk dictionary, etc. etc. An extremely flexible and powerful language.
A tale from the future when Pharo is a mainstream language: Business customers benefit from end users using applications that are written by Pharo programmers who built on the Pharo language and environment that had been developed by the Pharo community. One day there is a happy announcement: A new version of Pharo will be launched tomorrow. It is truly cool and includes any number of improvements, some of them documented. And, by the way, applications written in the current Pharo will no longer work. So please inform your customers that you will not be able to serve them for a while. We are confident that all your application programmers will be happy to drop whatever they are doing in order to adapt their applications to the new Pharo so that you can start serving your customers again.
Cheers --Trygve
On 06.05.2018 13:00, Norbert Hartl wrote:
Can you elaborate on what you consider as a kernel? There are always things moving in the pharo world. The last years the virtual machine got some iterations and it is still not fully stable. For pharo it is hard to have it stable because we feel the need that a lot of the existing parts need to be replaced to be useful in these times. Furthermore pharo is also prototyping platform for programming language features. All of these are counter-stability measures. So if you need a stable kernel from native ground up to UI pharo wonât be that thing you are looking for the coming years (if at all). You always need to adopt to change so you need to define your required scope better in order to get an estimate.
Norbert
Am 06.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver@ifi.uio.no <mailto:trygver@ifi.uio.no>>:
I'm working on a programing paradigm and IDE for the personal programmer who wants to control his or her IoT. The size of the target audience I have in mind is >100 million. I gave up Squeak long ago as a platform because they obsolete my code faster than I can write it. I have now frozen Squeak 3.10.2 and hope its runtime will survive until I find a better foundation. My hope is that Pharo has a stable kernel that I can build on. According to Stephan, this is not so. Is there any plan for creating a stable Pharo kernel that people can use for building software of lasting value for millions of non-expert users? --Thanks, Trygve
On 05.05.2018 13:53, Stephan Eggermont wrote:
Iâve taken a look at what would be needed to support magma on pharo a few years ago. Chris always told us he uses it professionally on squeak and has not enough capacity to keep up with changes in pharo without having a customer/maintainer for it. Twice a year or so someone asks about magma on pharo and takes a look. AFAIK there are no real obstacles to a port, but magma uses a lot of deep implementation specifics that will take an experienced smalltalker to deal with, and a lot of mailing list archeology as pharo changed a lot since magma worked on pharo last
Stephan
-- The essence of object orientation is that objects collaborate to achieve a goal. Trygve Reenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ <http://folk.uio.no/trygver/> N-0378 Oslo http://fullOO.info <http://fulloo.info/> Norway Tel: (+47) 22 49 57 27
-- The essence of object orientation is that objects collaborate to achieve a goal. Trygve Reenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ <http://folk.uio.no/trygver/> N-0378 Oslo http://fullOO.info <http://fulloo.info/> Norway Tel: (+47) 22 49 57 27
Please tell me when Java, C, C++, etc programs stopped working because their runtime systems had changed. Please tell me when Java, C, C++, etc compilers stopped compiling old code because the languages had changed. On 07.05.2018 11:57, Norbert Hartl wrote:
I understand what you are saying but it contains some misconceptions about the modern software world.
âThe earth is not stopping to turn just because you want to stay on the sunny sideâ
There is two funny concepts going on in the modern software industry. The one tells you that because you want to do a product everything else around you should come to a full stop so can comfortably build your software not disturbed by other things. The second one tells you that you _have to upgrade_ ⦠there is this magical force preventing you from staying where you are. Both notions are funny alone but they come combined and then they turn out to be a non-sensical monster.
Letâs take a different approach. Put in everything you say about software, libraries, etc the word version. So you can build upon Pharo version 3 your own product. You can stay at that version and it wonât change. If the software you sell is not 80% pharo but your own you should not have a problem just to stay on that version because you develop your own stuff. But still the world did not stop turning and there is pharo 4. You decide there are a few nice features but the work to adjust is too big to take the risk. Then there is pharo 5 and you ⦠nahhh not this timeâ¦.Then there is pharo6 and they not only changed the image but also the way source code is managed. That prevents you further from adjusting. But hey you can still be happy with pharo3 and it does not change.
So what is the real problem? Yes, money/time is not enough. I think there are a lot of people risking their health to promote pharo and now we have a consortium that can pay engineers to do work on pharo. So let me tell you a future story:
You see what pharo is doing and you think it is good. You can also see that there are too less resources to proceed in the way you need it to go. So you decide to show pharo to the world inspiring people with some kind of a vision. The result is that more people pay into the consortium and we hire more engineers. And then one day the consortium has enough money to pay engineers that can care about a LTS (long term support) version of pharo. So you can stay on pharo version 3 and still get those annoying bugs fixed. And hey this team has also enough time to provide you with tools that make a migration to pharo version 4 more easy and less annoying for you. And then you have your own product based on pharo version 4. And then for version 5, version 6,â¦. Sounds like a dreamâ¦but heyâ¦it is indeed realistic. It just depends on how the people approach it
How does this sound?
Norbert
Am 07.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver@ifi.uio.no <mailto:trygver@ifi.uio.no>>:
Thanks for your quick answer. I have only a fleeting knowledge of Pharo but liked what I saw. The Squeak class library has seen organic growth since 1978 or earlier. Pharo gave it a thorough overhaul. At the Pharo kernel was a minimal image with a minimal class library. The rest of the functionality was partitioned into packages that could be added to the kernel image as required. Beautiful. But only my dream?
/Matthew 7:24-27: And the rain fell, and the floods came, and the winds blew and beat on that house, but it did not fall, because it had been founded on the rock. And everyone who hears these words of mine and does not do them will be like a foolish man who built his house on the sand."/
I am developing an IDE for non-programmers called BabyIDE, a non-intrusive extension of Squeak. Where the Class Browser in Squeak is used to work with one class at the time, the BabyIDE browser is used to work with structures of collaborating objects, ignoring their classes. I would like to develop a BabyIDE image that gets broad usage and long life. I'm looking for a rock to build on and hoped it could be what I thought was the Pharo kernel+ a few selected packages. In your answer, I read that if I build BabyIDE on Pharo, I will be building on sand.
pharo.org <http://pharo.org/>writes: "/Pharo is a pure object-oriented programming language.../". The only language I can see is defined by the release image. A Pharo programmer builds application programs in this language. He or she can add new classes, change existing ones, subclass them, add or change methods, change the Smalltalk dictionary, etc. etc. An extremely flexible and powerful language.
A tale from the future when Pharo is a mainstream language:Business customers benefit from end users using applications that are written by Pharo programmers who built on the Pharo language and environment that had been developed by the Pharo community. One day there is a happy announcement: A new version of Pharo will be launched tomorrow. It is truly cool and includes any number of improvements, some of them documented. And, by the way, applications written in the current Pharo will no longer work. So please inform your customers that you will not be able to serve them for a while. We are confident that all your application programmers will be happy to drop whatever they are doing in order to adapt their applications to the new Pharo so that you can start serving your customers again.
Cheers --Trygve
On 06.05.2018 13:00, Norbert Hartl wrote:
Can you elaborate on what you consider as a kernel? There are always things moving in the pharo world. The last years the virtual machine got some iterations and it is still not fully stable. For pharo it is hard to have it stable because we feel the need that a lot of the existing parts need to be replaced to be useful in these times. Furthermore pharo is also prototyping platform for programming language features. All of these are counter-stability measures. So if you need a stable kernel from native ground up to UI pharo wonât be that thing you are looking for the coming years (if at all). You always need to adopt to change so you need to define your required scope better in order to get an estimate.
Norbert
Am 06.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver@ifi.uio.no <mailto:trygver@ifi.uio.no>>:
I'm working on a programing paradigm and IDE for the personal programmer who wants to control his or her IoT. The size of the target audience I have in mind is >100 million. I gave up Squeak long ago as a platform because they obsolete my code faster than I can write it. I have now frozen Squeak 3.10.2 and hope its runtime will survive until I find a better foundation. My hope is that Pharo has a stable kernel that I can build on. According to Stephan, this is not so. Is there any plan for creating a stable Pharo kernel that people can use for building software of lasting value for millions of non-expert users? --Thanks, Trygve
On 05.05.2018 13:53, Stephan Eggermont wrote:
Iâve taken a look at what would be needed to support magma on pharo a few years ago. Chris always told us he uses it professionally on squeak and/*has not enough capacity to keep up with changes in pharo without having a customer/maintainer for it.*/ Twice a year or so someone asks about magma on pharo and takes a look. AFAIK there are no real obstacles to a port, but magma uses a lot of deep implementation specifics that will take an experienced smalltalker to deal with, and a lot of mailing list archeology as pharo changed a lot since magma worked on pharo last
Stephan
-- /The essence of object orientation is that objectscollaboratetoachieve a goal./ TrygveReenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info <http://fulloo.info/> Norway                     Tel: (+47) 22 49 57 27
-- /The essence of object orientation is that objectscollaboratetoachieve a goal./ TrygveReenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info <http://fulloo.info/> Norway                     Tel: (+47) 22 49 57 27
-- /The essence of object orientation is that objects collaborateto achieve a goal. / Trygve Reenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway                     Tel: (+47) 22 49 57 27
Am 07.05.2018 um 12:42 schrieb Trygve Reenskaug <trygver@ifi.uio.no>:
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 <trygver@ifi.uio.no <mailto:trygver@ifi.uio.no>>:
Thanks for your quick answer. I have only a fleeting knowledge of Pharo but liked what I saw. The Squeak class library has seen organic growth since 1978 or earlier. Pharo gave it a thorough overhaul. At the Pharo kernel was a minimal image with a minimal class library. The rest of the functionality was partitioned into packages that could be added to the kernel image as required. Beautiful. But only my dream? Matthew 7:24-27: And the rain fell, and the floods came, and the winds blew and beat on that house, but it did not fall, because it had been founded on the rock. And everyone who hears these words of mine and does not do them will be like a foolish man who built his house on the sand." I am developing an IDE for non-programmers called BabyIDE, a non-intrusive extension of Squeak. Where the Class Browser in Squeak is used to work with one class at the time, the BabyIDE browser is used to work with structures of collaborating objects, ignoring their classes. I would like to develop a BabyIDE image that gets broad usage and long life. I'm looking for a rock to build on and hoped it could be what I thought was the Pharo kernel+ a few selected packages. In your answer, I read that if I build BabyIDE on Pharo, I will be building on sand.
pharo.org <http://pharo.org/> writes: "Pharo is a pure object-oriented programming language...". The only language I can see is defined by the release image. A Pharo programmer builds application programs in this language. He or she can add new classes, change existing ones, subclass them, add or change methods, change the Smalltalk dictionary, etc. etc. An extremely flexible and powerful language.
A tale from the future when Pharo is a mainstream language: Business customers benefit from end users using applications that are written by Pharo programmers who built on the Pharo language and environment that had been developed by the Pharo community. One day there is a happy announcement: A new version of Pharo will be launched tomorrow. It is truly cool and includes any number of improvements, some of them documented. And, by the way, applications written in the current Pharo will no longer work. So please inform your customers that you will not be able to serve them for a while. We are confident that all your application programmers will be happy to drop whatever they are doing in order to adapt their applications to the new Pharo so that you can start serving your customers again.
Cheers --Trygve
On 06.05.2018 13:00, Norbert Hartl wrote:
Can you elaborate on what you consider as a kernel? There are always things moving in the pharo world. The last years the virtual machine got some iterations and it is still not fully stable. For pharo it is hard to have it stable because we feel the need that a lot of the existing parts need to be replaced to be useful in these times. Furthermore pharo is also prototyping platform for programming language features. All of these are counter-stability measures. So if you need a stable kernel from native ground up to UI pharo wonât be that thing you are looking for the coming years (if at all). You always need to adopt to change so you need to define your required scope better in order to get an estimate.
Norbert
Am 06.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver@ifi.uio.no <mailto:trygver@ifi.uio.no>>:
I'm working on a programing paradigm and IDE for the personal programmer who wants to control his or her IoT. The size of the target audience I have in mind is >100 million. I gave up Squeak long ago as a platform because they obsolete my code faster than I can write it. I have now frozen Squeak 3.10.2 and hope its runtime will survive until I find a better foundation. My hope is that Pharo has a stable kernel that I can build on. According to Stephan, this is not so. Is there any plan for creating a stable Pharo kernel that people can use for building software of lasting value for millions of non-expert users? --Thanks, Trygve
On 05.05.2018 13:53, Stephan Eggermont wrote:
Iâve taken a look at what would be needed to support magma on pharo a few years ago. Chris always told us he uses it professionally on squeak and has not enough capacity to keep up with changes in pharo without having a customer/maintainer for it. Twice a year or so someone asks about magma on pharo and takes a look. AFAIK there are no real obstacles to a port, but magma uses a lot of deep implementation specifics that will take an experienced smalltalker to deal with, and a lot of mailing list archeology as pharo changed a lot since magma worked on pharo last
Stephan
-- The essence of object orientation is that objects collaborate to achieve a goal. Trygve Reenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ <http://folk.uio.no/trygver/> N-0378 Oslo http://fullOO.info <http://fulloo.info/> Norway Tel: (+47) 22 49 57 27
-- The essence of object orientation is that objects collaborate to achieve a goal. Trygve Reenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ <http://folk.uio.no/trygver/> N-0378 Oslo http://fullOO.info <http://fulloo.info/> Norway Tel: (+47) 22 49 57 27
-- The essence of object orientation is that objects collaborate to achieve a goal. Trygve Reenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ <http://folk.uio.no/trygver/> N-0378 Oslo http://fullOO.info <http://fulloo.info/> Norway Tel: (+47) 22 49 57 27
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 <trygver@ifi.uio.no <mailto:trygver@ifi.uio.no>>:
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 <trygver@ifi.uio.no <mailto:trygver@ifi.uio.no>>:
Thanks for your quick answer. I have only a fleeting knowledge of Pharo but liked what I saw. The Squeak class library has seen organic growth since 1978 or earlier. Pharo gave it a thorough overhaul. At the Pharo kernel was a minimal image with a minimal class library. The rest of the functionality was partitioned into packages that could be added to the kernel image as required. Beautiful. But only my dream?
/Matthew 7:24-27: And the rain fell, and the floods came, and the winds blew and beat on that house, but it did not fall, because it had been founded on the rock. And everyone who hears these words of mine and does not do them will be like a foolish man who built his house on the sand."/
I am developing an IDE for non-programmers called BabyIDE, a non-intrusive extension of Squeak. Where the Class Browser in Squeak is used to work with one class at the time, the BabyIDE browser is used to work with structures of collaborating objects, ignoring their classes. I would like to develop a BabyIDE image that gets broad usage and long life. I'm looking for a rock to build on and hoped it could be what I thought was the Pharo kernel+ a few selected packages. In your answer, I read that if I build BabyIDE on Pharo, I will be building on sand.
pharo.org <http://pharo.org/>writes: "/Pharo is a pure object-oriented programming language.../". The only language I can see is defined by the release image. A Pharo programmer builds application programs in this language. He or she can add new classes, change existing ones, subclass them, add or change methods, change the Smalltalk dictionary, etc. etc. An extremely flexible and powerful language.
A tale from the future when Pharo is a mainstream language:Business customers benefit from end users using applications that are written by Pharo programmers who built on the Pharo language and environment that had been developed by the Pharo community. One day there is a happy announcement: A new version of Pharo will be launched tomorrow. It is truly cool and includes any number of improvements, some of them documented. And, by the way, applications written in the current Pharo will no longer work. So please inform your customers that you will not be able to serve them for a while. We are confident that all your application programmers will be happy to drop whatever they are doing in order to adapt their applications to the new Pharo so that you can start serving your customers again.
Cheers --Trygve
On 06.05.2018 13:00, Norbert Hartl wrote:
Can you elaborate on what you consider as a kernel? There are always things moving in the pharo world. The last years the virtual machine got some iterations and it is still not fully stable. For pharo it is hard to have it stable because we feel the need that a lot of the existing parts need to be replaced to be useful in these times. Furthermore pharo is also prototyping platform for programming language features. All of these are counter-stability measures. So if you need a stable kernel from native ground up to UI pharo wonât be that thing you are looking for the coming years (if at all). You always need to adopt to change so you need to define your required scope better in order to get an estimate.
Norbert
Am 06.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver@ifi.uio.no <mailto:trygver@ifi.uio.no>>:
I'm working on a programing paradigm and IDE for the personal programmer who wants to control his or her IoT. The size of the target audience I have in mind is >100 million. I gave up Squeak long ago as a platform because they obsolete my code faster than I can write it. I have now frozen Squeak 3.10.2 and hope its runtime will survive until I find a better foundation. My hope is that Pharo has a stable kernel that I can build on. According to Stephan, this is not so. Is there any plan for creating a stable Pharo kernel that people can use for building software of lasting value for millions of non-expert users? --Thanks, Trygve
On 05.05.2018 13:53, Stephan Eggermont wrote:
Iâve taken a look at what would be needed to support magma on pharo a few years ago. Chris always told us he uses it professionally on squeak and/*has not enough capacity to keep up with changes in pharo without having a customer/maintainer for it.*/ Twice a year or so someone asks about magma on pharo and takes a look. AFAIK there are no real obstacles to a port, but magma uses a lot of deep implementation specifics that will take an experienced smalltalker to deal with, and a lot of mailing list archeology as pharo changed a lot since magma worked on pharo last
Stephan
--
-- /The essence of object orientation is that objects collaborateto achieve a goal. / Trygve Reenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway                     Tel: (+47) 22 49 57 27
Am 08.05.2018 um 08:30 schrieb Trygve Reenskaug <trygver@ifi.uio.no>:
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 <trygver@ifi.uio.no <mailto:trygver@ifi.uio.no>>:
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 <trygver@ifi.uio.no <mailto:trygver@ifi.uio.no>>:
Thanks for your quick answer. I have only a fleeting knowledge of Pharo but liked what I saw. The Squeak class library has seen organic growth since 1978 or earlier. Pharo gave it a thorough overhaul. At the Pharo kernel was a minimal image with a minimal class library. The rest of the functionality was partitioned into packages that could be added to the kernel image as required. Beautiful. But only my dream? Matthew 7:24-27: And the rain fell, and the floods came, and the winds blew and beat on that house, but it did not fall, because it had been founded on the rock. And everyone who hears these words of mine and does not do them will be like a foolish man who built his house on the sand." I am developing an IDE for non-programmers called BabyIDE, a non-intrusive extension of Squeak. Where the Class Browser in Squeak is used to work with one class at the time, the BabyIDE browser is used to work with structures of collaborating objects, ignoring their classes. I would like to develop a BabyIDE image that gets broad usage and long life. I'm looking for a rock to build on and hoped it could be what I thought was the Pharo kernel+ a few selected packages. In your answer, I read that if I build BabyIDE on Pharo, I will be building on sand.
pharo.org <http://pharo.org/> writes: "Pharo is a pure object-oriented programming language...". The only language I can see is defined by the release image. A Pharo programmer builds application programs in this language. He or she can add new classes, change existing ones, subclass them, add or change methods, change the Smalltalk dictionary, etc. etc. An extremely flexible and powerful language.
A tale from the future when Pharo is a mainstream language: Business customers benefit from end users using applications that are written by Pharo programmers who built on the Pharo language and environment that had been developed by the Pharo community. One day there is a happy announcement: A new version of Pharo will be launched tomorrow. It is truly cool and includes any number of improvements, some of them documented. And, by the way, applications written in the current Pharo will no longer work. So please inform your customers that you will not be able to serve them for a while. We are confident that all your application programmers will be happy to drop whatever they are doing in order to adapt their applications to the new Pharo so that you can start serving your customers again.
Cheers --Trygve
On 06.05.2018 13:00, Norbert Hartl wrote:
Can you elaborate on what you consider as a kernel? There are always things moving in the pharo world. The last years the virtual machine got some iterations and it is still not fully stable. For pharo it is hard to have it stable because we feel the need that a lot of the existing parts need to be replaced to be useful in these times. Furthermore pharo is also prototyping platform for programming language features. All of these are counter-stability measures. So if you need a stable kernel from native ground up to UI pharo wonât be that thing you are looking for the coming years (if at all). You always need to adopt to change so you need to define your required scope better in order to get an estimate.
Norbert
Am 06.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver@ifi.uio.no <mailto:trygver@ifi.uio.no>>:
I'm working on a programing paradigm and IDE for the personal programmer who wants to control his or her IoT. The size of the target audience I have in mind is >100 million. I gave up Squeak long ago as a platform because they obsolete my code faster than I can write it. I have now frozen Squeak 3.10.2 and hope its runtime will survive until I find a better foundation. My hope is that Pharo has a stable kernel that I can build on. According to Stephan, this is not so. Is there any plan for creating a stable Pharo kernel that people can use for building software of lasting value for millions of non-expert users? --Thanks, Trygve
On 05.05.2018 13:53, Stephan Eggermont wrote:
Iâve taken a look at what would be needed to support magma on pharo a few years ago. Chris always told us he uses it professionally on squeak and has not enough capacity to keep up with changes in pharo without having a customer/maintainer for it. Twice a year or so someone asks about magma on pharo and takes a look. AFAIK there are no real obstacles to a port, but magma uses a lot of deep implementation specifics that will take an experienced smalltalker to deal with, and a lot of mailing list archeology as pharo changed a lot since magma worked on pharo last
Stephan
--
-- The essence of object orientation is that objects collaborate to achieve a goal. Trygve Reenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ <http://folk.uio.no/trygver/> N-0378 Oslo http://fullOO.info <http://fulloo.info/> Norway Tel: (+47) 22 49 57 27
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 <norbert@hartl.name> wrote:
Am 08.05.2018 um 08:30 schrieb Trygve Reenskaug <trygver@ifi.uio.no>:
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 <trygver@ifi.uio.no>:
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 <trygver@ifi.uio.no>:
Thanks for your quick answer. I have only a fleeting knowledge of Pharo but liked what I saw. The Squeak class library has seen organic growth since 1978 or earlier. Pharo gave it a thorough overhaul. At the Pharo kernel was a minimal image with a minimal class library. The rest of the functionality was partitioned into packages that could be added to the kernel image as required. Beautiful. But only my dream? Matthew 7:24-27: And the rain fell, and the floods came, and the winds blew and beat on that house, but it did not fall, because it had been founded on the rock. And everyone who hears these words of mine and does not do them will be like a foolish man who built his house on the sand." I am developing an IDE for non-programmers called BabyIDE, a non-intrusive extension of Squeak. Where the Class Browser in Squeak is used to work with one class at the time, the BabyIDE browser is used to work with structures of collaborating objects, ignoring their classes. I would like to develop a BabyIDE image that gets broad usage and long life. I'm looking for a rock to build on and hoped it could be what I thought was the Pharo kernel+ a few selected packages. In your answer, I read that if I build BabyIDE on Pharo, I will be building on sand.
pharo.org writes: "Pharo is a pure object-oriented programming language...". The only language I can see is defined by the release image. A Pharo programmer builds application programs in this language. He or she can add new classes, change existing ones, subclass them, add or change methods, change the Smalltalk dictionary, etc. etc. An extremely flexible and powerful language.
A tale from the future when Pharo is a mainstream language: Business customers benefit from end users using applications that are written by Pharo programmers who built on the Pharo language and environment that had been developed by the Pharo community. One day there is a happy announcement: A new version of Pharo will be launched tomorrow. It is truly cool and includes any number of improvements, some of them documented. And, by the way, applications written in the current Pharo will no longer work. So please inform your customers that you will not be able to serve them for a while. We are confident that all your application programmers will be happy to drop whatever they are doing in order to adapt their applications to the new Pharo so that you can start serving your customers again.
Cheers --Trygve
On 06.05.2018 13:00, Norbert Hartl wrote:
Can you elaborate on what you consider as a kernel? There are always things moving in the pharo world. The last years the virtual machine got some iterations and it is still not fully stable. For pharo it is hard to have it stable because we feel the need that a lot of the existing parts need to be replaced to be useful in these times. Furthermore pharo is also prototyping platform for programming language features. All of these are counter-stability measures. So if you need a stable kernel from native ground up to UI pharo wonât be that thing you are looking for the coming years (if at all). You always need to adopt to change so you need to define your required scope better in order to get an estimate.
Norbert
Am 06.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver@ifi.uio.no>:
I'm working on a programing paradigm and IDE for the personal programmer who wants to control his or her IoT. The size of the target audience I have in mind is >100 million. I gave up Squeak long ago as a platform because they obsolete my code faster than I can write it. I have now frozen Squeak 3.10.2 and hope its runtime will survive until I find a better foundation. My hope is that Pharo has a stable kernel that I can build on. According to Stephan, this is not so. Is there any plan for creating a stable Pharo kernel that people can use for building software of lasting value for millions of non-expert users? --Thanks, Trygve
On 05.05.2018 13:53, Stephan Eggermont wrote:
Iâve taken a look at what would be needed to support magma on pharo a few years ago. Chris always told us he uses it professionally on squeak and has not enough capacity to keep up with changes in pharo without having a customer/maintainer for it. Twice a year or so someone asks about magma on pharo and takes a look. AFAIK there are no real obstacles to a port, but magma uses a lot of deep implementation specifics that will take an experienced smalltalker to deal with, and a lot of mailing list archeology as pharo changed a lot since magma worked on pharo last
Stephan
--
-- The essence of object orientation is that objects collaborate to achieve a goal. Trygve Reenskaug mailto: trygver@ifi.uio.no Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway Tel: (+47) 22 49 57 27
-- www.tudorgirba.com www.feenk.com "Obvious things are difficult to teach."
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 <trygver@ifi.uio.no <mailto:trygver@ifi.uio.no>>:
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 <trygver@ifi.uio.no <mailto:trygver@ifi.uio.no>>:
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 <trygver@ifi.uio.no <mailto:trygver@ifi.uio.no>>:
Thanks for your quick answer. I have only a fleeting knowledge of Pharo but liked what I saw. The Squeak class library has seen organic growth since 1978 or earlier. Pharo gave it a thorough overhaul. At the Pharo kernel was a minimal image with a minimal class library. The rest of the functionality was partitioned into packages that could be added to the kernel image as required. Beautiful. But only my dream?
/Matthew 7:24-27: And the rain fell, and the floods came, and the winds blew and beat on that house, but it did not fall, because it had been founded on the rock. And everyone who hears these words of mine and does not do them will be like a foolish man who built his house on the sand."/
I am developing an IDE for non-programmers called BabyIDE, a non-intrusive extension of Squeak. Where the Class Browser in Squeak is used to work with one class at the time, the BabyIDE browser is used to work with structures of collaborating objects, ignoring their classes. I would like to develop a BabyIDE image that gets broad usage and long life. I'm looking for a rock to build on and hoped it could be what I thought was the Pharo kernel+ a few selected packages. In your answer, I read that if I build BabyIDE on Pharo, I will be building on sand.
pharo.org <http://pharo.org/>writes: "/Pharo is a pure object-oriented programming language.../". The only language I can see is defined by the release image. A Pharo programmer builds application programs in this language. He or she can add new classes, change existing ones, subclass them, add or change methods, change the Smalltalk dictionary, etc. etc. An extremely flexible and powerful language.
A tale from the future when Pharo is a mainstream language:Business customers benefit from end users using applications that are written by Pharo programmers who built on the Pharo language and environment that had been developed by the Pharo community. One day there is a happy announcement: A new version of Pharo will be launched tomorrow. It is truly cool and includes any number of improvements, some of them documented. And, by the way, applications written in the current Pharo will no longer work. So please inform your customers that you will not be able to serve them for a while. We are confident that all your application programmers will be happy to drop whatever they are doing in order to adapt their applications to the new Pharo so that you can start serving your customers again.
Cheers --Trygve
On 06.05.2018 13:00, Norbert Hartl wrote:
Can you elaborate on what you consider as a kernel? There are always things moving in the pharo world. The last years the virtual machine got some iterations and it is still not fully stable. For pharo it is hard to have it stable because we feel the need that a lot of the existing parts need to be replaced to be useful in these times. Furthermore pharo is also prototyping platform for programming language features. All of these are counter-stability measures. So if you need a stable kernel from native ground up to UI pharo wonât be that thing you are looking for the coming years (if at all). You always need to adopt to change so you need to define your required scope better in order to get an estimate.
Norbert
Am 06.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver@ifi.uio.no <mailto:trygver@ifi.uio.no>>:
I'm working on a programing paradigm and IDE for the personal programmer who wants to control his or her IoT. The size of the target audience I have in mind is >100 million. I gave up Squeak long ago as a platform because they obsolete my code faster than I can write it. I have now frozen Squeak 3.10.2 and hope its runtime will survive until I find a better foundation. My hope is that Pharo has a stable kernel that I can build on. According to Stephan, this is not so. Is there any plan for creating a stable Pharo kernel that people can use for building software of lasting value for millions of non-expert users? --Thanks, Trygve
On 05.05.2018 13:53, Stephan Eggermont wrote:
Iâve taken a look at what would be needed to support magma on pharo a few years ago. Chris always told us he uses it professionally on squeak and/*has not enough capacity to keep up with changes in pharo without having a customer/maintainer for it.*/ Twice a year or so someone asks about magma on pharo and takes a look. AFAIK there are no real obstacles to a port, but magma uses a lot of deep implementation specifics that will take an experienced smalltalker to deal with, and a lot of mailing list archeology as pharo changed a lot since magma worked on pharo last
Stephan
--
-- /The essence of object orientation is that objectscollaboratetoachieve a goal./ TrygveReenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info <http://fulloo.info/> Norway                     Tel: (+47) 22 49 57 27
-- /The essence of object orientation is that objects collaborateto achieve a goal. / Trygve Reenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway                     Tel: (+47) 22 49 57 27
On 5/6/18, Trygve Reenskaug <trygver@ifi.uio.no> 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-Interaction http://wiki.squeak.org/squeak/6048 [2] BabySRE http://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 2017 http://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 download http://files.squeak.org/6.0alpha/
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<trygver@ifi.uio.no> 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: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway                     Tel: (+47) 22 49 57 27
Hello Trygve I am interested in an updated zip file of http://fulloo.info/Downloads/BabyIDE.zip (Squeak 3.10) Includes Squeak BabyIDE image and Win7-VM. As you write a new Squeak version will come later. --Hannes On 5/10/18, Trygve Reenskaug <trygver@ifi.uio.no> wrote:
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<trygver@ifi.uio.no> 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: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway Tel: (+47) 22 49 57 27
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
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: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway                     Tel: (+47) 22 49 57 27
On 5/9/18, Trygve Reenskaug <trygver@ifi.uio.no> 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-Supe... 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-Supe... 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: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway Tel: (+47) 22 49 57 27
Trygve Reenskaug <trygver@ifi.uio.no> wrote:
Please tell me when Java, C, C++, etc programs stopped working because their runtime systems had changed. Please tell me when Java, C, C++, etc compilers stopped compiling old code because the languages had changed.
Oracle lists 24 behavioral incompatibilities between Java SE 7 and SE 6. Stephan
On Mon, May 7, 2018 at 1:43 PM Trygve Reenskaug <trygver@ifi.uio.no> wrote:
Please tell me when Java, C, C++, etc programs stopped working because their runtime systems had changed. Please tell me when Java, C, C++, etc compilers stopped compiling old code because the languages had changed.
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.
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 <kilon.alios@gmail.com> wrote:
On Mon, May 7, 2018 at 1:43 PM Trygve Reenskaug <trygver@ifi.uio.no> wrote:
Please tell me when Java, C, C++, etc programs stopped working because their runtime systems had changed. Please tell me when Java, C, C++, etc compilers stopped compiling old code because the languages had changed.
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.
â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.... where we learned that the 'apt' tool was gone, the JDBC-ODBC bridge was gone, 32-bit Solaris support (and yes, I was still using 32-bit code in SPARC Solaris and Intel Solaris) was gone, and the type inference algorithm had changed in a way that could break things. I am still somewhat peeved about some of the rewriting I've had to do over the last several releases. Then there is the simple fact that porting code from one release of an OS to another can be a pain. Solaris 10 to OpenSolaris was easy. OpenSolaris to Solaris 11 was not as painless. Solaris 11 to OpenIndiana was not a happy time for me. OpenBSD changes forced rework. I'd finally got my program to port smoothly between Solaris, Darwin, and Linux. And then I had trouble porting to the next major release of Linux. And with Ubuntu 17, I've got another problem I still haven't tracked down. All of this in a C program that gets regularly (sp)linted and checked all sorts of ways, written with the intention of producing portable code. EVERYTHING BREAKS. On 7 May 2018 at 22:42, Trygve Reenskaug <trygver@ifi.uio.no> wrote:
Please tell me when Java, C, C++, etc programs stopped working because their runtime systems had changed. Please tell me when Java, C, C++, etc compilers stopped compiling old code because the languages had changed.
On 07.05.2018 11:57, Norbert Hartl wrote:
I understand what you are saying but it contains some misconceptions about the modern software world.
âThe earth is not stopping to turn just because you want to stay on the sunny sideâ
There is two funny concepts going on in the modern software industry. The one tells you that because you want to do a product everything else around you should come to a full stop so can comfortably build your software not disturbed by other things. The second one tells you that you _have to upgrade_ ⦠there is this magical force preventing you from staying where you are. Both notions are funny alone but they come combined and then they turn out to be a non-sensical monster.
Letâs take a different approach. Put in everything you say about software, libraries, etc the word version. So you can build upon Pharo version 3 your own product. You can stay at that version and it wonât change. If the software you sell is not 80% pharo but your own you should not have a problem just to stay on that version because you develop your own stuff. But still the world did not stop turning and there is pharo 4. You decide there are a few nice features but the work to adjust is too big to take the risk. Then there is pharo 5 and you ⦠nahhh not this timeâ¦.Then there is pharo6 and they not only changed the image but also the way source code is managed. That prevents you further from adjusting. But hey you can still be happy with pharo3 and it does not change.
So what is the real problem? Yes, money/time is not enough. I think there are a lot of people risking their health to promote pharo and now we have a consortium that can pay engineers to do work on pharo. So let me tell you a future story:
You see what pharo is doing and you think it is good. You can also see that there are too less resources to proceed in the way you need it to go. So you decide to show pharo to the world inspiring people with some kind of a vision. The result is that more people pay into the consortium and we hire more engineers. And then one day the consortium has enough money to pay engineers that can care about a LTS (long term support) version of pharo. So you can stay on pharo version 3 and still get those annoying bugs fixed. And hey this team has also enough time to provide you with tools that make a migration to pharo version 4 more easy and less annoying for you. And then you have your own product based on pharo version 4. And then for version 5, version 6,â¦. Sounds like a dreamâ¦but heyâ¦it is indeed realistic. It just depends on how the people approach it
How does this sound?
Norbert
Am 07.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver@ifi.uio.no>:
Thanks for your quick answer. I have only a fleeting knowledge of Pharo but liked what I saw. The Squeak class library has seen organic growth since 1978 or earlier. Pharo gave it a thorough overhaul. At the Pharo kernel was a minimal image with a minimal class library. The rest of the functionality was partitioned into packages that could be added to the kernel image as required. Beautiful. But only my dream?
*Matthew 7:24-27: And the rain fell, and the floods came, and the winds blew and beat on that house, but it did not fall, because it had been founded on the rock. And everyone who hears these words of mine and does not do them will be like a foolish man who built his house on the sand."*
I am developing an IDE for non-programmers called BabyIDE, a non-intrusive extension of Squeak. Where the Class Browser in Squeak is used to work with one class at the time, the BabyIDE browser is used to work with structures of collaborating objects, ignoring their classes. I would like to develop a BabyIDE image that gets broad usage and long life. I'm looking for a rock to build on and hoped it could be what I thought was the Pharo kernel+ a few selected packages. In your answer, I read that if I build BabyIDE on Pharo, I will be building on sand.
pharo.org writes: "*Pharo is a pure object-oriented programming language...*". The only language I can see is defined by the release image. A Pharo programmer builds application programs in this language. He or she can add new classes, change existing ones, subclass them, add or change methods, change the Smalltalk dictionary, etc. etc. An extremely flexible and powerful language.
A tale from the future when Pharo is a mainstream language: Business customers benefit from end users using applications that are written by Pharo programmers who built on the Pharo language and environment that had been developed by the Pharo community. One day there is a happy announcement: A new version of Pharo will be launched tomorrow. It is truly cool and includes any number of improvements, some of them documented. And, by the way, applications written in the current Pharo will no longer work. So please inform your customers that you will not be able to serve them for a while. We are confident that all your application programmers will be happy to drop whatever they are doing in order to adapt their applications to the new Pharo so that you can start serving your customers again.
Cheers --Trygve
On 06.05.2018 13:00, Norbert Hartl wrote:
Can you elaborate on what you consider as a kernel? There are always things moving in the pharo world. The last years the virtual machine got some iterations and it is still not fully stable. For pharo it is hard to have it stable because we feel the need that a lot of the existing parts need to be replaced to be useful in these times. Furthermore pharo is also prototyping platform for programming language features. All of these are counter-stability measures. So if you need a stable kernel from native ground up to UI pharo wonât be that thing you are looking for the coming years (if at all). You always need to adopt to change so you need to define your required scope better in order to get an estimate.
Norbert
Am 06.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver@ifi.uio.no>:
I'm working on a programing paradigm and IDE for the personal programmer who wants to control his or her IoT. The size of the target audience I have in mind is >100 million. I gave up Squeak long ago as a platform because they obsolete my code faster than I can write it. I have now frozen Squeak 3.10.2 and hope its runtime will survive until I find a better foundation. My hope is that Pharo has a stable kernel that I can build on. According to Stephan, this is not so. Is there any plan for creating a stable Pharo kernel that people can use for building software of lasting value for millions of non-expert users? --Thanks, Trygve
On 05.05.2018 13:53, Stephan Eggermont wrote:
Iâve taken a look at what would be needed to support magma on pharo a few years ago. Chris always told us he uses it professionally on squeak and *has not enough capacity to keep up with changes in pharo without having a customer/maintainer for it.* Twice a year or so someone asks about magma on pharo and takes a look. AFAIK there are no real obstacles to a port, but magma uses a lot of deep implementation specifics that will take an experienced smalltalker to deal with, and a lot of mailing list archeology as pharo changed a lot since magma worked on pharo last
Stephan
-- *The essence of object orientation is that objects collaborate to achieve a goal. * Trygve Reenskaug mailto: trygver@ifi.uio.no <%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info <http://fulloo.info/> Norway Tel: (+47) 22 49 57 27
-- *The essence of object orientation is that objects collaborate to achieve a goal. * Trygve Reenskaug mailto: trygver@ifi.uio.no <%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info <http://fulloo.info/> Norway Tel: (+47) 22 49 57 27
--
*The essence of object orientation is that objects collaborate to achieve a goal. * Trygve Reenskaug mailto: trygver@ifi.uio.no <%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway Tel: (+47) 22 49 57 27
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 <raoknz@gmail.com> 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.... where we learned that the 'apt' tool was gone, the JDBC-ODBC bridge was gone, 32-bit Solaris support (and yes, I was still using 32-bit code in SPARC Solaris and Intel Solaris) was gone, and the type inference algorithm had changed in a way that could break things. I am still somewhat peeved about some of the rewriting I've had to do over the last several releases.
Then there is the simple fact that porting code from one release of an OS to another can be a pain. Solaris 10 to OpenSolaris was easy. OpenSolaris to Solaris 11 was not as painless. Solaris 11 to OpenIndiana was not a happy time for me. OpenBSD changes forced rework. I'd finally got my program to port smoothly between Solaris, Darwin, and Linux. And then I had trouble porting to the next major release of Linux. And with Ubuntu 17, I've got another problem I still haven't tracked down. All of this in a C program that gets regularly (sp)linted and checked all sorts of ways, written with the intention of producing portable code.
EVERYTHING BREAKS.
On 7 May 2018 at 22:42, Trygve Reenskaug <trygver@ifi.uio.no> wrote:
Please tell me when Java, C, C++, etc programs stopped working because their runtime systems had changed. Please tell me when Java, C, C++, etc compilers stopped compiling old code because the languages had changed.
On 07.05.2018 11:57, Norbert Hartl wrote:
I understand what you are saying but it contains some misconceptions about the modern software world.
âThe earth is not stopping to turn just because you want to stay on the sunny sideâ
There is two funny concepts going on in the modern software industry. The one tells you that because you want to do a product everything else around you should come to a full stop so can comfortably build your software not disturbed by other things. The second one tells you that you _have to upgrade_ ⦠there is this magical force preventing you from staying where you are. Both notions are funny alone but they come combined and then they turn out to be a non-sensical monster.
Letâs take a different approach. Put in everything you say about software, libraries, etc the word version. So you can build upon Pharo version 3 your own product. You can stay at that version and it wonât change. If the software you sell is not 80% pharo but your own you should not have a problem just to stay on that version because you develop your own stuff. But still the world did not stop turning and there is pharo 4. You decide there are a few nice features but the work to adjust is too big to take the risk. Then there is pharo 5 and you ⦠nahhh not this timeâ¦.Then there is pharo6 and they not only changed the image but also the way source code is managed. That prevents you further from adjusting. But hey you can still be happy with pharo3 and it does not change.
So what is the real problem? Yes, money/time is not enough. I think there are a lot of people risking their health to promote pharo and now we have a consortium that can pay engineers to do work on pharo. So let me tell you a future story:
You see what pharo is doing and you think it is good. You can also see that there are too less resources to proceed in the way you need it to go. So you decide to show pharo to the world inspiring people with some kind of a vision. The result is that more people pay into the consortium and we hire more engineers. And then one day the consortium has enough money to pay engineers that can care about a LTS (long term support) version of pharo. So you can stay on pharo version 3 and still get those annoying bugs fixed. And hey this team has also enough time to provide you with tools that make a migration to pharo version 4 more easy and less annoying for you. And then you have your own product based on pharo version 4. And then for version 5, version 6,â¦. Sounds like a dreamâ¦but heyâ¦it is indeed realistic. It just depends on how the people approach it
How does this sound?
Norbert
Am 07.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver@ifi.uio.no>:
Thanks for your quick answer. I have only a fleeting knowledge of Pharo but liked what I saw. The Squeak class library has seen organic growth since 1978 or earlier. Pharo gave it a thorough overhaul. At the Pharo kernel was a minimal image with a minimal class library. The rest of the functionality was partitioned into packages that could be added to the kernel image as required. Beautiful. But only my dream?
*Matthew 7:24-27: And the rain fell, and the floods came, and the winds blew and beat on that house, but it did not fall, because it had been founded on the rock. And everyone who hears these words of mine and does not do them will be like a foolish man who built his house on the sand."*
I am developing an IDE for non-programmers called BabyIDE, a non-intrusive extension of Squeak. Where the Class Browser in Squeak is used to work with one class at the time, the BabyIDE browser is used to work with structures of collaborating objects, ignoring their classes. I would like to develop a BabyIDE image that gets broad usage and long life. I'm looking for a rock to build on and hoped it could be what I thought was the Pharo kernel+ a few selected packages. In your answer, I read that if I build BabyIDE on Pharo, I will be building on sand.
pharo.org writes: "*Pharo is a pure object-oriented programming language...*". The only language I can see is defined by the release image. A Pharo programmer builds application programs in this language. He or she can add new classes, change existing ones, subclass them, add or change methods, change the Smalltalk dictionary, etc. etc. An extremely flexible and powerful language.
A tale from the future when Pharo is a mainstream language: Business customers benefit from end users using applications that are written by Pharo programmers who built on the Pharo language and environment that had been developed by the Pharo community. One day there is a happy announcement: A new version of Pharo will be launched tomorrow. It is truly cool and includes any number of improvements, some of them documented. And, by the way, applications written in the current Pharo will no longer work. So please inform your customers that you will not be able to serve them for a while. We are confident that all your application programmers will be happy to drop whatever they are doing in order to adapt their applications to the new Pharo so that you can start serving your customers again.
Cheers --Trygve
On 06.05.2018 13:00, Norbert Hartl wrote:
Can you elaborate on what you consider as a kernel? There are always things moving in the pharo world. The last years the virtual machine got some iterations and it is still not fully stable. For pharo it is hard to have it stable because we feel the need that a lot of the existing parts need to be replaced to be useful in these times. Furthermore pharo is also prototyping platform for programming language features. All of these are counter-stability measures. So if you need a stable kernel from native ground up to UI pharo wonât be that thing you are looking for the coming years (if at all). You always need to adopt to change so you need to define your required scope better in order to get an estimate.
Norbert
Am 06.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver@ifi.uio.no>:
I'm working on a programing paradigm and IDE for the personal programmer who wants to control his or her IoT. The size of the target audience I have in mind is >100 million. I gave up Squeak long ago as a platform because they obsolete my code faster than I can write it. I have now frozen Squeak 3.10.2 and hope its runtime will survive until I find a better foundation. My hope is that Pharo has a stable kernel that I can build on. According to Stephan, this is not so. Is there any plan for creating a stable Pharo kernel that people can use for building software of lasting value for millions of non-expert users? --Thanks, Trygve
On 05.05.2018 13:53, Stephan Eggermont wrote:
Iâve taken a look at what would be needed to support magma on pharo a few years ago. Chris always told us he uses it professionally on squeak and *has not enough capacity to keep up with changes in pharo without having a customer/maintainer for it.* Twice a year or so someone asks about magma on pharo and takes a look. AFAIK there are no real obstacles to a port, but magma uses a lot of deep implementation specifics that will take an experienced smalltalker to deal with, and a lot of mailing list archeology as pharo changed a lot since magma worked on pharo last
Stephan
-- *The essence of object orientation is that objects collaborate to achieve a goal. * Trygve Reenskaug mailto: trygver@ifi.uio.no <%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info <http://fulloo.info/> Norway Tel: (+47) 22 49 57 27
-- *The essence of object orientation is that objects collaborate to achieve a goal. * Trygve Reenskaug mailto: trygver@ifi.uio.no <%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info <http://fulloo.info/> Norway Tel: (+47) 22 49 57 27 <+47%2022%2049%2057%2027>
--
*The essence of object orientation is that objects collaborate to achieve a goal. * Trygve Reenskaug mailto: trygver@ifi.uio.no <%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway Tel: (+47) 22 49 57 27 <+47%2022%2049%2057%2027>
At 87, I'm an old man. I'm told that I don't understand modern software, which is true. I use some programs daily: WIN7, Pharo, Thunderbird, ... From time to time, I am told that a new version of the program that fixes bugs and improves security is available. Press the button to install it. So I wonder: Is modern software out of control? Does /anybody /understand it, or is it so complicated that it is beyond human comprehension? Why didn't they get it right the first time? Most of us have the GOF book on Design Patterns on our bookshelf. In the introduction, they write: /An object-oriented program's runtime structure often bears little resemblance to its code structure. The code structure is frozen at compile-time; it consists of classes in fixed inheritance relationships. The runtime structure consists of rapidly changing networks of communicating objects.[GOF-95] p. 22./  and /â¦, it's clear that code won't reveal everything about how a system will work. [ibid.p.23]/ Modern programmers are thus reduced to relying on testing the code. In the words of Edsger Dijstra: /"Program testing can be used to show the presence of bugs, but never to show their absence!"[REF] / Modern programmers know all this but accept it as an unavoidable part of progress. Some may have seen it as a challenge, but they are up against the enormous inertia of a community who haven't changed their fundamental model of programming since the advent of the von Neumann stored program computer in 1948. I can't resist another quote; this time from Tony Hoare's TuringAward lecture: /âThere are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. â¦[Hoare-81]/ In the lecture, Hoare was bemoaning his unsuccessful fight for simplicity. Developers, particularly committees of developers, seem to love complexity for its own sake. I have never accepted that bugs are an unavoidable part of software.(See "2.   Get it Right the First Time" in the draft article). Bugs are parts of the facts of life but they are not an acceptable part of it. Ideally, my software should be /so simple that there are obviously no deficiencies. /One of my attempts at coming to grips with the problem is the DCI programming paradigm. Here, /the runtime structure of rapidly changing networks of communicating objects/ is specified in explicit code that says (almost) everything about what happens at runtime. Wouldn't it be wonderful if Pharo were to become first to overcome the GOF limitation? I challenge you to play with BabyIDE on Squeak and become convinced that it is a step in the right direction. I won't reread this message before I send it. I suppose it's controversial and should probably delete some or all of it to avoid angry answers. Another reason why I probably shouldn't send it is that I do not have time to engage in a discussion. I /must /give priority to finishing my article on DCI and PP. (A ~50 page draft is on my home page; it will be updated from time to time) I press the SEND button with a shaking hand --Trygve On 09.05.2018 15:53, Richard O'Keefe wrote:
âI have a C++ program written in the late 80s by someone else. It used to run fine under cfront 2.0 and early g++. Ten years after it was written it was impossible to compile.
*Since* that there have been changes to streams and strings, amongst other things.
The 1989 C standard changed the semantics of mixed signed/unsigned integer arithmetic. It also inadvertently rendered illegal a widely used technique. It is notoriously the case these days that compilers taking the C standards literally have "broken" quite a lot of code that worked with less ambitious compilers. I have been watching this phenomenon with considerable nervousness. See for example http://www.eng.utah.edu/~cs5785/slides-f10/Dangerous+Optimizations.pdf <http://www.eng.utah.edu/%7Ecs5785/slides-f10/Dangerous+Optimizations.pdf>
I have certainly had previously acceptable C89 code be rejected by compilers as not being legal C11. It is true that compilers tend to have command line/IDE switches to ask that old code be compiled under old rules, but you cannot say that *in* the program. There is no way to mark the language version, no    #pragma stdc version iso99
As for Java, I could rant about the floods of deprecation warnings from old code. I shall content myself with one observation. Read http://java-performance.info/changes-to-string-java-1-7-0_06/ Before Java 1.7, the substring operation in Java took O(1) time and space. From Java 1.7 on, it takes time and space linear in the size of the result. The syntax and abstract semantics did not change but the pragmatics did. Code that had adequate performance could suddenly start crawling.
Oracle do a tolerably thorough job of describing compatibility issues between JDK releases. See for example http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.... where we learned that the 'apt' tool was gone, the JDBC-ODBC bridge was gone, 32-bit Solaris support (and yes, I was still using 32-bit code in SPARC Solaris and Intel Solaris) was gone, and the type inference algorithm had changed in a way that could break things. I am still somewhat peeved about some of the rewriting I've had to do over the last several releases.
Then there is the simple fact that porting code from one release of an OS to another can be a pain. Solaris 10 to OpenSolaris was easy. OpenSolaris to Solaris 11 was not as painless. Solaris 11 to OpenIndiana was not a happy time for me. OpenBSD changes forced rework. I'd finally got my program to port smoothly between Solaris, Darwin, and Linux. And then I had trouble porting to the next major release of Linux. And with Ubuntu 17, I've got another problem I still haven't tracked down. All of this in a C program that gets regularly (sp)linted and checked all sorts of ways, written with the intention of producing portable code.
EVERYTHING BREAKS.
On 7 May 2018 at 22:42, Trygve Reenskaug <trygver@ifi.uio.no <mailto:trygver@ifi.uio.no>> wrote:
Please tell me when Java, C, C++, etc programs stopped working because their runtime systems had changed. Please tell me when Java, C, C++, etc compilers stopped compiling old code because the languages had changed.
On 07.05.2018 11:57, Norbert Hartl wrote:
I understand what you are saying but it contains some misconceptions about the modern software world.
âThe earth is not stopping to turn just because you want to stay on the sunny sideâ
There is two funny concepts going on in the modern software industry. The one tells you that because you want to do a product everything else around you should come to a full stop so can comfortably build your software not disturbed by other things. The second one tells you that you _have to upgrade_ ⦠there is this magical force preventing you from staying where you are. Both notions are funny alone but they come combined and then they turn out to be a non-sensical monster.
Letâs take a different approach. Put in everything you say about software, libraries, etc the word version. So you can build upon Pharo version 3 your own product. You can stay at that version and it wonât change. If the software you sell is not 80% pharo but your own you should not have a problem just to stay on that version because you develop your own stuff. But still the world did not stop turning and there is pharo 4. You decide there are a few nice features but the work to adjust is too big to take the risk. Then there is pharo 5 and you ⦠nahhh not this timeâ¦.Then there is pharo6 and they not only changed the image but also the way source code is managed. That prevents you further from adjusting. But hey you can still be happy with pharo3 and it does not change.
So what is the real problem? Yes, money/time is not enough. I think there are a lot of people risking their health to promote pharo and now we have a consortium that can pay engineers to do work on pharo. So let me tell you a future story:
You see what pharo is doing and you think it is good. You can also see that there are too less resources to proceed in the way you need it to go. So you decide to show pharo to the world inspiring people with some kind of a vision. The result is that more people pay into the consortium and we hire more engineers. And then one day the consortium has enough money to pay engineers that can care about a LTS (long term support) version of pharo. So you can stay on pharo version 3 and still get those annoying bugs fixed. And hey this team has also enough time to provide you with tools that make a migration to pharo version 4 more easy and less annoying for you. And then you have your own product based on pharo version 4. And then for version 5, version 6,â¦. Sounds like a dreamâ¦but heyâ¦it is indeed realistic. It just depends on how the people approach it
How does this sound?
Norbert
Am 07.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver@ifi.uio.no <mailto:trygver@ifi.uio.no>>:
Thanks for your quick answer. I have only a fleeting knowledge of Pharo but liked what I saw. The Squeak class library has seen organic growth since 1978 or earlier. Pharo gave it a thorough overhaul. At the Pharo kernel was a minimal image with a minimal class library. The rest of the functionality was partitioned into packages that could be added to the kernel image as required. Beautiful. But only my dream?
/Matthew 7:24-27: And the rain fell, and the floods came, and the winds blew and beat on that house, but it did not fall, because it had been founded on the rock. And everyone who hears these words of mine and does not do them will be like a foolish man who built his house on the sand."/
I am developing an IDE for non-programmers called BabyIDE, a non-intrusive extension of Squeak. Where the Class Browser in Squeak is used to work with one class at the time, the BabyIDE browser is used to work with structures of collaborating objects, ignoring their classes. I would like to develop a BabyIDE image that gets broad usage and long life. I'm looking for a rock to build on and hoped it could be what I thought was the Pharo kernel+ a few selected packages. In your answer, I read that if I build BabyIDE on Pharo, I will be building on sand.
pharo.org <http://pharo.org/>writes: "/Pharo is a pure object-oriented programming language.../". The only language I can see is defined by the release image. A Pharo programmer builds application programs in this language. He or she can add new classes, change existing ones, subclass them, add or change methods, change the Smalltalk dictionary, etc. etc. An extremely flexible and powerful language.
A tale from the future when Pharo is a mainstream language:Business customers benefit from end users using applications that are written by Pharo programmers who built on the Pharo language and environment that had been developed by the Pharo community. One day there is a happy announcement: A new version of Pharo will be launched tomorrow. It is truly cool and includes any number of improvements, some of them documented. And, by the way, applications written in the current Pharo will no longer work. So please inform your customers that you will not be able to serve them for a while. We are confident that all your application programmers will be happy to drop whatever they are doing in order to adapt their applications to the new Pharo so that you can start serving your customers again.
Cheers --Trygve
On 06.05.2018 13:00, Norbert Hartl wrote:
Can you elaborate on what you consider as a kernel? There are always things moving in the pharo world. The last years the virtual machine got some iterations and it is still not fully stable. For pharo it is hard to have it stable because we feel the need that a lot of the existing parts need to be replaced to be useful in these times. Furthermore pharo is also prototyping platform for programming language features. All of these are counter-stability measures. So if you need a stable kernel from native ground up to UI pharo wonât be that thing you are looking for the coming years (if at all). You always need to adopt to change so you need to define your required scope better in order to get an estimate.
Norbert
Am 06.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver@ifi.uio.no <mailto:trygver@ifi.uio.no>>:
I'm working on a programing paradigm and IDE for the personal programmer who wants to control his or her IoT. The size of the target audience I have in mind is >100 million. I gave up Squeak long ago as a platform because they obsolete my code faster than I can write it. I have now frozen Squeak 3.10.2 and hope its runtime will survive until I find a better foundation. My hope is that Pharo has a stable kernel that I can build on. According to Stephan, this is not so. Is there any plan for creating a stable Pharo kernel that people can use for building software of lasting value for millions of non-expert users? --Thanks, Trygve
On 05.05.2018 13:53, Stephan Eggermont wrote:
Iâve taken a look at what would be needed to support magma on pharo a few years ago. Chris always told us he uses it professionally on squeak and/*has not enough capacity to keep up with changes in pharo without having a customer/maintainer for it.*/ Twice a year or so someone asks about magma on pharo and takes a look. AFAIK there are no real obstacles to a port, but magma uses a lot of deep implementation specifics that will take an experienced smalltalker to deal with, and a lot of mailing list archeology as pharo changed a lot since magma worked on pharo last
Stephan
-- /The essence of object orientation is that objectscollaboratetoachieve a goal./ TrygveReenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ <http://folk.uio.no/trygver/> N-0378 Oslo http://fullOO.info <http://fulloo.info/> Norway Tel: (+47) 22 49 57 27
-- /The essence of object orientation is that objectscollaboratetoachieve a goal./ TrygveReenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ <http://folk.uio.no/trygver/> N-0378 Oslo http://fullOO.info <http://fulloo.info/> Norway Tel: (+47) 22 49 57 27
--
/The essence of object orientation is that objects collaborateto achieve a goal. / Trygve Reenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ <http://folk.uio.no/trygver/> N-0378 Oslo http://fullOO.info <http://fullOO.info> Norway Tel: (+47) 22 49 57 27
-- /The essence of object orientation is that objects collaborateto achieve a goal. / Trygve Reenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway                     Tel: (+47) 22 49 57 27
Hello Trygve I think you have written an excellent summary about the challenge presented by object-oriented programming. GOF book on Design Patterns â¦, it's clear that code won't reveal everything about how a system will work. [ibid.p.23] And the development of Pharo and Squeak the last 10..15 years exemplifies that this is indeed still a challenge though there are some examples and ideas how to cope with it. So is this a case for promoting DCI and related tools (which by itself goes back 10 years)? --Hannes On 5/10/18, Trygve Reenskaug <trygver@ifi.uio.no> wrote:
At 87, I'm an old man. I'm told that I don't understand modern software, which is true. I use some programs daily: WIN7, Pharo, Thunderbird, ... From time to time, I am told that a new version of the program that fixes bugs and improves security is available. Press the button to install it. So I wonder: Is modern software out of control? Does /anybody /understand it, or is it so complicated that it is beyond human comprehension? Why didn't they get it right the first time? Most of us have the GOF book on Design Patterns on our bookshelf. In the introduction, they write:
/An object-oriented program's runtime structure often bears little resemblance to its code structure. The code structure is frozen at compile-time; it consists of classes in fixed inheritance relationships. The runtime structure consists of rapidly changing networks of communicating objects.[GOF-95] p. 22./
and
/â¦, it's clear that code won't reveal everything about how a system will work. [ibid.p.23]/
Modern programmers are thus reduced to relying on testing the code. In the words of Edsger Dijstra:
/"Program testing can be used to show the presence of bugs, but never to show their absence!"[REF] /
Modern programmers know all this but accept it as an unavoidable part of progress. Some may have seen it as a challenge, but they are up against the enormous inertia of a community who haven't changed their fundamental model of programming since the advent of the von Neumann stored program computer in 1948.
I can't resist another quote; this time from Tony Hoare's TuringAward lecture:
/âThere are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. â¦[Hoare-81]/
In the lecture, Hoare was bemoaning his unsuccessful fight for simplicity. Developers, particularly committees of developers, seem to love complexity for its own sake. I have never accepted that bugs are an unavoidable part of software.(See "2. Get it Right the First Time" in the draft article). Bugs are parts of the facts of life but they are not an acceptable part of it. Ideally, my software should be /so simple that there are obviously no deficiencies. /One of my attempts at coming to grips with the problem is the DCI programming paradigm. Here, /the runtime structure of rapidly changing networks of communicating objects/ is specified in explicit code that says (almost) everything about what happens at runtime. Wouldn't it be wonderful if Pharo were to become first to overcome the GOF limitation? I challenge you to play with BabyIDE on Squeak and become convinced that it is a step in the right direction.
I won't reread this message before I send it. I suppose it's controversial and should probably delete some or all of it to avoid angry answers. Another reason why I probably shouldn't send it is that I do not have time to engage in a discussion. I /must /give priority to finishing my article on DCI and PP. (A ~50 page draft is on my home page; it will be updated from time to time)
I press the SEND button with a shaking hand --Trygve
On 09.05.2018 15:53, Richard O'Keefe wrote:
âI have a C++ program written in the late 80s by someone else. It used to run fine under cfront 2.0 and early g++. Ten years after it was written it was impossible to compile.
*Since* that there have been changes to streams and strings, amongst other things.
The 1989 C standard changed the semantics of mixed signed/unsigned integer arithmetic. It also inadvertently rendered illegal a widely used technique. It is notoriously the case these days that compilers taking the C standards literally have "broken" quite a lot of code that worked with less ambitious compilers. I have been watching this phenomenon with considerable nervousness. See for example http://www.eng.utah.edu/~cs5785/slides-f10/Dangerous+Optimizations.pdf <http://www.eng.utah.edu/%7Ecs5785/slides-f10/Dangerous+Optimizations.pdf>
I have certainly had previously acceptable C89 code be rejected by compilers as not being legal C11. It is true that compilers tend to have command line/IDE switches to ask that old code be compiled under old rules, but you cannot say that *in* the program. There is no way to mark the language version, no #pragma stdc version iso99
As for Java, I could rant about the floods of deprecation warnings from old code. I shall content myself with one observation. Read http://java-performance.info/changes-to-string-java-1-7-0_06/ Before Java 1.7, the substring operation in Java took O(1) time and space. From Java 1.7 on, it takes time and space linear in the size of the result. The syntax and abstract semantics did not change but the pragmatics did. Code that had adequate performance could suddenly start crawling.
Oracle do a tolerably thorough job of describing compatibility issues between JDK releases. See for example http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.... where we learned that the 'apt' tool was gone, the JDBC-ODBC bridge was gone, 32-bit Solaris support (and yes, I was still using 32-bit code in SPARC Solaris and Intel Solaris) was gone, and the type inference algorithm had changed in a way that could break things. I am still somewhat peeved about some of the rewriting I've had to do over the last several releases.
Then there is the simple fact that porting code from one release of an OS to another can be a pain. Solaris 10 to OpenSolaris was easy. OpenSolaris to Solaris 11 was not as painless. Solaris 11 to OpenIndiana was not a happy time for me. OpenBSD changes forced rework. I'd finally got my program to port smoothly between Solaris, Darwin, and Linux. And then I had trouble porting to the next major release of Linux. And with Ubuntu 17, I've got another problem I still haven't tracked down. All of this in a C program that gets regularly (sp)linted and checked all sorts of ways, written with the intention of producing portable code.
EVERYTHING BREAKS.
On 7 May 2018 at 22:42, Trygve Reenskaug <trygver@ifi.uio.no <mailto:trygver@ifi.uio.no>> wrote:
Please tell me when Java, C, C++, etc programs stopped working because their runtime systems had changed. Please tell me when Java, C, C++, etc compilers stopped compiling old code because the languages had changed.
On 07.05.2018 11:57, Norbert Hartl wrote:
I understand what you are saying but it contains some misconceptions about the modern software world.
âThe earth is not stopping to turn just because you want to stay on the sunny sideâ
There is two funny concepts going on in the modern software industry. The one tells you that because you want to do a product everything else around you should come to a full stop so can comfortably build your software not disturbed by other things. The second one tells you that you _have to upgrade_ ⦠there is this magical force preventing you from staying where you are. Both notions are funny alone but they come combined and then they turn out to be a non-sensical monster.
Letâs take a different approach. Put in everything you say about software, libraries, etc the word version. So you can build upon Pharo version 3 your own product. You can stay at that version and it wonât change. If the software you sell is not 80% pharo but your own you should not have a problem just to stay on that version because you develop your own stuff. But still the world did not stop turning and there is pharo 4. You decide there are a few nice features but the work to adjust is too big to take the risk. Then there is pharo 5 and you ⦠nahhh not this timeâ¦.Then there is pharo6 and they not only changed the image but also the way source code is managed. That prevents you further from adjusting. But hey you can still be happy with pharo3 and it does not change.
So what is the real problem? Yes, money/time is not enough. I think there are a lot of people risking their health to promote pharo and now we have a consortium that can pay engineers to do work on pharo. So let me tell you a future story:
You see what pharo is doing and you think it is good. You can also see that there are too less resources to proceed in the way you need it to go. So you decide to show pharo to the world inspiring people with some kind of a vision. The result is that more people pay into the consortium and we hire more engineers. And then one day the consortium has enough money to pay engineers that can care about a LTS (long term support) version of pharo. So you can stay on pharo version 3 and still get those annoying bugs fixed. And hey this team has also enough time to provide you with tools that make a migration to pharo version 4 more easy and less annoying for you. And then you have your own product based on pharo version 4. And then for version 5, version 6,â¦. Sounds like a dreamâ¦but heyâ¦it is indeed realistic. It just depends on how the people approach it
How does this sound?
Norbert
Am 07.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver@ifi.uio.no <mailto:trygver@ifi.uio.no>>:
Thanks for your quick answer. I have only a fleeting knowledge of Pharo but liked what I saw. The Squeak class library has seen organic growth since 1978 or earlier. Pharo gave it a thorough overhaul. At the Pharo kernel was a minimal image with a minimal class library. The rest of the functionality was partitioned into packages that could be added to the kernel image as required. Beautiful. But only my dream?
/Matthew 7:24-27: And the rain fell, and the floods came, and the winds blew and beat on that house, but it did not fall, because it had been founded on the rock. And everyone who hears these words of mine and does not do them will be like a foolish man who built his house on the sand."/
I am developing an IDE for non-programmers called BabyIDE, a non-intrusive extension of Squeak. Where the Class Browser in Squeak is used to work with one class at the time, the BabyIDE browser is used to work with structures of collaborating objects, ignoring their classes. I would like to develop a BabyIDE image that gets broad usage and long life. I'm looking for a rock to build on and hoped it could be what I thought was the Pharo kernel+ a few selected packages. In your answer, I read that if I build BabyIDE on Pharo, I will be building on sand.
pharo.org <http://pharo.org/>writes: "/Pharo is a pure object-oriented programming language.../". The only language I can see is defined by the release image. A Pharo programmer builds application programs in this language. He or she can add new classes, change existing ones, subclass them, add or change methods, change the Smalltalk dictionary, etc. etc. An extremely flexible and powerful language.
A tale from the future when Pharo is a mainstream language:Business customers benefit from end users using applications that are written by Pharo programmers who built on the Pharo language and environment that had been developed by the Pharo community. One day there is a happy announcement: A new version of Pharo will be launched tomorrow. It is truly cool and includes any number of improvements, some of them documented. And, by the way, applications written in the current Pharo will no longer work. So please inform your customers that you will not be able to serve them for a while. We are confident that all your application programmers will be happy to drop whatever they are doing in order to adapt their applications to the new Pharo so that you can start serving your customers again.
Cheers --Trygve
On 06.05.2018 13:00, Norbert Hartl wrote:
Can you elaborate on what you consider as a kernel? There are always things moving in the pharo world. The last years the virtual machine got some iterations and it is still not fully stable. For pharo it is hard to have it stable because we feel the need that a lot of the existing parts need to be replaced to be useful in these times. Furthermore pharo is also prototyping platform for programming language features. All of these are counter-stability measures. So if you need a stable kernel from native ground up to UI pharo wonât be that thing you are looking for the coming years (if at all). You always need to adopt to change so you need to define your required scope better in order to get an estimate.
Norbert
Am 06.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver@ifi.uio.no <mailto:trygver@ifi.uio.no>>:
I'm working on a programing paradigm and IDE for the personal programmer who wants to control his or her IoT. The size of the target audience I have in mind is >100 million. I gave up Squeak long ago as a platform because they obsolete my code faster than I can write it. I have now frozen Squeak 3.10.2 and hope its runtime will survive until I find a better foundation. My hope is that Pharo has a stable kernel that I can build on. According to Stephan, this is not so. Is there any plan for creating a stable Pharo kernel that people can use for building software of lasting value for millions of non-expert users? --Thanks, Trygve
On 05.05.2018 13:53, Stephan Eggermont wrote:
Iâve taken a look at what would be needed to support magma on pharo a few years ago. Chris always told us he uses it professionally on squeak and/*has not enough capacity to keep up with changes in pharo without having a customer/maintainer for it.*/ Twice a year or so someone asks about magma on pharo and takes a look. AFAIK there are no real obstacles to a port, but magma uses a lot of deep implementation specifics that will take an experienced smalltalker to deal with, and a lot of mailing list archeology as pharo changed a lot since magma worked on pharo last
Stephan
-- /The essence of object orientation is that objectscollaboratetoachieve a goal./ TrygveReenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ <http://folk.uio.no/trygver/> N-0378 Oslo http://fullOO.info <http://fulloo.info/> Norway Tel: (+47) 22 49 57 27
-- /The essence of object orientation is that objectscollaboratetoachieve a goal./ TrygveReenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ <http://folk.uio.no/trygver/> N-0378 Oslo http://fullOO.info <http://fulloo.info/> Norway Tel: (+47) 22 49 57 27
--
/The essence of object orientation is that objects collaborateto achieve a goal. / Trygve Reenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ <http://folk.uio.no/trygver/> N-0378 Oslo http://fullOO.info <http://fullOO.info> Norway Tel: (+47) 22 49 57 27
--
/The essence of object orientation is that objects collaborateto achieve a goal. / Trygve Reenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway Tel: (+47) 22 49 57 27
Trygve, Thank you for pressing the SEND button with a shaking hand. I am inspired by your words. But I am only 22 years younger than you, and I hope that others are reading and appreciating what you have to say. Dave On Thu, May 10, 2018 at 12:02:44PM +0200, Trygve Reenskaug wrote:
At 87, I'm an old man. I'm told that I don't understand modern software, which is true. I use some programs daily: WIN7, Pharo, Thunderbird, ... From time to time, I am told that a new version of the program that fixes bugs and improves security is available. Press the button to install it.?? So I wonder: Is modern software out of control? Does /anybody /understand it, or is it so complicated that it is beyond human comprehension? Why didn't they get it right the first time? Most of us have the GOF book on Design Patterns on our bookshelf.?? In the introduction, they write:
/An object-oriented program's runtime structure often bears little resemblance to its code structure. The code structure is frozen at compile-time; it consists of classes in fixed inheritance relationships. The runtime structure consists of rapidly changing networks of communicating objects.[GOF-95] p. 22./
??and
/???, it's clear that code won't reveal everything about how a system will work. [ibid.p.23]/
Modern programmers are thus reduced to relying on testing the code. In the words of Edsger Dijstra:
/"Program testing can be used to show the presence of bugs, but never to show their absence!"[REF] /
Modern programmers know all this but accept it as an unavoidable part of progress. Some may have seen it as a challenge, but they are up against the enormous inertia of a community who haven't changed their fundamental model of programming since the advent of the von Neumann stored program computer in 1948.
I can't resist another quote; this time from Tony Hoare's TuringAward lecture:
/???There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. ???[Hoare-81]/
In the lecture, Hoare was bemoaning his unsuccessful fight for simplicity. Developers, particularly committees?? of developers, seem to love complexity for its own sake. I have never accepted that bugs are an unavoidable part of software.(See "2.???? ??Get it Right the First Time"?? in the draft article). Bugs are parts of the facts of life but they are not an acceptable part of it. Ideally, my software should be /so simple that there are obviously no deficiencies. /One of my attempts at coming to grips with the problem is the DCI programming paradigm. Here, /the runtime structure of rapidly changing networks of communicating objects/ is specified in explicit code that says (almost) everything about what happens at runtime. Wouldn't it be wonderful if Pharo were to become first to overcome the GOF limitation? I challenge you to play with BabyIDE on Squeak?? and become convinced that it is a step in the right direction.
I won't reread this message before I?? send it. I suppose it's controversial and should probably delete some or all of it to avoid angry answers. Another reason why I probably shouldn't send it is that I do not have time to engage in a discussion. I /must /give priority to finishing my article on DCI and PP. (A ~50 page draft is on my home page; it will be updated from time to time)
I press the SEND button with a shaking hand --Trygve
On 09.05.2018 15:53, Richard O'Keefe wrote:
???I have a C++ program written in the late 80s by someone else.?? It used to run fine under cfront 2.0 and early g++. Ten years after it was written it was impossible to compile.
*Since* that there have been changes to streams and strings, amongst other things.
The 1989 C standard changed the semantics of mixed signed/unsigned integer arithmetic.?? It also inadvertently rendered illegal a widely used technique.?? It is notoriously the case these days that compilers taking the C standards literally have "broken" quite a lot of code that worked with less ambitious compilers. I have been watching this phenomenon with considerable nervousness.?? See for example http://www.eng.utah.edu/~cs5785/slides-f10/Dangerous+Optimizations.pdf <http://www.eng.utah.edu/%7Ecs5785/slides-f10/Dangerous+Optimizations.pdf>
I have certainly had previously acceptable C89 code be rejected by compilers as not being legal C11.?? It is true that compilers tend to have command line/IDE switches to ask that old code be compiled under old rules, but you cannot say that *in* the program. There is no way to mark the language version, no ?????? #pragma stdc version iso99
As for Java, I could rant about the floods of deprecation warnings from old code.?? I shall content myself with one observation. Read http://java-performance.info/changes-to-string-java-1-7-0_06/ Before Java 1.7, the substring operation in Java took O(1) time and space.?? From Java 1.7 on, it takes time and space linear in the size of the result.?? The syntax and abstract semantics did not change but the pragmatics did.?? Code that had adequate performance could suddenly start crawling.
Oracle do a tolerably thorough job of describing compatibility issues between JDK releases.?? See for example http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.... where we learned that the 'apt' tool was gone, the JDBC-ODBC bridge was gone, 32-bit Solaris support (and yes, I was still using 32-bit code in SPARC Solaris and Intel Solaris) was gone, and the type inference algorithm had changed in a way that could break things. I am still somewhat peeved about some of the rewriting I've had to do over the last several releases.
Then there is the simple fact that porting code from one release of an OS to another can be a pain.?? Solaris 10 to OpenSolaris was easy. OpenSolaris to Solaris 11 was not as painless.?? Solaris 11 to OpenIndiana was not a happy time for me.?? OpenBSD changes forced rework.?? I'd finally got my program to port smoothly between Solaris, Darwin, and Linux.?? And then I had trouble porting to the next major release of Linux.?? And with Ubuntu 17, I've got another problem I still haven't tracked down.?? All of this in a C program that gets regularly (sp)linted and checked all sorts of ways, written with the intention of producing portable code.
EVERYTHING BREAKS.
On 7 May 2018 at 22:42, Trygve Reenskaug <trygver@ifi.uio.no <mailto:trygver@ifi.uio.no>> wrote:
Please tell me when Java, C, C++, etc programs stopped working because their runtime systems had changed. Please tell me when Java, C, C++, etc compilers stopped compiling old code because the languages had changed.
On 07.05.2018 11:57, Norbert Hartl wrote:
I understand what you are saying but it contains some misconceptions about the modern software world.
???The earth is not stopping to turn just because you want to stay on the sunny side???
There is two funny concepts going on in the modern software industry. The one tells you that because you want to do a product everything else around you should come to a full stop so can comfortably build your software not disturbed by other things. The second one tells you that you _have to upgrade_ ??? there is this magical force preventing you from staying where you are. Both notions are funny alone but they come combined and then they turn out to be a non-sensical monster.
Let???s take a different approach. Put in everything you say about software, libraries, etc the word version. So you can build upon Pharo version 3 your own product. You can stay at that version and it won???t change. If the software you sell is not 80% pharo but your own you should not have a problem just to stay on that version because you develop your own stuff. But still the world did not stop turning and there is pharo 4. You decide there are a few nice features but the work to adjust is too big to take the risk. Then there is pharo 5 and you ??? nahhh not this time???.Then there is pharo6 and they not only changed the image but also the way source code is managed. That prevents you further from adjusting. But hey you can still be happy with pharo3 and it does not change.
So what is the real problem? Yes, money/time is not enough. I think there are a lot of people risking their health to promote pharo and now we have a consortium that can pay engineers to do work on pharo. So let me tell you a future story:
You see what pharo is doing and you think it is good. You can also see that there are too less resources to proceed in the way you need it to go. So you decide to show pharo to the world inspiring people with some kind of a vision. The result is that more people pay into the consortium and we hire more engineers. And then one day the consortium has enough money to pay engineers that can care about a LTS (long term support) version of pharo. So you can stay on pharo version 3 and still get those annoying bugs fixed. And hey this team has also enough time to provide you with tools that make a migration to pharo version 4 more easy and less annoying for you. And then you have your own product based on pharo version 4. And then for version 5, version 6,???. Sounds like a dream???but hey???it is indeed realistic. It just depends on how the people approach it
How does this sound?
Norbert
Am 07.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver@ifi.uio.no <mailto:trygver@ifi.uio.no>>:
Thanks for your quick answer.?? I have only a fleeting knowledge of Pharo but liked what I saw. The Squeak class library has seen organic growth since 1978 or earlier. Pharo gave it a thorough overhaul. At the Pharo kernel was a minimal image with a minimal class library. The rest of the functionality was partitioned into packages that could be added to the kernel image as required. Beautiful. But only my dream?
/Matthew 7:24-27: And the rain fell, and the floods came, and the winds blew and beat on that house, but it did not fall, because it had been founded on the rock. And everyone who hears these words of mine and does not do them will be like a foolish man who built his house on the sand."/
I am developing an IDE for non-programmers called BabyIDE, a non-intrusive extension of Squeak. Where the Class Browser in Squeak is used to work with one class at the time, the BabyIDE browser is used to work with structures of collaborating objects, ignoring their classes. I would like to develop a BabyIDE image that gets broad usage and long life. I'm looking for a rock to build on and hoped it could be what I thought was the Pharo kernel+ a few selected packages. In your answer, I read that if I build BabyIDE on Pharo, I will be building on sand.
pharo.org <http://pharo.org/>writes: "/Pharo is a pure object-oriented programming language.../". The only language I can see is defined by the release image. A Pharo programmer builds application programs in this language. He or she can add new classes, change existing ones, subclass them, add or change methods, change the Smalltalk dictionary, etc. etc.?? An extremely flexible and powerful language.
A tale from the future when Pharo is a mainstream language:Business customers benefit from end users using applications that are written by Pharo programmers who built on the Pharo language and environment that had been developed by the Pharo community. One day there is a happy announcement: A new version of Pharo will be launched tomorrow. It is truly cool and includes any number of improvements, some of them documented. And, by the way, applications written in the current Pharo will no longer work. So please inform your customers that you will not be able to serve them for a while. We are confident that all your application programmers will be happy to drop whatever they are doing in order to adapt their applications to the new Pharo so that you can start serving your customers again.
Cheers --Trygve
On 06.05.2018 13:00, Norbert Hartl wrote:
Can you elaborate on what you consider as a kernel? There are always things moving in the pharo world. The last years the virtual machine got some iterations and it is still not fully stable. For pharo it is hard to have it stable because we feel the need that a lot of the existing parts need to be replaced to be useful in these times. Furthermore pharo is also prototyping platform for programming language features. All of these are counter-stability measures. So if you need a stable kernel from native ground up to UI pharo won???t be that thing you are looking for the coming years (if at all). You always need to adopt to change so you need to define your required scope better in order to get an estimate.
Norbert
Am 06.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver@ifi.uio.no <mailto:trygver@ifi.uio.no>>:
I'm working on a programing paradigm and IDE for the personal programmer who wants to control his or her IoT. The size of the target audience I have in mind is >100 million. I gave up Squeak long ago as a platform because they obsolete my code faster than I can write it.?? I have now frozen Squeak 3.10.2 and hope its runtime will survive until I find a better foundation. My hope is that Pharo has a stable kernel that I can build on.?? According to Stephan, this is not so. Is there any plan for creating a stable Pharo kernel that people can use for building software of lasting value for millions of non-expert users? --Thanks, Trygve
On 05.05.2018 13:53, Stephan Eggermont wrote:
I???ve taken a look at what would be needed to support magma on pharo a few years ago. Chris always told us he uses it professionally on squeak and/*has not enough capacity to keep up with changes in pharo without having a customer/maintainer for it.*/ Twice a year or so someone asks about magma on pharo and takes a look. AFAIK there are no real obstacles to a port, but magma uses a lot of deep implementation specifics that will take an experienced smalltalker to deal with, and a lot of mailing list archeology as pharo changed a lot since magma worked on pharo last
Stephan
-- /The essence of object orientation is that objectscollaboratetoachieve a goal./ TrygveReenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ <http://folk.uio.no/trygver/> N-0378 Oslo http://fullOO.info <http://fulloo.info/> Norway Tel: (+47) 22 49 57 27
-- /The essence of object orientation is that objectscollaboratetoachieve a goal./ TrygveReenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ <http://folk.uio.no/trygver/> N-0378 Oslo http://fullOO.info <http://fulloo.info/> Norway Tel: (+47) 22 49 57 27
--
/The essence of object orientation is that objects collaborateto achieve a goal. / Trygve Reenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ <http://folk.uio.no/trygver/> N-0378 Oslo http://fullOO.info <http://fullOO.info> Norway Tel: (+47) 22 49 57 27
--
/The essence of object orientation is that objects collaborateto achieve a goal. / Trygve Reenskaug mailto: trygver@ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway??????????????????????????????????????????Tel: (+47) 22 49 57 27
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 <raoknz@gmail.com> 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.... where we learned that the 'apt' tool was gone, the JDBC-ODBC bridge was gone, 32-bit Solaris support (and yes, I was still using 32-bit code in SPARC Solaris and Intel Solaris) was gone, and the type inference algorithm had changed in a way that could break things. I am still somewhat peeved about some of the rewriting I've had to do over the last several releases.
Then there is the simple fact that porting code from one release of an OS to another can be a pain. Solaris 10 to OpenSolaris was easy. OpenSolaris to Solaris 11 was not as painless. Solaris 11 to OpenIndiana was not a happy time for me. OpenBSD changes forced rework. I'd finally got my program to port smoothly between Solaris, Darwin, and Linux. And then I had trouble porting to the next major release of Linux. And with Ubuntu 17, I've got another problem I still haven't tracked down. All of this in a C program that gets regularly (sp)linted and checked all sorts of ways, written with the intention of producing portable code.
EVERYTHING BREAKS.
On 7 May 2018 at 22:42, Trygve Reenskaug <trygver@ifi.uio.no> wrote:
Please tell me when Java, C, C++, etc programs stopped working because their runtime systems had changed. Please tell me when Java, C, C++, etc compilers stopped compiling old code because the languages had changed.
On 07.05.2018 11:57, Norbert Hartl wrote:
I understand what you are saying but it contains some misconceptions about the modern software world.
âThe earth is not stopping to turn just because you want to stay on the sunny sideâ
There is two funny concepts going on in the modern software industry. The one tells you that because you want to do a product everything else around you should come to a full stop so can comfortably build your software not disturbed by other things. The second one tells you that you _have to upgrade_ ⦠there is this magical force preventing you from staying where you are. Both notions are funny alone but they come combined and then they turn out to be a non-sensical monster.
Letâs take a different approach. Put in everything you say about software, libraries, etc the word version. So you can build upon Pharo version 3 your own product. You can stay at that version and it wonât change. If the software you sell is not 80% pharo but your own you should not have a problem just to stay on that version because you develop your own stuff. But still the world did not stop turning and there is pharo 4. You decide there are a few nice features but the work to adjust is too big to take the risk. Then there is pharo 5 and you ⦠nahhh not this timeâ¦.Then there is pharo6 and they not only changed the image but also the way source code is managed. That prevents you further from adjusting. But hey you can still be happy with pharo3 and it does not change.
So what is the real problem? Yes, money/time is not enough. I think there are a lot of people risking their health to promote pharo and now we have a consortium that can pay engineers to do work on pharo. So let me tell you a future story:
You see what pharo is doing and you think it is good. You can also see that there are too less resources to proceed in the way you need it to go. So you decide to show pharo to the world inspiring people with some kind of a vision. The result is that more people pay into the consortium and we hire more engineers. And then one day the consortium has enough money to pay engineers that can care about a LTS (long term support) version of pharo. So you can stay on pharo version 3 and still get those annoying bugs fixed. And hey this team has also enough time to provide you with tools that make a migration to pharo version 4 more easy and less annoying for you. And then you have your own product based on pharo version 4. And then for version 5, version 6,â¦. Sounds like a dreamâ¦but heyâ¦it is indeed realistic. It just depends on how the people approach it
How does this sound?
Norbert
Am 07.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver@ifi.uio.no>:
Thanks for your quick answer. I have only a fleeting knowledge of Pharo but liked what I saw. The Squeak class library has seen organic growth since 1978 or earlier. Pharo gave it a thorough overhaul. At the Pharo kernel was a minimal image with a minimal class library. The rest of the functionality was partitioned into packages that could be added to the kernel image as required. Beautiful. But only my dream?
*Matthew 7:24-27: And the rain fell, and the floods came, and the winds blew and beat on that house, but it did not fall, because it had been founded on the rock. And everyone who hears these words of mine and does not do them will be like a foolish man who built his house on the sand."*
I am developing an IDE for non-programmers called BabyIDE, a non-intrusive extension of Squeak. Where the Class Browser in Squeak is used to work with one class at the time, the BabyIDE browser is used to work with structures of collaborating objects, ignoring their classes. I would like to develop a BabyIDE image that gets broad usage and long life. I'm looking for a rock to build on and hoped it could be what I thought was the Pharo kernel+ a few selected packages. In your answer, I read that if I build BabyIDE on Pharo, I will be building on sand.
pharo.org writes: "*Pharo is a pure object-oriented programming language...*". The only language I can see is defined by the release image. A Pharo programmer builds application programs in this language. He or she can add new classes, change existing ones, subclass them, add or change methods, change the Smalltalk dictionary, etc. etc. An extremely flexible and powerful language.
A tale from the future when Pharo is a mainstream language: Business customers benefit from end users using applications that are written by Pharo programmers who built on the Pharo language and environment that had been developed by the Pharo community. One day there is a happy announcement: A new version of Pharo will be launched tomorrow. It is truly cool and includes any number of improvements, some of them documented. And, by the way, applications written in the current Pharo will no longer work. So please inform your customers that you will not be able to serve them for a while. We are confident that all your application programmers will be happy to drop whatever they are doing in order to adapt their applications to the new Pharo so that you can start serving your customers again.
Cheers --Trygve
On 06.05.2018 13:00, Norbert Hartl wrote:
Can you elaborate on what you consider as a kernel? There are always things moving in the pharo world. The last years the virtual machine got some iterations and it is still not fully stable. For pharo it is hard to have it stable because we feel the need that a lot of the existing parts need to be replaced to be useful in these times. Furthermore pharo is also prototyping platform for programming language features. All of these are counter-stability measures. So if you need a stable kernel from native ground up to UI pharo wonât be that thing you are looking for the coming years (if at all). You always need to adopt to change so you need to define your required scope better in order to get an estimate.
Norbert
Am 06.05.2018 um 11:31 schrieb Trygve Reenskaug <trygver@ifi.uio.no>:
I'm working on a programing paradigm and IDE for the personal programmer who wants to control his or her IoT. The size of the target audience I have in mind is >100 million. I gave up Squeak long ago as a platform because they obsolete my code faster than I can write it. I have now frozen Squeak 3.10.2 and hope its runtime will survive until I find a better foundation. My hope is that Pharo has a stable kernel that I can build on. According to Stephan, this is not so. Is there any plan for creating a stable Pharo kernel that people can use for building software of lasting value for millions of non-expert users? --Thanks, Trygve
On 05.05.2018 13:53, Stephan Eggermont wrote:
Iâve taken a look at what would be needed to support magma on pharo a few years ago. Chris always told us he uses it professionally on squeak and *has not enough capacity to keep up with changes in pharo without having a customer/maintainer for it.* Twice a year or so someone asks about magma on pharo and takes a look. AFAIK there are no real obstacles to a port, but magma uses a lot of deep implementation specifics that will take an experienced smalltalker to deal with, and a lot of mailing list archeology as pharo changed a lot since magma worked on pharo last
Stephan
-- *The essence of object orientation is that objects collaborate to achieve a goal. * Trygve Reenskaug mailto: trygver@ifi.uio.no <%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info <http://fulloo.info/> Norway Tel: (+47) 22 49 57 27
-- *The essence of object orientation is that objects collaborate to achieve a goal. * Trygve Reenskaug mailto: trygver@ifi.uio.no <%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info <http://fulloo.info/> Norway Tel: (+47) 22 49 57 27
--
*The essence of object orientation is that objects collaborate to achieve a goal. * Trygve Reenskaug mailto: trygver@ifi.uio.no <%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway Tel: (+47) 22 49 57 27
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
Just out of curiosity, which object database is recommended for Pharo? Something that is reliably up-to-date as Pharo changes. Stephan Eggermont-3 wrote
Sean P. DeNigris <
sean@
> wrote:
OT: It's ironic that Smalltalkers are often accused of NIH syndrome, but the first reaction of people from less "productive" languages/systems is to rewrite a working Smalltalk app in their language of comfortâ¦
Indeed. And rewriting something that also uses an OODB is going to kill productivity even more. 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
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Just out of curiosity, why do you want an OODB? SQLite has a plethora of tools, powerful query capabilities, can be migrated with very little pain, and can act a bit like an OODB using GLORP. I have lost too many data sets to proprietary OODBs to ever trust one again.
On May 6, 2018, at 10:00 AM, horrido <horrido.hobbies@gmail.com> wrote:
Just out of curiosity, which object database is recommended for Pharo? Something that is reliably up-to-date as Pharo changes.
Stephan Eggermont-3 wrote
Sean P. DeNigris <
sean@
> wrote:
OT: It's ironic that Smalltalkers are often accused of NIH syndrome, but the first reaction of people from less "productive" languages/systems is to rewrite a working Smalltalk app in their language of comfortâ¦
Indeed. And rewriting something that also uses an OODB is going to kill productivity even more. 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
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html>
I tend to agree with you. I like SQLite. Also, MongoDB isn't bad, either. But is there no scenario where an OODB would be highly advantageous? tblanchard wrote
Just out of curiosity, why do you want an OODB?
SQLite has a plethora of tools, powerful query capabilities, can be migrated with very little pain, and can act a bit like an OODB using GLORP.
I have lost too many data sets to proprietary OODBs to ever trust one again.
On May 6, 2018, at 10:00 AM, horrido <
horrido.hobbies@
> wrote:
Just out of curiosity, which object database is recommended for Pharo? Something that is reliably up-to-date as Pharo changes.
Stephan Eggermont-3 wrote
Sean P. DeNigris <
sean@
> wrote:
OT: It's ironic that Smalltalkers are often accused of NIH syndrome, but the first reaction of people from less "productive" languages/systems is to rewrite a working Smalltalk app in their language of comfortâ¦
Indeed. And rewriting something that also uses an OODB is going to kill productivity even more. 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
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html>;
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
PostgreSQL is a totally valid alternative as well. It is a real RDBMS, cross platform, open source, with wide support. We have two network level drivers in Pharo (PostgresV2 and recently P3) and it works well under GLORP.
On 6 May 2018, at 19:10, Todd Blanchard <tblanchard@mac.com> wrote:
Just out of curiosity, why do you want an OODB?
SQLite has a plethora of tools, powerful query capabilities, can be migrated with very little pain, and can act a bit like an OODB using GLORP.
I have lost too many data sets to proprietary OODBs to ever trust one again.
On May 6, 2018, at 10:00 AM, horrido <horrido.hobbies@gmail.com> wrote:
Just out of curiosity, which object database is recommended for Pharo? Something that is reliably up-to-date as Pharo changes.
Stephan Eggermont-3 wrote
Sean P. DeNigris <
sean@
> wrote:
OT: It's ironic that Smalltalkers are often accused of NIH syndrome, but the first reaction of people from less "productive" languages/systems is to rewrite a working Smalltalk app in their language of comfortâ¦
Indeed. And rewriting something that also uses an OODB is going to kill productivity even more. 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
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Postgres is indeed awesome - but pretty heavy for a resource constrained IoT client. Itâs great on the server though. Sent from the road
On May 6, 2018, at 10:36, Sven Van Caekenberghe <sven@stfx.eu> wrote:
PostgreSQL is a totally valid alternative as well. It is a real RDBMS, cross platform, open source, with wide support. We have two network level drivers in Pharo (PostgresV2 and recently P3) and it works well under GLORP.
On 6 May 2018, at 19:10, Todd Blanchard <tblanchard@mac.com> wrote:
Just out of curiosity, why do you want an OODB?
SQLite has a plethora of tools, powerful query capabilities, can be migrated with very little pain, and can act a bit like an OODB using GLORP.
I have lost too many data sets to proprietary OODBs to ever trust one again.
On May 6, 2018, at 10:00 AM, horrido <horrido.hobbies@gmail.com> wrote:
Just out of curiosity, which object database is recommended for Pharo? Something that is reliably up-to-date as Pharo changes.
Stephan Eggermont-3 wrote
Sean P. DeNigris <
sean@
> wrote:
OT: It's ironic that Smalltalkers are often accused of NIH syndrome, but the first reaction of people from less "productive" languages/systems is to rewrite a working Smalltalk app in their language of comfortâ¦
Indeed. And rewriting something that also uses an OODB is going to kill productivity even more. 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
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Todd Blanchard <tblanchard@mac.com> wrote:
Just out of curiosity, why do you want an OODB?
It sounds great...until something goes wrong. I wouldnât choose it for important data. I might use it as a local cache. Especially when it has a single maintainer I could go to for help. Sent from the road
On May 6, 2018, at 11:44, Stephan Eggermont <stephan@stack.nl> wrote:
Todd Blanchard <tblanchard@mac.com> wrote:
Just out of curiosity, why do you want an OODB?
From my current experiences ... the people do not choose OODBs, because in the mainstream languages the stuff is simply not visible (market share). The knowledge is not there and the biggest problem - a programming interfaces are not available.
People use RDBMS oder NoSQl systems, because these systems offer a programming model to developers - even if they are simply bad. And they offer language independent access to the data. Some people are moving from RDBMS to NoSQL-system, because they hope to get more OO-programming in the database. Thats also a problem with Gemstone/S. Its a wonderful database, but it offers no default programming model to external developers - so it will never be attractive to non-Smalltalk developers. Am 06.05.2018 um 23:08 schrieb Todd Blanchard:
It sounds great...until something goes wrong. I wouldnât choose it for important data. I might use it as a local cache. Especially when it has a single maintainer I could go to for help.
Sent from the road
On May 6, 2018, at 11:44, Stephan Eggermont <stephan@stack.nl> wrote:
Todd Blanchard <tblanchard@mac.com> wrote:
Just out of curiosity, why do you want an OODB?
participants (21)
-
aglynn42＠gmail.com -
Brad -
Clément Bera -
David T. Lewis -
Dimitris Chloupis -
H. Hirzel -
Herbert VojÄÃk -
horrido -
Marcus Denker -
Marten Feldtmann -
Norbert Hartl -
Richard O'Keefe -
Sean P. DeNigris -
Serge Stinckwich -
serge.stinckwich＠gmail.com
-
Stephan Eggermont -
Sven Van Caekenberghe -
Todd Blanchard -
Travis Ayres -
Trygve Reenskaug -
Tudor Girba