Hacker News Reader

Comment by the_af | Hacker News Reader

Everytime someone proposes a non-textual representation of code I cringe.

There's a reason no one single alternative has triumphed over text. And many have been proposed!

Standards are hard. Proprietary tools lock you in. Text is universal (OK, restricted to plain ASCII, which is a big deal but has already happened). You can open and modify a text file with whatever editor of your choice, the simplest possible editing tool. Some weirdos (joking) even print source code.

That reading, not modifying, is the primary operation to be done on source code is an unchangeable fact of life. You won't be able to change anything without inspecting it first, and no representation is going to save you from that -- and it's undesirable to wish for this, in fact.

View on HN

>Standards are hard. Proprietary tools lock you in. Text is universal (OK, restricted to plain ASCII, which is a big deal but has already happened). You can open and modify a text file with whatever editor of your choice, the simplest possible editing tool. Some weirdos (joking) even print source code.

Ideas are impossible to specify precisely, which is why we use words, with all their myriad definitions. However, if you apply enough computing power, you can autoencode your way to a compact expression of ideas as a 384 dimensional vector (like Word2Vec), that is non-standard, but exact for that particular model, with those particular weights. You can then repeat the process in multiple languages, and with parallel texts, language translation becomes something that can be automated.

The abstract syntax tree doesn't have to be something that can be shared to be a very powerful tool. It certainly doesn't have to be standardized. Just as there's no rational choices made in the 384 dimensions generated by word2vec, there doesn't have to be anything other than a binary format the tool can load and save, in order to work.

If you can ingest multiple languages, and regenerate them as output, translation between programming languages becomes almost trivial.

Thanks for your reply!

