joesavage

Glad you found it interesting! Personally, I get a lot of interesting information around these kinds of topics from Twitter. In addition to @maxkriegers, the author of that comic, I think you might find some value in checking out users like @andy_matuschak, @rsnous, @geoffreylitt, @yoshiki, and @elzr, as well as the broader communities that surround them.

Oops, quite right. I’ll try and push up a correction later today. Thanks!

I have aphantasia and love the analogy to hashing. It matches my experience quite closely in as much as I can't really imagine faces in the abstract, but can verify a match in the real world with ease. Reminds me of NP-hard problems in that respect – verification is easy, calculation is hard.

With respect to not being able to imagine music though, I don't think the two are necessarily linked. I most definitely get earworms, and as a guitarist rely heavily on my "mind's ear".

Sorry about this! It was a stock copyright clause provided by my university. I’ll look into getting it removed, and in the mean time am perfectly happy for you to use the work (with proper attribution) as you see fit.

EDIT: The problematic clause in question has now been removed.

To be clear, I’m familiar with the semantic Web and did a reasonable chunk of reading about it when doing this research, but view it as only tangentially related to the ideas I talk about here. If you’re looking for citations around this work, check the full dissertation — there are plenty.

That's a good point, and not one that I've considered particularly deeply to be honest. (I'd love to hear other people's point of view on the topic!) I guess in many ways the situation is similar to that around adblock. Ultimately, the links that are overlaid on a particular page should be solely and completely under the control of the user. If the technology that everyone is using permits this kind of behaviour, I'm not sure companies have much choice in the matter.

I largely agree. I'm very much coming at this from the angle of 'knowledge work', and think a system of this kind is most useful to (though definitely not only useful to!) scientists, engineers, designers, lawyers, journalists, etc. While the population of knowledge workers is admittedly much smaller than the population on the whole, though, it's still sizable. Knowledge workers play an incredibly important role in our society, and anything that can amplify their intellectual capabilities is well worthwhile in my view.

Author here. It’s definitely true that extending existing browsers is the fastest route to this kind of behaviour (though it’s not clear to me if it’s the best route). In fact, if you squint a bit (or maybe a lot), it could be argued that with application-specific URL schemes we kind-of sort-of already have the primitives we need to make something like this work.

Practically, though, if you want the multi-program side of this (which is kind of orthogonal to the 'multiple perspectives on how things are connected' side), then to make this kind of multi-window hypermedia system usable I think you need to have deep integration with the window manager. While Chrome OS tries to achieve this kind of integration by making the browser the OS, I propose that the best way forward here is to effectively make the OS the browser, as I discuss in the article. (Of course I’m not talking about the kernel when I say ‘OS’ here, but the desktop environment). At that point, I’d say the browser is different enough to the browsers of today that the description of ‘freeing the Web from the browser’ is still accurate.

As far as I’m aware SMT in Arm cores is pretty uncommon actually.

> First, compilers are really quite good. Yes, it's possible to beat them (I do) but generally not by much.

Genuine question: what would you quantify “not by much” as here? In my experience, it's not uncommon to see 2x+ speedups from well-written software pipelined hand-optimised assembly in hot loops. (Especially so for in-order processors, like you might see in embedded applications or as a LITTLE core in your smartphone.)

I completely appreciate that “writing hardware” is a totally different problem to writing software, and that hardware comes with its own set of quirks and challenges. I'm just saying that I don't think the CPU is fundamentally different than other abstractions in the stack.

C obviously isn't a good fit for a hardware language — it's designed for software! That doesn't mean that there doesn't exist similarly abstract ways of writing hardware though (that express the inherent parallelism, etc.). It is likely that these “higher level languages for hardware” would result in less efficient hardware solutions, but that's always a trade-off that is made through abstractions. Writing a program in properly scheduled assembly code is going to be a lot more efficient than writing the same program in C.

The difference with hardware in terms of language abstractions is not that it behaves differently to software. We could easily define a programming language that expresses parallelism in a way that would map nicely to hardware. The problem, from my perspective at least (please correct me if you think I'm wrong) is that hardware needs to be extremely efficient — particularly because it cannot be easily changed. As a result, hardware languages don't tend to be particularly abstract. But this doesn't mean that hardware languages couldn't be more abstract!