Python for Computer Vision

This is a quick installation guide that will show you how to set up a programming environment for writing computer vision algorithms in Python. You'll install Python, an IDE, and some supporting libraries. This guide is mostly cross-platform, with some emphasis on OS X.

You will need:

  • Python 3.x (3.3 at time of writing)1
  • Python libraries for common vision & scientific computing tasks
  • OpenCV (optional)
  • Eclipse with PyDev (optional but recommended)

Here are the Python libraries that you will use:

  • Python Imaging Library (PIL)
  • NumPy
  • matplotlib

And here are a couple additional ones which are optional, but you'll probably find them useful sooner or later:

  • SciPy
  • scikit-image
  • ipython

To install them you will use pip and virtualenv.2

Python and Assorted Libraries

You likely already have Python on your computer. But if you are on a Mac, I recommend for you to use Homebrew to manage your Python installations.

If you don't already have pip, install it now (if you're using Homebrew, this should already have been done for you):

If you don't already have virtualenv, install it now:

You could at this point try installing your Python packages, but you may have some missing dependencies.

On OS X, I needed to perform the following installations first (note that freetype may already exist somewhere, but needs to be symlinked to the correct location):3

On Linux, I needed to perform the following installations first (note that there are alternative choices for all of these dependencies; you just need some version of BLAS and LAPACK and a Fortran compiler):

Now you should be ready to install your cool Python tools!

Linux users: You may be able to skip part of the following step, because the major packages are often shipped with Linux distributions. It can't hurt to install the latest version, but you don't need to if you don't want to. Find out what's already installed with pip list. Find out if newer versions are available with pip list --outdated.

That's it! You're all ready to go with your next-generation Python algorithms for computer vision! If you additionally want to install OpenCV, see my separate post about that. If you don't yet have a Python development environment, do read my post on PyDev and virtualenv.

  1. I'm using Python 3 here. If you know anything about Python, you'll have heard how much confusion there is around Python 2 vs. Python 3. You can also use Python 2, but the entire NumPy/SciPy ecosystem has supported Python 3 for a couple years now, so you should be safe to prefer 3. Homebrew manages 2 and 3 as completely separate packages. You can have both simultaneously installed on your Mac, and 'python' will always refer to Python 2, while 'python3' will always refer to Python 3. The only hitch is you will have to remember to specify python3 for your virtualenv, and use pip3 to install global libraries for Python 3. If you don't understand what that means, just forget I even said it; I've written my instructions to do things the Python 3 way.
  2. If you need an introduction to Python's packaging system, see this page. TL;DR: pip lets you install packages (Python libraries). Usually, you do not want to install packages globally, for the entire system, because they may conflict with each other. Instead, you want each Python project you create to have its own isolated ecosystem. Virtualenv provides this isolation. Virtualenvwrapper makes virtualenv nicer to use.
  3. I'm not sure why Freetype is in a different location on OS X than on Linux, but I guess this is the location that Xcode decided upon and Homebrew follows suit. So we just create a quick symlink and hopefully never have to worry about it again.
  4. While writing this post I discovered a new package for the Python Imaging Library. It seems that support for PIL is waning, and is not available via pip by default. It might someday regain favor, but I find Pillow to be better supported at the moment.

Why PhD?

This is a repost of my answer to the Quora question: What are some strong motivations for earning a PhD?

