It works for me on XP, RealPlayer 10.5 Vaidas

Is there any chance to have a video in different (more open) format?

2008/4/18 Lukas Renggli renggli@gmail.com:

It doesn't work on the latest RealPlayer on OS X either :-(

Lukas

-- Lukas Renggli http://www.lukas-renggli.ch

Do not worked here. Is there someone that can convert the video to a popular format? thanks in advance, Ale.

----- Original Message ----- From: "Michael Haupt" mhaupt@gmail.com To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Friday, April 18, 2008 5:53 AM Subject: Re: [squeak-dev] Re: talk on Newspeak online

Dear all,

we do not have influence on the format the Tele-Task videos are published in.

Best,

Michael

I have converted the slides from ".rm" format to windows media format using PocketPC (wide screen) profile, to see the slides unplugged. The video can be downloaded from my swiki server (temporary store) at http://www.aleReimondo.com.ar/Temp (The file will be removed during next week) best, Ale.

----- Original Message ----- From: "Damien Cassou" damien.cassou@gmail.com To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Friday, April 18, 2008 7:38 AM Subject: Re: [squeak-dev] Re: talk on Newspeak online

I'm also interested in a new format.

On Fri, Apr 18, 2008 at 11:28 AM, Alejandro F. Reimondo aleReimondo@smalltalking.net wrote:

...

Do not worked here. Is there someone that can convert the video to a popular format? thanks in advance, Ale.

----- Original Message ----- From: "Michael Haupt" mhaupt@gmail.com To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Friday, April 18, 2008 5:53 AM Subject: Re: [squeak-dev] Re: talk on Newspeak online

...

Dear all,

we do not have influence on the format the Tele-Task videos are published

in.

...

Best,

Michael

-- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)

--------------------------------------------------------------------------------

Mhh, not being behind the university proxy helps here.

Lukas

Really interesting talk.

Is there anyway that the FFI his team created could be merged back into the main squeak vm?

Yes, amazing what they did in so little time.

Squeak looks really old compared to that.

Lukas

On Sat, Apr 19, 2008 at 4:15 PM, Bert Freudenberg bert@freudenbergs.de wrote:

Certainly. However, Gilad said they do not intend to release it.

• Bert -

On 19.04.2008, at 15:40, Wilkes Joiner wrote:

...

Really interesting talk.

Is there anyway that the FFI his team created could be merged back into the main squeak vm?

Hmm, I understood the contrary, that he was trying to convince his management that opensource was the way to go…

Wilkes Joiner wrote:

Understandably, he doesn't want to unleash Newspeak right now. I'm hoping that they will release just the FFI vm enhancements. Assuming that would be relatively simple to release independently.

Someone wake me up when that happens ;-)

Cheers, - Andreas

I read Gilad's blog and having some concepts which i think is redundant and smell like javaisms. For instance, i don't share the view, that all fields in class instance should be initialized and initialized once, by constructor (instance factory method). What about lazy initialization? What if superclass initializes ivar with something, then using that ivar during rest of initialization phase, and then at subclass initialization it can be overridden by another value, after done initializing superclass. I think that language shouldn't care or enforce rules aka 'constructors', its totally redundant to me. Developer should know himself, how and where initialize ivars, not in compiler/constructor.

Declaring private/public fields looking redundant too: they should be always private. Instead, accessors #foo, #foo: can be made public or private by the will. But if you make field public, then it's accessors became public as well? But what if i want #foo to be public, but #foo: to be private?

Hi Danil,

On Wed, May 7, 2008 at 11:26 AM, danil osipchuk danil.osipchuk@gmail.com wrote:

Igor, could you please give a link to the article where Gilad speaks about it? (I can not find anything related in his blog)

probably you will find what you are looking for by looking at the beginning of this very thread. ;-)

Best,

Michael

Hi Danil,

sorry, I misunderstood you there. :-)

Best,

Michael

On Wed, May 7, 2008 at 11:39 AM, danil osipchuk danil.osipchuk@gmail.com wrote:

I've seen Gilad's presentation, but I can not remember if he spoke about constructors there either. And I had impression from that talk that variables (my memory is not good though :-) ) in newspeak are similar to Self's slots - access through message send only, so where do private/public ivars come from?

Danil

2008/5/7 Michael Haupt mhaupt@gmail.com:

...

Hi Danil,

On Wed, May 7, 2008 at 11:26 AM, danil osipchuk danil.osipchuk@gmail.com wrote:

...

Igor, could you please give a link to the article where Gilad speaks

about

...

...

it? (I can not find anything related in his blog)

probably you will find what you are looking for by looking at the beginning of this very thread. ;-)

Best,

Michael

On Wed, May 7, 2008 at 10:22 AM, Igor Stasenko siguctua@gmail.com wrote:

I read Gilad's blog and having some concepts which i think is redundant and smell like javaisms. For instance, i don't share the view, that all fields in class instance should be initialized and initialized once, by constructor (instance factory method). What about lazy initialization? What if superclass initializes ivar with something, then using that ivar during rest of initialization phase, and then at subclass initialization it can be overridden by another value, after done initializing superclass. I think that language shouldn't care or enforce rules aka 'constructors', its totally redundant to me. Developer should know himself, how and where initialize ivars, not in compiler/constructor.

More on constructors in newspeak: http://gbracha.blogspot.com/2007/08/object-initialization-and-construction.h....

In Smalltalk, we have no constructor. However, when we want to initialize data from an instance creation method we have to use accessors:

Person class>>name: aString birthdate: aDate ^ self new name: aString; birthdate: aDate; yourself

Another solution is to use a specific method like #setName:birthdate:. However, these solutions pollute the interface of the Person class: the developer is forced to add these methods to the public interface of the Person class.

I believe Newspeak's solution may fix that point. What do you think?

2008/5/7 Klaus D. Witzel klaus.witzel@cobss.com:

On Wed, 07 May 2008 10:22:46 +0200, Igor Stasenko wrote:

...

I read Gilad's blog and having some concepts which i think is redundant and smell like javaisms.

;)

...

For instance, i don't share the view, that all fields in class instance should be initialized and initialized once, by constructor (instance factory method). What about lazy initialization?

Lazy in the sense of, a) initialize them with nil [in the constructor] then later b) assign them anything else? That's always possible, isn't it. I don't see much a problem here, except the *cause* of such language design decision.

So, instead of polluting code with initializers (__which is optional__) as in Damien's note:

Person class>>name: aString birthdate: aDate ^ self new name: aString; birthdate: aDate; yourself

they proposing to pollute code with nil initializers everywhere (__which is mandatory__)? I don't see how latter is better than smalltalk.

