Dave,

I'll take a look in a week or two into the UI differences between 4.0 and 4.1.2 and will send you any bug fixes that I come up with. The hardest part will probably be telling the difference between bugs and enhancements :-)

Dru,

I am sure most people subscribed to this list will be interested in hearing about Self-like languages too. I don't know of any better place to discuss them. Besides, it is hard to tell when things like Ultimardrev and JSelf cease to be Self and become Self-like.

One thing you should keep in mind when studying Self 4's implementation is that there is no interpreter - the bytecodes were designed specifically as the input to a compiler. Note how there is no "pop" bytecode, for example. This means that every result that isn't used (every time you have a "." separating expressions in the code) it just sits on the stack taking up space until the method finally returns. Or it would do that in an interpreter (like tinySelf 1), but the compiler must do data flow analysis in any case and it will generate optimized Sparc (or PPC) code that doesn't uselessly store unused results. Smalltalks normally have interpreters and so does implement "pop".

Same thing with blocks. Smalltalk uses a very different bytecode to push a block on the stack from the one that pushes literals (actually, blocks don't exist as objects in Smalltalk so the must be created by this bytecode instead of simply cloned - this saves some memory but is very ugly). A Self interpreter would suffer from a performance loss testing each literal to see if it is a block or not, but in Self 4 this test is done only when compiling the code to native machine language and in this case the overhead is essentially zero.

-- Jecel

Dru,

My implementation is using a bytecode interpreter and will have to implement a test on each push. I might make room for another type in the references, a block type. That way I could minimize the hit of the test to a simple AND rather than a proto lookup.

And don't forget that when you send the 'value' message to the cloned block, the method must be executed in a slightly different way from all other methods, so you need yet another test.

I would encourage you to try to think of new ways to think about blocks. Here is a copy of a message I sent to this list a long time ago about this (some things can't be understood without the context, but at least this should give you the flavor of what I am talking about):

Date: Mon, 18 Sep 1995 16:47:00 -0300 From: "Jecel Mattos de Assumpcao Jr." jecel@lsi.usp.br Message-Id: 199509181947.QAA03690@ofelia.lsi.usp.br To: self-interest@self.sunlabs.com Subject: blocks content-length: 6611

Re-reading the ECOOP proceedings this weekend I was surprised to find out that I hadn't read "Programming as an Experience: The Inspiration for Self". I could hardly believe it as I was so sure I had read it twice already, but it seems I got it confused with some other paper ( it happens as we get older ;-).

Anyway, it sure is great stuff! And all of the issues that I have raised here these last few days were mentioned in the paper and there were even some good answers. Rather than taking this as a sign that my idle speculations are not getting us anywhere, I couldn't resist taking a look at blocks.

The story for blocks seems a little strange, as the following table shows:

outer method = normal methods stored in constant slots block = the literal block object block context = the result of pushing a block on the stack value = the value method inside the block activation object inner method = literal anonymous methods used in Self 1.0

outer method block blockContext value inner method ----------------------------------------------------------------------------- clones when fetched from const slot YES -- -- YES --

can be stored in data slot NO NO YES NO NO

clones when fetched from data slot -- -- NO -- --

clones when pushed on stack -- YES -- -- YES

new slot name :self* -- <scope> <lexParent>* <lexParent>*

new slot value receiver -- thisContext same as thisContext blockContext <scope>

I found it very hard to justify the way that the value method of a block currently works. I could reduce blocks to mere syntactic sugar ( at the very high cost of using four temporary objects rather than the current two ) if Self had these two features:

1) local methods with the semantics of the old inner methods 2) the ability to manipulate running and dead Activations without mirrors

Item one means that the "silly" example I gave before would return 2 instead of 4, but the "self marker" would not move as Randy proved it shouldn't. The idea is that a method activation is a refinement of an object, so a method defined within this refinement should result in a refinement of the refinement rather than in a refinement of the original object. This is a very forced view of things, but is not totally unreasonable. The "self marker" stays in place by having a <lexParent>* slot instead of a :self* one.

