Tweak mainstream in Squeak

Alberto Berti alberto at metapensiero.it
Tue Jul 11 02:06:56 UTC 2006


Andreas Raab wrote:
>
> You're totally missing my point. Let's take one example from your 
> list: ToolBuilder. Let's say you've got some work that uses it, would 
> you really expect that in each new Squeak version you have to spend 
> major effort to port your code to the latest ToolBuilder version? Or 
> wouldn't you rather expect that there is a stable API that can be used 
> and that may be extended over time, or even broken, but if it's broken 
> that you may get some notice about it beforehand? Or, in particular 
> when the changes get really fundamental, that instead of modifying 
> ToolBuilder in-place you get the offer to use either ToolBuilder 
> (working the way it always did) and whatever the brand-new framework 
> of the day is?
>
> I'm curious but is my position in this discussion really so outrageous?
not for me
I'm primarily a python developer which looks at squeak as a wonderful 
platform where implement multimedia apps for children. Unfortunately, 
it's difficult for me to understand what's new in each release and where 
will go the development from there... No (or minor) release docs, no 
code that comes from enhancements proposals (like PEPs) and that's 
discussed before actual inclusion in the release. And with each release 
you get the 90% of probability that if you try to filein a package or 
code developed for the release before the one you are running it will 
not run at all.
Python has it's own big problems too (the code and naming style of its 
standard lib changes from module to module and big parts of that library 
are function oriented rather than object oriented), but it cares 
backward compatibility  a lot... Important enhancements that will be 
enabled by default in the next stable version are available in the 
actual release by importing them from a special "future" module as old 
features considered "deprecated" are available in a number of releases 
since then. I consider the fact that squeak is always a "moving target" 
from an API  POV one of its major drawbacks and one of the reasons why 
there is so little documentation about them, a fact that which i think 
keeps possible developers interested in squeak away from it.

my two cents,

Alberto



More information about the Squeak-dev mailing list