(Aspects) Utilities in Lisp vs Design Patterns in Smalltalk- Self

[Albertina Lourenci]

DEar All!
First of all I would like if someone explain to me
if there are differences between bottom-up programming
and exploratory programming.
Paul Graham says Bottom up design leads naturally to
extensible programs. The  simplest bottom-up programs
consits of two layers: language and program. Complex
 programs may be written as a series of layers, each one acting
as a programming language for the one above. If this philosophy
is carried all the way up to the topmost layer, that layer becomes a
programming language for the user. Such a program where
extensibility permeates every level, is likely to make a much
better programming language than  a system which was written
as a traditional black box, and then made extensible as an
'afterthought.
Could we say Aspect oriented software development is the latter way
of programming? Anyhow "crosscutting concerns in Lisp and Smalltalk
and Self" as well as in design patterns  are not exactly white boxes !
If you disagree, please help me out!
Indeed
neat separation of concerns is an initial condition! CRosscutting concerns
follows!A factoring out of what is common to the separated concerns.
In Lisp, Smalltalk and SElf, each function, object, class you create, is
immediately "compiled" or interpreted or tested! So when you reach
the end of the program it is already finished. It is the opposite of the
plan and implement development of compiling languages. Or is this
facility a characteristic of an interactive environment? I know for example
there is no exploratory programming in the Mjolner Beta system.
If the user or programmer wants to change the compiler it is not
possible, only the "authors" can!
How are utilities and design patterns related?
Paul Graham says In Lisp, language and program evolve together.
In the end your program will look as if the language had been
designed for it. And when language and program fit one another
well, you end up with code which is clear, small and efficient.
I am totally in agree because my ecodesign model and the underlying
geometric model behaves this way. Now I have to build the aspectual
collaborative aware architecture.
And obviously this cannot be done without a programming  language
that grasps the
nature of the ecodesign model and the underlying geometric model.
In my knowledge system to design and plan sustainable cities, there
are all the levels of concerns such as separation, crosscutting, parallelism
and composition of concerns. This is white box, it is not tangled as in
the papers dealing with nonfunctional requirements.
Indeed if my functional concerns behave like this, I see no reason why
we could not tame the nonfunctional concerns to behave the same.
The main hurdle is that it is lacking expertise at the level of
domain-specific
knowledge. Most PHD theses and papers take for granted that the reader
already knows everything about distribution, caching, concurrency and so on!
And hurry up to develop the application applying any technique that may fit!
I would thank you very much if you reference a list of such well developed
and encompassing research material.
I would start the list with:
Jörg Kienzle's PHD thesis Open Multithreaded Transactions A transaction MOdel
for
Concurrent Object-oriented programming and also Dirk Bäumer's PHD thesis
Software-architeckturen für die rahmenwekbasierte  Konstruction grosser
Anwendungssyteme.
Of course the design patterns represent such an endeavour of clear box!
However
the lack of abstraction and simplification led of course to the
Multidimensional
separation of concerns paradigm (MDSoCs).
A nice paper seems to be Coordinating Aspects and Objects  from Timo Aaltonen
and colleagues in Notes in Theoretical
Computer Science 68 No.3 (2003)
in http://www.elsevier.nl/locate/entcs/volume68.html

Best wishes,
Albertina
Dr. Albertina Lourenci
postdoctorate researcher
Laboratory of Integrated Systems
Polytechnic School USP Brazil
PHD candidate at the Department of Digital Aesthetics and Communication
Institute of TEchnology University Copenhagen



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.selflanguage.org/pipermail/self-interest/attachments/20030421/bb4d8a0c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lourenci.vcf
Type: text/x-vcard
Size: 316 bytes
Desc: Card for Albertina Lourenci
URL: <http://lists.selflanguage.org/pipermail/self-interest/attachments/20030421/bb4d8a0c/attachment.vcf>