has anyone on this list read (or heard things about) the book "Constructing Language Processors For Little Languages?" since Self is a little language, i thought this would be an appropriate place to ask.
thanks,
christian
On Saturday 04 January 2003 03:25, christian.hresko wrote:
has anyone on this list read (or heard things about) the book "Constructing Language Processors For Little Languages?" since Self is a little language, i thought this would be an appropriate place to ask.
I have heard about this book by Randy Kaplan, but haven't read it. I thought a friend had and had sent me some comments but I wasn't able to find them.
Note that though it is very tempting to think of Self as a little language due to the quest for simplicity, most attempts to treat it as such haven't yielded good results. Little languages inspired by Self, on the other hand, seem to be doing better (see a short list at the end of http://www.merlintec.com:8080/Self/).
-- Jecel
On Tuesday 07 January 2003 11:12, Jecel Assumpcao Jr wrote:
On Saturday 04 January 2003 03:25, christian.hresko wrote:
has anyone on this list read (or heard things about) the book "Constructing Language Processors For Little Languages?" since Self is a little language, i thought this would be an appropriate place to ask.
I have heard about this book by Randy Kaplan, but haven't read it. I thought a friend had and had sent me some comments but I wasn't able to find them.
Note that though it is very tempting to think of Self as a little language due to the quest for simplicity, most attempts to treat it as such haven't yielded good results. Little languages inspired by Self, on the other hand, seem to be doing better (see a short list at the end of http://www.merlintec.com:8080/Self/).
I think that would be me. However, I cannot for the life of me find the book. Moving will do that. I only started to read the book if I recall correctly... So, I can't say much about it.
Best, Kyle
On Tue, 7 Jan 2003, Jecel Assumpcao Jr wrote:
On Saturday 04 January 2003 03:25, christian.hresko wrote:
has anyone on this list read (or heard things about) the book "Constructing Language Processors For Little Languages?" since Self is a little language, i thought this would be an appropriate place to ask.
I have heard about this book by Randy Kaplan, but haven't read it. I thought a friend had and had sent me some comments but I wasn't able to find them.
Note that though it is very tempting to think of Self as a little language due to the quest for simplicity, most attempts to treat it as such haven't yielded good results. Little languages inspired by Self, on the other hand, seem to be doing better (see a short list at the end of http://www.merlintec.com:8080/Self/).
-- Jecel
There is (was?) a mailing list for the discussion of little languages by the author, and Smalltalk and derivatives were discounted if they were not command-line, declaratively driven.
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
On Monday 21 April 2003 09:27 am, Albertina Lourenci wrote:
DEar All! First of all I would like if someone explain to me if there are differences between bottom-up programming and exploratory programming.
Because exploratory programming requires the discovery of design and the evolution of a language to express that design, it tends to be closer to bottom up 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.
You can see this dramatically with Forth, most of whose dialects don't support forward references or objects. You are forced to do bottom-up programming.
However, the user-level language is only a subset of the language that evolves. There are always (at least in non-trivial systems) in-between layers whose vocabluary is only useful inside the system.
When we use objects, there's an additional dimension of separation of responsibility. In addition to growing the vocabulary toward the needs of the users, we're also separating responsibility along object and (later) package lines. The vocabulary that's visible between packages is the public vocabulary of the objects at the outside of the packages -- the interface objects. Inside a package, the concerns have already been separated along object lines.
On Monday 21 April 2003 13:27, Albertina Lourenci wrote:
First of all I would like if someone explain to me if there are differences between bottom-up programming and exploratory programming.
This is way off topic, but here is a short reply:
Imagine that a program A is made up of components B, C and D. Suppose that component C is made up of subcompenents E and F. This is a tree structure, right? As is usual in computer science, imagine the tree with the root (A) at the top.
If you create this program by starting with A and ending with E and F you will be doing "top-down design". "bottom-up design" goes in the opposite direction.
A problem with top-down design is that A can't really run if B, C and D haven't been created yet. So the very first time you get to run the program is when you have finished writing it! One solution is to create small "place holder" components that are dummy versions of B, C and D so you can test A and see if it works.
With a proper interactive environment (such as Self) you can test E as soon as you have written it. A more static environment would not allow you to call E from a command line and would make you write a program to call it (a dummy C, for example).
Many people plan ahead in a top-down fashion and then program in a bottom-up way. Others actually prefer to first think about the low level components (leaves of the tree) and play around with them exploring what they can do before moving on the the next level.
A language like Forth forces you to program bottom-up since everything a "word" refers to when it is defined must have been previously defined. Lisp and Self allow references to things that might not yet exist.
Aspects are "cross-cutting", as you said yourself, and would represent an entirely different direction compared to the up/down axis.
-- Jecel
But, in reality, most people design in both directions at once -- as it is important to thing about the low-level implementation at the same time as considering the overall stategy or hight-level shape of the program. David
Jecel Assumpcao Jr wrote:
On Monday 21 April 2003 13:27, Albertina Lourenci wrote:
First of all I would like if someone explain to me if there are differences between bottom-up programming and exploratory programming.
This is way off topic, but here is a short reply:
Imagine that a program A is made up of components B, C and D. Suppose that component C is made up of subcompenents E and F. This is a tree structure, right? As is usual in computer science, imagine the tree with the root (A) at the top.
If you create this program by starting with A and ending with E and F you will be doing "top-down design". "bottom-up design" goes in the opposite direction.
A problem with top-down design is that A can't really run if B, C and D haven't been created yet. So the very first time you get to run the program is when you have finished writing it! One solution is to create small "place holder" components that are dummy versions of B, C and D so you can test A and see if it works.
With a proper interactive environment (such as Self) you can test E as soon as you have written it. A more static environment would not allow you to call E from a command line and would make you write a program to call it (a dummy C, for example).
Many people plan ahead in a top-down fashion and then program in a bottom-up way. Others actually prefer to first think about the low level components (leaves of the tree) and play around with them exploring what they can do before moving on the the next level.
A language like Forth forces you to program bottom-up since everything a "word" refers to when it is defined must have been previously defined. Lisp and Self allow references to things that might not yet exist.
Aspects are "cross-cutting", as you said yourself, and would represent an entirely different direction compared to the up/down axis.
-- Jecel
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
David Harris wrote: Dear All! I have not been chatting about this because I am delving deeper into these topics! And I would appreciate an in-depth analysis because I do think it is of the utmost importance for the future of software towards implementation of complex systems! Albertina
But, in reality, most people design in both directions at once -- as it is important to thing about the low-level implementation at the same time as considering the overall stategy or hight-level shape of the program. David
Jecel Assumpcao Jr wrote:
On Monday 21 April 2003 13:27, Albertina Lourenci wrote:
First of all I would like if someone explain to me if there are differences between bottom-up programming and exploratory programming.
This is way off topic, but here is a short reply:
Imagine that a program A is made up of components B, C and D. Suppose that component C is made up of subcompenents E and F. This is a tree structure, right? As is usual in computer science, imagine the tree with the root (A) at the top.
If you create this program by starting with A and ending with E and F you will be doing "top-down design". "bottom-up design" goes in the opposite direction.
A problem with top-down design is that A can't really run if B, C and D haven't been created yet. So the very first time you get to run the program is when you have finished writing it! One solution is to create small "place holder" components that are dummy versions of B, C and D so you can test A and see if it works.
With a proper interactive environment (such as Self) you can test E as soon as you have written it. A more static environment would not allow you to call E from a command line and would make you write a program to call it (a dummy C, for example).
Many people plan ahead in a top-down fashion and then program in a bottom-up way. Others actually prefer to first think about the low level components (leaves of the tree) and play around with them exploring what they can do before moving on the the next level.
A language like Forth forces you to program bottom-up since everything a "word" refers to when it is defined must have been previously defined. Lisp and Self allow references to things that might not yet exist.
Aspects are "cross-cutting", as you said yourself, and would represent an entirely different direction compared to the up/down axis.
-- Jecel
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
On Thursday 24 April 2003 13:23, Albertina Lourenci wrote:
I have not been chatting about this because I am delving deeper into these topics! And I would appreciate an in-depth analysis because I do think it is of the utmost importance for the future of software towards implementation of complex systems!
These are actually basic programming topics, so you might have more luck finding information about them in a introductory text than in a advanced PhD thesis.
David Harris wrote:
But, in reality, most people design in both directions at once -- as it is important to thing about the low-level implementation at the same time as considering the overall stategy or hight-level shape of the program.
Exactly - you must both watch where you are stepping and yet keep your eye on where you are going. Creating random low level components without thinking about the higher level modules that will use them will get you nowhere. And defining high level abstractions without knowing what is available to implement is a sure way to get a project stuck in the design phase without ever moving to the programming phase.
But it isn't easy to do both at the same time, which is one of the reasons why I think that pair programming in extreme programming is a good idea.
-- Jecel
Jecel Assumpcao Jr wrote: Hi Jecel! Well the papers I have selected are not written by novice in computer science!!! And indeed it was exactly some of them that had led me to Self!!! Bye Albertina
On Thursday 24 April 2003 13:23, Albertina Lourenci wrote:
I have not been chatting about this because I am delving deeper into these topics! And I would appreciate an in-depth analysis because I do think it is of the utmost importance for the future of software towards implementation of complex systems!
These are actually basic programming topics, so you might have more luck finding information about them in a introductory text than in a advanced PhD thesis.
David Harris wrote:
But, in reality, most people design in both directions at once -- as it is important to thing about the low-level implementation at the same time as considering the overall stategy or hight-level shape of the program.
Exactly - you must both watch where you are stepping and yet keep your eye on where you are going. Creating random low level components without thinking about the higher level modules that will use them will get you nowhere. And defining high level abstractions without knowing what is available to implement is a sure way to get a project stuck in the design phase without ever moving to the programming phase.
But it isn't easy to do both at the same time, which is one of the reasons why I think that pair programming in extreme programming is a good idea.
-- Jecel
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
self-interest@lists.selflanguage.org
-
Albertina Lourenci -
Brian T Rice -
christian.hresko -
David Harris -
Jecel Assumpcao Jr -
Kyle Hayes -
Ned Konz