The latter is concerned with 1) modularity-ness of each and every constituent 2) non-staticness of each and every constituent and 3) mixin-able-ness of every class (aka behavior-bearing object). To highlight just one problem in this >= 3 dimension time-space, which AFAICT is not solved yet (or perhaps just not published yet) in Newspeak: its *constructor* selector (the symbol) is for sure a *static* symbol constituent, violating non-staticness desideratum ... that is to say, even in a very-highly modularized Newspeak system you have to know the constructor message name of the things you import/mixin so, what about when they are changed behind your back ? (in a library you use, for example)

...

To me it looks like people see a fallen tree across the road here. I don't see much problem with smalltalk's approach. Proper initialization will be always a concern of developer. There is no way how we can ease his task with language sugars/semantics, because there always can be cases, which don't fit to developer's plan of how things needed to be initialized. So, the less we constrain him here - the better. For instance: useful case - omit calling superclass initialization.

...

Declaring private/public fields looking redundant too: they should be always private.

Except when you do not want to disappoint the zillions of flies around you? (who, by "law of gravity", cannot err ...)

I don't see how message-driven design (which Newspeak claiming is) should care about declaring state properties. State in message-driven system is a behavioral component, not declarative one.

...

Instead, accessors #foo, #foo: can be made public or private by the will. But if you make field public, then it's accessors became public as well? But what if i want #foo to be public, but #foo: to be private?

This is not a valid question for obtaining a Certified Javanese credit! You failed ! ;)

I don't need Certified Javanese credit :)

/Klaus

2008/5/7 Klaus D. Witzel klaus.witzel@cobss.com:

On Wed, 07 May 2008 15:48:56 +0200, Igor Stasenko wrote:

...

...

...

To me it looks like people see a fallen tree across the road here.

Hhm. what's that mean.

Means that people keep staring at it or starting building new road instead of just jumping over and continue moving :)

...

I don't see much problem with smalltalk's approach. Proper initialization will be always a concern of developer. There is no way how we can ease his task with language sugars/semantics, because there always can be cases, which don't fit to developer's plan of how things needed to be initialized. So, the less we constrain him here - the better.

Unless a language designer puts inheritance into the developer's hands and promises that the language then still provides modularity+messaging+you_name_it (unlike Squeak/Smalltalk which doesn't implement anything related to modularity nor slots).

_Implement_ - exactly!. A modularity is related to implementation not to language syntax - right? I think smalltalk can be made modular very easily, by reviewing role of globals and classes/metaclasses. But smalltalk syntax don't need to be changed to support modularity.

I think that Newspeak language design is one approach, Squeak/Smalltalk implementation is another.

...

For instance: useful case - omit calling superclass initialization.

Not possible in Newspeak, since by *naming* the superclass (at the "declarative" time of subclassing) in Newspeak one *must* also name super's constructor (the *static* symbol that I reflected upon in the above and again in the next sentence), or else accept the default one (#new); similiar to how it is in Javanese ;)

And similar to C++. But it is really needed time to time to have different order of initialization, or do partial initialization. Its not a point of good/bad design , its a point of simply allowing or disallowing that.

FWIW, the superclass' slot name can be anything (message based, of course) but, the constructor's message selector is the *static* thing that user of a module has to know about ...

Hmm, can classes have multiple constructors? Or just #new if not defined by developer and #myUberConstructor if defined?

...

I don't see how message-driven design (which Newspeak claiming is) should care about declaring state properties. State in message-driven system is a behavioral component, not declarative

one.

...

Didn't understand a word :( what has *state* to do with a scope-bound privilege? Can you reformulate using a) global visibility of a slot v.s. b) ... v.s. c) ... v.s. x) local visibility of a slot. TIA.

Writing 'v.s' in java and other rudimentary languages tells compiler to find a field with name 's' and check scope/visibility rules.

In message-based system, if i write 'object s' , error is possible only at runtime, since compiler knows nothing about object: does it having #s message? and what it does? does it private or public? Makes no sense at all.

So, in message-based system you really can tell compiler to check the caller context of message, and if caller context is wrong - generate exception. And this is nothing to do with slots, its only applicable to methods, because only messages we have, and messages computed by methods. Unless you put slot == method.

I have considerable experience programming in both Smalltalk and Newspeak, and (despite my email address) I'll say that Newspeak is an improvement in a number of aspects. That includes constructors.

The knee-jerk reaction of "X is crap because $(language_name) which has X is crap" can prevent you from seeing the nature of the issue. It helps to understand what X gives and what it takes away. Also, the particular X can be quite different from X in $(language_name).

What we are talking about here is _instance creation discipline_. Like any other discipline, it eliminates some freedoms in the interest of order and predictability. The question is always whether the gains of the latter compensate for the loss of former. I imagine 30 years ago there were people decrying the loss of goto and the freedom it brings.

Here is what disciplined instance creation brings:

1. Better class usability. The first question one has when looking at an unfamiliar class is "how do I use it?". The next one is often "how does it work?" Answering both depends on knowing how an instance is created and initialized. A Newspeak class declaration always provides the answer. In contrast, in Smalltalk you can only guess what instance creation messages can produce a valid instance. Presumably, the ones in the class will. Maybe the inherited ones too. At least some of them. Or will they?

2. Assurance that the instance you get is initialized properly as intended by the class author.

3. Easier change management. When I need to add a Boolean flag to an instance, I add one line to the class saying

isFoo ::= false.

This is the only change, other than actually using the flag, to ensure that the slot is there and properly initialized in all instances. I don't need to add a word to the class declaration to declare the variable, and then hunt down all possible initialization methods (what are they? did I cover all of them?) to ensure the initial value is always set. Furthermore, as the system mutates the existing instances, it can use this new declaration to initialize the slot in the old instances to at least have a value of proper type.

In my experience, all of the above are significant benefits that make it easier to build reliable programs.

On a more philosophical note, whether a "language shouldn't care or enforce rules aka 'constructors'". A language should help the developer use its facilities. Some rules and the structures they enforce may be helpful, even if they are not part of the language core. Objects are the primary facility of Smalltalk/Newspeak, and their creation is a common operation. Proper initialization is indeed concern of a developer, but it *can* in fact be eased with language semantics. Again, this is not a hypothetical proposition, this is my experience report.

As for the "useful" case of skipping superclass initialization--again, goto proponents had various use cases of how indispensable it was. The two cases are not that far from each other. You lose some capabilities, but in the larger picture of writing more predictable software the loss is more of a "good riddance" to the ability to introduce non-local idiosynchrasies.

Regarding "static constructor messages", I fail to see the problem. A message name is static by its nature, in that it is a human-readable reference to a certain behavioral contract. A "+" refers to a contract promising to perform an addition-like operation. "x:y:" refers to a contract to create a vector-like entity from components that carry a certain meaning. Patterns for adapting contracts with mismatching names have long existed, and can be applied to instance creation as well as they have been elsewhere.