You want to earn a PhD because...

  • You want to surround yourself with the best, brightest, and most motivated people on Earth, and in so doing, push yourself to become one of them.
  • You want to get paid to (mostly) have free reign to explore your own ideas, to fail without consequences, or to try something that doesn't have to work—as long as it expands human knowledge.
  • This video looks like heaven to you: rocks, bands, logic (2012)
  • You relish being able to say "I just got home from the lab" instead of "I just got home from the office".
  • You want your life to be science fiction.
  • You want to live on the very precipice of human knowledge, and witness new discoveries firsthand, years before the general public catches wind of it.
  • You've looked everywhere and you just can't find the stimulating intellectual atmosphere like that of a university. Your coworkers just don't seem to think about or care about the same things as you.
  • No matter what high-tech goliath or trendy startup or progressive non-profit you work for, it's just not fulfilling. It appears to you that fulfilling industry jobs do exist, but they almost all require a PhD and involve at least part-time research.
  • You constantly challenge and push yourself. You relish being around people who do the same.
  • You want to continue growing and learning at a breakneck pace. (It is possible to do this in the workplace, but far from automatic. Being in school forces you to grow due to the incredibly steep learning curve. See here about the importance of maintaining a steep learning curve: Edmond Lau's answer to Career Advice: How do you know when it's time to leave your current company and move on?)
  • You tried briefly to follow research on your own, but it's just too hard to navigate. You need someone to guide you into the field. You need a set of strong mentors to teach you how to read a paper and how to identify the important results in the field (be it science, history, philosophy... even literature).
  • You want to work at pretty much the only place outside the army that will demand everything you can give and force you to "Be all you can be".
  • You want to own all of your work. You decide what you're going to work on and whether to give it away for free or start a company out of it. Unlike the army, you're not a cog in someone else's machine here.
  • You want a job that will have you (1) travel all over the world and (2) meet people who are the best in the world at what they do.
  • You want to be part of a global community (science transcends borders; same for other scholarly disciplines).
  • You want a job that will train you in (or force you to learn) all kinds of invaluable life skills: technical writing and communication, delivering presentations and speeches, teaching and mentoring, etc. (It's pretty hard to get such a wide range of leadership skills in any other entry-level job!)
  • You want your contribution to the world to be in the form of knowledge. In their careers, most people render a product or service to the world. Your job is to render knowledge, and publications are the medium.
  • And of course, you want a job where you can answer questions on Quora instead of working for a day. ;-)

This might be a slightly romanticized version, but you asked for some strong reasons, and these mostly hold true. They may not all apply to you, but the biggest advantage of a PhD is the flexibility. It really is what you make it out to be; you can become more involved and practice more leadership skills, or you can put your head down and bury yourself in your research. You choose how often you skip out on work and go to the beach. You decide who to collaborate with, and when to go on vacation.

Whichever combination of these reasons appeals to you, they should obey this one overriding rule: You do a PhD for the experience of doing a PhD. You don't do a PhD for the job that comes afterward. Some people go on into very lucrative jobs, some start companies out of their PhD, and some struggle with low wage for the rest of their lives. Whatever comes after the PhD, is whatever comes after the PhD. You do the degree for the degree itself.

People often ask me what I want out of my PhD, what my end goal is, why am I doing it, what job title am I looking for? Well, of course I have some ideas about that—too many ideas, in fact—but for now, for right now, the answer to their question is actually: I want the job title of PhD Candidate. Seriously. There is nothing better I can imagine doing with my life right now than being paid to dig deep, being paid to learn, to take classes, to take on outlandish projects, to soak up knowledge like a sponge. I have to live on a very meagre salary and work very hard, but in return I get this incredible job with flexible hours and amazing colleagues from all over the world. If I'm lucky, I'll get to continue doing that after I'm done, and I'll work in a place with the same invigorating environment and the same clever, diverse, interesting colleagues. I can only hope.

Disclaimer: I'm currently only in the first year of my Masters, but already grad school has been the most rewarding and transforming experience of my entire life, and I don't expect it to change anytime soon.

A Taxonomy of Toolchains

I recently came back to C++ development for the first time in 7–8 years; in many ways, for the first time ever. What follows is something I wrote when I finally began to understand the development workflow for C++. I hope it will help other students and newcomers to C++ pick out their preferred toolchain for comfortable and productive development.

What is a Toolchain?

There are two major uses of the word toolchain. Its use in reference to C/C++ typically signifies a collection of tools used to build a program; a chain of transformations which takes the C++ source code to binary machine opcodes (you thought that this was what a compiler does, but in fact the compiler is only one piece of this process). More generally, the term is also used to refer to the set of software tools and utilities a programmer chooses to assist them in development. Here, we will refer to this broader category as one's development environment. So when I say toolchain, I mean the choice of compiler and build tools, which is a subset of your development environment.

When you begin C++ development, you're thrown into the deep end. You need to choose what tools you're going to use for development, before you even know what the tools are used for. This choice is strongly affected by which operating system you use, which operating system you want your program to run on, whether you choose up-front setup cost in return for easier development, and other deeply personal preferences. The goal of this tutorial is to give you the background you need to choose wisely, plus some sensible recommendations to get you started.

A toolchain, then, is a chain of tools: the major components of a toolchain are builder, compiler, linker, and debugger. This is how they work together:


To make this example concrete, here are the GNU equivalents of the above components:

Builder make
Compiler g++
Linker ld
Debugger gdb

The GNU toolchain is generally the de facto option for C++ development on any operating system and any processor. It's generally a good recommendation for anything you need to accomplish. When in doubt, use GNU.

What is a Development Environment?

