higher level languages

Gary McGovern zeppy at australia.edu
Mon Mar 8 15:31:28 UTC 2004


Dear Darius,
Thanks for your email and feedback. Some really interesting things there
but I cannot say I agree with all at the moment. But then I haven't really
researched and found facts.

Gestures are interesting, a couple of years I did a course assignment and
looked into brainwaves, (not quite thought recognition). There was some
interesting things being done a few ago. But a lot was hard to understand
because I'd only just started to study computers. 

Then for the huge screen, I like the idea of a stack of screens, or a
collection of screen stacks of different sizes. I still like to lie on the
floor with books and papers scattered in front of me, so I can see them all
(like I did when doing homework at school). I don't like to sit at a desk
and type.

Natural languages are interesting, but I imagine you would need the classes
to support it. Voice recog would be good, but I would not always like to do
it that way. I like to restore photos etc, everything is done with the
mouse, no typing unless you like hotkeys. I'm interested to see some
programming app like that. 

A problem with inheritance is the inheritance of bugs. I find it shocking
that something which worked ok two years ago, maybe now won't.(e.g. event
recorder morph worked in 2.7 didn't work in 3.0).

There is a few other interesting points you made that I'd like to look at
more.

I was looking at some IBM tv commercials on a dvd the other day, and they
claim the future is open. I'm glad they like the idea. Maybe they can put
their source code where their mouth is, and give us ViaVoice to port :)

What's the best research method in short ? The best I know is: form a
hypothesis then test it. Any feedback ? But how can that be if there is no
correct way to program, and programming is an art. I've read Alan Kay
comparing software engineering to making arches (buildings). But buildings
are static objects. Would it not be better to compare to something from the
industrial revolution, such as the spinning jenny, a machine with cogs and
wheels, automated processing and production. A computer is a multi-purpose
machine, the purpose changed only through the software in use. Or maybe he
means the fact that it was a great achievement to invent and make arches.

And maybe I've heard this argument lots. The best language for the purpose
!!!

Thanks,
Gary

>Gary McGovern asks: 
>
>> Can anyone say what the highest level languages will end up like? 
>
>Based on my psychology training and Jef Raskin's "The Humane Interface"
and 
>Charles Simonyi's "Intentional Programming", I have some suggestions which
might 
>indicate which direction programming environments very well might go. I
say 
>environments because I don't believe a text language alone can store,
transport, 
>and convey all the concepts that bug-free, efficient, robust, and easily 
>modifiable programming applications require. This path of discovery /will/

>require some imagination on your part. 
>___
>
>First, imagine you have lost the use of your figures. Therefore, you must
input 
>your programming by voice only. 
>
>Why? Those who have a handicap often must focus on what are their most
important 
>needs and the most efficient way to meet those needs in any given
situation. Now 
>list what problems you think you'll encounter and create some ideas how to
get 
>around them. Carefully note how you'll need the computer to respond and 
>represent the programming logic and data. I have my own list that I will
share 
>later. 
>
>For the "real thing", I am not saying we will or should program by voice
or even 
>by natural language. This is just an exercise to illustrate how to focus
on what 
>is important and that there may be mechanisms in natural languages that we
may 
>not yet be taking advantage of in programming languages. 
>___
>
>Imagine that you can still gesture with you hand (or hands, really) and
the 
>system will know exactly what you are pointing at. 
>
>For the "real thing", you might be using two mice at the same time 
>___
>
>Now imagine you have a 72" monitor to display your programming environment
and 
>programming logic. It will probably need to curve around you in this
imaginary 
>work environment. 
>
>Why? Most of the standards and styles for navigation in the application
user 
>interfaces, the programming user interfaces, as well as the programming
language 
>syntax are a byproduct of having to reveal and re-hide, collapse, and 
>symbolically represent information that cannot be seen. By making most
data and 
>functions visible and available all at the same time will eliminate most
of the 
>time consuming steps for navigation and the arbitrary symbols that consume
so 
>much time in explanation and education and which are so easily forgotten.
For 
>example, why do icons now have text below them or text pops up when you
hover 
>over them? A large display allows proximity and mapped location to convey 
>additional meaning and provide additional visual clues and memory aids
that are 
>lost when everything is collapsed. 
>
>For the "real thing", I am not saying we will have such large, expensive,
and 
>natural resource consuming displays. Head mounted, "augmented reality"
displays 
>will adequately simulate such a display. Such a "personal" display will
make the 
>programmer more "mobile" and programming more of a "social" activity
allowing 
>the programmer to spend more time with other developers and end users.
This 
>technology will also allow end users to be more actively involved in the 
>creative process of application development (per Simonyi). Nor am I saying

>nothing can be hidden or that no visual clues added to focus our
attention, just 
>that the more there is at our finger tips, the less time spent searching
and 
>learning. 
>___
>
>Here is a brief summary of other important points required for future 
>programming environments:
>(I will post more details on my Squeak People diary. 
>http://people.squeakfoundation.org/person/Socinian/  )
>o Multiple views of the code, all dynamic and interactive 
>o The importance of lists 
>o Syntax as a grid (rather than a tile) 
>o Explicitly representing all concepts 
>o Powerful, context sensitive searching, filtering/collapsing, and 
>      Why? Too may classes, methods and ambiguous names to be humanly
remembered 
>o "Auto-complete" for data entry
>      Why? Too may classes, methods and ambiguous names to be humanly
remembered 
>o Human memory as a limited, but powerful natural resource 
>o Programming environments and applications environments will both be
equally 
>powerful environments for creativity and perhaps even be the same
environment 
>(better than Squeak & Morphic) 
>o Reference rather than copy/paste 
>___
>
>More time will be spent describing the domain and the range of the problem
and 
>why it is important than time spent on describing /how/ to solve the
problem. It 
>is the description/representation of the problem domain and the 
>description/representation of desired effects) which are most reusable and

>should be separated from the "how" logic. This is required for just the
same 
>reasons that the display logic should be separated from the application
logic 
>and both of those separated from the persistence logic and the transport 
>protocol logic.
>
>Cheers,
>Socinian
>






More information about the Squeak-dev mailing list