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