[Packages] Split-Join in development universe etc

Jason Johnson jason.johnson.081 at gmail.com
Thu Aug 9 20:05:55 UTC 2007


On 8/9/07, Keith Hodges <keith_hodges at yahoo.co.uk> wrote:
>
> >
> If someone wants to do this then let em, its an open source project, if
> it works then great, if not then good luck to them. Its not our job to
> be the censors as to what someone may or may not do with squeak in the
> future.



No one is stopping them.  From doing it to their own image or fork.  But to
the base image?

Yes it takes more thought to refactor and tidy up that it did to put it
> in in the first place, there are often more factors to be considered.
> Having a bigger armory of techniques is not a bad thing.



To a point.  But not all techniques fit.  I think you would agree that e.g.
pointers are a technique we don't need.

I mean by this that simply saying "this is another technique" isn't a get in
free card.  It still has be accepted by the right people, and if it isn't
that isn't necessarily a failing of the community.

I still don't understand the problem with having this a package and let
people use it that want it?  Ok, so they can't use it on the Kernel, but
most Squeak work done is in external projects, not the Kernel.

The use of innovations in that sentence is not referring to anything
> specific, its a general point, so I am not pronouncing anything.


Then what innovations did you have in mind that were rejected?


This is pitting abstract versus concrete thinking. Adding a language
> feature is an abstract concept, and provides benefits in terms of the
> abstractions available for thinking about the problem etc. Concrete
> thinking is demanding stats before the fact.


No, I'm talking about what works.  Put the thing in your own personal image
and use abstract thinking to make the image better and then you have
something concrete to show people to get adoption.

But is it possible that you are still seeing things through the lens of your
previous language experience?  Is it possible that the Null pattern is
normally done some other way in Smalltalk and therefor isn't the hammer it
was in Objective-C?

I see a lot of places I feel that I could make more concise/clear code if we
had Haskell/Erlang style pattern matching for functions, but that's not how
Smalltalk works.  Smalltalk has a Smalltalk way to solve that (e.g. double
dispatch).  I would search out the Smalltalk way before trying to force
pattern matching into the language.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070809/ffa1920a/attachment.htm


More information about the Squeak-dev mailing list