There is an intuitive sense that there is something wrong or missing about representing software as text.
But what is wrong with text? It is not that text lacks expressiveness: in fact it is perhaps, because of its abstractness, the most expressive kind of form we could choose. Natural language is text, and that is certainly richly expressive. But natural language is doing something very different, and that is what points at the problem.
It is not the ‘expressiveness’, it is what we do with/to software that counts. It is manipulating software as text that is problematic. Putting software in text leads us to type it and edit it, which is deeply wrong, or lacking. Software is a particular complex structure that needs to be manipulated in a particular complex way.
Should we have graphical/visual programming languages instead?
Text is a graphical format – one highly refined and compacted. It is a system of miniature glyphs, assembled in layers of structure: horizontally adjacent letters, wrapped lines, vertically adjacent paragraphs, etc. (Notably echoing DNA's levels of packing . . . ).
And simply as a 2D graphical object it is clearly very informationally dense. A diagram would have to be very detailed to compare.
It seems a good graphical code format would likely still be largely text anyway.
Code already does have particular medium-higher layer representational structures (somewhat equivalent to sentences, paragraphs, chapters), but there seems to be room for more expansive, free, spatial arrangement. How?
If you look at the discipline of graphic design, you see that a lot of it is actually text-focused or text-heavy. Signage, magazines, food packets, . . . and web pages.
Web pages would seem a rather good example of text-centric graphic design for software (well, assuming the design is good). They are mostly text, with minimal yet effective graphical support: structured, systematic, convention-using, e.g. Slashdot , Techmeme , BBC news .
Code should look something like web pages: code should look like the web.
But software should not just look like the web, it should be more like the web. What software looks like is there to serve what we do with it: the particular complex manipulations applied. And the web fits this in some basic way.
WWW/Rest defines only a minimal substrate of getting resources, that are assumed linked, in a universal space. Text is made into WWW by adding some metadata and universal naming/addressing; more fully, by:
This is a good reflection of software's fundamental structure: functions call each other, and so are linked resources; and when we make software we build on other already available pieces, ideally at a global scale.
So, from that – with the assumption of functions as the fundamental/primary unit of software:
Realising the outer part, the interface, is somewhat easy. We already have some IMT/MIME types defined, we just want more. Realising the inner part, the implementation, seems hard. Do we not need some way of marking up general algorithmic structure? No, we do not need to solve that problem here. Just label the function with the language/platform it was written for. Which gives:
The WWW is a way to make a globally connected info system (rather solidly well proven too). Software source-code is info we want globally connected. So a simple pragmatic strategy would be to apply the basic rules of the WWW to web-ify software. (It also seems sympathetic to content-centric networking ideas, since the WWW is quite intermediate between TCP/IP and CCNX . . .)