Coding day in and out on LessWrong 2.0


Concepts in formal epistemology


My paper was signalling the whole time - Robin Hanson wins again

Mod note: Replaced the link to the image with the actual image, since I assigned substantial probability to that being your intention, but our editor image handling being too confusing and you giving up. But feel free to revert it if it was intentional.

Why isn't there a LessWrong App? Is a "blog-app" sustainable/useful for a community?

Ah, yeah. I agree that the popovers could use a lot of work on mobile. I was thinking you were referring to something else. In this case I agree with you and am reasonably annoyed at how we handle this myself.

Why isn't there a LessWrong App? Is a "blog-app" sustainable/useful for a community?

I agree with this hypothetically, but I actually think this matters a lot in practice. Browsers are actually just quite slow at doing a lot of things. As a concrete example, the Facebook web-app (which I use since I don't want Facebook installed on my phone) is many times slower than their native app, with scrolling often being visibly sluggish, and clicking on buttons having a visible delay. 

Of course it's possible that the app is just written less well, but given that the same is true for the Twitter web-app, and the apps of basically any major platform that I have used both as a native app and on the web (Pinterest, Messenger, Google Plus in the old days, Adobe Color, Google Docs), I think it's reasonable to conclude that native apps feel a lot snappier and are generally faster across the board, at least on my relatively weak phone CPU (My phone is about ~5 years old now, so it does tend to struggle with a reasonable number of websites). I think a substantial chunk of this is explained by the different languages, and another substantial chunk is probably the result of the different ecosystems, with the javascript ecosystem being generally not very performance friendly.

Again, I am not saying at all that it's impossible, or even that hard, to make a performant web-app for something in the reference class of LessWrong. I am just saying that if you build an app and don't make performance an explicit goal of your webapp, and don't put substantial effort and design attention into it, then the difference between a native app and a webapp will be quite substantial. Of course if you do put in that attention and thought you can make it snappy in javascript. As you say, fundamentally you are just putting text in boxes and the theoretical limit of performance is far far above what you need for an app like this.

Why isn't there a LessWrong App? Is a "blog-app" sustainable/useful for a community?

And overriden click behaviors

Huh, do you have any concrete examples of this? I think almost all of our buttons that could be links, are indeed links, and if you notice anything that is a weird javascript link that takes you to a different page but you can't open in a new tab, please let us know. I would consider that a straightforward bug, since I also hate links that I can't open in new tabs.

Why isn't there a LessWrong App? Is a "blog-app" sustainable/useful for a community?

Given that native mobile apps are often written in C, objective-C or C++, just on a simple language level you should expect something like 3-10x speedup from the switch from an interpreted language to a compiled language (sometimes more, sometimes less, depending on the application). In general interpreted languages continue to be substantially slower (and though interpreted languages have been getting faster due to smarter execution environments and lots of fancy tricks, so have compiled languages, due to improvements in compilers). 

The comparison is pretty similar to the python vs. C comparison, which I have a good amount of concrete experience with, since it's super common that if you write ML code, and want to optimize any specific part of it, you rewrite it in C or C++ and then call that C code from Python. Doing so usually gives you something like a 10x performance improvement, though it depends a bit on exactly what you are doing. I expect the difference between C++ and javascript to be similar. 

So yes, I do think that progressive web-apps running on javascript does mean they are fundamentally slower than native apps written in C, C++, or even Swift or Java. This doesn't mean it's impossible to write a performant progressive web-app, but it does likely mean that you have to put a lot more thought into optimization than you would if you were to write native code (also because the javascript ecosystem really isn't well-optimized for performance, and so it's really easy to build a non-performant app).

Why isn't there a LessWrong App? Is a "blog-app" sustainable/useful for a community?

This seems roughly right to me. We've tried reasonably hard (though we could definitely do better) to make the mobile version of the site work well enough to use it on phones, which I do think is important, but I don't feel like on the margin making a native app version is that valuable. In the long run I do hope that we can make LessWrong into a proper progressive web-app, which would allow users to read articles offline, access the site through their home-screen and generally treat it like an app (though performance wise it would be worse, since progressive web-apps run on Javasript and native apps get to be written in much faster languages).

There is also one additional consideration, which is that I am worried about making LessWrong the kind of thing that is primarily a phone app. I think by their nature phones are much worse for longform content, both reading and creating it, and I think a LessWrong that was predominantly used by people on their phones would be forced to have much shorter content, and correspondingly be a lot more like the rest of the internet in it's pressure to be short and snappy and as a result of that fail to be able to grapple with problems in any real depth. I would never write a full LessWrong post on my phone, and even notice that the comments that I write on my phone or Ipad tend to be lower quality, with fewer links to external resources, and less thought put into the formatting or content. It's also much harder to present a lot of information on a small phone screen, making certain types of intellectual labor quite difficult (as an example, if we were developing our tagging system primarily for a phone-driven audience, I think it would have to be quite a lot simple and lose a lot of functionality, or require a lot more design effort put into it, which then corresponds to us building fewer other things).

I do think it's likely that if things go well, we will eventually have an app, but these tradeoffs are why it hasn't been a priority till now, and probably won't be for a while longer.

Power as Easily Exploitable Opportunities

Seems plausible to me, though I am not sure whether I would say probable. If you could do something like backprop through the human mind, then I think I can imagine outcomes similar to this: 


Tagging Open Call / Discussion Thread

Yeah, ok. I do think personalization is blocked on Algolia, and I didn't really think about this as a potential solution to this (but it totally is). So yeah, maybe slighting Algolia was the right call.

Tagging Open Call / Discussion Thread

I am pretty confused what any of this has to do with Algolia. The primary problem to me appears to be that we don't actually have a large fraction of the tags categorized in the tag hierarchy displayed on the All Tags page. We could show you a copy of the tag page table, but that would omit a lot of new tags, and also probably not be dense enough. We could develop some custom UI for that menu to group them, but that's mostly a bunch of work (and doesn't have super much to do with Algolia). 

The site search will probably always have somewhat different constraints than normal database operations (in particular if we want to stay within the autocomplete paradigm), so I don't think anything about this would get easier if we switch away from Algolia (things like this are actually a domain where Algolia is pretty great). 

Are we in an AI overhang?

Out of curiosity, what was it that convinced you this isn't an infohazard-like risk?

Some mixture of: 

  • I think it's pretty valuable to have open conversation about being in an overhang, and I think on the margin it will make those worlds go better by improving coordination. My current sense is that the perspective presented in this post is reasonably frequent among people in ML, so that marginally reducing how many people believe this is not going to do much of a difference, but having good writeups that summarize the arguments seems like it has a better chance of creating some kind of common knowledge that allows people to coordinate better here.
  • This post more so than other posts in its reference class emphasizes a bunch of the safety concerns, whereas I expect the next post to replace it to not do that very much
  • Curation in particular mostly sends out the post to more people who are concerned with safety. This post found a lot of traction on HN and other places, so in some sense the cat is out of the bag and if it was harmful the curation decision won't change that very much, and it seems like it would unnecessarily hinder the people most concerned about safety if we don't curate it (since the considerations do also seem quite relevant to safety work).
Load More