As I'm referring to it, a development environment is nothing other than your tool belt as a programmer. It is the entire corpus of software utilities you use to get stuff done. Primarily what we'll focus on in this tutorial are text editors, compiler toolchains, build tools, and debuggers. Often these are all wrapped up in a single package, called the Integrated Development Environment (IDE).


There are two main choices when it comes to development environment. From what I've seen, seasoned software practitioners in industry are pretty equally split between these options. I think either of them would be a great choice for a newcomer. They are:

  • An integrated development environment.
  • Emacs or Vim, combined with make or CMake, plus a debugger.1

I hope to educate you in the various nuances of these choices, and give you just enough information to start your own quest for your C++ holy grail. Here is the sequence of tasks I put before you:

  1. Determine what OS you'll be doing development on (your host machine).
  2. Determine what OS(es) you'd like your program to run on (your target machine).
  3. Pick a text editor (for the host machine) (ideally works on the target as well).
  4. Pick a compiler (for the target machine).
  5. Pick a build management tool (for the target machine).
  6. Pick a debugger (for the target machine).

It's often the case that you're concerned with supporting only one OS, and you don't need to worry about the difference between host machine and target machine. But sometimes, you'll want to support all the major operating systems, right? You want the whole world to adopt your program! This can become difficult with a language that compiles to machine code, like C++. You'll need to make sure to pick a set of build tools that works on all platforms. This usually boils down to the GNU toolchain.2

Notes on Text Editor Choice

Your text editor is your main weapon in the mean streets of programmerdom. In many ways it will define your style, your strengths, and your weaknesses. Will you become a master of the timeless emacs-fu? Will you artfully slice and dice a bit of source code with sublime text kendo? Or will you employ the secrets of IntelliJitsu to amaze your friends and confound your enemies? An editor is not the full martial art—it's only a weapon—but it will do much to influence your style. Just as Bruce Lee rejected studying a single martial art in favor of borrowing techniques from all over, you should eventually try a few of these tools.3

My advice is to try a couple different ones in the next few weeks, then commit to one for the next year or so. If you continue down the path of software development, you will inevitably master many of these tools, so don't worry about making the perfect choice.4

As stated above, your main choice is to decide between a full-blown IDE on the one hand, or a text editor + build tool + debugger combo on the other. We can safely assume you'll use make + gdb as your build tool + debugger, so the only real choice is this: IDE or text editor? The main trade-off here is setup time vs. feature richness.

An IDE will ultimately allow you to be more productive, but involves an initial setup cost in terms of configuring the project.5 If you can get past that point, you have access to a world of features that are not afforded to text editors, or can only be had through a hodgepodge of plugins. These features include indexing, autocompletion, refactorings, in-editor documentation, code templates, and more. An IDE does more than simply unite the basic pieces of a development environment—it adds many utilities on top of that.

A text editor is easier to get started with, especially if you are working on someone else's project. In this case you don't have the pain of figuring out how to get your IDE to build their project; you just use whatever build process they used. However, there are some text editors which are not so easy to get started with, yet are more powerful, so I should make some further distinctions.

There are two types of text editor. One is a graphical editor like GEdit, Notepad++, or Sublime Text. The other is a command-line editor like Emacs or Vim. Most graphical editors don't bring the amazing range of functionality that an IDE provides. So these are the easiest to learn, but also the most limited. They are generally not used by folks in industry.[citation needed] In contrast, the CLI editors can be as feature-rich as an IDE. But it takes a long time and a lot of customization to make them that way. This is both good and bad. Many people get off on this.6 An IDE is ultimately easier to master than one of these editors, but once again, involves more initial setup time.

The CLI editors have one major advantage that should not be missed: they are already installed on pretty much every Unix/Linux distribution you'll ever use. Whether you need to ssh into a Linux server to edit some config files for a website, or you need to telnet into a robot to edit its source code, being proficient with one of these editors is a huge boon to your programming life. Even if you use an IDE for most programming tasks, you will probably need to use one of the CLI editors eventually.

Bottom Line: Whichever way you choose, the main point to remember is that IDEs will require more babysitting, but give you more bang for your buck. They are likely to be more difficult in the outset, but much easier after the initial setup.7

Notes on Compiler Choice

Just like choosing a debugger (below), you'll either use the default supplied by your IDE, or you'll use the GNU toolchain. GNU provides gcc for C development and g++ for C++ development. At the end of the day, g++ is just a wrapper around gcc.

