2010/1/24 keith keith_hodges@yahoo.co.uk:
On 24 Jan 2010, at 06:44, Friedrich Dominicus wrote:
Josh Gargus josh@schwa.ca writes:
The "community" doesn't want only one thing, and different people in it want different things to different degrees. I don't dispute that what you have described above is desirable, in principle, to the vast majority of community members. However, it is fundamentally at odds with other goals that various community members hold dear. A balance must be struck.
You are right, but let's as it that way:
- how many of you do activly work in the "Kernel!"
- how many of you do use it for application development
I would be suprised to see a ratio much higher than 1:10 000 or even 1: 100 000 (kernel dev/application dev).
As I understand Keiths posting he's mainly an application developer and so it's clear that he does not like to re-write his code over and over again (for whatever good/bad technical reason).
It's worse than that.
When there are too many packages all a moving target, being written on too many differing kernels, also moving targets. At some point the task of building an application and maintaining it becomes virtually impossible.
Suddenly there comes a point where the only choice you have is to fork everything!
This is a very hard choice to make if you are not good enough, or you don't have the time to maintain everything.
Of course the gurus Lukas', Andreas and Stefane don't have this problem, so they apparently don't see a need.
There's IMHO no better way to drive away people but to break their code over and over again...
Amen, Amen and Amen.
Here's a very specific example. I would like to see more integrated support for concurrent programming in the Squeak kernel. Toward that end, I've added a trivial implementation of "promises" to the trunk (hopefully, I'll take it further relatively soon... one of the things I've done in the interim was to re-read Mark Miller's dissertation).
Well so you are interested in another thing. Well so you probably do not see the points of Keiths mails.
Regards Friedrich
Josh,
So, your implementation of futures, that sounds useful. My images are all based upon 3.10, so would you be so kind as to package up your implementation in a form that I can actually use in my images. A change set that is load able into 3.10 would be good enough, if you did this then Edgar would use it too I am sure. You see, then I can use your API with my current code base. When the time comes to move my code base to 3.11, the transition will be a smooth one.
thanks in advance
Keith
Keith, you know very well your main options: 1) you take a trunk/pharo/cuis image then reload all your stuff (LPF/Installer/Sake/Package SHOULD be helpful). You may report compatibility problems in relevant list. 2) you start with an unmaintained image from the past, transform MC diffs into change sets and you cherry pick, but you're on your own.
I know very well your problems. I played option 2) during seveal years when releasing a commercial product in VW. I know very well the costs, and I know you are in trouble with this path.
Not that many experienced people are still supporting option 2). Juan still use it because he wants a very fine grain control. The fact that Cuis is minimal may help but he knows how much time it costs. Sorry, but I doubt you'll attract many people on that path.
Would I develop an app today, no doubt it would be with option 1. Installer/Sake could be used as well for option 1, couldn't it ? You have to think about this option too. That's how I see things with option 1: - you select an image when you think added value is worth the effort (like faster file I/O) - you load and run specific Kernel tests expressing the essential expectations of your application here, you can have a go/no go decision. It can also be a maybe: you send requests to developpers or propose your own changes in trunk. - you play your scripts to load your application - you run your application tests and ask for support on regressions and uncompatibilities.
More over, with bob you could automate the tests and automatically know if trunk updates are breaking things or not. So the question of an officially "released" image is less relevant. If you really want this process, adopt Pharo, they are close to 1.0 (without faster streams and other improvments of course...).
Cheers.
Nicolas