I already have item two in tinySelf. This can be explained in terms of the implementation ( which is how I answered Mario when he asked why my "thisContext = (self)" example didn't run into infinite recursion ) or by looking into "slot types" as Mark explained about Glyphic Script. Here is a third alternative to explain this:

I don't like that when a method object is cloned to produce an activation a ":self*" slot must be added. I want the method object to have this slot too, so it is a real prototype of the activation. Of course, its argument slots don't have any valid values yet and this would be nasty in the case of a parent slot like ":self*".

What happens when we fetch an object from a slot? We can imagine that it is sent an "Eval" meta-message. For most objects, this would just return the object itself. For methods, it would clone it and fill in the arguments and schedule it for execution. What if this were achieved by placing a special value in the ":self*" slot so that the method object would inherit this cloning behavior? In that case, once the arguments were filled in ( including the self slot ) then the activation could be stored in data slots and fetched without cloning - it would now inherit from a "normal" object and would handle "Eval" like normal objects - returning itself rather than a clone.

So we have that in Self 4.0 activations are not true clones of methods, but both handle "Eval" in the same way. In tinySelf activations are true clones of methods, but handle "Eval" differently due to a different value in the dynamic parent slot. TinySelf is backwards compatible, however, as it is not possible to store an activation in a slot in Self 4.0 to see the difference.

Now, supposing the above hasn't made you too sick to proceed :-)

globals _AddSlots: ( | blockActivationProto = () | )

blockActivationProto _Define: ( | parent* = traits block. scope | )

traits block _AddSlots: ( | value = (scope value) | )

( | test = ( | i <- 0. b1 = ( | value = ( (i * i) printLine ). bap = blockActivationProto | bap clone scope: _ThisActivation ). b2 = ( | value = ( i factorial printLine ). bap = blockActivationProto | bap clone scope: _ThisActivation ) | ......... ......... ......... ... ifTrue: b1 False: b2. ......... ) | ) test

This code causes the following four temporary objects to be create per block use:

(1) a clone of b1 is created when it is fetched from its slot in the "... ifTrue: b1 ..." part of the code. It has a <lexParent>* slot ( rather than self* ) that is set to the current activation.

(2) a clone of blockActivationProto is created when (1) is executed and its scope slot is set to (1).

(3) a clone of the "value" method is created when the ifTrue:False: sends this message to (2). The method is found in traits block and the self* slot is set to (2).

(4) a clone of the "value" method is created when (3) executes. The method is found in (1) and the <lexParent>* slot is set to (1).

Of course, not only are four objects a bit too much for a thing like this, but we also have a problem that (4) inherits from (1) which inherits from the original method activation ( which has the "i" slot, for example ). This means that (4) sees the "value" and "bap" slots in (1) ( but this could be "fixed" by using weird names like was done with "<lexParent>*" ).

Please note that this could be done with mirrors in the b1 and traits block value methods if we didn't have the item 2) above, but this would mean yet another temporary object.

While this is clearly not the solution to the "blocks problem", I think the answer is somewhere in that direction.

Cheers, -- Jecel

New millenium, new news...

I'd like the new millenium gives us prototypes...

Happy new year!!!

Diego Gomez Deck

Before the new year comes in, I would like to announce something.

I have created a Self like language called 'Cel'.

You can see it at http://www.redwoodsoft.com/cel

More to come on this later.

Happy New Year

Dru Nelson San Mateo, California

Hi,

I just wanted to get a little bit more about this out on the list since: I like this list, the people on it, and the projects.

To be fair, this will be the last post about this, since I feel it is off topic and I wouldn't want to offend the good people here...

So, since there are Selfers here, I will only go into the history here.

*History*

In 1998, I became upset with the current state of computing. Java had become the new darling, Nextstep looked like it was dead (as well as Objective-C), Perl/Python was popular - but not the type of OO I liked. Squeak was/is neat, but the 1970's interface, class system, and monolithic image system was getting tired. I didn't have access to a Sun, so I couldn't try Self. During one of my fits, a friend of mine, Steve Dekorte, kept trying to convince me that prototypes would be the right way to go. I was at the end of researching various Forth technologies. Something clicked and I said, I'll create a language using protos, it will be fun! That was May 1998. I never implmented a language system before. (Side note: Steve showed me the Sun Labs Self Video and I have often drank orange juice out of a Self coffee mug at his house)

At the 1998 Oopsla, I attended the Prototypes track in Vancouver. Mr. Dekorte had a presentation. There were maybe 20 people in the room. At the end, people were discussing ways of advocating prototype based languages. I raised my voice and announced that I would be creating a language. Nobody at that meeting probably remembers that or me, otherwise I would have received queries about that statement over time.

Time goes on. In my off hours when the mood was right, I would work on the language. A lot of the details about the implementation changed. I never thought it would take this long to get something so little out. A few days ago, blocks finally worked. The major hurdles were done, it is ready to be looked at.

*What Is This Language?*

The goal was to create a simple, interpreted, prototype based language with Self like syntax. The language would be implemented in C The language platform was to be unix (freebsd, linux, etc.). The language should integrate with unix and other libraries very well. The language should be declarative, not image based. The language should be free to download (like Self) It would be stack based It will have exceptions (this is a TBDesigned item) Originally, the VM was going to be an advanced VM, that mapped to processors well. However, that got pushed off and a simple stack based VM was used.

Some of the differences with Self are: single inheritance,small lexical and grammatical differences, no excellent optimization technologies, it is interpreted on a VM, not image based, no windowing system or GUI (Morphic?) built in.

Current State.

In it's current form, it is very primitive. floats or arrays aren't there. 'resend' isn't implemented yet, as well as non-local returns, and a lot of other little things and methods.

I chose the name 'Cel' after Apple took the name Aqua. (The other names were terrible).

*How Does this Affect Self and the Other Projects Here*

I don't think that this interferes with any of the other projects mentioned here: Self Mac OS, MerlinTech, other ports, etc. I intend to keep going on Cel. However, it is nowhere near as polished as Ungar's Self on the Mac. Cel is still a system in flux and many things were implemented in the 'naive' way :-)

Thanks for reading this so far, if you are interested further, go to the web page. http://www.redwoodsoft.com/cel

I would also like to state that I do enjoy this list, and I appreciated the help from Jecel for his answers on many occasions. Without his careful explanations, I wouldn't have gotten even to this point.

** Thank you **

Dru Nelson San Mateo, California

P.S. Above, when I said, "In 1998, I became upset with the current state of computing." I meant, In 1998 I finally decided to do something about the state of computer technology that has plagued us for the last 15? years, as a fun, 'what the heck' attempt.

At 11:32 01/01/2001 -0800, Kyle wrote:

I'm in San Francisco. We should meet some time. Drop me a note. Jecel and I actually met in person for a few short weeks a few years ago in Brazil. Even though we couldn't "geek" as much as we might have liked (my wife was there too), the few hours we spent in front of a computer were quite productive. I've always been a "whiteboard" kind of guy and find that talking this over with others with a whiteboard helps moving things forward much more quickly.

I would like to sit in on such a meeting myself. I have been considering a language design based on prototyping and implmented with partial compilation/JIT compilation and metaobject threaded interpretation. The programs would compile first to a platform-independent description of syntax and semantics (similar to the 'slim binaries' used in some implementations of Oberon), which would be compiled again into a stand-alone executable. Internally, the interpreter would be a meta-class of the base 'Object' class. Methods would pass right to left, with any invocation of objects without a method passed to them returning a reference to the object. As a rough example of one syntax I've been considering:

HelloWorld := Program new: [ "Hello World!" show; ] end: HelloWorld;

As you can see, I'm looking at a combination of Smalltalk and Pascal style syntax (note specifically the 'positive close' at the end). While it's not clear here, my ideas are also heavily influenced by Scheme; the brackets enclosing the program body, in fact, form a a list literal. I'd been considering a LISP-like syntax as another possible approach, but I have serious reservations about it. While I am willing to try out more than one language concept, perfectionism, combined with a lack of time and/or self-confidence, has held me back from experimenting. Seeing what others are doing or considering might just get me finally started...