There is also a relatively new toolchain (new as in 2003) called LLVM. The compiler for LLVM is called Clang, and is rapidly gaining popularity (in fact, clang has replaced g++ on OS X). Clang gives nicer error output and may actually be very helpful for a beginner. As far as I know, it accepts most of the same options as g++ so you can start using it as a drop-in replacement. You might want to check it out.

Bottom Line: Use g++ (or whatever your IDE provides).

Notes on Build Management Choice

Here are your choices when it comes to build management:

  • IDE builder
  • CMake
  • Autotools
  • Make
  • your own blood, sweat, tears, etc.

One of the biggest advantages an IDE typically brings is automated build management. Without an IDE, you need to compile your code yourself, with handwritten calls to a compiler. The good folks at GNU have come up with a terrible, barely-working solution to this problem. Instead of tediously writing compiler commands yourself, you tediously write them into a Makefile. That way, at least you only have to do it once. But you do still have to do it yourself. And you need to change it every time you add a new source file. And it often varies from machine to machine.

The state of affairs in C++ build management is so bad that there is yet another tool that runs on top of make, called Autotools, that attempts to make the process bearable. In my opinion, it doesn't really achieve this goal. Here's how it works. You write files and files for automake. automake generates the files needed for autoconf, which generates the makefiles you need, which are used by make to generate compiler commands, which is what you actually wanted in the first place.

There is another build manager which does somewhat better, called CMake. It directly generates makefiles, and has very nice formatted output, though it is still rather difficult to use.8 When you start a larger project, you may want to check it out. For now, you can leave it.

Bottom Line: Choose an IDE or lightweight makefiles ... for now. Oh, and here's another diagram:


C++ build management: infinite recursion

Notes on Debugger Choice

The debugger situation can get a bit confusing, because there's many debugger front ends but few actual debuggers. There's essentially only three debuggers out there, and they are:

  • GDB (GNU toolchain)
  • LLDB (LLVM toolchain)
  • CDB (Windows toolchain)

It can also be confusing because each C++ toolchain provides its own debugger. So do you have to use the debugger that matches your compiler? As it turns out, no. Debuggers are completely compiler-agnostic; they depend on the binary format, which is determined by the OS. For example, all compilers that work on Unix produce binaries in the same format, the ELF format, and most of them provide debugging flags in the same format, the DWARF format (you can tell these things were invented by a bunch of geeks). All Unix debuggers know how to interpret these formats. So nothing prevents you from compiling with g++ and debugging with lldb, or compiling with clang and debugging with gdb.9

If you use an IDE, the choice of debugger is already made. The IDE serves as a GUI for one of the above debuggers. Otherwise, you'll generally choose GDB, or a GUI front-end for GDB (GNU wins again). It's been around for a long time and has wide support. LLDB is a new, improved choice which is almost ready for adoption, but it doesn't yet have any GUIs that support it. Still, if you plan to work command-line-only and GUI-free, you may want to give it a look.

Bottom Line: Use what your IDE provides, or use GDB.

Summing It Up

It's my recommendation that you try Emacs, Vim, or an IDE. Any one of these will be a valuable part of your toolbelt in a career in software engineering, and even in further computer science courses. Still, it can be a lot to learn a whole new toolset all at once, while at the same time learning a new language. You may want to find a powerful text editor with a more gradual learning curve, so that's okay too. I won't make any specific recommendations here (although I did in the footnotes). You can find many opinions online about which text editors are most popular.

In terms of a builder, you should probably use Make for now. There are other options to look into when your projects become bigger.

In terms of everything else, either use your IDE's default toolchain, or use the GNU toolchain. But look out in the near future for the LLVM toolchain; I think its tipping point is upon us.

All the best on your quest, and Happy Coding!

  1. You could replace the use of "Emacs or Vim" here with any text editor of your choosing. Sooner or later, I think you will have to learn one of the choices I've given (Emacs, Vim, or IDE). Your choice, then, is whether you want that to be "sooner" or "later."
  2. At the very least, it means you need to be careful not to use any platform-specific libraries in your source code. Other times, you'll only have one target machine but it will be different from your host machine, because the target is a robot, or an airplane, or a DVR. You can't exactly do development on those machines; you need to cross-compile from host to target. As a beginner, you don't need to worry about these more complex setups too much—but now that I've mentioned them, hopefully they won't confuse you if you see them mentioned on a website somewhere.
  3. That advice applies tenfold to programming languages.
  4. I myself hold black belts in both Eclipse and IntelliJ, and something like a blue belt in Vim and Sublime Text.
  5. If you are creating a project from scratch, then using the IDE's "hello world" template will avoid most of this pain and have you started very quickly. Trying to build some existing source code can be trickier.
  6. See also: yak shaving.
  7. Let me reemphasize my opinion that you should jump right in and use Emacs, Vim, or an IDE. I think you will end up learning these at some point before you graduate. Still, learning a whole new development environment while also learning a new programming language is daunting. If it's too much right now, may I recommend you try Sublime Text. At the time of writing, it's pretty new to the scene, yet already a favorite among those in the know.
  8. Believe it or not, I actually use CMake to generate my Eclipse project files, and then I use Eclipse for development. And I'm not alone. I gather that most people in the robotics industry use this toolchain. Just goes to show how messed up C++ development is.
  9. Supposedly. Theoretically. In an ideal world.