Cheers,

--Vassili

On Thu, 08 May 2008 04:56:11 +0200, Igor Stasenko wrote:

2008/5/8 Vassili Bykov wrote:

...

I have considerable experience programming in both Smalltalk and Newspeak, and (despite my email address) I'll say that Newspeak is an improvement in a number of aspects. That includes constructors.

[...big snip...]

About constructors.

It is really easy to maintain same discipline in smalltalk. Maybe its hackish, but its possible to implement w/o changing syntax:

Heh! you seem to have the inlining compiler in mind when you give examples like the one below ;)

Anyways, hands up please: who's willing to be conformant, in her/his projects, to lengthy instance creation cobb salad (californian) like this?

MyStrictClass>>new self checkConstructor. ^ super new

MyStrictClass>>checkConstructor | sender | [ sender := thisContext sender. sender sender receiver == self ] whileTrue. self assert: (self validConstructors includes: sender method selector )

MyStrictClass>>validConstructors ^ ( #new )

MyStrictSubClass>>x: aX y:aY ^ super new x: aY; y: aY; yourself.

MyStrictSubClass>>validConstructors ^ ( #x:y: )

MyStrictSubClass2>>validConstructors ^ ( #x:y: #new ) "allow constructors from superclass and from superclass superclass"

2008/5/8 Igor Stasenko siguctua@gmail.com:

Btw, no one disallow you from doing following:

MyStrictClass>>new self isInDevelopmentMode ifTrue: [self checkConstructor]. ^ super new

so, it will cost you 1 extra send in deployed mode :)

Sorry for repost, this example actually shows that developer can easily enforce own (arbitrary) coding discipline, but without the need in changing anything in language.

2008/5/8 Klaus D. Witzel klaus.witzel@cobss.com:

On Thu, 08 May 2008 00:17:07 +0200, Vassili Bykov wrote:

...

I have considerable experience programming in both Smalltalk and Newspeak, and (despite my email address) I'll say that Newspeak is an improvement in a number of aspects. That includes constructors.

The knee-jerk reaction of "X is crap because $(language_name) which has X is crap" can prevent you from seeing the nature of the issue.

Vassili, this is squeak-dev list here, in which nobody would ever call a language which based on Smalltalk (and Self) as being *crap*.

C++ is crap, Java is crap, anyone wants to argue? And borrowing crappy concept from crappy language produces crap. Crap, despite how good it looks like outside (syntax sugar) still stays crap inside. ;) More about this at the end of message.

We [yes, I think: we] all admire the tremedous work you folks are doing with developing Newspeak on the Squeak platform. I know many of us who can't wait to get a full copy of Newspeak on their notebook, same for myself (if only to browse for the first time in life a *very*high*modular* messaged-based Smalltalk-rooted system ;-)

I'm looking forward to see Newspeak on my box. But my primary concern is not language problems (and what tricks authors made to get around them), but paths taken to meet goals of: - modularity - locality - security - reflectivity - flexibility of kernel/libraries.

AFAICT Igor is concerned about reduncancy and stiffness with particular language design decisions, on Newspeak constituents which he is used to implement himself in Smalltalk, on the fly and in such a way that it befits his actual project and not the language designer.

Right. One more point: What about metaprogramming?

Does anyone finds following pattern as bad style of programming? :

MyExternalModule>>new Smalltalk platformName = 'Windoze' ifTrue: [ ^ MyWin32ExternalModule new ]. Smalltalk platformName = 'Mac' ifTrue: [ ^ MyMacExternalModule new ]. Smalltalk platformName = 'foo' ifTrue: [ ^ MyfooExternalModule new ]. self error: 'Unsupported platform'.

The users of class does not care about subclasses and calling uniform MyExternalModule>>new which returning a proper instance for working on current platform. Interesting, how above looks in Newspeak?

Also, how about creating anonymous instance factories (also known as classes) on the fly?

AnonClassFactory>> x: aX y: aY | newClass | newClass := ClassBuilder new newSubclassOf: self type: self typeOfClass instanceVariables: '' from: nil. ^ newClass new x: aX y: aY

And finally, who told that, ultimately, only classes can create instances? Its interesting, in what way something like Prototype package can be implemented in NewSpeak?

Personally, i see that constructors putting flaws in message-oriented principles of NewSpeak. They shifting responsibility of message handling from developer's hands to compiler's hands and introducing unnecessary constrains forcing future developers to invent schemes how to avoid/sidestep them.

2008/5/8 Klaus D. Witzel klaus.witzel@cobss.com:

On Thu, 08 May 2008 12:30:54 +0200, Igor Stasenko wrote:

...

And borrowing crappy concept from crappy language produces crap. Crap, despite how good it looks like outside (syntax sugar) still stays crap inside. ;)

We'll see what *crap* you will produce (when Newspeak is released) when you're asked to then show solutions (in then existing Newspeak code) for

o every class can be mixed in [modulo slot name collision] o modules are containers with high degree of isolation o no extra code to make *something* a module o subclassing guarantees proper initialized subinstances

Can we stick with "redundant" instead of "crap" for the moment? ;)

Is it just only because *crap* is rude word or because it not precisely characterizing problems? ;)

...

Does anyone finds following pattern as bad style of programming? :

Yes, me ;) I dislike your constants (strings and class names as well). I know you can do better ;) Also, you must change your method once you have one more platform (or after one is renamed to Microhoo ;) I prefer production systems that can be changed without compiling existing methods (for example, when foo is temporarily not supported but Mac can do part of its job for a while).

...

MyExternalModule>>new Smalltalk platformName = 'Windoze' ifTrue: [ ^ MyWin32ExternalModule new

].

...

Smalltalk platformName = 'Mac' ifTrue: [ ^ MyMacExternalModule new ]. Smalltalk platformName = 'foo' ifTrue: [ ^ MyfooExternalModule new ]. self error: 'Unsupported platform'.

MyExternalModule>>#newFor: platName (Symbol hasInterned: platName ifTrue: [:sym | sel := sym]) ifFalse: [self error: '*unknown* platform name']. subclass := self platsSupported at: sel ifAbsent: [self error: '*unsupported* platform name']. ^ subclass new

In fact, this code snippet belongs to VMMaker, not mine. ;)

I would write it with a single line (true ST way of doing things):

MyExternalModule class>>new ^ ( self allSubclasses detect: [:class | class supportsPlatform: Smalltalk platformName ] ifNone: [ self error: 'unsupported platform' ] ) new

...

The users of class does not care about subclasses and calling uniform MyExternalModule>>new which returning a proper instance for working on current platform. Interesting, how above looks in Newspeak?

Preferable the way I rewrote it above (not only because that way it can be done in Newspeak ;)

...

Also, how about creating anonymous instance factories (also known as classes) on the fly?