I'm not sure if this is what you're saying, but I think the AST is not meant for "human" consumption (so it'd be outside the scope of this debate, I think), but also, translations that result in alternative and radically different representations between what you see and what I see can be problematic.

"I don't understand your program, it's hard to follow."

"What do you mean? The yellow and black colors alternate quite nicely."

"Colors? What do you mean? I only see triangles arranged in a jarring manner, and they are hard to navigate."

"Navigate? Everything fits in a single board of yellow and black colors, no need to navigate anything."

Etc.

>I'm not sure if this is what you're saying, but I think the AST is not meant for "human" consumption, but also, translations that result in alternative and radically different representations between what you see and what I see can be problematic.

File systems aren't meant for human consumption either, they're a practical solution to the need to store various bits of data on a disk in a coherent manner. We've made tools for representing the inodes and other structures in human readable form. We also represent them visually.

We can do the same for the AST. It doesn't have to be a dump of the structure, a tool just has to present a view that is close enough for our brains to impedance match, and we're off to the races.

Isn't a text file representation -- what you and I see when we open a text editor -- already an abstraction for human consumption? They are not filesystem-level storage.

You can view an AST, but this is never going to supplant a textual representation of code as a lingua franca between you and me. A tool that represents ASTs is always going to be a boundary between you and me (and also, a more complex tool than a simple text editor).

Actually, I think we have already moved away from pure text a long time ago. Think about it this way:

If "text" (so only the sequence of tokens) was the valuable representation, then we would all program without any formating (no additional spaces and linebreaks).

Now, you might say well formating is important for readability. These spaces and line breaks do matter. But, just adding them randomly where they are syntactically allowed is not helpful either. There is some very specific structure to formating: The AST.

So, in other words we usually structure short snippets of text sequences in a graphical layout by ASCII-arting the structure into it. And, even with that, many people would complain about the missing syntax highlighting, another meta property that pure text does not have ...

Anyway, I think you are right about almost all tooling being build for text, so we are kind of stuck with it ("unchangeable fact of life"). However, that does not mean that it is the ultimate representation.

E.g. there is still one industrial nation stuck using the imperial system, and that is certainly not because it is more practical than the metric system. It is just that the infrastructure, tooling and culture has internalized it.

Thanks for the thoughtful reply.

I think what you call formatting is an essential part of textual representation (alas! It's also the most contentious part). After all, formatting is an essential part of how we write and read novels, articles, etc.

In this sense, I think text with formatting is pure text... for human consumption.

I am arguing it is the ultimate representation: for historical reasons, of course, but also because there is less friction with tooling, less vendor lock in, fewer standards that must be developed and adopted universally, etc.

I actually started writing a blog post along this theme but never got very far with it.

I'm not against code storage and representation as text per-se, merely that typing/editing it (text) is a not particularly efficient way of thinking about code.

A lot of people I'd characterise as 'words-per-minute is everything' style thinking are seeking the most efficient way to convert thoughts into text input. From punch-tape to mechanical keyboards the ultimate goal of programming language development is a 'faster keyboard'.

I think this focus on text input as foundational is incorrect. Most text isn't meaningful, the subset of meaningful text is severely constrained by the execution environment of the text. Outside of variable names and naming functions text input just isn't that interesting or important. For example unless you have previously declared one, invoking a function named `ttoString` isn't useful.

This is why I think coding outside some form of IDE (how far along that spectrum is up for debate, but I'd say autocomplete at minimum) is somewhat inefficient. Code is text, but it's also a layer on top of the text, the set of possibilities defined both by the text and the compiler/interpreter (or more specifically as you mention in your comment, AST). Treating code as text where you might rename a function with find-and-replace is frankly, daft and backwards. Your tools should rename the concept/symbol/whatever you're targetting specifically and they should understand your intent and meaning. By focusing monomaniacally on text we're ending up with worse tools.

This also scales to text input more generally. For some reason spell-checking doesn't work for me in Firefox so I'll have no doubt made a bunch of spelling mistakes in this post and it feels a considerably worse way of typing. I don't particularly value the ability to write "ocurence" since it's incorrect. I'd rather have tools that assist me communicating efficiently in a manner understoof (sic) by others. Text is fine but tools are great.

This develops into a more general objection to languages like Python/Ruby/JS but that's a whole other flamewar.

To be clear: I don't think about text and text input in terms of efficiency. Well, that too -- almost every other form of input feels clumsier to me, but that may be because I'm more used to text. But I think typing efficiency is a red herring, a fetish of hackers who also worry about mechanical keyboards and keyboard layouts and "you cannot code unless you use three 4K monitors at a minimum". That's a fetish -- time with code is spent thinking about it, not typing words or even clicking with the mouse. Still, many here will fight to the death to claim these are very important things, even crucial; and I'll politely disagree.

I think text reigns supreme because it's more universal, less convoluted, and has zero vendor lock-in. If you want, the tools to read and edit source code come with your operating system!

There have been tons of musings, thoughts and even projects to replace text representation of code. Where is their widespread success?

I think text is the ultimate "worse is better", in the positive sense of that concept.

Thanks for the response. I think we probably ultimately agree. I was taking aim at that second group you outline with my rant.

I had always assumed punch-tape was encoding some other representation of code than text until I did the research for my blog post. I think text is here to stay and I don't have any real problems with that. Where my tools offer designers or visual editors for code/UIs I still prefer to use text.

As an on-ramp to programming nothing quite beat opening up an HTML file in Notepad (or text editor of choice), making some changes and seeing that your header now flashed and was red.

I do think however that much like digging on a beach with a plastic bucket and spade is fun when you are young and carefree; when you're being paid to dig holes you want the biggest shiniest JCB you can get.

I am mainly reacting to the second group who curl their lips with disdain at the idea of doing anything other than coding in Nano or whatever pure text environment. They seem to see programming as a priestly sect dedicated to text like Lindisfarne's monks and people who don't know their Cherry Reds from Browns as fake/noob/impostor programmers.

But how do we know which part of our preference for the querty keyboard is it's efficiency and which part is not wanting to learn?

If I think of non textual rep I'm getting a picture of someone trying to strike a pinata with a blind fold on where the someone is me.

Good question!

I think there's always going to be friction for old programmers used to their ways, but why then aren't new programmers more successful with their piñata alternatives to text? ;)

Alternatives have been proposed and they haven't caught on so far (for general usage, I'm not talking about specialized applications where they make sense).

Standard boomer rant.

> There's a reason why the status quo exists

Yes, it's called the status quo.

> text is universal

Which one, ASCII, code page 9000, or UTF-8? Are you saying just restrict to ASCII? Then we need custom solutions every time someone wants to talk a different language.

> lock in

I am locked into using retarded insecure terminal emulators because all my tools depend on it to render what you people call "text" which is supposdedely "simple" or "universal". Even vim breaks from unicode already. The primitive language of the OS should not be some poorly defined idea of "text", but algebraic data types.

> reading important

Which is better done by graphics that text. Just the fact that with a structural editor - an if statement spans the amount it appears to span, instead of having to trust someone to format it correctly - is already enough reason to ditch text.

> Standard boomer rant.

Please stay polite. I'm not a boomer and my comment wasn't a rant.

> Yes, it's called the status quo.

I didn't mention the "status quo", please don't misquote me in order to make a clever retort.

> Which one, ASCII [...]

I preemptively mentioned which one, which defuses the rest of your sentence. More importantly, you know which one I meant. And I know you know, so please, let's not argue this.

> I am locked into using retarded insecure terminal emulators [...] Even vim breaks from unicode already

None of this has much to do with what I wrote. Again, I must ask you to stay polite and on topic. If you dislike your tools, use better ones.

> The primitive language of the OS should not be some poorly defined idea of "text", but algebraic data types.

This discussion is about representations meant to be universally understandable by programmers, i.e. humans, not by the OS.

> [reading] is better done by graphics that text

Reading is mostly done using a special kind of "graphics" called "text". People with disabilities or who are busy doing something else, like driving a car, choose alternatives; but let's be honest, most people read text.

Reply on news.ycombinator.com