[squeak-dev] [Cuis] Cuis

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Sun Jan 24 13:42:08 UTC 2010


2010/1/24 keith <keith_hodges at yahoo.co.uk>:
>
> On 24 Jan 2010, at 06:44, Friedrich Dominicus wrote:
>
>> Josh Gargus <josh at 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



More information about the Squeak-dev mailing list