AnonClassFactory>> x: aX y: aY | newClass | newClass := ClassBuilder new newSubclassOf: self type: self typeOfClass instanceVariables: '' from: nil. ^ newClass new x: aX y: aY

This one addresses my concern: just put (... newSubclassOf: anArgument ...) into the above and then begin to wonder about what's the constructor message selector's name :|

Well, a #new is not anyhow better than anything else. Who knows what anArgument>>#new does? It may or may not create instance, it can create an instance of different class, it can throw an error it can do virtually anything :)

...

And finally, who told that, ultimately, only classes can create instances? Its interesting, in what way something like Prototype package can be implemented in NewSpeak?

Personally, i see that constructors putting flaws in message-oriented principles of NewSpeak.

Do you think that it cannot be circumvented by the developer one way or the other in Newspeak?

If yes, why not?

Hmm, what is the purpose of language feature then if it need to be circumvented? Seems like people forget to use http://en.wikipedia.org/wiki/Occam%27s_Razor principles :)

On Thu, 08 May 2008 14:06:09 +0200, Igor Stasenko wrote:

2008/5/8 Klaus D. Witzel wrote:

...

On Thu, 08 May 2008 12:30:54 +0200, Igor Stasenko wrote:

...

And borrowing crappy concept from crappy language produces crap. Crap, despite how good it looks like outside (syntax sugar) still stays crap inside. ;)

We'll see what *crap* you will produce (when Newspeak is released) when you're asked to then show solutions (in then existing Newspeak code) for

o every class can be mixed in [modulo slot name collision] o modules are containers with high degree of isolation o no extra code to make *something* a module o subclassing guarantees proper initialized subinstances

Can we stick with "redundant" instead of "crap" for the moment? ;)

Is it just only because *crap* is rude word or because it not precisely characterizing problems? ;)

Both, of course; you know me by now ;) The third is [OT] your new role (being on the board ;)

...

...

Does anyone finds following pattern as bad style of programming? :

Yes, me ;) I dislike your constants (strings and class names as well). I know you can do better ;) Also, you must change your method once you have one more platform (or after one is renamed to Microhoo ;) I prefer production systems that can be changed without compiling existing methods (for example, when foo is temporarily not supported but Mac can do part of its job for a while).

...

MyExternalModule>>new Smalltalk platformName = 'Windoze' ifTrue: [ ^

MyWin32ExternalModule new ].

...

Smalltalk platformName = 'Mac' ifTrue: [ ^ MyMacExternalModule new

].

...

Smalltalk platformName = 'foo' ifTrue: [ ^ MyfooExternalModule new

].

...

self error: 'Unsupported platform'.

MyExternalModule>>#newFor: platName (Symbol hasInterned: platName ifTrue: [:sym | sel := sym]) ifFalse: [self error: '*unknown* platform name']. subclass := self platsSupported at: sel ifAbsent: [self error: '*unsupported* platform name']. ^ subclass new

In fact, this code snippet belongs to VMMaker, not mine. ;)

I would write it with a single line (true ST way of doing things):

MyExternalModule class>>new ^ ( self allSubclasses detect: [:class | class supportsPlatform: Smalltalk platformName ] ifNone: [ self error: 'unsupported platform' ] ) new

Ahh, I knew you know how :) But, by the joy offered from implicit-self message sends (statement-initial identifiers *are* sent :) one could also keep your (VMMaker's) style 1:1 in Newspeak. It's Smalltalk -anyways- even when I say I dislike it [the style of your method example].

[OT] is the snippet in Slang? then there could be C-compilation-reason for the style.

...

...

The users of class does not care about subclasses and calling uniform MyExternalModule>>new which returning a proper instance for working on current platform. Interesting, how above looks in Newspeak?

Preferable the way I rewrote it above (not only because that way it can be done in Newspeak ;)

...

Also, how about creating anonymous instance factories (also known as classes) on the fly?

AnonClassFactory>> x: aX y: aY | newClass | newClass := ClassBuilder new newSubclassOf: self type: self typeOfClass instanceVariables: '' from: nil. ^ newClass new x: aX y: aY

This one addresses my concern: just put (... newSubclassOf: anArgument ...) into the above and then begin to wonder about what's the constructor message selector's name :|

Well, a #new is not anyhow better than anything else. Who knows what anArgument>>#new does? It may or may not create instance, it can create an instance of different class, it can throw an error it can do virtually anything :)

Sure.

...

...

And finally, who told that, ultimately, only classes can create

instances?

...

Its interesting, in what way something like Prototype package can be implemented in NewSpeak?

Personally, i see that constructors putting flaws in message-oriented principles of NewSpeak.

Do you think that it cannot be circumvented by the developer one way or the other in Newspeak?

If yes, why not?

Hmm, what is the purpose of language feature then if it need to be circumvented?

Quick: what's the most circumvented language feature people use when smalltalking ;)

Seems like people forget to use http://en.wikipedia.org/wiki/Occam%27s_Razor principles :)

Nah. [OT] people tend to overuse (in the sense of over-cite) the razor principle, because its base is *plausible* *facts* which is only given when you *do*not* have plenty of choice (i.e. just choose between two). Otherwise the principle is synonym to lottery-principle ;)

On Thu, 08 May 2008 21:58:42 +0200, Igor Stasenko wrote:

2008/5/8 Klaus D. Witzel wrote:

...

On Thu, 08 May 2008 14:06:09 +0200, Igor Stasenko wrote:

[...]

...

...

Is it just only because *crap* is rude word or because it not precisely characterizing problems? ;)

Both, of course; you know me by now ;) The third is [OT] your new role (being on the board ;)

I trying to be constructive here. I not throwing a words that *something* is stinks just because i don't like the *thing*, i providing arguments and explanations why i think its err.. crappy :) Oh, and i didn't used this word before Vassili started.

Right, and from his other post it seems like he's using the word like any other slot name ;)

NP, back to the issues :)

Well, if people want to defend their position more aggressively, i answer in same style. But this not means that my point is not constructive however. Please do not take my comments as personal attack or ranting, i just trying to put arguments and discuss why some things i think having flaws.

Sure, I knew we will agree on this :) And I think you know that I appreciate your valued critique. So when I ask, don't use "crap" word, then I want more/detailed critique, not the metaphors ;)

...

...

[OT] is the snippet in Slang? then there could be C-compilation-reason for the style.

Can't parse your last phrase. Please elaborate.

In Slang you wouldn't be able to use metaobjects (your use of #subclasses) nor dictionaries (as in my example) so one way to express the [small] case list in Slang is with a list of ifTrue's.

...

...

...

Hmm, what is the purpose of language feature then if it need to be circumvented?

Quick: what's the most circumvented language feature people use when smalltalking ;)

No idea. Put on desk the aces from you sleeve :)

