Magic (was Re: [squeak-dev] Re: Menu Registries)

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Apr 28 18:40:47 UTC 2010


2010/4/28 Bert Freudenberg <bert at freudenbergs.de>:
> Folks, *please* change the subject according to the discussion topic. Srsly.
>
> On 28.04.2010, at 17:57, Andreas Raab wrote:
>>
>> On 4/28/2010 8:47 AM, Brent Pinkney wrote:
>>> Hi all,+
>>>
>>> Could those in the know comment on how this<...>  proposal is (or is not) consistent with the fundamental Smalltalk principles
>>> that:
>>>
>>> 1. "an object is send a message and responds with an object"
>>
>> It is perfectly consistent with it.
>>
>>> 2. there is no other "magic" in the system.
>>
>> Did you make that up? A wise man once said that any sufficiently advanced technology is indistinguishable from magic. I don't recall this ever being mentioned as a "fundamental principle" of Smalltalk.
>>
>>> Are we proposing a break fromv this ? If so, IMO we need to really get it right before we commit.
>>
>> Nobody is proposing to break with the first. I don't know what constitutes "magic" to answer the second but I'll point out that reflection has generally been accepted as a tool in the Smalltalk community although it could be considered magic.
>>
>> Cheers,
>>  - Andreas
>
> IMHO there is a tendency even in the Smalltalk community towards working more with code, less with objects. What method properties do could as well be represented differently, and edited with some other UI than text. But we still do not have an accepted way to share objects, so we tend to put everything into code.
>
> In a way, method properties are a reification of comments, meant to be utilized by the system. It allows the system to know more about this piece of code than "this is a sequence of message sends". This meta information could as well be represented elsewhere, but putting it in as text along with the code lets us re-use the interface (text editing).
>
> - Bert -
>

It's a question of tools for sure, with a textual representation we
can manage versions and exchange objects more easily.
But it's also a question of quality process. Selling the object
without the building process is like we lost the recipe.
Textual representation is limitating (a good example is a programmed
icon versus an artistic one), but easier to manage and reproduce.

When I worked with VW, I used objects a lot at the beginning, but when
bored porting from an image to the other (the problem being how to be
sure I did not forget an object), I cut my wings and fell back to
text.

Nicolas



More information about the Squeak-dev mailing list