The main Squeak problem Was: [Re: [squeak-dev] SqueakMap is a "Showroom"]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

The main Squeak problem Was: [Re: [squeak-dev] SqueakMap is a "Showroom"]

Igor Stasenko
2008/6/28 Damien Pollet <[hidden email]>:
> Ex. Pier needs Seaside. If there is a new release of Pier, the Pier
> developers update the Pier package and nothing more. If Seaside gets
> upgraded, the Pier package should *not* have to change/be
> regenerated/whatever until the Pier code is updated.
>

This scenario is quite unlikely in Squeak , but surely it is possible
in general in smalltalk (Spoon addresses that, getting rid of globals
addresses that :)
Once you change a class from which depends the rest, it may require to
update dependent code as well, otherwise it will be broken.
Unless people design things with modularity in mind, but i don't see
many of such packages, which can be used w/o fear that updating them
will not break something else. This is a real main problem of squeak:
bad design which prohibits modularity, not MC or SqueakMap nor CPAN or
other tools.

First, we need a paradigm shift IMO. From solid, single image where
everything is closely tied, to modular system where different parts
does not interfere with others, or if interfere, they play by strict
rules.

We had a lengthly battle yesterday on #squeak IRC channel. It seems
everyone wants better Squeak as we know it. But having different views
on it.

Surely, we can improve our tools, and they indeed need improvement.
This is great, but in the end, if we stay with old paradigm, no wonder
will happen.
Ask yourself, do you want a system, where you can load any code
without any risk, and even if it broken, it will not break the rest of
your system?
Do we want it to be a smalltalk, not a NewSpeak? Or we just wait till
NewSpeak (or another heir of smalltalk will successed and migrate to
it?).

Lets just understand, that to get to new level, we need a quality
shift (change system to become truly modular) , not quantity (make
more or better tools). Only after we do that, squeak can explode with
quantity, because there will be much less things to deal with.
As with Alan's analogy: we have objects which behave as body cells and
they are quite modular. But why, at same time, we deny that group of
cells (package/set of classes) can't be modular?

Make system modular. This is what most of currently elected board
members (including me) had in their platform. This is what, i think
people wanted from us.


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: The main Squeak problem Was: [Re: [squeak-dev] SqueakMap is a "Showroom"]

Damien Pollet
On Sat, Jun 28, 2008 at 11:01 PM, Igor Stasenko <[hidden email]> wrote:
> Once you change a class from which depends the rest, it may require to
> update dependent code as well, otherwise it will be broken.

Yeah but that's not the fault of the package system then, it's poor
development practice as you say.

> First, we need a paradigm shift IMO. From solid, single image where
> everything is closely tied, to modular system where different parts
> does not interfere with others, or if interfere, they play by strict
> rules.

This is a chicken/egg problem as usual. IMHO if we have a package
system then users will try to upgrade things more often (revealing
bugs faster) and developers will have something to document
dependancies in a practical way. That's also why I'd like to see the
package layer integrated with squeaksource eventually, to make it
simple to update a package (with metadata integrated in MC snapshots
for instance).


--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

Reply | Threaded
Open this post in threaded view
|

Re: The main Squeak problem Was: [Re: [squeak-dev] SqueakMap is a "Showroom"]

Michael van der Gulik-2
In reply to this post by Igor Stasenko


On Sun, Jun 29, 2008 at 9:01 AM, Igor Stasenko <[hidden email]> wrote:

Ask yourself, do you want a system, where you can load any code
without any risk, and even if it broken, it will not break the rest of
your system?

I'm working on it... ;-).

http://gulik.pbwiki.com/SecureSqueak

Gulik.

--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/