There is definitely the other side of things, that side that says you cant have 
an omelet if you don't brake some eggs. I always admire people that go against 
the flow , people who are willing to sacrifice convenience for progress.  

I do believe in the direction pharo is going , I do believe that keeping code 
clean and reliable should be main priority. And even though people love to call 
attempts dead and futile , ideas are near impossible to kill because they 
always find brains to flourish on. And even a bad idea in time can turn into 
something great. 


Because as one Greek philosopher once said "everything is changing" , 
everything has a life of its own, and as far as software is concern as long as 
there are coders for it , it aint dead yet. And there definitely benefits to be 
gained from braking compatibility. But progress is definitely a tricky things 
full of pitfalls and new is not always better. Its ironic how software seems to 
going back through time nowdays and rediscovering old relics like smalltalk and 
lisp. And "old" becomes the new "new". Definitely keeping an open mind is the 
wise thing to do any direction one may chooses to go. And I am certainly going 
to follow pharo and squeak progress closely because both have still a lot to 
say.



________________________________
 From: Nicolas Cellier <[email protected]>
To: [email protected]; [email protected] 
Sent: Tuesday, 11 December 2012, 22:50
Subject: Re: [Pharo-project] About (backwards) Compatibility
 
2012/12/11 Chris Muller <[email protected]>:
> If my goal is to make my computer work for ME, then I want my
> development system to maximize my leverage and minimize my effort.
> Breaking compatibility for cleaner code subverts this, as Hannes said,
>

One thing is clear, forking is not anything near minimizing the
effort, quite the opposite.
It's the way to build one's own jail  - some will say to be free ;).
Clearly, Marcus and Stephane have other goals and it's a good thing to
have both Squeak and Pharo.

>>> Constant input in maintenance effort is needed.
>
> I want to use my time applying Smalltalk to real-world problems, not
> API changes.
>
> A blue-plane innovation is worth breaking backward compatibility,
> reinventing the past isn't.
>

Ah, if future is the past, then I wonder whether it's not yet another
damned Smalltalk circularity trick ;)

>
>>> maintaining libraries and maybe compatibility layers are very welcome.
>>>
>> Yes, and how did we ever thought we could invent the future with Squeak
>> when in reality, we could not even change a typo in a comment?
>>
>>         Marcus
>>
>>
>>
>>
>

Reply via email to