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.
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.
Abuse of this sort of functionality is definitely something I've thought about, but discussions around these sorts of ecosystem issues weren't my focus in this work. Ultimately, there are solutions. For starters, you almost certainly don't want every link or comment from any user to show up automatically for everyone the instant it is made. There's a fantastic comment by user 'enkiv2' over on lobste.rs about this (relating to design decisions around Xanadu) that also roughly reflects the kinds of assumptions that I've been making in my prototyping about how this might work in practice: https://lobste.rs/s/p0sgoj/freeing_web_from_browser#c_vivphl
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.
> 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!
Perhaps I'm reading too far into what you wrote, but I'm not sure I agree that the CPU is fundamentally different from other layers of abstraction in computer systems.
All abstractions “lie” in the sense that they present a perspective of the world that is slightly different to the reality — function calls “lie” about the operations that are really being performed, the ISA “lies” about the electronics of the CPU, and transistors “lie” about the underlying behaviour of the universe.
Around two years ago now I created a League of Legends champion information/countering website: https://www.championcounter.com/
Growth was slow but steady, and the site now receives ~1.4M pageviews per month. The money to keep things up and running comes through banner ads - it's not a huge amount (have only started hitting just about $1000/mo in recent months, and don't know how long that'll last for), but it's still a nice revenue stream to have.
Switching over to HTTPS in and of itself shouldn't stop much data leakage given that the hostname - at least at current - isn't difficult to obtain (and really gives the game away for the content you're visiting as far as my site is concerned), but I suppose it's a step in the right direction and will stop primitive tracking attempts.
Protecting against code injection is actually a fair point though.
I run a site that provides counter information for League of Legends (http://www.championcounter.com/) and I doubt very much my users will benefit at all from me moving over to HTTPS.