Just noticed that Dave is giving what looks like a really interesting talk at OOPSLA 2003: http://oopsla.acm.org/oopsla2003/files/key-4.html
Any hope for a protos workshop this year? Everything seems to be about design patterns or Agile programming. Borrrrrring. :-)
Cheers, Steve OSX freeware and shareware: http://www.dekorte.com/downloads.html
On Fri, 1 Aug 2003, Steve Dekorte wrote:
Just noticed that Dave is giving what looks like a really interesting talk at OOPSLA 2003: http://oopsla.acm.org/oopsla2003/files/key-4.html
Any hope for a protos workshop this year? Everything seems to be about design patterns or Agile programming. Borrrrrring. :-)
I would organize a BOF if I can manage to make it, but finances are really tight right now.
On Friday 01 August 2003 20:00, Brian T Rice wrote:
On Fri, 1 Aug 2003, Steve Dekorte wrote:
Just noticed that Dave is giving what looks like a really interesting talk at OOPSLA 2003: http://oopsla.acm.org/oopsla2003/files/key-4.html
It sure looks like something worth waking up early for :-)
Any hope for a protos workshop this year? Everything seems to be about design patterns or Agile programming. Borrrrrring. :-)
I would organize a BOF if I can manage to make it, but finances are really tight right now.
I'll be participating in the demo track, showing two different machines running Neo Smalltalk (previously Self/R and Merlin OS before that...) which is prototype based. It would be great to meet other people interested in Self or prototypes in general.
-- Jecel
Dear Selfers! I am curious if there are any relationship between Kansas and Tcl, both from Sun! Best wishes Albertina http://www.lsi.usp.br/~lourenci
TCL already existed before John Osterhaut (spelling?) joined Sun, and while Tcl was here, there was very little mutual influence between the Self and TCL groups, since both were rather mature and conceptually far apart by the time.
--Randy
Albertina Lourenci wrote:
Dear Selfers! I am curious if there are any relationship between Kansas and Tcl, both from Sun! Best wishes Albertina http://www.lsi.usp.br/~lourenci
Yahoo! Groups Links
Randy Smith wrote: Hi Randy! John K. Ousterhout in IEEE Computer March 1998 writes: I am not aware of any rapid-development environments for GUIs based on a system programming language. Whether the environment is Windows, Macintosh Toolbox or Unix Motif GUI toolkits based on languages such as C or C++ have proven hard to learn, clumsy to use, and inflexible in the results 'they produce.Some of these systems have nice graphical tools for designing screen layouts that hide the underlying language, but things become difficult as soon as the designer has to write code, for example to provide the behaviors for the interface elements. All of the best rapid development GUI environments are based on scripting languages: Visual Basic, HyperCard and Tcl/TK. page 28
I would like you to comment on Self's GUI within the context put forward by Ousterhout. For him scripting languages deal with policy and system programming languages with mechanisms. He sees no problem in implementing scripting languages in programming languages of course. Indeed TCl is implemented in C. It may also be extended in C.
Have a fun-filled, peaceful, creative weekend Albertina http://www.lsi.usp.br/~lourenci
TCL already existed before John Osterhaut (spelling?) joined Sun, and while Tcl was here, there was very little mutual influence between the Self and TCL groups, since both were rather mature and conceptually far apart by the time.
--RandyAlbertina Lourenci wrote:
Dear Selfers! I am curious if there are any relationship between Kansas and Tcl, both from Sun! Best wishes Albertina http://www.lsi.usp.br/~lourenci
Yahoo! Groups Links
Yahoo! Groups Links
Okay Albertina, I'll try to respond for you here: Self's GUI was never tuned to being like Motif or being fully brought up to address the construction of stand alone, single apps. Rather we were exploring the sense of a world in which many applications could be created and recombined. Nevertheless, our hypothesis has always been that the difficulties Ousterhout observes (the problem of bridging the direct GUI environment with a general purpose programming language) can be addressed. There are difficulties of course, and deep issues such as the fact that direct GUI assembly and modification is a different environment than the textual environment of the language's code.
Albertina Lourenci wrote:
Randy Smith wrote: Hi Randy! John K. Ousterhout in IEEE Computer March 1998 writes: I am not aware of any rapid-development environments for GUIs based on a system programming language. Whether the environment is Windows, Macintosh Toolbox or Unix Motif GUI toolkits based on languages such as C or C++ have proven hard to learn, clumsy to use, and inflexible in the results 'they produce.Some of these systems have nice graphical tools for designing screen layouts that hide the underlying language, but things become difficult as soon as the designer has to write code, for example to provide the behaviors for the interface elements. All of the best rapid development GUI environments are based on scripting languages: Visual Basic, HyperCard and Tcl/TK. page 28
I would like you to comment on Self's GUI within the context put forward by Ousterhout. For him scripting languages deal with policy and system programming languages with mechanisms. He sees no problem in implementing scripting languages in programming languages of course. Indeed TCl is implemented in C. It may also be extended in C.
Have a fun-filled, peaceful, creative weekend Albertina http://www.lsi.usp.br/~lourenci
TCL already existed before John Osterhaut (spelling?) joined Sun, and while Tcl was here, there was very little mutual influence between the Self and TCL groups, since both were rather mature and conceptually far apart by the time.
--RandyAlbertina Lourenci wrote:
Dear Selfers! I am curious if there are any relationship between Kansas and Tcl, both from Sun! Best wishes Albertina http://www.lsi.usp.br/~lourenci
Yahoo! Groups Links
Yahoo! Groups Links
Yahoo! Groups Links
* To visit your group on the web, go to: http://groups.yahoo.com/group/self-interest/ * To unsubscribe from this group, send an email to: self-interest-unsubscribe@yahoogroups.com <mailto:self-interest-unsubscribe@yahoogroups.com?subject=Unsubscribe> * Your use of Yahoo! Groups is subject to the Yahoo! Terms ofService http://docs.yahoo.com/info/terms/.
Randy Smith wrote:
Thanks Randy! Indeed in the same paper Ousterhout recognizes there are many interesting languages that cannot be characterized cleanly as a system programming language or a scripting language. For example, the LISP family of languages lies somewhere between scripting and system programming with some of the attributes of each.
LIsp pioneered concepts such as interpretation and dynamic typing that are now common in scripting languages, as well as automatic storage management and integrated development environments which are now used in both scripting and system programming languages. Do you think Self plays the role of a programming and scripting language? I don''t have the book or have experienced with Tcl or Motif to check if indeed it deals with policy or strategy perfectly well. Indeed Agile Development Software Ecosystems try to do this. However they try to do this based on natural language! Something like Christopher Alexander does in his books A pattern language or The Nature of Order. Indeed the general theory of the sign from Peirce tries to overcome this difficulty. And the Greimasian semiotics unfolds the same concern in a more scientific way I believe. (My postdoctorate Scientific Report III deals with this - see my homepage - however I was shyly trying to unravel a morphodynamic level there) I have not gathered my recent conclusions about this in a report yet.
Okay Albertina, I'll try to respond for you here: Self's GUI was never tuned to being like Motif or being fully brought up to address the construction of stand alone, single apps. Rather we were exploring the sense of a world in which many applications could be created and recombined. Nevertheless, our hypothesis has always been that the difficulties Ousterhout observes (the problem of bridging the direct GUI environment with a general purpose programming language) can be addressed. There are difficulties of course, and deep issues such as the fact that direct GUI assembly and modification is a different environment than the textual environment of the language's code.
See my main problem with graphical user interfaces is that they are based on Euclidean geometry. My algebraic-geometric modeling is based on symmetry groups of the plane and the dotless plane (similarity symmetry groups and conformal symmetry groups). And of course the underlying algebra is textual transformable into geometric groups. This is cool! Likewsise graph theory where we also have planar graphs. Hence I would like to mimic this in a collaborative aware architecture. Of course the (hermeneutic = dialogue, chat, game) nature of the Self language matches my artistic needs. However I think there are too many things implicit in the programming environment. I know nothing about Motif but to pick up ready stuff sounds nasty. Of course Self (Kansas) tries to bridge the gap between programmers and language developers. One should strive to embed things in an infinitely encompassing level of abstraction.I was successful to do this in my domain model as well as in my geometric modeling. Why not to pursue the same goals in architecture and programming code of my knowledge system to design and plan sustainable cities? Best wishes Albertina
Albertina Lourenci wrote:
Randy Smith wrote: Hi Randy! John K. Ousterhout in IEEE Computer March 1998 writes: I am not aware of any rapid-development environments for GUIs based on a system programming language. Whether the environment is Windows, Macintosh Toolbox or Unix Motif GUI toolkits based on languages such as C or C++ have proven hard to learn, clumsy to use, and inflexible in the results 'they produce.Some of these systems have nice graphical tools for designing screen layouts that hide the underlying language, but things become difficult as soon as the designer has to write code, for example to provide the behaviors for the interface elements. All of the best rapid development GUI environments are based on scripting languages: Visual Basic, HyperCard and Tcl/TK. page 28
I would like you to comment on Self's GUI within the context put forward by Ousterhout. For him scripting languages deal with policy and system programming languages with mechanisms. He sees no problem in implementing scripting languages in programming languages of course. Indeed TCl is implemented in C. It may also be extended in C.
Have a fun-filled, peaceful, creative weekend Albertina http://www.lsi.usp.br/~lourenci
TCL already existed before John Osterhaut (spelling?) joined Sun, and while Tcl was here, there was very little mutual influence between the Self and TCL groups, since both were rather mature and conceptually far apart by the time.
--RandyAlbertina Lourenci wrote:
Dear Selfers! I am curious if there are any relationship between Kansas and Tcl, both from Sun! Best wishes Albertina http://www.lsi.usp.br/~lourenci
Yahoo! Groups Links
Yahoo! Groups Links
Yahoo! Groups Links
* To visit your group on the web, go to: http://groups.yahoo.com/group/self-interest/ * To unsubscribe from this group, send an email to: self-interest-unsubscribe@yahoogroups.com <mailto:self-interest-unsubscribe@yahoogroups.com?subject=Unsubscribe> * Your use of Yahoo! Groups is subject to the Yahoo! Terms ofService http://docs.yahoo.com/info/terms/.
Yahoo! Groups Links
On Friday 05 March 2004 15:56, Randy Smith wrote:
Okay Albertina, I'll try to respond for you here: Self's GUI was never tuned to being like Motif or being fully brought up to address the construction of stand alone, single apps. Rather we were exploring the sense of a world in which many applications could be created and recombined.
Just to reinforce this idea by saying the same thing in slightly different words: if you define as a basic parameter of your project that it will run as a "normal" application in some environment such as Windows XP, Mac OS X or X Window then you are automatically excluding tools which include their own environments (such as Self or Squeak) from consideration. All you have left are scripting languages and things like C++ and in that case the scripting languages do indeed look like the best option.
This is exactly the case mentioned in another thread by Stefan Urbanek. One of his requirements is that the application must run in the Cocoa (NeXTStep/Mac OS X) environment. As Steve Dekorte pointed out, a simple scripting language like Io would more easily fit into this project. Note that there is nothing about the Self language itself that keeps us from creating a scripting version of it, just that only one person who has worked on Self so far has been interested in this (OpenSelf, but see my note at http://www.merlintec.com:8080/Self).
Nevertheless, our hypothesis has always been that the difficulties Ousterhout observes (the problem of bridging the direct GUI environment with a general purpose programming language) can be addressed. There are difficulties of course, and deep issues such as the fact that direct GUI assembly and modification is a different environment than the textual environment of the language's code.
This is one of the main issues I am addressing in Neo Smalltalk. Note that unifying the two environments greatly simplified the language itself - there is no need for a syntax for literal objects if you have graphical ones (even for strings and numbers).
-- Jecel
Jecel Assumpcao Jr wrote: Hi Jecel!
On Friday 05 March 2004 15:56, Randy Smith wrote:
Okay Albertina, I'll try to respond for you here: Self's GUI was never tuned to being like Motif or being fully brought up to address the construction of stand alone, single apps. Rather we were exploring the sense of a world in which many applications could be created and recombined.
Just to reinforce this idea by saying the same thing in slightly different words: if you define as a basic parameter of your project that it will run as a "normal" application in some environment such as Windows XP, Mac OS X or X Window then you are automatically excluding tools which include their own environments (such as Self or Squeak) from consideration. All you have left are scripting languages and things like C++ and in that case the scripting languages do indeed look like the best option.
This is exactly the case mentioned in another thread by Stefan Urbanek. One of his requirements is that the application must run in the Cocoa (NeXTStep/Mac OS X) environment. As Steve Dekorte pointed out, a simple scripting language like Io would more easily fit into this project. Note that there is nothing about the Self language itself that keeps us from creating a scripting version of it, just that only one person who has worked on Self so far has been interested in this (OpenSelf, but see my note at http://www.merlintec.com:8080/Self).
I see your viewpoint.
Nevertheless, our hypothesis has always been that the difficulties Ousterhout observes (the problem of bridging the direct GUI environment with a general purpose programming language) can be addressed. There are difficulties of course, and deep issues such as the fact that direct GUI assembly and modification is a different environment than the textual environment of the language's code.
This is one of the main issues I am addressing in Neo Smalltalk. Note that unifying the two environments greatly simplified the language itself - there is no need for a syntax for literal objects if you have graphical ones (even for strings and numbers).
I miss the point here. Semiotically speaking there may be different forms for the same content. What's the problem with this? For me the problem is when there is no correspondence between the two different forms. This is exactly what happens when one tries to map domain model and architecture into programming languages. Indeed in the levels of the natural language there is no such isomorphism because each level plays a different role. However there are some structures that might be isomorphic or that are traceable (I think I make this neat in my paper and presentation for ROOTS'02 (Bergen Norway)
from my homepage. Best wishes Albertina http://www.lsi.usp.br/~lourenci
-- Jecel
Yahoo! Groups Links
On Friday 05 March 2004 19:45, Albertina Lourenci wrote:
Jecel Assumpcao Jr wrote:
This is one of the main issues I am addressing in Neo Smalltalk. Note that unifying the two environments greatly simplified the language itself - there is no need for a syntax for literal objects if you have graphical ones (even for strings and numbers).
I miss the point here. Semiotically speaking there may be different forms for the same content. What's the problem with this?
The problem is that there are two contexts, with some forms used in one and others used in the other. That makes programming more awkward than it should be.
When you are in the textual programming context and you need to refer to an object, you can:
1) just use the literal syntax of the language to describe it, if it is one of the few kinds of objects for which that is available - 23, 'hello world', [|:i| i + 1], (| answer <- 7 |)
2) create the object by sending a message to a literal, if that is relatively simple and fast for this kind of object - 4@7, ('a' & 'e' & 'i') asSet
3) create the object in some initialization code and store it in a variable which other code can "see" - look at the methods which create the little buttons for the outliners for an example
Besides these traditional options, in Self we can also:
4) create the object using any tools provided by the system, call up its outliner from the blue menu, create a slot pointing to () or 0 or anything like that in the object you are writing the method for, drag the arrow from the new slot to point to the outliner. Now you can reference the slot name in the method.
This is the first real step of allowing me to use the graphical representation from the textual programming context. A fine first step, but what things can't we do even now?
5) put any object in the middle of some code, not just the few literal kinds
6) name the objects in the graphical context (see Visual Basic) and use these names in the method text
Having all this would make programming far nicer, in my opinion.
For me the problem is when there is no correspondence between the two different forms. This is exactly what happens when one tries to map domain model and architecture into programming languages.
There is always a correspondence between any forms, but often it isn't very convenient. For us, I mean - the computer doesn't care since everything is just bits to it.
Indeed in the levels of the natural language there is no such isomorphism because each level plays a different role. However there are some structures that might be isomorphic or that are traceable (I think I make this neat in my paper and presentation for ROOTS'02 (Bergen Norway) from my homepage.
I didn't find any examples in the presentation, only explanations of several different philosophical theories.
-- Jecel
Jecel Assumpcao Jr wrote: Dear Jecel!
On Friday 05 March 2004 19:45, Albertina Lourenci wrote:
Jecel Assumpcao Jr wrote:
This is one of the main issues I am addressing in Neo Smalltalk. Note that unifying the two environments greatly simplified the language itself - there is no need for a syntax for literal objects if you have graphical ones (even for strings and numbers).
I miss the point here. Semiotically speaking there may be different forms for the same content. What's the problem with this?
The problem is that there are two contexts, with some forms used in one and others used in the other. That makes programming more awkward than it should be.
Is the main difference between syntax for literal and graphical objects that the latter is interactive?
When you are in the textual programming context and you need to refer to an object, you can:
- just use the literal syntax of the language to describe it, if it is
one of the few kinds of objects for which that is available - 23, 'hello world', [|:i| i + 1], (| answer <- 7 |)
- create the object by sending a message to a literal, if that is
relatively simple and fast for this kind of object - 4@7, ('a' & 'e' & 'i') asSet
- create the object in some initialization code and store it in a
variable which other code can "see" - look at the methods which create the little buttons for the outliners for an example
Besides these traditional options, in Self we can also:
- create the object using any tools provided by the system, call up
its outliner from the blue menu, create a slot pointing to () or 0 or anything like that in the object you are writing the method for, drag the arrow from the new slot to point to the outliner. Now you can reference the slot name in the method.
This is the first real step of allowing me to use the graphical representation from the textual programming context. A fine first step, but what things can't we do even now?
- put any object in the middle of some code, not just the few literal
kinds
- name the objects in the graphical context (see Visual Basic) and use
these names in the method text
Having all this would make programming far nicer, in my opinion.
For me the problem is when there is no correspondence between the two different forms. This is exactly what happens when one tries to map domain model and architecture into programming languages.
There is always a correspondence between any forms, but often it isn't very convenient. For us, I mean - the computer doesn't care since everything is just bits to it.
Indeed in the levels of the natural language there is no such isomorphism because each level plays a different role. However there are some structures that might be isomorphic or that are traceable (I think I make this neat in my paper and presentation for ROOTS'02 (Bergen Norway) from my homepage.
I didn't find any examples in the presentation, only explanations of several different philosophical theories.
I put forward clearly in my papers that the software architecture is the place of discourse and communication. The place of a collaborative architecture.Of course it matters if this is bidimensional or tridimensional. If it is bidimensional one cannot see the stakeholders in three dimensions. However I realize one can trace perfectly well the three-dimension into the banners in bidimensional collaborative software architecture like in Kansas. Of course if one adds contextual information in the three dimensional architecture there is no real traceability between bi and three-dimensional.
The three dimensional collaborative architecture is not isomorphic to the bidimensional architecture.
This is a far cry from the domain model. Traceability is achieved of course because necessarily the components of the domain model are part of the software architecture and of course they must be implemented. I mean each level has a different nature and I explain this clearly for natural language. Many thanks for your detailed explanation above however it is not clear if syntax for literal and graphical objects are isomorphic.
Best wishes Albertina
-- Jecel
Yahoo! Groups Links
On Saturday 13 March 2004 15:12, Albertina Lourenci wrote:
Is the main difference between syntax for literal and graphical objects that the latter is interactive?
The main difference is that, in existing systems, they are used in different places. The graphical object normally (but not always) is interactive while we don't think of the textual syntax as such.
Let us imagine we want to have architectural objects in a Self-like language. One such object is a wall, and we could invent a special syntax for it so we could write
w1: <.5,0>=<0,0>=<0,7>=<7,7>=<7,6.5>
to describe a wall with the standard height and width which starts at coordinates x=0.5 and y=0.0 and then passes through three intermediate points before ending at x=7.0 and y=6.5.
Instead of doing this, we could define the '===' message for points and walls in regular Self and write
w1: (0.5@0)===(0@0)===(0@7)===(7@7)===(7@6.5)
using only the literal syntax for numbers and the '@' and '===' messages to build the same wall object as in the previous example. The problem with this is that it takes a little while to build this wall from the 10 numbers and so we don't want to do this every time a popular method is executed.
To show a graphical version of this same wall object I would have to attach a picture to this email, so I will let you just imagine we did it with the sketchMorph we created for your thesis. You can change the wall after it was created since the sketchMorph is a graphical editor, but you can also edit the text for the two version of the example I gave above. The first, of course, can be done while the program is running while the latter while the program is being created. That makes a difference for languages like C, but not for Self.
Even though the three versions of the wall object are equivalent in theory, in practice it is more fun to deal with the graphical version.
I put forward clearly in my papers that the software architecture is the place of discourse and communication.
I was hoping for a simple and concrete example like I gave above.
-- Jecel
Jecel Assumpcao Jr wrote: Hi Jecel!
On Saturday 13 March 2004 15:12, Albertina Lourenci wrote:
Is the main difference between syntax for literal and graphical objects that the latter is interactive?
The main difference is that, in existing systems, they are used in different places. The graphical object normally (but not always) is interactive while we don't think of the textual syntax as such.
Let us imagine we want to have architectural objects in a Self-like language. One such object is a wall, and we could invent a special syntax for it so we could write
w1: <.5,0>=<0,0>=<0,7>=<7,7>=<7,6.5>
to describe a wall with the standard height and width which starts at coordinates x=0.5 and y=0.0 and then passes through three intermediate points before ending at x=7.0 and y=6.5. Well, in this case we have no graphical wall!
Of course for graphical designers this makes no sense! What I understand by graphical syntax is something like the GUI, the outliner and so on! In this case you also have true graphical objects. Hence the difference is not it is only interactive. Indeed it has different functionality from the literal syntax. It is something like three dimensional collaborative architecture and bidimensional collaborative architecture.
Instead of doing this, we could define the '===' message for points and walls in regular Self and write
w1: (0.5@0)===(0@0)===(0@7)===(7@7)===(7@6.5)
using only the literal syntax for numbers and the '@' and '===' messages to build the same wall object as in the previous example. The problem with this is that it takes a little while to build this wall from the 10 numbers and so we don't want to do this every time a popular method is executed.
To show a graphical version of this same wall object I would have to attach a picture to this email, so I will let you just imagine we did it with the sketchMorph we created for your thesis. You can change the wall after it was created since the sketchMorph is a graphical editor, but you can also edit the text for the two version of the example I gave above. The first, of course, can be done while the program is running while the latter while the program is being created. That makes a difference for languages like C, but not for Self.
Even though the three versions of the wall object are equivalent in theory, in practice it is more fun to deal with the graphical version.
I see no equivalence! Only if you make a reductionist effort or a rough mapping from one to the other. For a designer this makes no sense!
I put forward clearly in my papers that the software architecture is the place of discourse and communication.
I was hoping for a simple and concrete example like I gave above.
I could give the example in terms of the subgroup relationships of the crystallographic groups where everybody becomes a designer and a "philosopher"!!:-)! Thank you! Best wishes Albertina
-- Jecel
Yahoo! Groups Links
On Monday 15 March 2004 19:32, Albertina Lourenci wrote:
Well, in this case we have no graphical wall!
It is an example of a textual notation, not a graphical one.
Of course for graphical designers this makes no sense!
My point exactly.
What I understand by graphical syntax is something like the GUI, the outliner and so on! In this case you also have true graphical objects.
I am typing this in an application running in a GUI, yet can't use it to send you an example of a graphical notation. The outliner only allows you to type text in it to define a method, even though it is a very nice graphical notation of an object.
Hence the difference is not it is only interactive. Indeed it has different functionality from the literal syntax. It is something like three dimensional collaborative architecture and bidimensional collaborative architecture.
Right.
Even though the three versions of the wall object are equivalent in theory, in practice it is more fun to deal with the graphical version.
I see no equivalence! Only if you make a reductionist effort or a rough mapping from one to the other. For a designer this makes no sense!
It is not a rough mapping - it is an exact mapping which an automatic tool can use to translate from one notation to the other.
But you are the one who said:
# I miss the point here. Semiotically speaking there may be different # forms for the same content. What's the problem with this? For me the # problem is when there is no correspondence between the two different # forms. This is exactly what happens when one tries to map domain model # and architecture into programming languages.
I showed you three different forms for the same content, and hope you now see the problem with this. In practice, some forms are more convenient than others.
-- Jecel
Jecel Assumpcao Jr wrote: Hi Jecel!
On Monday 15 March 2004 19:32, Albertina Lourenci wrote:
Well, in this case we have no graphical wall!
It is an example of a textual notation, not a graphical one.
Of course for graphical designers this makes no sense!
My point exactly.
What I understand by graphical syntax is something like the GUI, the outliner and so on! In this case you also have true graphical objects.
I am typing this in an application running in a GUI, yet can't use it to send you an example of a graphical notation. The outliner only allows you to type text in it to define a method, even though it is a very nice graphical notation of an object.
Hence the difference is not it is only interactive. Indeed it has different functionality from the literal syntax. It is something like three dimensional collaborative architecture and bidimensional collaborative architecture.
Right.
And this confirms my viewpoints there is no one-to-one mapping. Different functionalities are involved.
Even though the three versions of the wall object are equivalent in theory, in practice it is more fun to deal with the graphical version.
I see no equivalence! Only if you make a reductionist effort or a rough mapping from one to the other. For a designer this makes no sense!
It is not a rough mapping - it is an exact mapping which an automatic tool can use to translate from one notation to the other.
I see! It is like free-hand sketch and then technical drawing!
But you are the one who said:
# I miss the point here. Semiotically speaking there may be different # forms for the same content. What's the problem with this? For me the # problem is when there is no correspondence between the two different # forms. This is exactly what happens when one tries to map domain model # and architecture into programming languages.
Sure! I believe the conundrum might be solved if one builds programming languages inspired by what happens in domain model and architectures. And yet the programming language has its own development!
I showed you three different forms for the same content, and hope you now see the problem with this. In practice, some forms are more convenient than others.
I see. Thank you for the detailed explanation. Best wishes Albertina
-- Jecel
Yahoo! Groups Links
On 2004-03-05 22:06:07 +0100 Jecel Assumpcao Jr jecel@merlintec.com wrote:
On Friday 05 March 2004 15:56, Randy Smith wrote:
Okay Albertina, I'll try to respond for you here: Self's GUI was never tuned to being like Motif or being fully brought up to address the construction of stand alone, single apps. Rather we were exploring the sense of a world in which many applications could be created and recombined.
Just to reinforce this idea by saying the same thing in slightly different words: if you define as a basic parameter of your project that it will run as a "normal" application in some environment such as Windows XP, Mac OS X or X Window then you are automatically excluding tools which include their own environments (such as Self or Squeak) from consideration. All you have left are scripting languages and things like C++ and in that case the scripting languages do indeed look like the best option.
This is exactly the case mentioned in another thread by Stefan Urbanek. One of his requirements is that the application must run in the Cocoa (NeXTStep/Mac OS X) environment. As Steve Dekorte pointed out, a simple scripting language like Io would more easily fit into this project. Note that there is nothing about the Self language itself that keeps us from creating a scripting version of it, just that only one person who has worked on Self so far has been interested in this (OpenSelf, but see my note at http://www.merlintec.com:8080/Self).
Just to add a note to this... Self does not have any working GUI/app framework that would be sufficient for creating an usable application. And as I see it, Self will not have it in near future. What Self has, is a great computational mechanism and different view on how to "model a problem". Ant there is the power of Self. Yecel named it "scripting", others can name it "integration" - with that both sides can gain. Application developers will get powerful computational engine and Self will finally get users (developers, testers, ...).
The advantage of Self is not only "scripting". I think of scripts as of some small pieces of code for automation or customisation. The advantage is, as I have mentioned before, the different computational model and well tested, fast runtime. Those are features that no other (or very few) scripting languages/environments offer. This moves Self to another, higher level, where one can use it not only for small pieces of code. One can use it for larger (user customisable) parts of an application. There are lots problems that can be solved in Self much more easier than in C/C++/ObjectiveC.
How I see it? Application using one or more Self environments. Ok, now I let my imagination go... What about stadard application as a frontend to a distributed self environments on different machines? It's just an example, but you get the idea where it should go...
I am not a Self developer, I come from another world and I am just saying how I see it from the outside. I think that a fight for a user environment is lost at this time, what can be won is a battle for exceptional computational environment/engine.
Stefan Urbanek
Stefan Urbanek wrote: Dear Stefan! See below!
On 2004-03-05 22:06:07 +0100 Jecel Assumpcao Jr jecel@merlintec.com wrote:
On Friday 05 March 2004 15:56, Randy Smith wrote:
Okay Albertina, I'll try to respond for you here: Self's GUI was never tuned to being like Motif or being fully brought up to address the construction of stand alone, single apps. Rather we were exploring the sense of a world in which many applications could be created and recombined.
Just to reinforce this idea by saying the same thing in slightly different words: if you define as a basic parameter of your project that it will run as a "normal" application in some environment such as Windows XP, Mac OS X or X Window then you are automatically excluding tools which include their own environments (such as Self or Squeak) from consideration. All you have left are scripting languages and things like C++ and in that case the scripting languages do indeed look like the best option.
This is exactly the case mentioned in another thread by Stefan Urbanek. One of his requirements is that the application must run in the Cocoa (NeXTStep/Mac OS X) environment. As Steve Dekorte pointed out, a simple scripting language like Io would more easily fit into this project. Note that there is nothing about the Self language itself that keeps us from creating a scripting version of it, just that only one person who has worked on Self so far has been interested in this (OpenSelf, but see my note at http://www.merlintec.com:8080/Self).
Just to add a note to this... Self does not have any working GUI/app framework that would be sufficient for creating an usable application. And as I see it, Self will not have it in near future. What Self has, is a great computational mechanism and different view on how to "model a problem". Ant there is the power of Self. Yecel named it "scripting", others can name it "integration" - with that both sides can gain. Application developers will get powerful computational engine and Self will finally get users (developers, testers, ...).
The advantage of Self is not only "scripting". I think of scripts as of some small pieces of code for automation or customisation. Well Ousterhout thinks of scripting languages as designed for gluing. They assume the existence of a set of powerful components and are intended primarily for connecting components.System programming languages are strongly typed to help manage complexity while scripting languages are typeless to simplify connections among components and provide rapid application development. in IEEE computer march 1998.
Scripting languages and system programming languages are complementary, and most major computing platforms since the 1960s have included both kinds of languages. The languages are typically used together in component frameworks, where components are created with system programming languages and glued together with scripting languages.
In his PHD thesis Software-architeckturen für die rahmenwerkbasierte Konstruktion grosser Anwendungssysteme (Arquiteturas de software baseadas em framework para a construção de grandes sistemas de aplicações) that is an Umberto Eco's semiotics application the connectors are the design patterns! These are also small pieces of code for customisation. Hence what's the difference between design patterns and scripts?
The advantage is, as I have mentioned before, the different computational model and well tested, fast runtime. Those are features that no other (or very few) scripting languages/environments offer. This moves Self to another, higher level, where one can use it not only for small pieces of code. One can use it for larger (user customisable) parts of an application. There are lots problems that can be solved in Self much more easier than in C/C++/ObjectiveC.
I believe nobody has doubts about Self's power of expressiveness.
How I see it? Application using one or more Self environments. Ok, now I let my imagination go... What about stadard application as a frontend to a distributed self environments on different machines?
This sounds great. Distributed Self environments on different machines as the basis of a collaborative architecture. Something like OpenCroquet (Alan Kay and so on) intends to offer to develop applications written in Squeak?:-)!
It's just an example, but you get the idea where it should go...
I am not a Self developer, I come from another world and I am just saying how I see it from the outside. I think that a fight for a user environment is lost at this time, what can be won is a battle for exceptional computational environment/engine.
Best wishes Albertina http://www.lsi.usp.br/~lourenci
Stefan Urbanek
First they ignore you, then they laugh at you, then they fight you, then you win.
- Mahatma Gandhi
Yahoo! Groups Links
Albertina,
On 2004-03-06 10:57:42 +0100 Albertina Lourenci lourenci@lsi.usp.br wrote:
Stefan Urbanek wrote: Dear Stefan! See below!
On 2004-03-05 22:06:07 +0100 Jecel Assumpcao Jr jecel@merlintec.com wrote:
<snip>
The advantage is, as I have mentioned before, the different computational model and well tested, fast runtime. Those are features that no other (or very few) scripting languages/environments offer. This moves Self to another, higher level, where one can use it not only for small pieces of code. One can use it for larger (user customisable) parts of an application. There are lots problems that can be solved in Self much more easier than in C/C++/ObjectiveC.
I believe nobody has doubts about Self's power of expressiveness.
Well ... nobody here has doubts. You know about the power, people on this list know, I do and perhaps very-very few others, but that is all. In fact, Self does not exists. I'll move a bit offtopic, but ... if current developers of self will retire, Self will retire with them. And that would be pity.
How I see it? Application using one or more Self environments. Ok, now I let my imagination go... What about stadard application as a frontend to a distributed self environments on different machines?
This sounds great. Distributed Self environments on different machines as the basis of a collaborative architecture. Something like OpenCroquet (Alan Kay and so on) intends to offer to develop applications written in Squeak?:-)!
Yes, and it is not too difficult to create something with OpenCroquet idea. Different from Squeak implementation there is one, perhaps not very nice analogy:
There is: WWW (passive) worlds + web browser There can be: Self (active) worlds + not-yet-written user (non-self) interface application.
If environment-native application (with environment-native visualising graphical tools) was used as an entrance or window to Self worlds, then it can be easily adaptable for potential users. And I think that it would be much more easier to introduce native app than to introduce something totally new.
Just imagine what everything can be done with those "living selfish worlds"... :-)
Best regards,
Stefan Urbanek
Stefan Urbanek wrote: Hi Stef!
Albertina,
On 2004-03-06 10:57:42 +0100 Albertina Lourenci lourenci@lsi.usp.br wrote:
Stefan Urbanek wrote: Dear Stefan! See below!
On 2004-03-05 22:06:07 +0100 Jecel Assumpcao Jr jecel@merlintec.com wrote:
<snip>
The advantage is, as I have mentioned before, the different computational model and well tested, fast runtime. Those are features that no other (or very few) scripting languages/environments offer. This moves Self to another, higher level, where one can use it not only for small pieces of code. One can use it for larger (user customisable) parts of an application. There are lots problems that can be solved in Self much more easier than in C/C++/ObjectiveC.
I believe nobody has doubts about Self's power of expressiveness.
Well ... nobody here has doubts. You know about the power, people on this list know, I do and perhaps very-very few others, but that is all. In fact, Self does not exists. I'll move a bit offtopic, but ... if current developers of self will retire, Self will retire with them. And that would be pity. Sure! When they die the world will not be better and they will die without memory! I am running the same risk with my modeling
to design and plan sustainable cities. Many interesting applications will stop because computer science is still crawling!
How I see it? Application using one or more Self environments. Ok, now I let my imagination go... What about stadard application as a frontend to a distributed self environments on different machines?
This sounds great. Distributed Self environments on different machines as the basis of a collaborative architecture. Something like OpenCroquet (Alan Kay and so on) intends to offer to develop applications written in Squeak?:-)!
Yes, and it is not too difficult to create something with OpenCroquet idea.
Here where I am Internet 2 is already a reality. Hence we could run OpenCroquet when there will be a working version available and work collaboratively with researchers in American universities.
Different from Squeak implementation there is one, perhaps not very nice analogy:
There is: WWW (passive) worlds + web browser There can be: Self (active) worlds + not-yet-written user (non-self) interface application. Something like OpenCroquet in (SelfCroquet :-)!) sounds wonderful!
If environment-native application (with environment-native visualising graphical tools) was used as an entrance or window to Self worlds, then it can be easily adaptable for potential users. And I think that it would be much more easier to introduce native app than to introduce something totally new.
Just imagine what everything can be done with those "living selfish worlds"... :-) It is up to us that tune to "living selfish worlds" to accomplish them :-)!
Ciao Albertina http://www.lsi.usp.br/~lourenci
Best regards,
Stefan Urbanek
First they ignore you, then they laugh at you, then they fight you, then you win.
- Mahatma Gandhi
Yahoo! Groups Links
On Mar 5, 2004, at 1:06 PM, Jecel Assumpcao Jr wrote:
Note that there is nothing about the Self language itself that keeps us from creating a scripting version of it, just that only one person who has worked on Self so far has been interested in this (OpenSelf, but see my note at http://www.merlintec.com:8080/Self).
This link appears to be broken.
I think might really help in getting people to try and use Self if:
- when you download Self on OSX, it would be one file (a .app wrapper) and you could simply double click on it to start Self. (no messing with environment variables, etc.)
- there was a command line version that accepted script files and can be used for writing web scripts (yes, the web is a crummy UI - but it's useful)
- these features would be supported by the maintainers of Self directly, so users have confidence that they will continue to be supported
Just suggestions, -- Steve
self-interest@lists.selflanguage.org
-
Albertina Lourenci -
Brian T Rice -
Jecel Assumpcao Jr -
Randy Smith -
Stefan Urbanek -
Steve Dekorte -
Thorsten Dittmar