Graydon Hoare

> Or do people use it for coding too?

Over time, you may discover one of the biggest truth about computing - the immense (and sadly disregarded) value of plain text¹. Code is nothing but structured text. The cardinal job of a programmer is text manipulation.

I'm reading this thread in my editor. Why? Because I'm dealing with text - browsers are great for presentation of text, not so nice for manipulating it. What kind of manipulations? Well, I can find, narrow, collapse/expand, translate, extract summaries for paragraphs, find all the URLs (including matching a pattern), etc. Good luck doing all that in the browser - even with the extensions.

Most developers don't even get annoyed by seemingly small things. Like how often do you need to bring the url of a given browser tab into your editor? Simplest thing, yet do it dozens of times a day and it gets vexing. For me - it takes milliseconds and a keypress - it even extracts the URL description and converts the link to markdown (if needed).

Or another example - whenever someone's screen sharing, or I'm watching a video and they show a piece of text (let's just for consistency say a url). How would you normally extract it? e.g, for your notes. For me - it takes selecting a region of screen and a keypress - my editor calls a CLI OCRing tool and voila. I don't really care that the source isn't "technically speaking" text - if I can read it, then computer for sure can "read" it too, am I right? That's text manipulation.

There…

>And some languages learned the right lessons from the coloring problem. For example, Go deliberately chose goroutines over async/await, accepting a heavier runtime in exchange for no function coloring at all. Java’s Project Loom (virtual threads in Java 21) made the same bet: lightweight threads that look and behave like regular threads, so no code needs to change color. The Loom team explicitly cited function coloring as a problem they wanted to avoid.

>Zig went further: it removed its compiler-level async/await entirely and rebuilt around an Io interface parameter that i/o operations accept. [...] Though some argue that the Io parameter itself is a form of coloring.

>Language designers who studied the async/await experience in other ecosystems concluded that the costs of function coloring outweigh the benefits and chose different paths.

Green threads with a heavier runtime isn't the "right" lesson. Instead, it's a fundamental tradeoff of no-function-colors-ergonomics vs maximum performance. Some simply don't want to pay the "performance tax" or "interoperability tax" to avoid function coloring.

The following is copy-paste of previous discussion links and added Wayback Machine links because lobste.rs is often down. Anyone who thinks Golang made the "right" decision should read why early Rust developers tried green threads and abandoned them. The revised conclusion is that Go's design is a tradeoff that works for their devs but not for Rust. The author of this…

Whenever I see things like this I tend to think back to this:

> Largely I think that text is already a highly-structured graphical notation, and that when people try to get "away" from it they're often doing so from a position of ignorance of how very long it took to get to where we are in textual notations, and how very many technical innovations are latent in textual notations. Visually unambiguous yet uniform symbol sets, combinatorial-positional word formation, linear spatio-temporal segregation, punctuation and structured page layout .. these are all technologies in writing that we had to laboriously invent, and they have purposes, advantages! Similarly in coding, we had to invent and adapt technologies from verbal and mathematical notations refined over millennia: lines and columns, indentation, block layout, juxtaposition and precedence, scope, evaluation order, comments, grammars, version control, diff and merge algorithms ... the pile of structuring technologies embedded in the textual representation of programs isn't free, and it isn't useless. So I'm just really cautious when people suggest throwing it all out for some hypothetical reinvention. You need those structures: so you've got an immediate problem of "what are you going to use instead", and a longer-term question of "what makes you think you're not going to wind up right back at the same place ten thousand years of refining graphemes-on-a-page wound up"?

(Taken from https://graydon2.dreamwidth.org)

I skimmed your blog post, and I'm not quite sure I understand how it will make editing easier. It seems more complex to me, although that might be because it's unfamiliar.

If you want some intelligent counterpoint, here is a post by the designer of Rust on why text is a good representation for programs:

Always Bet On Text https://graydon2.dreamwidth.org/193447.html

As someone who's working on a programming language, and has implemented a few DSLs and many parsers, I tend to agree with him.

Parsing is a pain in the ass, but I think it can made easier. The difference between text and structured data is "just" parsing, so I don't feel that switching to structured data can be a real paradigm shift. If there was a paradigm shift to be found, then it would have been implemented already by converting text to structured data, and operating on that data.

And this of course already happens in dozens of IDEs, and that's great, but it already happened. And while I have seen people be fantastically productive in IDEs, a lot of the best programmers I've seen also use emacs/vim.

But your ideas do seem more fleshed out than most, and I think that developing a prototype is the only way to make them more concrete, and more clearly see the benefits and costs. I do think there are benefits to making structured data the primary format -- I just think they are outweighed by the costs. Graydon's post outlined a bunch of things you lose if you abandon text.

> "Rust isn't designed for efficiency"

Citation needed, because Graydon Hoare the original Rust creator (who has not been involved with Rust development for quite a long time) wrote about how the Rust that exists is not like the original one he was designing:

- "Tail calls [..] I got argued into not having them because the project in general got argued into the position of "compete to win with C++ on performance" and so I wound up writing a sad post rejecting them which is one of the saddest things ever written on the subject. It remains true with Rust's priorities today"

- "Performance: A lot of people in the Rust community think "zero cost abstraction" is a core promise of the language. I would never have pitched this and still, personally, don't think it's good. It's a C++ idea and one that I think unnecessarily constrains the design space. I think most abstractions come with costs and tradeoffs, and I would have traded lots and lots of small constant performancee costs for simpler or more robust versions of many abstractions. The resulting language would have been slower. It would have stayed in the "compiled PLs with decent memory access patterns" niche of the PL shootout, but probably be at best somewhere in the band of the results holding Ada and Pascal."

https://graydon2.dreamwidth.org/307291.html

I still can't believe that there are people who actually think VR is going to be used by anyone besides people who play video games. I've used an Oculus, and I've used a Vive, and I've used a Google Cardboard, and I've tried all sorts of neat demos.

I fully believe a photorealistic experience can be had, and I fully believe that that experience will be able to exist at a reasonable price point, but I don't believe normal people will be interested in such an experience.

As a medium, it's not nice to use with other people, which is a huge part of the way we consume our media. I don't believe that normal people are going to ever socialize by looking at each others avatars. If you consider interacting with someone's avatar socializing, you should understand that is why people make jokes at the expense of World of Warcraft players. Once the novelty wears off, people aren't going to find it interesting.

It's not great for text either, and I don't think it will ever be better than a 4k monitor for text... Always bet on text. http://graydon2.dreamwidth.org/193447.html

I agree that AR could be huge. But VR gets way too much hype.