Ask HN: Why is programming editing text?

I find it interesting (and somewhat unexpected) that even digital hardware, while consisting of discrete elements, blocks, etc. that can be easily visualized, is still "defined" using pure-text "hardware definition languages."

Whatever you say must needs be parsed. And humans can parse the curly-brace style about as easily as any other semantic representation.

The advantage is transparency. I'm actually not sure if the tradeoff is worth it, if symbolic code manipulation would be better, but code as we've written it is no harder for humans to parse than would be a symbolic representation of the same. It already is a symbolic representation of itself, because humans don't see curly brace, double quote, key; humans see things in groups and clumps. Just as when you read these words I'm typing you don't see period, double space, J, u; you see 'clumps. Just'. However, what you see on your screen is exactly the file that's stored on the disc, the bytestream read by your texteditor, the bytestream read by your compiler. And that's worth something.

Because you would have to have dozens of such operations, at which point you have to filter through them, at which point it’s faster to just type what you want to do.

Seriously, the best thing I ever did was learn to type 140 wpm.

Especially with regard to intentions and interpretations, this immediately draws a parallel in my mind to movies versus books. Movies can definitely have impactful illustrative power, but it's almost a given that the book will have been better. I think the reasons that this is the case are probably the same reasons why code is expressed better through written language than other mediums.

I see what you mean, but I think that we are both correct - I agree entirely that stories in pictures can give both a deeper or quicker understanding of most topics - the issue is that they cannot clarify or directly state something. The best works of art are open to many interpretations - or we would never re-read imaginative literature, re-visit galleries we had been to previously, and so on.

On the other hand, for an instruction manual, there is little room for interpretation as the words only have so many definitions (though read "Authority and American Usage" by DFW to really open a can of worms), so we do not often re-read a manual for a process we know (though it could be argued we ought to). I also concede that for simple tasks entirely visual instruction manuals suffice, and to that end I will say that I've enjoyed writing simple things with Scratch (for example), but I would hesitate to write a program that needed to be maintained with a visual language.

To put a more fine point on it: For the top 1% of programmers it may be the case that they would work best in a visual language, but the maintenance and support of those applications by the bottom 99% would erase many of the gains (I am here assuming programming as a professional activity in support of an organization's goals, not, as it were, a strictly artistic personal activity). In a professional context - I am unfeeling about what my predecessors felt about any part of the code, I only need to know what their intentions were, and I need them to tell me so, as explicitly as possible.

*Edit: I think that there may be use in clarifying whether we are discussing professional programming or programming as a hobby - because I enjoy both, and while I enjoy learning and using some languages (cough Haskell, Lisp) for myself, I would be very hesitant to use them professionally due to the difficulty others have in maintaining/understanding them. (Food for thought: why do Java, Javascript, and Python absolutely dominate our field despite having "better" alternatives?)