Installing GDB on OS X Mavericks

If you prefer watching videos to reading articles, Cody Henrichsen has created a video walkthrough of this procedure.

With its new OS release, Apple has discontinued the use of GDB in OS X. Since 2005 Apple has steadily been moving away from the GNU toolchain in favor of LLVM. This means that Xcode now uses LLDB instead.

LLDB looks to be a very nice replacement for GDB, and I hope to use it in the future, but currently Xcode is the only graphical front-end that supports its use; pretty much every other debugging GUI uses GDB under the hood, including Eclipse. So, if you want to debug C/C++ code in Eclipse CDT on the Mac, you must install GDB.1

Here is the procedure that worked for me.2 Others have reported issues with this, so please do let me know in the comments if it doesn't work for you.

Known Issues

GDB will not be able to breakpoint inside any template function, though it should be able to step into it. This problem may be resolved if you use the MacPorts installation procedure (below) but it may only work if you also compile with Apple's GCC.

It was also reported in the comments that it cannot breakpoint into a shared library function. I have not confirmed this issue myself.

On OS X Yosemite, the MacPorts version will require some extra hoops to jump through. See below.

Installing GDB

You can install via MacPorts or Homebrew. MacPorts has Apple's official GDB distribution, which is modified for OS X. This is probably the best option (thanks to CC's comment for this tip). However, on my machine this only seems to work if the program is compiled using Apple's GCC, which is no longer supported by Apple. All things being equal, I vastly prefer to avoid MacPorts altogether. So I installed with Homebrew, despite recommending MacPorts. If you have no preference either way, go with MacPorts.

Update for Yosemite users: I haven't upgraded to Yosemite yet, but some folks have reported problems in the comments below (and for some, it worked fine). It seems that Apple's GDB (the MacPorts install) is currently broken on Yosemite. If you know what you're doing, you can apply the Portfile patch from this ticket. It seems like a bit of a pain, though, so you might switch to plain vanilla GDB, which can be installed with either MacPorts or Homebrew.

Install with MacPorts

  1. Install Xcode and MacPorts, if not already installed.
  2. Now install the Apple GCC and GDB from MacPorts:
  3. For the remainder of the tutorial, use /opt/local/bin/gdb-apple as the GDB executable
  4. Remember if you want breakpoints in template functions to work, you'll need to change your compiler to g++-apple-4.2 instead of g++! This can be done in your Makefiles or in your IDE settings.

Install with Homebrew

  1. Install Xcode and Homebrew, if not already installed.
  2. Now install GDB from Homebrew:
  3. For the remainder of the tutorial, use /usr/local/bin/gdb as the GDB executable

If that worked, then lucky you! Getting it compiled is where many people seem to have trouble. Now you just need to sign it to give it permission to control OS X processes.

Certifying GDB

