On Tuesday, June 24, 2003, at 03:19  Uhr, Brent Pinkney wrote:

> What our application needs, and I know I am phrasing this poorly, is 
> to exploit the duality between code and data.
>  Sometimes an object behaves like code -i.e it controls the behaviour 
> of the application, and other times it behaves like data - passive 
> stuff which is stored, retrieved, end manipluated.

I think on of the points of "objects" in the first place is that they 
integrate both these aspects.

> Concrete examples are configuration files, user defined rules, etc.

Yes.  Which then expand to gain more and more intelligence, until they 
turn into scripting languages, which then morph into full-fledged 
programming languages by accretion.  Ick.

I remember having this discussion with some colleagues who insisted 
that a WebObjects app I wrote had to have some configuration files, 
which I steadfastly refused to put in.  The reason for my refusal was 
simple:  the WebObjects app was only the thinnest of wrappers around a 
whole big set of frameworks, and written in interpreted WebScript.  So 
the app *was* the "configuration file".

This they could not understand.  Of course, part of this was the fact 
that they weren't very capable programmers, so for them that little WO 
wrapper that to me was just that, a throw-away wrapper, presented 
something of high value that needed to be preserved intact.

That sentiment  of "preserve what we have at all cost" is one of the 
biggest hurdles, since real progress (see refactoring and 'burning disk 
packs') can only come when we abstract the old into the new, not when 
we built on top of the old.

> To me, it is a spectrum - at the extremes some parts are always code 
> and others always data,

Yes, definitely the spectrum.  One end is code, the other is data.  And 
objects have the wonderful property of actually being able to smoothly 
go from one end of the spectrum to the other.  And back!  So I disagree 
(a little) with the "always" part, although I will admit that today it 
most often is the case.  However, I am almost certain that it should 
not be the case, that there should be (better/easier) movement from one 
end to the other.

We need better facilities for moving objects from more "data-ness" 
(less abstract) to more "code-ness" (more abstract) and back.  
Refactoring is a part of this, but it only works if you're already in 
"code-space".   I also have a feeling that most of us know 
"instinctively" what this is supposed to look like.  It seems to me 
that EToys, Self, Morphic, Fabrik, ThingLab etc. all show us different 
glimpses of this thing we all know should exist but cannot yet fully 
describe or create, which is why all of these things get an immediate 
(emotional/gut-feeling) "cool!!" reaction.  But they all fall short, 
and developing their individual properties further doesn't seem to 
quite do the trick either, by themselves they all seem like dead ends, 
even though each is very powerful and has that "cool!" factor.

So something even simpler is needed, and it is probably staring us in 
the face so big and obvious that we will kick ourselves when we finally 
figure it out.

>  but we spend an awful amount of time creating settings and 
> preferences, embedded VB parsers for callback functionality, and 
> elaborate import and export utilites.

Yup :-(   And various templating mechanisms, GUI-builders, 
"middleware-abstraction-layers" (had to fit that one in, I just laughed 
so hard when I first heard it...) etc., over and over again ad nauseam.

> Some simple experiementation with Smalltalk suggests that is is a lot 
> easier if I can regard my code as data and then interpret/execute it 
> later.

Yes.  You can cut so much complexity out of your system once you 
realize this.

> Clearly languages like C++/Java/C# battle with this, whilst languages 
> like Smalltalk/Lisp excel.

With all due respects to Winston Churchill, as well Dan and Alan:

	Smalltalk is the worst of all computer languages.  Apart from all the 
others.

;-)


(getting off my soap-box,)

Marcel

-- 
Marcel Weiher				Metaobject Software Technologies
marcel at metaobject.com		www.metaobject.com
Metaprogramming for the Graphic Arts.   HOM, IDEAs, MetaAd etc.
		1d480c25f397c4786386135f8e8938e4