<!doctype html public "-//w3c//dtd html 4.0 transitional//en">

<html>

DEar All!

<br>First of all I would like if someone explain to me

<br>if there are differences between <i>bottom-up programming</i>

<br><i>and exploratory programming. </i>

<br>Paul Graham says <i>Bottom up design leads naturally to</i>

<br><i>extensible programs. The  simplest bottom-up programs</i>

<br><i>consits of two layers: language and program. Complex</i>

<br><i> programs may be written as a series of layers, each one acting</i>

<br><i>as a programming language for the one above. If this philosophy</i>

<br><i>is carried all the way up to the topmost layer, that layer becomes

a</i>

<br><i>programming language for the user. Such a program where</i>

<br><i>extensibility permeates every level, is likely to make a much</i>

<br><i>better programming language than  a system which was written</i>

<br><i>as a traditional black box, and then made extensible as an</i>

<br><i>'afterthought.</i>

<br><i><font color="#3366FF">Could we say Aspect oriented software development

is the latter way</font></i>

<br><i><font color="#3366FF">of programming? Anyhow "crosscutting concerns

in Lisp and Smalltalk</font></i>

<br><i><font color="#3366FF">and Self" as well as in design patterns 

are not exactly white boxes !</font></i>

<br><i><font color="#3366FF">If you disagree, please help me out!</font></i>

<br><i>Indeed</i>

<br><i>neat separation of concerns is an initial condition! CRosscutting

concerns</i>

<br><i>follows!A factoring out of what is common to the separated concerns.</i>

<br><i>In Lisp, Smalltalk and SElf, each function, object, class you create,

is</i>

<br><i>immediately "compiled" or interpreted or tested! So when you reach</i>

<br><i>the end of the program it is already finished. It is the opposite

of the</i>

<br><i>plan and implement development of compiling languages. Or is this</i>

<br><i>facility a characteristic of an interactive environment? I know

for example</i>

<br><i>there is no exploratory programming in the Mjolner Beta system.</i>

<br><i>If the user or programmer wants to change the compiler it is not</i>

<br><i>possible, only the "authors" can!</i>

<br><i>How are utilities and design patterns related?</i>

<br><i>Paul Graham says In Lisp, language and program evolve together.</i>

<br><i>In the end your program will look as if the language had been</i>

<br><i>designed for it. And when language and program fit one another</i>

<br><i>well, you end up with code which is clear, small and efficient.</i>

<br>I am totally in agree because my ecodesign model and the underlying

<br>geometric model behaves this way. Now I have to build the aspectual

collaborative aware architecture.

<br>And obviously this cannot be done without a programming  language

<br>that grasps the

nature of the ecodesign model and the underlying geometric model.

<br>In my knowledge system to design and plan sustainable cities, there

<br>are all the levels of concerns such as separation, crosscutting, parallelism

<br>and composition of concerns. This is white box, it is not tangled as

in

the papers dealing with nonfunctional requirements.

<br>Indeed if my functional concerns behave like this, I see no reason

why

we could not tame the nonfunctional concerns to behave the same.

<br>The main hurdle is that it is lacking expertise at the level of domain-specific

<br>knowledge. Most PHD theses and papers take for granted that the reader

<br>already knows everything about distribution, caching, concurrency and

so on!

<br>And hurry up to develop the application applying any technique that

may fit!

<br><font color="#3366FF">I would thank you very much if you reference

a list of such well developed</font>

<br><font color="#3366FF">and encompassing research material.</font>

<br><font color="#3366FF">I would start the list with:</font>

<br><font color="#3366FF">Jörg Kienzle's PHD thesis <i>Open Multithreaded

Transactions A transaction MOdel for</i></font>

<br><i><font color="#3366FF">Concurrent Object-oriented programming and

also Dirk Bäumer's PHD thesis</font></i>

<br><i><font color="#3366FF">Software-architeckturen für die rahmenwekbasierte 

Konstruction grosser</font></i>

<br><i><font color="#3366FF">Anwendungssyteme.</font></i>

<br><i><font color="#3366FF">Of course the design patterns represent such

an endeavour of clear box! However</font></i>

<br><i><font color="#3366FF">the lack of abstraction and simplification

led of course to the Multidimensional</font></i>

<br><i><font color="#3366FF">separation of concerns paradigm (MDSoCs).</font></i>

<br><i><font color="#3366FF">A nice paper seems to be Coordinating Aspects

and Objects  from Timo Aaltonen</font></i>

<br><i><font color="#3366FF">and colleagues in Notes in Theoretical</font></i>

<br><i><font color="#3366FF">Computer Science 68 No.3 (2003)</font></i>

<br><i><font color="#3366FF">in <A HREF="http://www.elsevier.nl/locate/entcs/volume68.html">http://www.elsevier.nl/locate/entcs/volume68.html</A></font></i><i><font color="#3366FF"></font></i>

<p><i><font color="#000000">Best wishes,</font></i>

<br><i><font color="#000000">Albertina</font></i>

<br><i><font color="#000000">Dr. Albertina Lourenci</font></i>

<br><i><font color="#000000">postdoctorate researcher</font></i>

<br><i><font color="#000000">Laboratory of Integrated Systems</font></i>

<br><i><font color="#000000">Polytechnic School USP Brazil</font></i>

<br><i><font color="#000000">PHD candidate at the Department of Digital

Aesthetics and Communication</font></i>

<br><i><font color="#000000">Institute of TEchnology University Copenhagen</font></i>

<br> 

<br><i></i> 

<br><i></i> </html>