Open up the Keychain Access application (/Applications/Utilities/Keychain Navigate via the menu to Keychain Access > Certificate Assistant > Create Certificate...


Enter a name for the certificate. For this how-to, I'll call it "gdb-cert". Set the fields exactly as shown below.


The maximum validity period is 999 days. I don't really want to deal with this again, so I'm going to max it out.


Keep clicking the "Continue" button until you are asked for a location. Set it to "System".3




Now make sure the cert is always trusted. Right-click the new certificate and select Get Info. Under the Trust section, set Code Signing to Always Trust.



Now that we have a certificate, we need to use it to sign GDB. First, we'll restart the taskgated process to make sure it picks up the new certificate. Quit Keychain Access (you must quit Keychain Access!) and return to the Terminal for these final commands.

Find the taskgated process.

The first number in the above output is the PID. Use this to kill the process (it will immediately restart itself).

Now you can finally code sign GDB.

Now you should be all set! The OS X Keychain may ask for your password the first time you attempt to debug a program, but it should work!

Getting it to Work with Eclipse

There's one more step for Eclipse users. You need to specify where Eclipse can find the new GDB. Specify the path to GDB in Preferences > C/C++ > Debug > GDB:


If you already have some debug configurations, you may need to edit them individually to point to the correct place (under Run > Debug Configurations...):


  1. The CDT developers are planning to support LLDB, but they will have to write a whole new interface, and I think most of them only work on Eclipse in their spare time, so it will likely be at least some months before LLDB support is there.
  2. The procedure is derived from this StackOverflow post and this GDB Wiki page.
  3. If you are unable to save it to the System keychain, then save it to the login keychain. You can later export the cert, and then import it into the System keychain. I didn't have to do this, so comment if you have any problem.

Freedom's Just Another Word for Nothing Left to Work For

Try this idea on for size.

Just as the atom bomb [was] supposed to render war obsolete, the Internet seems like capitalism’s ultimate feat of self-destructive genius, an economic doomsday device rendering it impossible for anyone to ever make a profit off anything again.

—Tim Kreider in Slaves of the Internet, Unite!

In a world with Groupon hemorrhaging millions of dollars a year and Facebook reaching a market cap of $104 billion while making under 0.2% that amount each year, this is all too easy to believe. It seems like the profit models of most major tech companies involve living off research grants and investor funds. Facebook exists simply because the public values it enough to keep it afloat. In a world of BitTorrent, open source, freeware, ad-funded, and "freemium" revenue models, it really is starting to look like the beginning of the end of capitalism.

But is this really all that bad? Is capitalism the only working model? Here's another great excerpt from the same piece:

“Let us not kid ourselves,” Professor Vladimir Nabokov reminds us. “Let us remember that literature is of no practical value whatsoever. ... ” But practical value isn’t the only kind of value. Ours is a mixed economy, with the gift economy of the arts existing (if not exactly flourishing) within the inhospitable conditions of a market economy, like the fragile black market in human decency that keeps civilization going despite the pitiless dictates of self-interest.1

As I sit here sharing my own free, unsolicited2 opinions with the world, I'm prompted to think of the implications of recession and academic inflation in my own industry. Interestingly, this is even a problem in the research sciences, with today's glut of PhDs. The blog linked there hints at my own opinion: students and other hopefuls cannot stand up for themselves. Employers must refuse to let people work for free. It hurts the whole economy, and it is not the way forward.

Just the other day I was talking to a friend about the possibility of entering a post-scarcity economy in the next few decades. Sometimes the dearth of jobs and the neverending recession make me think that post-scarcity might almost be upon us. After all, we are becoming ever more efficient with food production.3 There is already enough food produced each year to feed everyone in the world (and there has been since 2002). What's the problem with not everyone having a job, as long as we can continue to feed them?

More and more tasks are becoming automated, putting humans out of menial jobs. This creates more demand for jobs that cannot be automated because they depend on human creativity, such as the jobs in art and writing that are now struggling for pay. It also creates more demand for jobs that require true human intelligence, which involves more than basic training; these are jobs in science, law, medicine, and engineering that demand years of education. These jobs cannot be filled by robots in the near future, or possibly any future.

So as labor jobs experience a shortage, knowledge work experiences growth. But these jobs will be less numerous as the economy becomes more productive. As a rule, a single person will be able to achieve more and more in an increasingly technological economy. Their job will become more automated. They will acquire more sophisticated tools that can accomplish the same tasks in less time. The demands of the world simply will not be able to keep up with this new level of productivity. Thus, there will be less demand for people to work. There will still be jobs to be done, but the few that are left will require a lifetime of intensive training, and cannot (nor need not) be filled by everyone.

Perhaps Karl Marx's day is approaching at last, though not quite in the way he imagined it. If everyone could have basic living expenses paid for, then we could all be free to do what inspires us. I could stop hearing artists complain about how much I'm pirating their music, and patent trolls could release their stranglehold on the tech industry. Perhaps most surprising is that these aren't just the whacky thoughts of some out-of-touch roboticist with a soft spot for science fiction.4 In actual fact, Switzerland is already voting on it.

  1. He certainly has a way with words, doesn't he? Maybe he should get paid after all.
  2. Surprisingly, no one asked me to write this (unlike some of Kreider's work).
  3. We're also having trouble managing the effects of big agro on the environment, but I view that as a separate issue.
  4. Well, they are also that.