On Wed, Jan 16, 2013 at 03:54:17AM +0100, Rob T wrote: [...] > I was just a while ago thinking that a reason why text based > programming has been so predominant may be that the ability to > transmit and discuss programming problems are much easier to do when > the program is represented in written form. > > The minute you move to what could be a much more efficient and > effective method of programing, you suddenly lose the ability to > easily transmit the source code to other people. For example, it is > very easy to post code samples in this forum for discussion, but if > we represented programs in graphical form, we would have to upload > images instead which not quite as easy to do.
I invented a 4-dimensional esolang once, that represented program code as tiles in an N*N*N*N tesseract. It was ultimately represented in text, but you couldn't effectively program directly in a text editor because it was a pain to keep things aligned properly, and non-trivial programs wouldn't fit on your screen. For coding, I wrote a 4D tile editor. :-P Extreme example, granted. But you could include snippets of code in, say, email, and the recipient could paste it into the 4D editor for viewing, editing, etc.. > Another issue at hand, is when collaborating over the wire with Git > and other revision control systems, none of them operate effectively > when using encoding methods that are not text based. Revision control > systems just don't work well with binary files. That's not quite true, you know. Binary diffing has been around for a long time now. But I suppose you could say that there is currently no effective, generic way to display binary diffs in an understandable way. But then, I believe git has diff plugins that one could write custom diff displayers for, so this is merely a small impediment, not a fundamental one. > Having said this, there may still be better ways of representing > programs that do not lose the advantages of text based programming, > but what those methods look like is not so obvious. [...] Whatever structures said methods may use, can ultimately be reduced to some kind of linear representation, which in turn can be reduced to some text representation. I mean, no matter what you do, it will ultimately have to be stored as a sequence of binary bytes. And programmers like getting to the bottom of things, so directly manipulating a text representation is the most obvious approach. Now, granted, just because something can be represented as text doesn't mean a text editor is the best tool for manipulating it (XML comes to mind ;-)). One could imagine programming by visually manipulating graphs, for example. Or take music composition as a kind of analogous process: while you can certainly use a text editor to edit, say, a Lilypond file and spell out notes and stuff directly, most people would prefer a graphical interface where you can manipulate the musical notation directly instead. Trying to write highly-polyphonic music interspersed with chords in plain text format is possible, but extremely painful and tedious, whereas writing it out in musical notation is almost trivially straightforward. I've no idea what the programming analogue of musical notation would be, though. (Please don't say APL. ;-P) T -- Ignorance is bliss... but only until you suffer the consequences!