ObSelf: I would also like to contribute to any attempt at either a Linux or a Windows port of Self.

J Osako Operating Systems Designer, Notational Engineer, Generalist http://www.slip.net/~scholr/

Dru Nelson wrote:

Hi:

*How Does this Affect Self and the Other Projects Here*

I don't think that this interferes with any of the other projects mentioned here: Self Mac OS, MerlinTech, other ports, etc. I intend to keep going on Cel. However, it is nowhere near as polished as Ungar's Self on the Mac. Cel is still a system in flux and many things were implemented in the 'naive' way :-)

Indeed even for me more people interested in prototypes and doing research in prototypes is welcome!!! The only hurdle for me is that from now on I shall be registered as an advisor at POLI (Polytechnic School of the University of Sao Paulo) which is considered the best and biggest school of Latin America. For example my contacts with the Group of Energy, another big group of studies at Electrical Engineering enable me to implement one of the dearest part of my ecodesign model. It deals with the electric model of the wall. This model enables one to build panels of several layers made of different materials that give precision of air conditioning wherever they are built. I mean the model covers the range of climates all over the world. One has to vary the thermal resistances and capacitances of the materials. So I can work right now with graduate students from Mechanical Engineering and those from the Group of Energy. But the point is, how will this simulation be implemented?

How will I teach Self to the students, if I do not know much about debuggers and so on ...I am sure they won't do better than I. I have long years of studying OO languages and environment. An engineer in Brazil know at best case C++. I can do this part of the work in C++ of course. But then how will I integrate it in my knowledge based system? These are things I have to solve right now!!! So should I ask FAPESP a Sun to run Self, who on this list can tell me if there will be a real version for PC. It seems even for people in the North Hemisphere it is not that easy to have a Sun. So if someone can suggest me how to solve this hurdle, I shall be happy. FAPESP is offering me the opportunity to go abroad for a year to develop a tutorial in Self. If someone here is able to work with me in his/her laboratory to accomplish this goal, I would be the happiest woman/human being in the world!

Anyhow even for accomplishing this simulation it is better if I count on a good GUI? I do not know if there is a good GUI in C++. The other solution would be to implement in Smalltalk or Squeak. But this leads me far away from the monolithism searched all these years. But what I know is that my research shall not stop. So better if I can implement it in Self. I could go abroad while the grad students would continue research in collecting the necessary data and keep learning about Self too.

The structural system and the architectural system requires a very powerful and full fledged GUI interface to be implemented. This is the core of my knowledge based system.

Thanks for reading this so far, if you are interested further, go to the web page. http://www.redwoodsoft.com/cel

I would also like to state that I do enjoy this list, and I appreciated the help from Jecel for his answers on many occasions. Without his careful explanations, I wouldn't have gotten even to this point.

Me too. Jecel has been of great help to me. And all the info I collect in this list are fundamental for the development of my research. Thanks to God it exists!! Thank you for being, Self community! Albertina

** Thank you **

Dru Nelson San Mateo, California

P.S. Above, when I said, "In 1998, I became upset with the current state of computing." I meant, In 1998 I finally decided to do something about the state of computer technology that has plagued us for the last 15? years, as a fun, 'what the heck' attempt.

-- .----------------------------------------------------------. | Albertina Lourenci | | PhD in Architecture and Urbanism | | post-doctorate researcher | | Laboratory of Integrated Systems University of Sao Paulo | | Avenida Professor Luciano Gualberto, 158 Travessa 3 | | CEP: 05508-900 | | Sao Paulo Sao Paulo State Brazil | | Voice: +55 011 818 5254 | | Fax: +55 11 211 4574 | .----------------------------------------------------------.

On Thursday 04 January 2001 11:07, Jecel Assumpcao Jr wrote:

On Mon, 01 Jan 2001, Dru Nelson wrote:

...

I have created a Self like language called 'Cel'.

This is great!

