On Wed, Apr 27, 2011 at 1:10 PM, Michael Forster <mike@sharedlogic.ca>wrote:

On Wed, Apr 27, 2011 at 4:47 AM, Marcus Denker <marcus.denker@inria.fr> wrote: [...]

...

Yes, using the old version of Pharo that you used when you implemented them. Like MacOS 9 programs run on MacOS 9.

If you want to run your MacOS 9 Program on MacOSX, there is for a time an emulator, and for a time some source compatibility. But in the end, the only option is to port.

There is no magic.

You can select between

-> Inventing the Future -> Be compatible to the Past at any cost.

If what you have in the Past is valuable, selecting the second option makes sense. (IBM, Microsoft). If not, then it's idiotic.

We will improve this a bit in the future, but this is research, so no promises.

So, we mission-critical users should probably disregard the mission statement on the web page misleading:

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

It doesn't say anything about backward compatibility. As marcus said, we want a stable system. That means it is stable. Few bugs, robust, etc. If you use that system for the next 5 years, it will continue to be stable. You understood stable in the sense that it won't change among releases? if so, yes, the text is misleading and we need to fix it.

I'm sorry that I don't have time right at the moment to address this properly, because I do respect the efforts of the Pharo developers, I fully appreciate the challenges of a FOSS project, and I like some of the results I've seen (very nice developer UI features, movement towards announcements, the collaboractive book, and so on). I am interested, only, in offering constructive criticism, so please don't mistake my tone.

Please, go ahead. And don't mistake my tone neither. I am just nicely discussing :)

The short version of my concern is this: As a "mission critical" user of Pharo, I will trade backward compatibility for improvement, if, as you say, you provide "maintained releases". Those last two words are the most important and incur a great burden of responsibility. I don't think the Pharo project has fully considered the responsibility of using those two words.

We did Pharo 1.1.1 and we are planning Pharo 1.2.2. And they are "maintained releases". Of course, don't expect now for example, a maintained release in Pharo 1.0. At least not from me. This is open-source. Nobody pays. Resources are limited. So...if you need something in Pharo.1.0 NOW, you take the image and you integrate the fix by yourself. Or you can kindly ask. Crucial bugs are always included and integrated.

The short version of my recommendation is this: Have a look at the FreeBSD release engineering process.

how many developers are working in FreeBSD? how much money they receive? It is not that we do this because we want. Resources are limited and we need to use where we think they are used better.

They break backward compatibility all the time, but, if I have a mission critical application running on 4.5, I will still get essential bug and security fixes for a few years, and I can run trials with 8.0 on my other servers.

If people ask us, we are not going to do a new release for Pharo 1.0. However, if someone comes and say, "hey, please, can you consider create a Pharo 1.0.XX with the fixed issues A B C F R". Sure we can do it. What you should not expect is: - new developments to be included in old version - non critical bugs to be included in old versions - that you won't have to change anything in your apps in order to upgrade to a new pharo version

Moreover, they have an updated documented roadmap that I can look at to determine that I should continue to run 4.5 on that one box while testing 8.0 on the others.

We don't need to exaggerate. Pharo position about this topic was from the VERY beginning. In fact, it was created just because of that. Now...it is already like 3 years and 3 big releases. I am not aware of someone who needs to migrate and couldn't. So...it is working fine for the moment.

Best regards,

Mike

-- Mariano http://marianopeck.wordpress.com

Aside from the bank examples, that I have never personally been involved in any way, I have to see a system that can survive several years between versions without requiring some amount of patching/upgrading/care. Even big $$$ systems like Oracle RDBMS, MS SQL Server, big Unix/linux deployments require some amount of work in order to upgrade existing apps to new versions of them. Anyway if you have an app that is so important to be running flawlessly over the years and have no chance for failure then you have the $$$ to maintain it that way, either by you yourself patching the old version so that remains useful to you or by extensively testing the old app in the new version. That is something that banks have, that is sure. And that is something that any FOSS project almost never have. Even Red Hat (with corporate $$$) or linux kernel (with tons of developers paid and pro-bono) can't. They sometime have to let behind some release and concentrate effort in new versions and new users. Pay attention that most users doesn't need a 100% backwards compatible platform so there is no reason to slow down or stop improvement for the most in the name of the few. Not that is something personal to the few either. It just a practical issue. Cheers El mié, 27-04-2011 a las 06:10 -0500, Michael Forster escribió:

On Wed, Apr 27, 2011 at 4:47 AM, Marcus Denker <marcus.denker@inria.fr> wrote: [...]

...

Yes, using the old version of Pharo that you used when you implemented them. Like MacOS 9 programs run on MacOS 9.

If you want to run your MacOS 9 Program on MacOSX, there is for a time an emulator, and for a time some source compatibility. But in the end, the only option is to port.

There is no magic.

You can select between

-> Inventing the Future -> Be compatible to the Past at any cost.

If what you have in the Past is valuable, selecting the second option makes sense. (IBM, Microsoft). If not, then it's idiotic.

We will improve this a bit in the future, but this is research, so no promises.

So, we mission-critical users should probably disregard the mission statement on the web page misleading:

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

I'm sorry that I don't have time right at the moment to address this properly, because I do respect the efforts of the Pharo developers, I fully appreciate the challenges of a FOSS project, and I like some of the results I've seen (very nice developer UI features, movement towards announcements, the collaboractive book, and so on). I am interested, only, in offering constructive criticism, so please don't mistake my tone.

The short version of my concern is this: As a "mission critical" user of Pharo, I will trade backward compatibility for improvement, if, as you say, you provide "maintained releases". Those last two words are the most important and incur a great burden of responsibility. I don't think the Pharo project has fully considered the responsibility of using those two words.

The short version of my recommendation is this: Have a look at the FreeBSD release engineering process. They break backward compatibility all the time, but, if I have a mission critical application running on 4.5, I will still get essential bug and security fixes for a few years, and I can run trials with 8.0 on my other servers. Moreover, they have an updated documented roadmap that I can look at to determine that I should continue to run 4.5 on that one box while testing 8.0 on the others.

Best regards,

Mike

-- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

Hi Stef I was not really comparing on a language level Smalltalk and Cobol, but more about systems in general. Those legacy systems are around for many years: people have learned the hard way about compatibility, reliability etc. on the other hand, legacy is often a chaotic [some words removed] mess.. I have worked on programs modified over a period of 20 years by 10 or more programmers.. This is also no fun, on the contrary, often a nightmare. I did those ancient languages (Cobol Fortran, and more) for many years and still will do with these procedural languages, because I have to make a living. But don't worry: to me, it sometimes gives the same fun as e.g. a technician who likes working on old steam locomotives in a railway museum :o) The whole environment is however painstakingly difficult (not the language) and needs discipline. I could give you a sightseeing on a mainframe site, but it would make you weep :o) btw. May I introduce myself? look at my CV at : http://tedvg.seasidehosting.st/seaside/TGCVSite (very beta, my first Smalltalk/Seaside app. my picture is a bit formal even wearing a tie:o) I tried in the last 15 years or so to get work with more modern OOP systems e.g. Smalltalk, Java C#. even Delphi. mostly I dindn't succeed. I studied all of this intensively in my free time. I would (if I could) rather have written all these past software in Smalltalk.. Would have saved me a lot of headaches But back then systems were too slow, it was all "too academic" and Smalltalk had just being invented. In those years me, and many others too, had almost no notion of what object technology really is.. Now, today, I see my long existing dreams actually getting fulfilled! I can use Smalltalk because now it works and is fast enough too. I like it very much and hope to get work with it if get more proficient with it. Pharo looks good, is stable and a please to work with. I really hope Pharo / Smalltalk establishes itself, because it is clean, pure, fun and I can concentrate on fast application building instead of many nitty gritty language details. I am still a rookie on Smalltalk steroids, will contribute if I get better with it. Thanks all for all the work. Perhaps it is comforting to know that even people like me, coming from totally different IT fields believe in Smalltalk, maybe it is exactly because we can compare to what we already know. Ted Jikes! too much text. Too much time. I need to get a job soon. On Wed, Apr 27, 2011 at 7:42 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