Will do but, not in this thread and at another time ;)

First of all, I take none of this personally or as an offense so don't worry about the language or what's being said. In fact, it was I who first referenced "crappy languages", and we seem to agree on what those are. :)

I'm not arguing against the general thesis that borrowing crappy features from crappy languages produces crap. But the important question is whether constructors are a crappy feature in C++ or Java because the *idea* of disciplined object initialization is flawed, or because its particular incarnation in those languages is bad. Also, "borrowing" is a vague notion with an arbitrary attribution. What makes you believe that Newspeak "borrows" the idea of disciplined object initialization from C++ or Java and not, say, from CLOS or Dylan? And what exactly is borrowed, besides the term?

Igor, from trying to follow this thread I got an impression that the reason for your pushback may be an implicit assumption that Newspeak "constructors" are the same thing as Java constructors. It's understandable that anyone here may have misconceptions, and that's the reason I'm responding in this thread. There is not much information out there, not because of any secrecy, simply because it's not written up. I'd be happy to answer any questions that help clarify things.

Now, as an aside, it's hard to parse a day's worth of posts consisting mostly of many levels of quoted text and a few lines of actual content, so excuse me if I missed a prior question worth answering. I did notice the question about MyExternalModule and how that would look in Newspeak. There are several possible solutions. Here is one:

class ExternalInterface platform: platform = ( | platformName = platform platformName. |) ( private class MacOSExternalInterface = ...

private class LinuxExternalInterface = ...

private class Win32ExternalInterface = ...

new = ( platformName = 'MacOS' ifTrue: [^MacOSExternalExternalInterface new]. platformName = 'Linux' ifTrue: [^LinuxExternalExternalInterface new]. platformName = 'Win32' ifTrue: [^Win32ExternalExternalInterface new]. error: 'unknown platform'. ) )

I took the liberty of replacing "Module" with "Interface" to avoid confusion, as I'll be talking about modules in a different sense.

This snippet illustrates many Newspeak things at once: absense of global state, nested classes and classes-as-modules, read-only slots, and message privacy. The top-level class ExternalModule plays the role of a module. The argument 'platform' is a platform object the module user will provide at the time a module instance is created, for example as:

ExternalInterface platform: Smalltalk

The use of '=' in the 'platformName' slot definition identifies it as a read-only slot: the class will include a getter for it but no setter.

The three nested classes are private, which means the module will not respond to messages such as #MacOSExternalInterface if they are sent by other objects. It will respond to these messages sent from itself, as in the #new method. And thanks to that #new method, the module is also a factory that creates an interface instance appropriate for the platform.

As a user of this, you would likely create an instance of the module and store in a slot defined as something like (assuming that ExternalInterface and Smalltalk have been bound to appropriate objects):

Interface = ExternalInterface platform: Smalltalk.

And then create instances in the code with "Interface new". To the rest of the code, "Interface" is no different from a real instantiable class.

If the classes nested in ExternalInterface were not qualified as private, it would be possible to retrieve them by sending a getter message to the module and instantiate directly:

(ExternalInterface platform: Smalltalk) Win32ExternalInterface new

Some other points.

Regarding freedom vs restrictions and predefined mechanisms, you have to realize that very often abstraction design is like cutting a fractal border with a straight knife. No matter how you do it, by imposing regularities you leave something unnecessary and cut off something useful. This is why any example like "here is one case where X is clearly better than the alternatives" never proves anything by itself, being only an isolated case. It's all a matter of statistics and priorities.

I'm not sure how "locality" as a positive quality and the ability to skip superclass initialization as a useful feature go together.

Regarding constructors "implemented" in Smalltalk--it shows two things at once. 1) there if enough reflection in Smalltalk to implement something like this, and 2) there is not enough syntactic abstraction to hide the boilerplate and make it usable. There is a similar issue with providing list comprehensions within Smalltalk/Newspeak syntax. It's easy to do the work, but it's impossible to hide all the exposed wiring, avoid binding names more than once, etc. In the end, it's only a proof of concept and not a *usable* feature.

And, I completely agree with Klaus about Occam's Razor sometimes being cited indiscriminately. There might be a place somewhere in the Fifth Circle where Occam's Razor abusers are implementing a Blue Book VM on the Turing machine.

Cheers,

--Vassili

On Thu, May 8, 2008 at 4:50 PM, Igor Stasenko siguctua@gmail.com wrote:

In given example i assumed that ExternalInterface is basic abstract class, which provides common interface, while different subclasses providing specialization for each separate platform.

Good point. I thought to gloss over this to keep my explanation shorter but no such luck. :) However, this leads to interesting follow-up examples.

In your original example, and usually in real cases like this in Smalltalk, the superclass plays several roles. As a class it captures the common behavior, sometimes abstract sometimes not. As an object, it is a factory. As a name in the developer's vocabulary it references a piece of functionality, or a "module".

In my example an instance of the outer class is really a factory and a module. I omitted a superclass for capturing common behavior. A more complete example with more descriptive names would be:

class ExternalInterfaceFactory platform: platform = ( | platformName = platform platformName. | ) ( private class ExternalInterface = (...)

private class MacOSExternalInterface = ExternalInterface (...)

...and so on... )

Now that the pieces are more appropriately named, hopefully it is clearer how they relate. You create an instance of a factory by sending #platform: to the outer class, and then you create instances of the nested classes by sending #new to the factory.

Note that the outer class still combines two roles: a module providing some functionality and a factory. If need be, they can also be separated:

class ExternalInterfaceModule platform: platform = ( | platformName = platform platformName. factory = InterfaceFactory new. | ) ( private class InterfaceFactory = ( | | ) ( new = ( platformName = 'MacOS' ifTrue: [^MacOSExternalInterface new]. ... ) )

private class ExternalInterface = (...)

private class MacOSExternalInterface = ExternalInterface (...)

...and so on... )

This would now be used in a two-step process, first creating the module and then retrieving its factory to create instances. A factory could be designed to support "plugins" for other platforms registered with a message such as #createInstancesFor:using:. Presumably some or all of the nested classes would be public in such a scenario to make them available for subclassing. A user module might look something like:

class MyApp platform: platform externalInterface: moduleClass = ( | ExternalInterfaceModule = moduleClass platform: platform. ExternalInterface = ExternalInterfaceModule factory. AbstractExternalInterface = ExternalInterfaceModule ExternalInterface. | Interface createInstancesFor: 'Foobar' using: [^FoobarExternalInterface new] ) ( private class FoobarExternalInterface = AbstractExternalInterface (...) ... )

This also illustrates how a class declared under one name can be bound to a different name within another module, to avoid a name conflict or on a whim. Here we suppose that in our code we want to write "ExternalInterface new" to create instances of interfaces, so we bind that name to a factory. To avoid a conflict, the ExternalInterface class retrieved from the module is made known as AbstractExternalInterface.