I think that this list is the right place for discussions of Self-like languages like this, Kyle's TSOL and Joseph Osako's ideas. Here is a less Self-like language that might also interest people in this list:

http://www.ericsworld.com/Mark/HTML/Avail.html

Happy 2001, a Self Odyssey -- Jecel

Yes, Avail is interesting. There was an ongoing thread about it on the Concatenative mailing list for a while.

Since Self brought prototypes into focus for many people for the first time, it is a prototype of a prototype-based language (there were others, but not as widely used or seen). Each of these languages, if triggered by Self, really applies the basic programming concepts from Self to the language as a whole.

All languages have boundaries that define what is "in" the language and what isn't. Even the most reflective languages usually have some dark corners that aren't really accessible within the language itself. Self is no different in this regard. One of the things that I never really understood was why the compiler was not written in Self. You cannot change the internals of the Self compilation system through Self. Similarly, the VM is not accessible.

Reflection has its costs too. For instance, imagine changing the VM slightly and just a little too late finding out that there is a bug in your new code... Forth allows you to change virtual (or really all?) everything in the language. It is rather easy to have enough knowledge to be dangerous in Forth.

Some languages simply do not try to cover everything. Pascal comes to mind here. The language is fairly clean and clear, but it is quite limited. C lets you get to the "bare metal" and you pay for it with the lack of GC, pointers and all the interesting (but terminal) things you can do with them. Java stears away from too much reflection. You can look at methods and classes etc., but you can't change the GC system or the VM from within Java.

Squeak comes close to finding a good balance. While the system is all in Smalltalk, you can recode the VM and the GC system and then have the system re-emit this as C code. Thus, there is a reintroduction of the edit-compile-debug cycle on a larger scale than is usual in Smalltalk. I would love to see a Self-like system that is much like Squeak. One of the beautiful things about such a system is that you can have a working environment and use it to replumb itself! Carefully of course :-)

Classes have always bothered me a bit because I kept thinking about Plato's allegory of the cave. OO systems are about modelling and "real life" is messy, not some platonic ideal. Classes are a useful implementation tool, but it seems like bookeeping that is best left to a compiler or automated system rather than the programmer. When I first saw Self described in about 1989, I was fascinated because it seemed like the first time that I had seen a system when the things you care about (the entities that make up the system) are the things you manipulate. How do you change an object in Smalltalk or C++? You don't change the object, you change its class. This indirection removes the immediacy and intuitiveness of you interactions with the system.

In short I think that prototype systems model the way that we think more closely than those based on classes. When 32K was a lot of memory for a mainframe, perhaps FORTRAN and COBOL were the best possible ways to view computation. When it is hard to find a desktop with less than 64MB of memory and a processor capably of over 500 million useful instructions per second, I don't think that the same restrictions apply.

Best, Kyle

Kyle,

for the 37380 methods in the Demo snapshot, we have this distribution of source length (31886, or 85%, are less than 1000 bytes long):

0-99 10776 100-199 4778 200-299 3791 300-399 4110 400-499 2780 500-599 1773 600-699 1212 700-799 1063 800-899 887 900-1000 716 1000-1999 4173 2000-2999 593 3000-3999 407 4000-4999 99 5000-5999 28

10500 1

219700 193

Repeating the same thing but counting in number of lines we have (20085, 53%, are less then 10 lines long):

1 5615 2 2101 3 2721 4 2630 5 1728 6 1582 7 1391 8 1323 9 994 10-19 10441 20-29 3274 30-39 1860 40-49 622 50-59 259 60-69 268 70-79 128 80-89 131 90-99 91 100-109 25 120-129 2

238 1 3449 193

The 238 line method is one that creates a frameMorph full of little icons, all "spelled out" in details. The 193 very large methods seem to be code to recreate objects for the tutorial.

When browsing with an outliner, you can directly see the code for all methods which are just one line long when they, plus the method name, are short enough to fit in the outliner's width. My impression is that from one fourth to one half of the methods I see are in that group, which seems to agree with the numbers above.