Mike and other

How many engineers are payed to deliver freeBSD? How many active committers and packages responsible are actively commiting and taking responsibility for packages?

We need also stability but right now not changing is just been dead. I think that lot of people do not read the code of pharo else they would see why we are changing. We do not change for the fun. THIS IS NOT FUN TO write boring code to fix ugly situation. We would prefer to write hyper cool sexy app and be fancy to impress girls but this is not like that. Network is bad, compiler is bad, file is ugly.... Once this will be fixed then we will not change for the sake of it.

Now comparing Smalltalk to cobol is silly (sorry but it is). Right we are fighting with python, ruby, javascript (in fact we are not fighting since we do not even exist in the radar). If we want to get a chance, we should move way faster and be really aggressive to make sure that you can write hyper cool application.

Now why would you need to upgrade all the time to new versions if your system is working.

Metacello and versioning systems are your friends: maintain difference streams and versions if you want to share between different versions.

Stef

Em 27-04-2011 18:41, Jon Hancock escreveu:

Stef, I'm with you!! Keep hacking away at Pharo and make it the cleanest, nicest Smalltalk environment. Backwards compat talk this early in Pharo's life is premature. Besides, one of Smalltalk's best features is discovery and refactoring. This makes it much easier to migrate and rewrite when things break.

Thanks for all your work!! I'm only "playing" with pharo these days but keep looking for U.S. clients where I can plug it in. ~Jon +1 here.

Backwards compatibility would make sense only if there were widespread use applications. Except for seaside I cannot mention (I'm not being rude, neither willing to hurt feelings) other pharo/squeak artifact that's used in a scale enough to demand back compat. Small scale applications or stand alone solutions don't require updates/upgrades. I agree with Stef & others: the important thing at the moment is having a platform. Pharo isn't it yet. At current pace it will be soon. When it happens and people see the value to deliver mass solutions, then a requirement for back compat will appear. It's interesting but many complaints about compatibility are done regarding to packages that aren't even maintained anymore. And that happens in part because of platform deficiencies pointed by Stef. My 0,99c here... CdAB

I've noticed a funny behavior of Transcript. Sometimes it is loosing it's "window" attributes (borders, etc). Sometimes it's "waking by itself" (meaning, it's minimized & when something is output to it it appears on World but without borders, etc). I'll investigate more & inform. CdAB

On Apr 27, 2011, at 11:41 PM, Jon Hancock wrote:

Stef, I'm with you!! Keep hacking away at Pharo and make it the cleanest, nicest Smalltalk environment. Backwards compat talk this early in Pharo's life is premature. Besides, one of Smalltalk's best features is discovery and refactoring. This makes it much easier to migrate and rewrite when things break.

Thanks for all your work!! I'm only "playing" with pharo these days but keep looking for U.S. clients where I can plug it in.

Excellent I cross my finger. Stef

~Jon

On 04/27/2011 01:42 PM, Stéphane Ducasse wrote:

...

Mike and other

How many engineers are payed to deliver freeBSD? How many active committers and packages responsible are actively commiting and taking responsibility for packages?

We need also stability but right now not changing is just been dead. I think that lot of people do not read the code of pharo else they would see why we are changing. We do not change for the fun. THIS IS NOT FUN TO write boring code to fix ugly situation. We would prefer to write hyper cool sexy app and be fancy to impress girls but this is not like that. Network is bad, compiler is bad, file is ugly.... Once this will be fixed then we will not change for the sake of it.

Now comparing Smalltalk to cobol is silly (sorry but it is). Right we are fighting with python, ruby, javascript (in fact we are not fighting since we do not even exist in the radar). If we want to get a chance, we should move way faster and be really aggressive to make sure that you can write hyper cool application.

Now why would you need to upgrade all the time to new versions if your system is working.

Metacello and versioning systems are your friends: maintain difference streams and versions if you want to share between different versions.

Stef