Regarding prototypes--this isn't a model Newspeak supports *as part of the language standard*. But before you say "boo!"--neither does Smalltalk. A particular Smalltalk *system* may allow making a behavior an instance of itself as an implementation-specific feature. Smalltalk-80 had no facilities for that. Adrian Kuhn first implemented his Protalk on VisualWorks last year, but a year or so before he wouldn't be able to. Eliot had a thought to try self-instantiating behaviors for a personal project he and I worked on in 2006, and that was when he fixed the VM to allow that.

All this is to say that I'm being very careful to draw a line between what a language provides as a standard facility which doesn't cross a metalevel boundary, and reflective capabilities of certain implementations. With this caveat--of course, a particular Newspeak implementation and *in a particular context*--more on this after the example--could support creation of self-instantiated behaviors. Of course, it would be done through a controllable mirror interface. For example:

newBehavior: Behavior new. newMirror: (ObjectReflection reflect: newBehavior). newMirror objectClass: newBehavior; methodAt: #foo put: ...

Unlike the usual model of just changing the class, here the reflection facility is in control of what reflective capabilities the code receives in the form of a mirror. For example, an untrusted application in a web browser might receive a mirror with no modification capabilities, or no capabilities at all. Find and watch Gilad's talk at Google on "objects as software services", it will give you an idea of what are the priorities for Newspeak.

Cheers,

--Vassili

On Fri, May 9, 2008 at 11:27 AM, Klaus D. Witzel klaus.witzel@cobss.com wrote:

Do you mean that the following steps are not possible:

1] myPrototype := Behavior new 2] initialize the instVars of myPrototype properly 3] myPrototype class become: myPrototype

Why shouldn't that be possible, right from the beginning of Smalltalk-80?

Because in step (3) at the same time as "myPrototype class" becomes myPrototype, myPrototype becomes "myPrototype class". ST-80's become: swaps identities, not assigns them.

Cheers,

--Vassili

This thread is all over the map and I don't have time to read it all, so my apologies in advance if I'm rehashing something someone already said.

I've always preferred a prototype/cloning approach rather than the traditional initialization we find in Smalltalk. I find that there often isn't one properly initialized form of an instance that you need to provide, but several or perhaps many. One simple example is "Semaphore new" and "Semaphore forMutualExclusion". It's an example of two differently initialized forms. Instead of having two different constructor methods (#new and #forMutualExclusion), you could have two different prototypes initialized in the manner you want them and then clone one of them when you need new instances. Another interesting point is that it's the consumer of the class that determines which form is appropriate to use, not the class itself. So, at the very least, you do need to support many constructors for any given class (not all of which need be located in the same "module" as the class itself), and perhaps you might want to do the construction in advance and simply clone the appropriate prototype to get new instances.

However, I still use the traditional approach most often simply because I've never bothered to create an easy frameork for creating and organizing such prototypes.

- Stephen

Now, as an aside, it's hard to parse a day's worth of posts consisting mostly of many levels of quoted text and a few lines of actual

Oh lord yes please god make it stop..

2008/5/9 Florin Mateoc fmateoc@gmail.com:

Vassili Bykov wrote:

...

...

This snippet illustrates many Newspeak things at once: absense of global state, nested classes and classes-as-modules, read-only slots, and message privacy. The top-level class ExternalModule plays the role of a module. The argument 'platform' is a platform object the module user will provide at the time a module instance is created, for example as:

One thing that I particularly like about Smalltalk is precisely the small number of features/concepts. I don't think that more is always better, and all those "crappy" languages prove it again and again.

...

Some other points.

Regarding freedom vs restrictions and predefined mechanisms, you have to realize that very often abstraction design is like cutting a fractal border with a straight knife. No matter how you do it, by imposing regularities you leave something unnecessary and cut off something useful. This is why any example like "here is one case where X is clearly better than the alternatives" never proves anything by itself, being only an isolated case. It's all a matter of statistics and priorities.

Yes, you can always make a case that, as the developer of a piece of code, you want for example something to be read-only. In reality, if your code is to survive and to be shared with others, you will never be able to foresee the needs of all the developers coming after you that will (have to) maintain that code. Smalltalk is a blessing in this regard, because no matter how screwed up the legacy code is, one can always find a way to adapt it to new realities. In big part, this is because Smalltalk does not enforce almost anything, unlike languages that embrace the paradigm that the original developer always knows best (as if the original Java or C# developers always knew best when they built their first version of their class library. Or their second. Or their third...).

To give other examples of "order and discipline" concepts (or, as you call them, "imposing regularities") that proved much worse than what they gained: checked exceptions in Java, the non-override default for methods in C#, and of course, visibility rules in all of them (and now it seems in Newspeak).

Right now, at work, in a Java project, we cannot (easily) move to newer versions of SWT because, as we needed access to aspects that the original developers considered internal machinery (so they did not expose them as an API), we had to add stuff to their packages. And now they sealed their packages. Because they can, and because they know better. Why do they even bother to distribute the sources?

Not all developers are the same, not even if we only consider the brilliant ones. Some are more paranoid than others, some are more over-engineerish than others, some are more frugal, some are more hackish. If you happen to find yourself downstream from a paranoid one, and the language supports his or her paranoia, you are out of luck

...

Regarding constructors "implemented" in Smalltalk--it shows two things at once. 1) there if enough reflection in Smalltalk to implement something like this, and 2) there is not enough syntactic abstraction to hide the boilerplate and make it usable. There is a similar issue with providing list comprehensions within Smalltalk/Newspeak syntax. It's easy to do the work, but it's impossible to hide all the exposed wiring, avoid binding names more than once, etc. In the end, it's only a proof of concept and not a *usable* feature.

And here I have to disagree again. I have worked on a large and successful Smalltalk project, where some such internal machinery was developed to add all kinds of semantics to the slots: default values/initializers, constraints (types/values), persistence, object-graph ownership relations, ... Yes, if you looked, you could see the wiring. So what! It worked very well and no language will ever come up with all the useful semantics that one may want to add. At least Smalltalk lets you do it. Gilad with his pluggable type systems should know better

Cheers,

Florin

One, big +1 to this post. The one of reasons why i started looking for something better than so-called mainstream languages is a freedom in expressing myself in the way how i like it, not in the way how others think or expect it should be.

Often a code library having both: a brilliant parts and worthless cruft. There is a big difference between smalltalk & C++/Java clones how well you can improve the library and how much efforts it can take. And regularities 'helping' to make it harder.

Another aspect of visibility rules: they influencing developing process, imposing the rules how people should use your code. But when your application ready to run , these rules have nothing to do in deployed system. They just left at early stages and again, software left alone, running how it likes and not caring about the rules. The above means, that despite how much you did best to protect your code from faults, there can be always a zillion cases how to put your software on the knees. A C++/Java is good illustration of that - given to many rules to 'protect' the code from faults at early stages, there are still a lot big holes left, how users can abuse your code in a numerous ways.

