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