Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

Jacob Sparre Andersen wrote:
> Michael R wrote:
> 
>> There's a note in November's Communications of the ACM titled "Sir,
>> Please Step Away from the ASR-33!" with the sub-title "To move forward
>> with programming languages we must first break free from the tyranny
>> of ASCII".
>>
>> It's interesting that Ada has already stepped away from ASCII. Many of
>> the test cases for my ZanyBlue.Text localization support library
>> contain non-ASCII source, e.g., a test enumeration with identifiers
>> containing Greek characters:
> 
> This is definitely a small step in the right direction.  But I don't
> think it is anywhere as far at Poul-Henning Kamp would like it to go.  I
> have the impression that as long as our source files are only defined as
> a sequence of characters, we aren't there yet.  I'm a bit scared by the
> thought of a source code being defined both at the file level (for
> compatibility) and as a 2D (3D?) visual structure (for editing and
> inspection).

Such mixed 2D+text codes are already a reality for many programmers who 
use box-and-arrow diagrams with tools like LabView, Simulink, or any of 
the UML-based tools, combined with application-specific function-boxes 
written in some traditional textual language. These programmers may not 
even glance at the 1D-text source-code that the tools generate from the 
diagrams, much less attempt to understand the structure of this code. 
They are satisfied that the final program does what the diagrams show. 
And why not? Few programmers inspect the assembly-language form of their 
C or Ada programs.

For an amusing idea of 2D programming, see the "funge" languages in 
http://en.wikipedia.org/wiki/Esoteric_programming_language: "A funge is 
an esoteric programming language which models its programs as metric 
spaces with coordinate systems (often, but not necessarily, Cartesian) 
and which execute instructions located at points in their program space 
by moving an instruction pointer (a position vector which indicates the 
currently executing instruction) through that space. Different 
instructions determine the direction in which the instruction pointer 
moves, and consequently, the sequence of instructions that is executed."

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .