Live data from Hacker News

Always Bet on Text (2014)

graydon2.dreamwidth.org

341–349 of 349 posts

Re: Always Bet on Text (2014)

#341
post #6

Earlier quoted context omitted.

It's solid technology to be excited about. For example. Graphical programming languages are nowhere. Closest I had was either VHDL or backed by copious amounts of XML like Xtend. And both of those have a textual Component as well.

Text based programming is inherently 1d, so isn't well suited for the highly parallelised computing we have today. 2d programming would make much more sense. The issues with graphical languages arethings like being much harder diff/merge and version control generally, being dependent on IDEs, and severely limited by mouse usage. I don't see any of those issues as being impossible to overcome, but instead graphical pr…

This, exactly.

I think there are three reasons why non-textual programming is constricted to a few domains, and is not widespread as general-purpose:

- As you point out, all the tooling around programming like editors, exchange formats, version control, debuggers etc. are only available for text, rendering everything else generally unusable.

- There are many failed attempts, with many still being textual in the end, only with over-the-top syntax highlighting, such as Scratch. These attempts have paved the way of non-textual programming with gravestones, making the field look like a graveyard, so nobody wants to get into it anymore. Scratch might still have its place in education as an gentle introduction to the concepts of programming, but no software developer is seriously going to use it for any big project.

- People are used to text and they will reject other approaches instinctively. You can read many statements in this discussion here like: "Graphical programming would make your head explode", which I think is similar to how people where afraid of using trains in the early days: "Driving to fast will kill you" and "Nobody can survive such speeds". It might take a whole new generation of programmers to accept anything non-textual as intuitive (which is why it could become popular with artists and designers I think).

Re: Always Bet on Text (2014)

#342

It really depends on what you define as text. Does it involve special notations such as math? Can it involve diagrams? If all you mean is prose, as writing sentences in whatever native language you speak, then I must respectfully disagree with the OP. Yes, text is marvelous. I'm an author of multiple books and have a passion for the written word, but there are things for which there are better ways to convey informat…

Let me try. Text is anything human-readable which supports easy editing in WYSIWYG way. For example: XML, maybe JSON, non-obfuscated source code, LaTeX notation for math, vector images, chess notation, etc. Diagrams are not text but they are easy to be describen in plain English, much easier than memes or photos. Electric circuit is a beautiful example between text and non-text. You know EC is drawing but any EC is m…

Your definition appeals to tools and technological limitations, smalltalk had this notion that anything is editable, including the IDE itself and the (running!) programs. Your definition + a smalltalk IDE would imply that a running program is text. Furthermore, the abilities of the message reciever factor into this as well : web pages are editable, but somewhat non-trivially. So the combination of tooling and abilities could be used to argue that everything is text: for a graphics artist with even a paint instance running, a picture is the epitome of human readability and editabiliy, while chess sounds like a gibberish unicode file opened with a wrong encoding.

That doesn't mean your definition is useless, its an interesting take to draw the lines between media along editabiliy, but I wouldn't call that a definition of text. It would exclude and include all the wrong things.

One is really starting to believe Wittgenstein that all disagreements boil down to definitions.

Re: Always Bet on Text (2014)

#343
post #290

The author seems to be arguing that "most general" = "best" - because text is the most general communication format, it's the best. This argument is pretty trivially false. By this logic, the best programming language is assembly, because it's the most general. Actually, writing opcodes directly might be more general, in case your assembler doesn't have translations for some undocumented opcodes. The best editor woul…

Assembly language is not the most general because and particular assembly code can be run on only a few particular architectures. It's the higher-level languages that are more general.

Alright, I'll add a caveat: "assembly language is the most general for a particular architecture".

> It's the higher-level languages that are more general.

This is still false. Rust, for instance, is higher-level than C, while being less general - the borrow-checker constrains you from being able to do certain things. Haskell is even higher-level and even more restrictive.

The most general "programming language" is a Turing machine. Not coincidentally, it's also the least useful, and nobody programs in it.

This reinforces my point that "more general = more useful" is false.

Re: Always Bet on Text (2014)

#344

Earlier quoted context omitted.

It’s also in ascii, is that superior to all other character sets, or an accident of history?

> It’s also in ascii No it isn't: > 10:48:55.380 document.location.href > 10:48:55.384 " https://news.ycombinator.com/item?id=26166797 " > 10:48:57.723 document.characterSet > 10:48:57.726 "UTF-8"

If it was really Unicode I could use an eye roll emoji to reply with a succinct image, instead of all these words to describe my reaction.

Re: Always Bet on Text (2014)

#345
post #100
post #89

Earlier quoted context omitted.

I don't think people are afraid of moving forward. Plenty of alternatives have been proposed, and text remains as effective as ever. The problem with punch cards is that they weren't effective: they were what technology permitted back then. But technology permits many other things besides text nowadays, and text still remains an amazing and effective piece of "technology", in the broadest sense of the term. Are we co…

I don’t think hybrid or non-textual methods have really been given their due or worked on so much, simply because the only-text sentiment is so pervasive. I’m not proposing punch cards as effective. It was just a simple comparative example, which I thought was clear and that the rest of my post clarified what I actually meant. > Are we communicating, right now, via animation or fancy PowerPoint slides? It’s ironic yo…

> I don’t think hybrid or non-textual methods have really been given their due or worked on so much,

The problem is that they really have. Visual thinkers in academia have been aggressively pursuing this in CS PhDs and research since the 80s or even 70s.

The results haven't been great. Visual programming works well for some limited cases. Rational Rose, which produces code from UML diagrams, came out in 1994 and has been in continuous development since, has not taken over the world.

The big problem is high information density. With text you can go through it in a linear fashion, even if it's very long. Diagrams tend to hit a breaking point where they're too complex to take in. There's no clear place to start. Then suddenly they are worthless.

Re: Always Bet on Text (2014)

#347

The question is whether these advantages are because text is a better communication medium, or because of the limitations of our technology? Take using a computer to type a word versus draw a picture: Effectively everyone who uses a computer can type a word, but I'd bet less than 10% could draw a circle. But put a piece of paper in front of someone and effectively everyone can draw a circle. This points to there bein…

If someone can draw a circle on a piece of paper they can do it on a computer. The only difference is that we start you practicing doing it on paper in preschool.

Re: Always Bet on Text (2014)

#348

And somewhere in that discussion, I hear a faint echo of "org-mode" being whispered : ) Jokes aside, I often notice, how I am more productive, when relying on plain text, than relying on "enterprise" wiki systems, which make it impossible to export to any useful further processable format (looking at you, Confluence). One of my favorite features is, that it is easy to put text under version control, so that diffs hav…

Would you be willing to share what type of additional export formats you're looking for, and for what purposes?

Re: Always Bet on Text (2014)

#349

Earlier quoted context omitted.

> It’s also in ascii No it isn't: > 10:48:55.380 document.location.href > 10:48:55.384 " https://news.ycombinator.com/item?id=26166797 " > 10:48:57.723 document.characterSet > 10:48:57.726 "UTF-8"

If it was really Unicode I could use an eye roll emoji to reply with a succinct image, instead of all these words to describe my reaction.

That's HN filtering your input, nothing to do with the actual encoding.

Plenty of non-ASCII symbols show up perfectly fine. For example, '£'.

Post reply on HN