text and gui (was: Kansas and Tcl)
Jecel Assumpcao Jr
jecel at merlintec.com
Sat Mar 13 00:38:56 UTC 2004
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 at 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
More information about the Self-interest
mailing list