gistfile1.txt

I tried to write a bit about my short contacts with
Haskell and why I don't really like it, but that's
just going to attract an angry mob; besides, my
experiences are too brief to really build a
solid opinion I would be able to defend.

So instead I'll write a bit about why I think that
our problems go deeper than any text-based
programming language could solve.

This is my first attempt at formulating my
intuitions, so please bear with me. I _work_ a lot
with code, I don't write a lot about it.
My background is veteran C/C++/Python experience, 
and I mostly did entertainment/art oriented code: 
music DSP, graphics demos, games.

I'm more and more convinced that text-based
languages are generally bad at dealing with any
structure that has a higher dimensionality than 
the medium one is working in, and that tends to be
nearly every greater complex of problems one is
working on. 

This becomes even more apparent when working in 
a language where a huge part of the grammar consists
of describing graphs, that is, connecting vertices
using text symbols as endpoints and some sort of
an edge syntax (e.g. A <- B; B <- C; A <- C).

In an 1D medium such as text (A line-wrapped 1D
stream of characters), it is impossible to describe
an overlapping graph in such a way that each vertex
symbol is only mentioned once, and spatially next
to the vertices it is connected to.

By requiring to mention each vertex more than once,
and introducing a fundamental redundancy, the code
can become inconsistent through simple typing errors; 
Now, additional safeguards, like types, are
required to protect the intention of the program. 

To recap:

Because every character has a non-zero chance of
being mistyped (and that's just the lowest level of
making errors), more typing equals more mistakes,
which in turn requires more safeguarding.

Ironically, redundancy can be a good provider of
safeguards, and so more redundancy is introduced 
voluntarily into the language, which in turn,
again ironically, introduces more chances of
getting things wrong.

But didn't we want to do more with less?

My understanding is that I would like to get rid of
redundancy; because once it exists, it leads to
requiring more of it, in different shape or form;

I would also need to get rid of typing, because
clearly, it seems to be an inherently unsafe way
of entering information. Plaintext's enticing
quality is the ubiquitous support, that's why 
we keep using it. But will it remain the
universally best way to build programs forever?

Building graphs visually, in a true 2D 
environment, appears more promising; the program
maintains all tokens for us, typing is localized,
edges and dependencies are immediately visualized.

While nearly all problems that occur during working
with graphs can be covered by smart user interfaces
that introduce no additional redundancy, there
is at least one unsolvable problem with graphs in 2D
environments:

Graphs can easily become visually confusing as soon
as edges overlap; Fabian Giesen introduced me to the
Petersen Graph (http://en.wikipedia.org/wiki/Petersen_graph) 
as a particularly heinous example of a tangled
structure.

In short: it is impossible to ensure that any graph in 
2D is non-overlapping, and so spaghetti mess is
unavoidable.

I'm currently in the early beginnings of exploring 
graph editing in 3D, where edges never
intersect, and thus also the Petersen graph can
be visualized intersection-free.

With new depth-aware 3D visualizations such as the 
Oculus Rift, it might be possible to devise programming
interfaces that are easier to grok than any text-based
or 2D node based system. After all, 3D is what we work
with every day when we're not staring at a screen.


-- Leonard Ritter (@paniq)