I've never understood why we still look at the plain text representation of code, and not a visualization of the code that makes more sense.

Note that, in my mind, this visualization is not automatically generated, but lovingly created by humans who wish their code to be understood by others. It is not separate from the code, as typical design documentation is, but an integral part of it, stored in metadata. Consider it an extension of variable and function naming.

There is of course "literate programming" [1], but somehow (improvements of) that never took off in larger systems.

[1] https://en.wikipedia.org/wiki/Literate_programming

▲ AdieuToLogic 4 days ago | parent | next [-]

> I've never understood why we still look at the plain text representation of code, and not a visualization of the code that makes more sense.

My guess is it is the same reason why the most common form of creating source code is typing and not other readily available mechanisms:

  Semantic density

Graphical visualizations are approachable representations and very useful for introductory, infrequent, and/or summary needs. However, they become cumbersome when either a well-defined repetitive workflow is used or usage variations are not known a priori.

An example of both are the emacs and vi editors. The vast majority of supported commands are at most a few keystrokes and any programming language source code can be manipulated by them.

▲ jraph 4 days ago | parent | prev | next [-]

> I've never understood why we still look at the plain text representation of code, and not a visualization of the code that makes more sense.

I suppose this is because nobody has been able to create good tooling for it (the visualization itself, the efficient editing, etc). You'll have to deal with the text version of it at some point if not all tools that we rely on get a version for the new visualization.

Another hypothesis is that it might not matter this much that we work with text directly after all.

> Note that, in my mind, this visualization is not automatically generated, but lovingly created by humans who wish their code to be understood by others.

If you allow manual crafting there, I suspect you'll need some sort of linting too.

▲

seer 4 days ago | parent [-]

Um isn't that what Lisp and its children / siblings have been all about. I've written a bit of Closure it has a very clear idea that code is data and data is code. Your code is trivially serializable in your mind and by various tools, and because it is lisp - it all kinda makes sense.

I really wish we lived in a universe where a lisp became the lengua franca of the world instead of javascript, as almost happened with Netscape, but alas ...

	▲	jraph 4 days ago \| parent [-]
		The "code is data" aspect of lisp seems orthogonal to how code is still written as text, and btw lisp is still written using text. You still need to indent all these parentheses. Virtually all programming languages are parsed into ASTs, and these ASTs can be serialized back. This is what formatters/"prettifiers" usually do. Did I miss something?

▲ rerdavies 4 days ago | parent | prev [-]

    We must include the standard I/O definitions, since we want to
    send formatted output to stdout and stderr.
    <<Header files to include>>=
    #include <stdio.h>
    @

Not hard to see why nobody really embraced it. And not helped buy the fact that it was published right around the time that best practice was switching toward "don't comment unless absolutely necessary".