Amazing stuff (Was: Re: [squeak-dev] The future of Squeak & Pharo
(was Re: [Pharo-project] [ANN] Pharo MIT license clean))
Cameron Sanders
csanders.personal at functional-analyst.com
Mon Jun 29 15:08:39 UTC 2009
On Jun 29, 2009, at 3:10 AM, Stéphane Rollandin wrote:
> now, seriously: I never said things should not be cleaned up. my
> view about backward compatibility and progress is quite balanced, to
> me. I'm sorry I can't make it convincing, and sorry to end up being
> considered as an extremist opposed to any change.
>
> Stef
I applaud your efforts - all of you - on the creation side.
I abandoned my Python base this last year because I got tired of the
language changing. This system was the result of 10 years of part-
time development. I like most of the changes to the language over the
years, especially as they firmed up the OO aspects (names spaces,
etc.), I just simply got tired of rewriting my code every time a new
version came out and I wanted to utilize the features. And sometimes
that was because some 3rd party library wasn't being ported to the new
version and I was forced to adopt a new library. (Sure, I am being a
little dramatic, as not every change was so radical as to require
rewrites.)
I had some interest in C++ in the mid-1980's... but I did not like
that the language definition kept changing (in that era). Fortunately
I discovered smalltalk and objective-c around that time. Although,
because of the lack of stable (multi-platform) support for objective-
C, my shop ended up rolling our own dynamic messaging system (change-
notification manager, and all the bells and whistles) in straight-up
C... because we knew we would always be able to compile C.
For people to get serious about building large apps in Pharo -- and
the following may not be one's goal, depending on who we are talking
about -- it MUST have a stable interface (set of methods) to some core
classes. Ideally, the core environment should have the minimal
interface that is guaranteed not to change. The implementation can be
whatever fulfills the behavioral requirements best at the time; the
end user (a programmer) does not care, so long as a given interface
provides a predictable behavior across versions.
Is this a good time to talk about packages and namespaces? As a user
(programmer), it would be nice to be able to specify which extensions
(or behavioral overrides) to the core classes to enable. Ideally these
extension sets/definitions could co-exist in the same image... but
that is NOT required to provide the capability. It seems that a such
capabilities would allow one to clean up the core, without abandoning
existing interfaces; and hence, without completely breaking legacy
code, e.g. to have #isKindOf:orOf: perhaps you need to import, or load
the package KitchenSink. It *seems* that such capabilities could help
bridge any future gaps between Squeak & Pharo, for example.
Of course, having these capabilities is one thing, and going through
and scrubbing the code is another. Which, aside from the effort, still
requires a committee to decide what is core (and to be permanently
supported) and what is not.
-- back to broad adoption issues...
Speed/performance is also important in order to make Pharo appeal to a
broader audience. Xupery might solve the problem. (I assume the C code
generated has been highly optimized -- does any person "in the know"
believe there is an opportunity for improving the C code?)
--
[Did I write something like this last week? I think i did, and then
deleted it -- if this is a repeat, my apologies.]
Pharo is great. And for my development, I simply do not perform the
updates very often, because I do not want to risk entering a debugging
cycle on things that currently work. But the momentum is exciting and
is part of the attraction!
With appreciation,
Cam
More information about the Squeak-dev
mailing list
|