Hi Chris,
I'm sorry to say that your advice didn't work. Worse: The Squeak community has lost a valuable contributor, a prime mover in the patterns and agile communities and the author of several books on OO. My friend wrote: " I still can’t find a version of Squeak for my Mac that will run Trygve’s current BabyIDE. At this point, even if one appears, it is obvious that my dependence on “the introvert Squeak community” will put me in a much more fragile position than with any of my other concept proofs. It will be extremely difficult to build a future on such fragile foundations." I came to Xerox PARC and Smalltalk in 1978 where I made my contributions to Smalltalk-80. Since then, I have been working almost exclusively with Smalltalk. My company invested in a VW class library of more than 100,000 lines of Smalltalk code and used it in our consulting. A strong selling point was that our tenders were accompanied by a demo version of the program we offered to deliver. Our library and applications were repeatedly threatened by new versions of VW. The code is now dead; there is no VM that will run our old images. The investment is lost. I hoped Squeak would be better. It isn't. Squeak is less stable than VW ever was. My new programming paradigm, DCI, is supported by BabyIDE that runs under Squeak 3.10. I have ported BabyIDE to 4.5, but there are new bugs caused by differences between 3.10 and 4.5. The result is that I have reverted to 3.10 because it's too much hassle to run after the stream of Squeak releases. I thought Pharo would be better, but their mailing list conversations indicate that they do not understand that developers need a stable foundation for their work. The result is that I too leave Smalltalk and concentrate on other environments. A pity, because I still believe Smalltalk has the potential to become a superior environment for non-professional programmers. I am particularly thinking of children and experts such as computational chemists who use computers in their work. It's very painful, but I am now terminating development work in Squeak leave the Squeak and Pharo mailing lists. I will continue my work in some mainstream language. I have just done some work in Java with Netbeans and I am buying a book on JavaScript. It's heavy going, but better that working for the dustbin. Cheers --Trygve On 31.05.2015 16:52, Trygve Reenskaug wrote: Hi, A friend of mine is doing some experiments using a Mac and my program Baby IDE. BabyIDE is works under Squeak 3.10.2. Is there a binary virtual machine for a current Mac that he can use? On 31.05.2015 17:00, Chris Cunnington wrote: You need a non-Cog vm. I usually download any Etoys vm. [1] |
Hi Trygve,
Did you see my earlier reply suggesting that you use the VM at http://www.squeakvm.org/~lewis/MacOS-test-Javier/ ? I believe that I sent it directly to your personal email address, but I don't know if you received it. The newer Cog VMs used in Squeak all-in-one and Pharo will not work with a Squeak 3.10 image, but any of the traditional context interpreter VMs (including this recently built VM provided by Javier Diaz-Reinoso) should be fine. A bit off topic from your orginal question, but I would also encourage you to take a look at http://try.squeak.org/ as a source of inspiration. This is Bert Freudenberg's remarkable SqueakJS running in a web browser, and it might prove quite suitable for certain kinds of software demos where you want a run-anywhere capability. You should be able to drag and drop your BabyIDE image onto that web page, and run it directly in your your web browser with no need to install a VM at all. HTH, Dave > Hi Chris, > I'm sorry to say that your advice didn't work. Worse: The Squeak > community has lost a valuable contributor, a prime mover in the patterns > and agile communities and the author of several books on OO. My friend > wrote: > " /I still canât find a version of Squeak for my Mac that will run > Trygveâs current BabyIDE. At this point, even if one appears, it is > obvious that my dependence on âthe introvert Squeak communityâ will > put > me in a much more fragile position than with any of my other concept > proofs. It will be extremely difficult to build a future on such fragile > foundations./" > > I came to Xerox PARC and Smalltalk in 1978 where I made my contributions > to Smalltalk-80. Since then, I have been working almost exclusively with > Smalltalk. My company invested in a VW class library of more than > 100,000 lines of Smalltalk code and used it in our consulting. A strong > selling point was that our tenders were accompanied by a demo version of > the program we offered to deliver. Our library and applications were > repeatedly threatened by new versions of VW. The code is now dead; there > is no VM that will run our old images. The investment is lost. > > I hoped Squeak would be better. It isn't. Squeak is less stable than VW > ever was. My new programming paradigm, DCI, is supported by BabyIDE that > runs under Squeak 3.10. I have ported BabyIDE to 4.5, but there are new > bugs caused by differences between 3.10 and 4.5. The result is that I > have reverted to 3.10 because it's too much hassle to run after the > stream of Squeak releases. I thought Pharo would be better, but their > mailing list conversations indicate that they do not understand that > developers need a stable foundation for their work. > > The result is that I too leave Smalltalk and concentrate on other > environments. A pity, because I still believe Smalltalk has the > potential to become a superior environment for non-professional > programmers. I am particularly thinking of children and experts such as > computational chemists who use computers in their work. > > It's very painful, but I am now terminating development work in Squeak > leave the Squeak and Pharo mailing lists. I will continue my work in > some mainstream language. I have just done some work in Java with > Netbeans and I am buying a book on JavaScript. It's heavy going, but > better that working for the dustbin. > > Cheers > --Trygve > > > On 31.05.2015 16:52, Trygve Reenskaug wrote: > Hi, > A friend of mine is doing some experiments using a Mac and my program > Baby IDE. BabyIDE is works under Squeak 3.10.2. Is there a binary > virtual machine for a current Mac that he can use? > > On 31.05.2015 17:00, Chris Cunnington wrote: >> You need a non-Cog vm. I usually download any Etoys vm. [1] >> From there, drag it onto the vm or right click, choose âOpen Withâ >> and >> choose Etoys. >> >> Chris >> >> [1] http://squeakland.org/download/ > > |
In reply to this post by Trygve
I'm sorry to say that Pharo public API does not change that much.
We could port all Moose in one afternoon and Moose is certainly more complex :). Stef Le 9/6/15 18:07, Trygve Reenskaug a
écrit :
Hi Chris, |
In reply to this post by Trygve
It is always the same question. Why do you upgrade if you don't want things to change? It is close to obvious that there is no one paradigm that is so perfect it does not need change. If there is no new feature you need there is no reason to upgrade. Of course new releases fix bugs and at the same time the introduce incompatibilities. That's how it goes. I doubt you find anything different in any other language. The only thing you can do is asking for help.
Norbert
|
In reply to this post by stepharo
Stef,
Why be sorry? It's great that you have a stable kernel in Pharo. Where do I find the definition of the Pharo public API? In which way is the Pharo technology that underlies Moose more complex than BabyIDE? Porting BabyIDE from Squeak 3.10 to 4.5 was hard because it extends the Squeak Parser and debugger and that this is unknown territory to me. There remains, of course, minorproblems and bugs caused by changes in the various services offered by the Squeak kernel. It's clear that one port went without a hitch for you. That does not mean that porting BabyIDE to Pharo will be equally simple. And may be the people who did your port do not share my extensive ignorance of the Pharo innards and the nature of the changes in the release? I am not a Pharo creator. I was considering to become a Pharo user but reconsidered when I read what you say below. This was partly because I believe you underestimate the work needed to port BabyIDE to Pharo and partly because you do not appear to appreciate the need that programmers (your customers) have for a stable programming language. Trygve On 09.06.2015 19:59, stepharo wrote:
I'm sorry to say that Pharo public API does not change that much. |
If I remember correctly, it was easy to port Moose from VW to Pharo,
because there was a lot of tests. I'm currently working on porting another software from VW to Pharo without any tests and I'm suffering ;-) On Wed, Jun 10, 2015 at 8:36 PM, Trygve Reenskaug <[hidden email]> wrote: > Stef, > Why be sorry? It's great that you have a stable kernel in Pharo. Where do I > find the definition of the Pharo public API? > > In which way is the Pharo technology that underlies Moose more complex than > BabyIDE? Porting BabyIDE from Squeak 3.10 to 4.5 was hard because it extends > the Squeak Parser and debugger and that this is unknown territory to me. > There remains, of course, minorproblems and bugs caused by changes in the > various services offered by the Squeak kernel. > > It's clear that one port went without a hitch for you. That does not mean > that porting BabyIDE to Pharo will be equally simple. And may be the people > who did your port do not share my extensive ignorance of the Pharo innards > and the nature of the changes in the release? I am not a Pharo creator. I > was considering to become a Pharo user but reconsidered when I read what you > say below. This was partly because I believe you underestimate the work > needed to port BabyIDE to Pharo and partly because you do not appear to > appreciate the need that programmers (your customers) have for a stable > programming language. > Trygve > > On 09.06.2015 19:59, stepharo wrote: > > I'm sorry to say that Pharo public API does not change that much. > We could port all Moose in one afternoon and Moose is certainly more complex > :). > > Stef -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/ |
In reply to this post by Trygve
On 10/06/15 20:36, Trygve Reenskaug wrote:
> In which way is the Pharo technology that underlies Moose more complex > than BabyIDE? Porting BabyIDE from Squeak 3.10 to 4.5 was hard because > it extends the Squeak Parser and debugger and that this is unknown > territory to me. There remains, of course, minor problems and bugs caused > by changes in the various services offered by the Squeak kernel. Porting BabyIDE to Pharo is hard because: - we now have a different compiler and debugger - BabyIDE uses parts of Morphic that we changed and/or removed. - Nautilus doesn't easily support changing the syntax highlighter As key developers of Moose are also key developers of Pharo, a smooth transformation is something that should be expected or at least hoped for. On the other hand, BabyIDE is much smaller than Moose. > you do not appear to appreciate the need that programmers (your > customers) have for a stable programming language. We try to provide for both the need to have a stable environment and the need to innovate and try new things. There is an inherent conflict there that we try to resolve by providing a continuous integration environment where we can get fast feedback on breaking changes. It works pretty well for the projects that have an active maintainer. Stephan Eggermont |
In reply to this post by Trygve
Hi,
On Wed, Jun 10, 2015 at 8:36 PM, Trygve Reenskaug <[hidden email]> wrote:
That is an interesting request coming from someone that
It is not one port. We are developing Moose on top of Pharo since 7 years. Even though Moose depends quite deeply on the inner workings of Pharo (package model, code model, RB AST, inspector, debugger, canvas, text editor), we could consistently move it between successive versions with limited effort (typically measured in days).
The comparison is not quite fair :). The point of Stef was about moving between versions of Pharo, not between Squeak and Pharo.
The choice belongs to you, but I do not quite understand your line of reasoning. What Stef said is that even if Pharo changes fast, there is evidence to show that even in larger projects moving between successive versions of Pharo is a handle-able undertaking. Now, about BabyIDE. I think it is certainly an interesting project, and it would be interesting to have it in Pharo. If you need help, you can always ask on the Pharo lists and you typically get the expected answers. Cheers, Doru
|
In reply to this post by SergeStinckwich
I rest my case.
--Trygve On 10.06.2015 20:57, Serge Stinckwich
wrote:
|
If I understand correctly, your case is that it is easier to move from Squeak to JavaScript than to move from Squeak to Pharo. I must be missing something important. Could you clarify? Cheers, Doru On Fri, Jun 12, 2015 at 10:12 AM, Trygve Reenskaug <[hidden email]> wrote:
|
In reply to this post by Stephan Eggermont-3
Le 11/6/15 17:00, Stephan Eggermont a écrit : > On 10/06/15 20:36, Trygve Reenskaug wrote: >> In which way is the Pharo technology that underlies Moose more complex >> than BabyIDE? Porting BabyIDE from Squeak 3.10 to 4.5 was hard because >> it extends the Squeak Parser and debugger and that this is unknown >> territory to me. There remains, of course, minor problems and bugs >> caused >> by changes in the various services offered by the Squeak kernel. > > Porting BabyIDE to Pharo is hard because: > - we now have a different compiler and debugger > - BabyIDE uses parts of Morphic that we changed and/or removed. > - Nautilus doesn't easily support changing the syntax highlighter > > As key developers of Moose are also key developers of Pharo, > a smooth transformation is something that should be expected > or at least hoped for. This is not true. But I have something else than arguing... > On the other hand, BabyIDE is much smaller than Moose. > >> you do not appear to appreciate the need that programmers (your >> customers) have for a stable programming language. > > We try to provide for both the need to have a stable environment > and the need to innovate and try new things. There is an inherent > conflict there that we try to resolve by providing a continuous > integration environment where we can get fast feedback on breaking > changes. It works pretty well for the projects that have an active > maintainer. > > Stephan Eggermont > > > > |
Free forum by Nabble | Edit this page |