I discovered a significant error in the simulations I ran in the previous post. So I'd like to present the corrected simulations, and also explain more deeply the assumptions and known weaknesses even in these fixed simulations. I also made the charts easier to use. However, I won't re-explain the background, so please see the previous post for that.

Summary for those who don't want to read the whole thing: Using an interval modifier near 140% is probably a reasonable default for language learning with Anki.

Read more...

UPDATE: I found a major problem with the below simulations, which I have fixed in a follow up post. Please DO NOT use the graphs or settings advice below. Instead see the follow up post.

(If you're already familiar with all this background and just want to see the results, skip down to the Results section.)

Something I haven't talked about on this blog yet is that I'm learning Japanese.

One of the tools that many people use to aid in learning a new language is an application called Anki. It's a flashcard application with automated review scheduling based on spaced repetition. You can make flash cards in Anki for just about anything, but in the context of language learning it's really useful for moving vocabulary, grammar, etc. into your long-term memory. As I understand it, it shouldn't be your primary study method, but it can accelerate your language learning when used as a supplement to e.g. immersion/input-based approaches.

One of the resources I've found useful in figuring out how to even approach learning Japanese has been the YouTube channel Matt vs Japan, and he recently posted a video suggesting a different approach to configuring Anki's spaced repetition settings.

Read more...

Bryan Lunduke posted a video earlier this year entitled "Divisive Politics are destroying Open Source". I only just now came across it, and it sparked both thoughts and feelings for me. My thoughts are not, I think, terribly complex, but I would nevertheless like to take a moment to write them out. In particular, as an avid Rust programmer, I'd like to give my perspective on the Rust community, since Bryan briefly touched on that.

Read more...

My first post in four years! And, interestingly, on a similar topic as my last post.

Zed, the editor I raved about in my last post, is now essentially abandoned and unmaintained by its author. This is understandable given the direction his career has taken, but is also a bit unfortunate given its innovative approach to editing.

I've since been bouncing around using some other editors, including Atom, VS Code, and most recently Sublime Text 3. In all three cases I've configured them to function as similarly to Zed as possible, but it's never been quite right. Under the hood, all three editors still assume an "open dirty buffer" model of document management, and this leaks out from time to time.

Despite the shortcomings, I've been mostly okay with this state of affairs. But there are nevertheless some things that annoy me:

1. Both Atom and VS Code are built on top of web technology. I don't like my editors taking up hundreds of megabytes of RAM with only a couple of text files open. That's just silly. And in Atom's case, it has chuggy performance to boot.
2. Sublime Text isn't open source. I don't mind paying for software (and happily did in Sublime Text's case), but I always feel nervous about committing my workflow to software that doesn't belong to a larger community.

Because of these annoyances, a few years ago I developed an interest in writing my own editor. This sounds completely silly, and it pretty much is. Nevertheless, the journey of creating my own editor has been really interesting, and I've learned a lot of cool things.

Read more...

I like to write code. And like many such people, I am constantly in search of the perfect code editor. Of course, such a tool does not actually exist. But nevertheless, from time to time I like to try new editors that seem to present something new and interesting, to see if I can improve my code editing experience.

Most recently, over the last year or so, I've been playing with editors built on top of web technology. Specifically, I've been playing with Light Table, Brackets, Atom, and Zed.

I started off with Light Table—which is a really cool and innovative project, and I certainly recommend checking it out—but I pretty quickly migrated to Brackets (which is a bit more conventional) for most of my coding.

Brackets is a really cool editor, with an obvious focus on UX concerns. The editor itself looks beautiful, and I appreciated how it eschewed tabs in favor of a simple vertical list of open documents. Despite Brackets being targeted at web development, I primarily used it for C++ coding. And it worked wonderfully. The only real complaints I had about it at the time were that its scrolling and editing were a bit laggy, and it didn't support split views. (Incidentally, it now supports split view.)

Read more...