Wednesday, 31 October 2012

Learning languages online with gamification

Gamification—the use of game-like mechanics to motivate non-game activities—is a bit of craze at the moment. There is all manner of websites popping up to help you solve all of your problems. Whether or not they'll work remains to be seen, but for now, I've been experimenting with two that help you to learn (or, rather, consolidate learning of) languages. I'll save comment for later on whether or not gamification works, or even should or can work. Here, I'm just summarizing tools I've been trying, but if you've found others, let me know in the comments.


The idea behind Duolingo is to teach by immersion. This is achieved by forcing you to do a lot of translating and occasionally teaching you new vocabulary. It currently offers to teach English-speakers French, German or Spanish. 

You gain points by completing lessons that involving translating to and from the objective language, or by translating sentences from online content. This content translation is how Duolingo claims to remain free, but I'm not really sure who would be paying for such content. I could imagine a mass-translation of, say, Wikipedia articles by Wikimedia, but not by many others that wouldn't do it in house anyway.

From my experience so far, Duolingo is okay as long as you're building on existing knowledge of a language. In particular, it doesn't seem to be much use for learning the grammar of a language. You pretty much have to infer that for yourself. But if you've previously learned the language and just  lack vocabulary and some idiomatic expressions, Duolingo is probably a reasonably good way to stay in practice.


Memrise helps you remember any list of associated things by forcing you to recall them at increasing intervals. This is one area where I also found Duolingo a bit lacking, so it makes for a pretty good complement. I think it limits itself to testing you on 50 items at any one time, which is long but not too long. Possible its biggest downside is its lame metaphor about watering plants and moving them from the greenhouse to the garden...

So far, I've only used one of the officially-endorsed vocabulary lists but there's an enormous number of community-supplied courses, too, including a few grammar courses. I'll let you know how these pan out. For vocab lists, it seems pretty good so far.

Monday, 22 October 2012

Best Practices for Scientific Computing

I recently learned of an article that appeared in the Computer Science section of the arXiv entitled Best Practices for Scientific Computing. It's a sound list of software engineering practices and philosophies that lead to code that is generally easier to understand, operate and maintain. It also links to plenty of resources to help implement these practices.

While understanding, operation and maintenance might not sound like interesting objectives for lonely coders rushing to a minimal result-producing code, remember that your program carries more value (and potentially citations!) if other people are able to use, modify and extend it. Also, don't forget that you need to write code that your future self can understand...

I recommend a quick read of the six-page article, but I've listed here the section titles and emphasized directives.
  1. Write programs for people, not computers.
    1. A program should not require its readers to hold more than a handful of facts in memory at once.
    2. Names should be consistent, distinctive, and meaningful.
    3. Code style and formatting should be consistent.
    4. All aspects of software development should be broken down into tasks roughly an hour long.
  2. Automate repetitive tasks.
    1. Rely on the computer to repeat tasks.
    2. Save recent commands in a file for re-use.
    3. Use a build tool to automate scientific workflows.
  3. Use the computer to record history.
    1. Software tools should be used to track computational work automatically.
  4. Make incremental changes.
    1. Work in small steps with frequent feedback and course correction.
  5. Use version control.
    1. Use a version control system.
    2. Everything that has been created manually should be put in version control.
  6. Don’t repeat yourself (or others).
    1. Every piece of data must have a single authoritative representation in the system.
    2. Code should be modularized rather than copied and pasted.
    3. Re-use code instead of rewriting it.
  7. Plan for mistakes.
    1. Defensive programming: programers should add assertions to programs to check their operation.
    2. Use an off-the-shelf unit testing library.
    3. Turn bugs into test cases.
  8. Optimize software only after it works correctly.
    1. Use a profiler to identify bottlenecks.
    2. Write code in the highest-level language possible.
  9. Document the design and purpose of code rather than its mechanics.
    1. Document interfaces and reasons, not implementations.
    2. Refactor code instead of explaining how it works.
    3. Embed the documentation for a piece of software in that software.
  10. Conduct code reviews.
    1. Use code review and pair programming when bringing someone new up to speed and when tackling particularly tricky design, coding, and debugging problems.
    2. Use an issue tracking tool.
The bigger problem is motivating scientists to spend the time to adopt these practices. But arguing for why they are helpful to code writers is a good place to start.