Vassili Bykov wrote:

On Thu, May 8, 2008 at 11:04 PM, Florin Mateoc fmateoc@gmail.com wrote:

...

One thing that I particularly like about Smalltalk is precisely the small number of features/concepts. I don't think that more is always better, and all those "crappy" languages prove it again and again.

Hi Florin, it's good to see you. Here are lists of core concepts of a couple of modern Smalltaks, and of Newspeak. I'm skipping secondary and transient artifacts such as categories, method arguments, temps and contexts.

Squeak:

Instances Classes Traits Methods Messages Assignment Instance variables Class variables Class instance variables Pool dictionaries SystemDictionary (global scope)

VisualWorks:

Instances Classes Methods Messages Assignment Instance variables Class shared variables Class instance variables Class imports Namespaces Namespace shared variables Namespace imports Name visibility Import visibility SystemDictionary (global scope)

Hi Vassily, it's good to hear from you too. I think you forgot the new kinds of literals introduced to support namespaces, plus I suspect that you bear some responsibility for the increase in complexity in VW as well :)

Newspeak:

Instances Mixins (classes are only applications of mixins) Methods Messages Slots Access modifiers Initializers

Come on, you had just mentioned nested classes, isn't that a new concept? And doesn't the label "Access modifiers" hide a collection of concepts/features ? And mixins, are they themselves classes or are they separate concepts from classes?

And talking about global scope, e.g. Java doesn't have (an objectified) global scope. So what do people do when they need it? They stick whatever they need in a class, which is globally visible (I assume this is true even in Newspeak), and access it indirectly. The only thing you "gained" is an extra indirection. Sure, global scope should not be abused. But it is damned convenient. Very useful as a quick debugging aid. Once again you seem to want to save us from ourselves, but there are a lot of languages out there that are already doing just that, thank you very much (they are called crappy languages). Give us more power, not more guard rails!

...

Not all developers are the same, not even if we only consider the brilliant ones. Some are more paranoid than others, some are more over-engineerish than others, some are more frugal, some are more hackish. If you happen to find yourself downstream from a paranoid one, and the language supports his or her paranoia, you are out of luck

Right. This is an old argument, and my sympathy has always been (and still is) with the side arguing for less control and paranoia. It feels funny to seem to argue the opposite. But it often helps to analyze your own weaknesses. One of the big weaknesses of Smalltalk is the inability of untangling your application from the rest of the ball of wax. The proof of this are the niches where it is successful. One of the characteristics of those is that deployment is very controllable. You are either on a server or in a position of not scaring users away by a multi-megabyte monolithic install. "20M for an RSS reader? You've got to be kidding!" The second important factor, Dolphin being a pleasant exception, is that the users shouldn't be scared by ugly and clunky GUIs. Marketing megadollars and institutional stupidity are big problems, but there are the technical issues that exacerbate them. Show me how my Smalltalk app can be separated from image version 3.10.1234 with custom patches to WorldState and initialization of ClassBuilder circumvented by my very special subclass, and shipped over the wire to run elsewhere. Funny that I should be among the least unhappy with the status quo--I've been paid for working in Smalltalk for 15 years straight. Perhaps if us Smalltalkers are happy to mediate on the perfection of our navel with no regard to what happens outside the image, we shouldn't be concerned with vulgar issues such as relevancy and paid jobs.

Ah, you mentioned the "dirty image" curse word! Time for another rant:

Let's take Java, which does not have the concept of snapshotting a fully loaded and initialized memory dump of their application. Because of that, they are now scrambling to find ways to "pre-load" stuff in order to cut those awful startup times that have to be paid again and again by everybody, every time they use a (large) Java application. Oh, what joy to spend time loading and compiling and initializing those exact same classes again and again instead of doing it only once! I find it mind-boggling that even Smalltalkers are complaining about this "bad" image idea, when it's one of the major factors in their superior productivity. Let's not even mention the benefit for development of living in the same space as both the target application and the development environment. Even for deployment it is a great debugging aid to just leave all the tools in the image (just hide them), so when the inevitable occurs, you are not stranded (like in the crappy languages) with an unwound stack that you cannot debug. Of course, one can do stupid things with an image: one can save it with all kinds of external resources open etc. But, you know, if it hurts, don't do it. Does this mean we should all give up all the amazing benefits that we enjoy, simply because somebody could be stupid and use it poorly? This is like saying that merely because one could take a copy of a hibernated OS image from a laptop and move it in a different, inappropriate place where it could break when started, we should all give up the capability of doing hibernation on our laptops. And why do you conflate the image "problem" with modifying base classes? If somebody really wants to, now that we have the full sources to the Java class libraries, nothing stops anybody from modifying them, putting them in a jar and the jar in the classpath. Yes, many will shoot themselves in the foot in the process, but if somebody can make a useful bugfix/feature that Sun has not thought of, why not?

Of course a Smalltalk app can be separated. It may be painful. I went through that pain just for kicks with the VW base image when I had too much time on my hands during the post-internet bubble downturn. I did it by talking to my target image through tcp-ip, and slowly peeling away. Craig demonstrated another, more productive way in Squeak. The thing is, it is possible, and to my mind, the main reason it is not in wide use is because that dreadful image problem is not as dreadful as it is made out to be (by some).

...

And here I have to disagree again. I have worked on a large and successful Smalltalk project, where some such internal machinery was developed to add all kinds of semantics to the slots: default values/initializers, constraints (types/values), persistence, object-graph ownership relations, ... Yes, if you looked, you could see the wiring.

I'd be interested to see an example. I really mean it. Especially default values/initializers.

Well, I cannot offer you or Stef code, it is a proprietary application. But I can talk about it, and there is nothing special about the code. It is not deeply hackish/mop-ish from an implementation point of view. Of course, it is so from a conceptual point of view.

I think the main insight was that these do not have to be universal features in the image, they do not need to include the base classes, anyway the base image code would not know what to do with them. So if we only need them for application-specific code, we can simply make all our classes be subclasses of a certain class, let's call it Special, and restrict our modifications to these subclasses. Well, I lied, there was a need for a few special base classes (collections), and as a result there was a little bit of hierarchy duplication because collection-like classes were created as subclasses of Special. The rest was achieved by modifying the browsers, to make them aware of (and to display and make editable) the extra features. This was all the meta-layer separation that we needed, the wiring was almost never touched, and all the development happened through normal (but enhanced) browsers. This had a very natural feeling to it, it almost looked like Smalltalk itself had those extra properties.

Cheers,

Florin

2008/5/11 Vassili Bykov smalltalkbigot@gmail.com:

