text and gui (was: Kansas and Tcl)

[Jecel Assumpcao Jr]

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