I have written some very large methods in Self, unfortunately. These were either due to a lack of experience or the need to do complex object initializations. So I would expect future Self programs to be nearly as well factored as Forth programs. Note that it was easier to deal with longer methods in the old, text based Selfs but with shorter methods (you don't have to open them) in Self 4.

Forth has an advantage - there is little overhead for defining words and none at all for using them. But Self has objects, not just words. And this is a very, very important point: a truly object oriented program has most of its "smarts" in the way the objects are connected to each other, not inside each object. This makes them hard to understand by reading the code - the methods are so short and mostly seem to be delegating the same messages to other objects instead of actually doing anything.

The other day I was trying to explain this to a person and comparing objects with neural networks. People coming from a procedural language tend to create one giant object with a few, large methods and several dumb objects (nothing but data slots).

-- Jecel

On Thu, 11 Jan 2001, Kyle wrote:

The histograms of this are interesting. Nearly 25% are between 10 and 20 lines. That actually seems a bit surprizing. I would have thought that the bulge would be in the 5-10 range.

Actually, there is a very large spike for 10 line methods. That did seem odd, so I took a closer look at them. There were a lot of repeated methods - only 65 were unique, while 251 had 6 repetitions each:

1 65 2 53 3 59 4 43 5 62 6 251 7 5 8 2 9 5 10 4 12 7 27 1

Most of these seem to be machine generated instead of written by hand, though it isn't easy to be sure without further investigation. In any case, they all have the pattern

_some_primitive_IfFail:

[|:e| ('badTypeError' isPrefixOf: e) || ['deadProxyError' isPrefixOf: e] ifFalse: [ ^fb value: e] True: [ ( reviveIfFail: [|:e| ^ fb value: e]) _some_primitive_IfFail: fb ]]

If we eliminate all these from consideration, then methods in Self are much shorter than they initially seemed.

It is not clear whether lines of code or bytes correspond more closely to FORTH-style factoring. In fact, I wasn't considering methods at all as part of Self's factoring, but objects with all their methods. Perhaps looking at methods is a better metric? It is not clear. FORTH doesn't really support objects directly (though you can extend it to do so easily enough). It is quite inefficient in most OO languages to define objects with just a few methods (for instance two). Generally, objects start "acquiring" more methods and grow as time goes on.

I think there is a relation - you use what is easy to do. Making new words in Forth is trivial, as is making new kinds of objects in Self.

A better mapping might be objects in OO and vocabularies/wordlists in FORTH?

Probably not. Though words and methods are different things, they don't feel too different. Vocabularies are very heavy weight things, so Forth programs tend to use just one or two.

Graphics are nice, but there is a loss of semantic density. The proceedings from InterCHI '93 have some stuff on this I think (it was the only one I attended). There are some things that are simply easier to communicate with special shorthand symbols. For instance,

a[42]->y(x);

(In C). This is very compact. In just a few bytes I can represent an array operation, a structure field access and a function call with specified argument. How do you show this graphically?

I was comparing

( | meth1 = ( | x | .... | ). meth2: z = ( | a <- 1 | .... | ). | )

with the outliners. Though the outliners take up less pixels, they are cleaner (thin lines instead of characters) and don't get in the way as much as the textual representation. In text, you want longer methods since then you have a lower percentage of "overhead" characters. With outliners, this isn't a problem.

Actually, your point about OO being somewhat _more_ difficult to understand is interesting and particularly relevent. I'll have to think on this more. I have long thought that the manner in which the program was presented was much more important to understanding than grammatical issues.

Here Self has a great advantage over other OO languages in that its natural representation is a graph of box-like objects. If the meaning of a program is in this graph, then having it be invisible is a real obstacle.

I have seen both extremes. In one, first time OO programmers (with a procedural background) do as you note. In the other, they make everything in sight an object and then try to use objects as functions in their main routine. It generates... interesting code. I have had better luck explaining that OO is a really nice way of writing clean looking ADTs.

The idea of the FlyWeight Pattern is that it is possible to go to far in "objectifying" stuff. Should every character in a text be a real object? Most people would say no, but I will repeat Dave Ungar's motto here: "anything worth doing is worth overdoing" :-)

FORTH is "clean" because it lets you define what to do very easily. It gives you no intrinsic tools to describe what you do it with. That makes FORTH programs all verbs. There are few nouns in FORTH. OO programming is about noun verb combinations and seems closer to natural language.

One thing that is important to remember about Forth is that it limits your ambitions. Sort of like when you just have wood and cloth to build an aircraft with, you will think differently than if you had composite materials (I was going to say Titanium, but it seems that Apple is using all there is ;-)

So I don't expect to see a Kansas written in Forth, and that is ok. The world needs lots of small stuff.

Anyway, Forth is a pyramid of words while Self is a graph of objects. It is interesting that there is any comparison between them at all.

-- Jecel

At 15:54 01/07/2001 -0800, you wrote:

Interesting. After the last rebuke, I came to the opposite conclusion - that this list, being specifically about Self, should be primarily about Self. It also occured to me that there might be a need for a general discussion group on 'new' languages, Self-like or not. To this end, I have created a new eGroups list, MFTL.

In accordance with The Law of the Prophet Murphy, it was only after I set up MFTL that I learned that there already is an eGroups list for this sort of thing, called Language-Wars. Damn.

J Osako Operating Systems Designer, Notational Engineer, Generalist http://www.slip.net/~scholr/

Jecel Assumpcao Jr wrote:

On Sun, 07 Jan 2001, J Osako wrote:

...

At 15:54 01/07/2001 -0800, you wrote:

...

Interesting. After the last rebuke, I came to the opposite conclusion - that this list, being specifically about Self, should be primarily about Self. It also occured to me that there might be a need for a general discussion group on 'new' languages, Self-like or not. To this end, I have created a new eGroups list, MFTL.

In accordance with The Law of the Prophet Murphy, it was only after I set up MFTL that I learned that there already is an eGroups list for this sort of thing, called Language-Wars. Damn.

What does MFTL mean? Are you going to continue with this group or use Language-Wars instead?

I agree that this shouldn't become a general language discussion list, but while the traffic is still low I see no problems with some information on Self-like languages being posted here. If someone feels differently, please say so.

Well, what I really think is that computer science is rather looking like a Babel Tower. When I joined the Workshop of the PHD students in OO programming at ECOOP'97, my colleagues were already feeling this phenomenon..Their proposal or at least of some there was that we should restrict the proliferation of new languages. No more languages...Of course I found and find this proposal preposterous.

However reading papers about reflection right now, I start feeling things are like Babel Tower. To read a single paper I have to know all about all types of patterns (architectural, design and so on) all about reflection(!!!), distributed systems, OO, media space and so on...Finally after a great effort I am managing to understand what this intriguing paper is about. And of course I still do not know which language will be used for implementation....

Maybe there should be a list to try to integrate all these different computational trends. For example suddenly I discovered that a user interface is a virtual machine!!!!That the user can program the set of instructions of programmable processors and so on ...

I do not go crazy because I am an architect and at least for the moment although I am dependent thoroughly on computer science, the integration of my knowledge based system can be accomplished at a design level before proceeding to implementation. ANyhow all this is very frustrating. I would appreciate more integrative approaches in computer science.

Cheers Albertina

Of course, I hope the Self specific traffic won't be low forever...

-- Jecel

-- .----------------------------------------------------------. | Albertina Lourenci | | PhD in Architecture and Urbanism | | post-doctorate researcher | | Laboratory of Integrated Systems University of Sao Paulo | | Avenida Professor Luciano Gualberto, 158 Travessa 3 | | CEP: 05508-900 | | Sao Paulo Sao Paulo State Brazil | | Voice: +55 011 818 5254 | | Fax: +55 11 211 4574 | .----------------------------------------------------------.

Brian Rice wrote:

...

...

Well, what I really think is that computer science is rather looking like a Babel Tower. When I joined the Workshop of the PHD students in OO programming at ECOOP'97, my colleagues were already feeling this phenomenon..Their proposal or at least of some there was that we should restrict the proliferation of new languages. No more languages...Of course I found and find this proposal preposterous.

However reading papers about reflection right now, I start feeling things are like Babel Tower. To read a single paper I have to know all about all types of patterns (architectural, design and so on) all about reflection(!!!), distributed systems, OO, media space and so on...Finally after a great effort I am managing to understand what this intriguing paper is about. And of course I still do not know which language will be used for implementation....

Maybe there should be a list to try to integrate all these different computational trends. For example suddenly I discovered that a user interface is a virtual machine!!!!That the user can program the set of instructions of programmable processors and so on ...

I do not go crazy because I am an architect and at least for the moment although I am dependent thoroughly on computer science, the integration of my knowledge based system can be accomplished at a design level before proceeding to implementation. ANyhow all this is very frustrating. I would appreciate more integrative approaches in computer science.

Cheers Albertina

Hi Brian:

<PLUG TYPE="shameless"><A HREF="http://www.tunes.org">The TUNES Project</A></PLUG>

I downloaded "Metaprogramming and free availability of sources. Two challenges for computing today + Why a new operating system? + The TUNEs glossary.

I found interesting the list of people working on reflection. However I consider Patrick Steyaert from Belgium a leading name in the subject and his name was not there. Will you please add his important contribution? Especially because it is associated with the prototype-based language Agora.

Seriously, this is what I am working on (Jecel also participates when he can). The project is unfunded (I have even had to drop out of school for a few years to avoid "brainwashing"), but a few people (mostly Faré and I) have accomplished a lot of headway. Unfortunately because we have no formal support from any institutions (at the moment), our research efforts have been hampered by a perceived lack of a precise plan.

I am lucky because I have a precise plan, the development of a prototype based knowledge based system to design and plan sustainable cities. Due to the complexity of the architectural and urban design and urban planning reasoning, I am finally perceiving that I will need a much more encompassing computational open system than the Self language by itself can provide. However I would abandon Self only for a superior language to it. The problem for international joint research is the low salaries in Brazil. FAPESP can provide funds of millions of dollars for outstanding research plans but payment for personnel will be according to BRazilian standards.

Because of this, our mailing list has also over the years picked up a lot of this Babel effect (I avoided it for years for this reason), even as our goal is unification (be careful on how you interpret that).

Well I am not a computer scientist, but I am managing to unfold a knowledge based system that cares for unification in the realm of urban sustainability in such a way that it respects the very creativity of the free form in architecture. Every architectural designer will express himself through the ecodesign model and the submodel of the geometric modeling. The outcome is always a surprise even for the designer. Until now any style in architecture is a simple imitation of previous styles. There is no radical change. Moreover one could work in a team of hundreds of people!!!And yet there can be consensus about the final outcome of something. This final outcome can always be improved and another outcome can be reached if someone for example the owner of the project is not satisfied.

So I think when one thinks scientifically one can delve deeper into any realm and manage to grasp the gist of the domain and translate it into scientifc terms, I mean objective terms This is possible because the nature of a thing, of an idea is captured and this does not depend on a subject (I or other's opinion).

I have no idea how to reach this unification in computer science, but what I am sure if no effort is held in this direction no efficient computational open system will be built. Hence no knowledge based system for complex applications will work efficiently.

I've said too much already.

If you could show us how Self can be integrated into this broader unifying framework you and Faré and others are trying to build you will be contributing greatly to my research. Or if Self must be adapted or you would suggest building a far better language and cite the necessary properties of this new language it is also objective contribution.

I do thank you for this new intriguing site.

Best wishes and good luck!

Albertina

-- .----------------------------------------------------------. | Albertina Lourenci | | PhD in Architecture and Urbanism | | post-doctorate researcher | | Laboratory of Integrated Systems University of Sao Paulo | | Avenida Professor Luciano Gualberto, 158 Travessa 3 | | CEP: 05508-900 | | Sao Paulo Sao Paulo State Brazil | | Voice: +55 011 818 5254 | | Fax: +55 11 211 4574 | .----------------------------------------------------------.