On Fri, May 9, 2008 at 10:31 PM, Florin Mateoc fmateoc@gmail.com wrote:

...

I think you forgot the new kinds of literals introduced to support namespaces, plus I suspect that you bear some responsibility for the increase in complexity in VW as well :)

I bear some responsibility for work in VW. Why work equals increased complexity is an interesting question, and besides organizational things it ties right into the concept of an image as a delivery artifact. Combine it with paying customers who expect their applications which depend on the last 15 years of the image genesis to keep working, and you have yourself a nice katamari ball which only knows how to grow.

...

Come on, you had just mentioned nested classes, isn't that a new concept? And doesn't the label "Access modifiers" hide a collection of concepts/features ? And mixins, are they themselves classes or are they separate concepts from classes?

I didn't include nesting because it is a relationship rather than a core entity. It's not a biased exclusion--otherwise I'd have to include things like inheritance, importing of pool dictionaries by classes and a few other things.

Access modifiers represent a single concept: acceptance policy of messages. Just like methods, classes and slots are accessed by sending messages (and *only* by sending messages). A public class/slot/method means its accessor message is accepted from any object. For a private construct, an accessor message is accepted only from the same object.

A mixin is a primary concept. Classes and their inheritance are derivatives. A subclass is an application of a mixin to a superclass. Thus, a class in general is a chain of mixin applications beginning with nil.

...

And talking about global scope, e.g. Java doesn't have (an objectified) global scope. So what do people do when they need it? They stick whatever they need in a class, which is globally visible (I assume this is true even in Newspeak), and access it indirectly. The only thing you "gained" is an extra indirection.

No, global visibility of classes is not true in Newspeak. Everything, and that means _everything_ is a message send. A module can only use library classes it retrieved by sending messages to a library instance passed as an initialization argument. I already illustrated it in the last message, but in case it got lost among other points:

class MyApp usingLibrary: library = ( private Array = library Collections Array. private Stream = library Streams Stream. ...

Similar can be easily implemented in smalltalk. As well as private/public symbol scoping.

I think more fair comparison would be not comparing implementation-related concepts , but only languages. Smalltalk is pretty obscure in this regard: it defines only message sending syntax. blocks & methods and yes, assignment and instance vars. The rest is implementation specific. Even a class 'definition' is nothing more than a message send:

ProtoObject subclass: #Object instanceVariableNames: '' classVariableNames: 'DependentsFields' poolDictionaries: '' category: 'Kernel-Objects'.

Can you say the same for NewSpeak?

Its only a question of implementing new method at class side to make a 'private' subclass whatever that may mean to users:

Object privateSubclass: #MyPrivateSubclass ...

This is how MyApp learns "global" class names. Class names are just accessor methods in their containing class. Here, we assume that the library is subdivided into submodules such as Collections and Streams, so that we first retrieve one of those and then the class.

nothing prevents you to use implement similar concepts in smalltalk.

All you need (at least in Squeak) is to provide own implementation of #bindingOf: method which sent to a class by compiler to resolve names which not found in local scope, when method being compiled. So, in smalltalk, it is a choice of implementor to introduce 'private' symbols or other privileges in own, arbitrary way, not in the way how other people see the meaning of private symbols.

...

Sure, global scope should not be abused. But it is damned convenient. Very useful as a quick debugging aid.

Nothing prevents you in Newspeak from having *a* scope somewhere to use as a debugging aid. Except that it will be your own private debugging aid scope nobody else will see or depend on.

...

Ah, you mentioned the "dirty image" curse word! Time for another rant:

There was no such word in what I said. Images are extremely useful as development workplaces. But not as much as delivery tools. Most people who know what they are doing are taking care that their work is not dependent on *the* image. They set up a declarative scheme where a work image is built from a seed image and sources. Too bad that the "seed" in case of something like Squeak starts off with the world and a kitchen sink, and in case of VW it must keep alive the past 15 years of Smalltalk industry.

Cheers,

--Vassili

On Mon, 12 May 2008 00:52:33 +0200, Vassili Bykov wrote:

On Sun, May 11, 2008 at 11:26 AM, Igor Stasenko wrote:

[...]

...

All you need (at least in Squeak) is to provide own implementation of #bindingOf: method which sent to a class by compiler to resolve names which not found in local scope, when method being compiled.

As long as that's a facility for your own corner of the image, it won't accomplish what one would need it for. It won't allow an application written for Foobar 3.8 to coexist with one that wants Foobar 3.10. There can only be one Foobar in the SystemDictionary, and that's that.

Yes, no, and a question:

No: it's relatively easy to create a smallish set of subclasses of SharedPool, fix #bindingOf: such that SharedPools are inherited correctly, and then distribute (with #declare:) the globals over these SharedPools and attach the pools where they are needed. Compiles well and runs well [have as yet not tested all classes, see following issue].

Yes: it's almost impossible to now change all the existing tools so that they no longer use SystemDictionary's singleton. That is, even now that SystemDictionary's instance is empty and two versions of Foobar are possible without any conflict, one wouldn't do that because of lack of tool support (or unwillingness to really do such Sisyphus change to all the existing tools).

Question: say you change a Newspeak module and want that now to be effective, for example you now have FastOrderedCollection besides OrderedCollection. Since all is message based and the platform argument which was passed in at module creation time has gone long time ago, how's that done?

My guess: you browse all senders of OrderedCollection, judge and then Sisyphus changes the respective method(s), as ordered by Tartarus, right? And then?

Who said DLL hell was a Windows-only problem?

Hhm, that wasn't you ? ;)

Cheers,

--Vassili

On Sun, Apr 20, 2008 at 6:42 AM, Damien Pollet damien.pollet@gmail.com wrote:

On Sat, Apr 19, 2008 at 4:15 PM, Bert Freudenberg bert@freudenbergs.de wrote:

...

Certainly. However, Gilad said they do not intend to release it.

• Bert -

On 19.04.2008, at 15:40, Wilkes Joiner wrote:

...

Really interesting talk.

Is there anyway that the FFI his team created could be merged back into the main squeak vm?

Hmm, I understood the contrary, that he was trying to convince his management that opensource was the way to go…

That is correct.

--Vassili

On Sat, Apr 19, 2008 at 8:19 PM, Andreas Raab andreas.raab@gmx.de wrote:

Wilkes Joiner wrote:

...

Is there anyway that the FFI his team created could be merged back into the main squeak vm?

Sure, let's look at it. Where is it? (and how can watch the video???)

I understood, from what he says towards the end, that the code is currently proprietary, although he's hopeful that he will be able to persuade the Cadence managers of the benefits of open-sourcing it. (Sorry I can't help you with your video problems except to add another data point - it works okay for me using RealPlayer 10.1 on Leopard 10.5.2).