As should be obvious to my regular readers, I'm using the Axis of Eval to post raw thoughts. I don't do the work of rigorously thinking these thoughts through. I'm trying to narrate my mental work, in whatever state it is at the moment, with the hope to engage in dialogue with those of you with similar interests.
With this disclaimer out of the way, another take on the text/graphical axis.
In a comment on The Escape from the Tyranny of the Typewriter, John writes:
Okay, I'll play devil's advocate here. Text is the most articulate form of expression we have; it's so potent that even your graphical representation actually resorts to it. If you're going to introduce something else as well, that reduces simplicity, so there should be a very clear reason for it, and what you introduce should be in some sense manifestly The Right Thing.But the plain text we use with computers is hugely impoverished, compared to pre-computer texts. Compare to Dadaists' use of text (the art at beginning of text) or religious texts, which were widely "scribbled in the margins", and adorned with many graphical features.
Or take mathematical text: it has rich, mostly informal structure for conveying information:
This brings us to computers' favorite: a sequence of code-points. That is simply in no way adequate to represent the exploits of the past, not to speak of the future.
Modern mathematicians are shoehorned into writing their fomulas in LaTex and having them presented to them in ASCII art in their mathematical REPLs.
So let's turn the tables: Plain text is a particular special case of using a general purpose graphical display to display sequences of code points. Furthermore, plain text stored in a file is also just a special case of arbitrary information stored in a file.
9 comments:
Let me add another question, another small angle to inspect the matter. Leaving its weaknesses for a moment, text is obviously very successful and very good. But *why*?
Perhaps it would it be illuminating to discern *what* exactly is good about text, then do *more* of it, in some different way, or adapt it, or add that essence to non-text formats?
Is it the chunk-size -- everything is decomposed into 95 ascii chars/glyphs? Is it a kind of redundancy -- that could be automatically generated? . . .
Some really miscellaneous thoughts.
* Beware the use of colors; there's an awful lot of color-blindness out there.
* It's worth keeping in mind that the function of many of these old documents was to communicate thoughts and feelings to human readers. When you're trying to communicate something discrete and objective and unambiguous that's a somewhat different task.
* One of the blog-post topics I've got in my pile is to do with flowcharts. I know, second-hand, there were programmers who were most productive in the heyday of flowcharts, and never did as well after flowcharts were "officially" judged to be an evil associated with spaghetti code and the vile GOTO.
* Though I've got nothing in principle against squeezing every visualization advantage out of a 2D representation for superficial syntax (methinks 3D would require technology currently not readily enough available), I want it to be a representation of a data structure that is extremely simple from the computer's perspective. No, it doesn't have to be conses. (Does it seem that xonses are actually more text-oriented than conses?) I find it rather fascinating to try to envision what sort of very simple data structure would lend itself to, and really play to the strengths of, a 2D representation.
some random thought on the subject,
i think 2d objects in modern attempts at visual programming require too much effort to comprehend and interact with for the amount of meaning they provide. a big box with shadows and borders and all kinds of significance simply can't be "just" an if statement. what do i care what color or position is my if statement. etc. etc.
i think the examples of text/visuals interaction you provided were used in the early days of programming, but are totally ignored these days. They might be an interesting intermediate step. a mathematica sheet can be seen as an equivalent of an illuminated text, but clim presentation types take it even further. new iteration of that same idea is bret victor's magic ink. a mix of text and visuals with dynamic feedback between the two.
To put some of the rather strong pro-text statements in the comments under some different perspective: when my son was 6 we did a kind of an animation/wargame in Scratch starting from zero in about 2 hours. Designing the "sprites" took the main chunk of the time. And it was mainly him doing the "programming" while me I was his "compiler".
Today I did a procedural drawing (a "flower") in Snap in about 45min.
Sure, both Scratch and Snap (an evolution of Scrach) are both "domain specific languages" aimed at graphics/sprites. None the less, Snap has lists and Lambdas so... I am wondering how far I could get with it.
If I had to programm the same thing in "text" I don't even know where I'd start. I guess it'd take me a week starting from zero and then I'd have programmed myself into a hole and I'd never be as flexible going forward from there as when using Snap for the task.
Greets,
*t
I would like some visual presentation and manipulation of code. I think live programming would be greatly augmented by graphical programming. I also think it helps bridge the gap between programming languages and UI.
But I would also like a well-defined and human readable serialization for it. Here is how I have envisioned a path to graphical code:
(a) create a grammar for creating graphical programming grammars, i.e. with symbols describing shapes and colors and spatial relationships and connectivity.
(b) create problem-specific languages atop graphical grammars.
(c) create an IDE that can render and manipulate programs developed in any language built atop the graphical grammers.
Color blindness would be much less an issue if graphical programming is backed by text.
I may be wrong about this, but my understanding is that mathematics has unified geometry and algebra so that statements and proofs in one can be reformulated in the other.
Which suggests to me that there's nothing you can express diagrammatically that can't be equally well expressed in symbols.
So it then boils down to convenience for the writer and the reader. What's the best UI?
Hinting with colour may mean less typing, but if I have to take my hand off the keyboard to grab the mouse to pop-up a colour picker it sure ain't faster or more convenient than a few extra keystrokes which I've probably cognitively chunked as part of my program-typing skill.
Until now, given that every computer has been equipped with a typewriter-like input and a character displaying output (teletype or voice if not screen), then text has been the most conveniently general purpose representation.
We also have a very rich ecosystem of tools and techniques to work with it. Not just text editors or IDEs with syntax checking / colouring, autocomplete etc. But text search, grep, diff tools, patch management, distributed source control like Git. Macros, templates, text rewrite rules, regular expressions, code-generation, compilers. The Unix pipe to compose multiple textual tools together (which can be used in both composition and analysis of textually represented programs).
If you want to get away from text, you have to replace all of this. (I recently attributed the failure of Smalltalk to this issue http://thoughtstorms.info/view/smalltalkunix )
I guess it's possible that in the age of multitouch tablets we may start to develop some rich vocabularies of gestures that could represent programs, particularly data-flow programs or ones that represent networks of parallel processes, more conveniently and readably as diagrams than as text.
A good person to follow, if you aren't already, is Bret Victor of WorryDream ( http://worrydream.com/ ) who has some awesome demos, especially under his KillMath project.
Food for thought, on use of non-text for programs: "Sleeping Barber" in Humus.
I think you might like
this
Extending on my previous comment.
I am currently evaluating a CIP-Tool, which serves to model parallel state machines and their interactions. It's got a graphical and a structured representation and finaly a text-only XML representation that the user is not concerned with.
The tool is actually used in industrial production.
It's only concerned with the composition/interaction/communication part of the problem and leaves the implementation of functionality up to some other implementation language. Thus it's an orthogonal language.
It's quite nice to work with and the graphical representation of the interactions between components is a lot more "intuitive" to reason about and to manipulate compared to a text only representation.
Post a Comment