Exceptional coding style

[H. S. Teoh]

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!