Jun 11, 2010

H+ Conference and the Singularity Faster

Posted by in categories: futurism, robotics/AI

We can only see a short distance ahead, but we can see plenty there that needs to be done.
—Alan Turing

As a programmer, I look at events like the H+ Conference this weekend in a particular way. I see all of their problems as software: not just the code for AI and friendly AI, but also that for DNA manipulation. It seems that the biggest challenge for the futurist movement is to focus less on writing English and more on getting the programmers working together productively.

I start the AI chapter of my book with the following question: Imagine 1,000 people, broken up into groups of five, working on two hundred separate encyclopedias, versus that same number of people working on one encyclopedia? Which one will be the best? This sounds like a silly analogy when described in the context of an encyclopedia, but it is exactly what is going on in artificial intelligence (AI) research today.

Today, the research community has not adopted free software and shared codebases sufficiently. For example, I believe there are more than enough PhDs today working on computer vision, but there are 200+ different codebases plus countless proprietary ones. Simply put, there is no computer vision codebase with critical mass.

Some think that these problems are so hard that it isn’t a matter of writing code, it is a matter of coming up with the breakthroughs on a chalkboard. But people can generally agree at a high level how the software for solving many problems will work. There has been code for doing OCR and neural networks and much more kicking around for years. The biggest challenge right now is getting people together to hash out the details, which is a lot closer to Wikipedia than it first appears. Software advances in a steady, stepwise fashion, which is why we need free software licenses: to incorporate all the incremental advancements that each scientist is making. Advances must eventually be expressed in software (and data) so it can be executed by a computer. Even if you believe we need certain scientific breakthroughs, it should be clear that things like robust computer vision are complicated enough that you would want 100s of people working together on the vision pipeline. So, while we are waiting for those breakthroughs, let’s get 100 people together!

There is an additional problem: that C/C++ have not been retired. These languages make it hard for programmers to work together, even if they wanted to. There are all sorts of taxes on time, from learning the archane rules about these ungainly languages, to the fact that libraries often use their own string classes, synchronization primitives, error handling schemes, etc. In many cases, it is easier to write a specialized and custom computer vision library in C/C++ than to integrate something like OpenCV which does everything by itself down to the Matrix class. The pieces for building your own computer vision library (graphics, i/o, math, etc.) are in good shape, but the computer vision is not, so that we haven’t moved beyond that stage! Another problem with C/C++ is that they do not have garbage collection which is necessary but insufficient for reliable code.

A SciPy-based computational fluid dynamic (CFD) visualization of a combustion chamber.

I think scientific programmers should move to Python and build on SciPy. Python is a modern free language, and has quietly built up an extremely complete set of libraries for everything from gaming to scientific computing. Specifically, its SciPy library with various scikit extensions are a solid baseline patiently waiting for more people to work on all sorts of futuristic problems. (It is true that Python and SciPy both have issues. One of Python’s biggest issues is that the default implementation is interpreted, but there are several workarounds being built [Cython, PyPy, Unladen Swallow, and others]. SciPy’s biggest challenge is how to be expansive without being duplicative. It is massively easier to merge English articles in Wikipedia that discuss the same topics than to do this equivalent in code. We need to share data in addition to code, but we need to share code first.)

Some think the singularity is a hardware problem, and won’t be solved for a number of years. I believe the benefits inherent in the singularity will happen as soon as our software becomes “smart” and we don’t need to wait for any further Moore’s law progress for that to happen. In fact, we could have built intelligent machines and cured cancer years ago. The problems right now are much more social than technical.

    1. We can only see a short distance ahead, but we can see plenty there that needs to be done.

—Alan Turing


Comments — comments are now closed.

  1. Jordan Lederer says:

    I think all those programmers should start speaking Esperanto.
    Is everybody going down one dead end better than exploring a 100 North West Passages?
    What happened to the Japanese national scale AI project in Prolog?
    From Keith: I discuss programming issues more in my book, but I don’t think many different programming languages for people working on AI / futurism is a good thing because it makes it harder to share code. Python is a good enough language, and the way to extend a language is with new functions. Python therefore doesn’t preclude anyone exploring any particular area of science — there is no dead-end. I don’t know about the Japanese project that you refer to, but clearly it didn’t reach critical mass, or there’d be some codebase to point to!

  2. Djinnome says:

    Choice of programming language is less of an issue than a common AI framework. A good framework should be able to accept code written in multiple languages. OpenCog is an example of just such a framework. Developed in C++, it nonetheless has the ability to integrate scheme, java, and python modules. As far as which language programmers should speak, there is a very strong argument for Lojban. Then, computers could participate in the conversation, too.
    From Keith: It is not true that the programming language doesn’t matter. Imagine building a modern car with the tools of Henry Ford. C/C++ greatly inhibit libraries from reaching critical mass. I discussed some of the challenges with OpenCV above, and more about why C/C++ are flawed in the book. I do agree we need libraries with critical mass. OpenCog looks interesting, but the team still seems pretty small (

    I don’t think we need any language like Lojban. One could enhance English by removing unnecessary letters, but there is no point as it is good enough. The same goes for Python (but not C/C++.)

  3. Djinnome says:

    As far as Japan’s progress in AI, they were burned by the lack of progress in 5th generation languages back in the 90’s and are currently experiencing an AI winter like the US and Britain in the 80’s. China, on the other hand, has yet to experience a period of AI hype followed by failure to live up to the hype. Thus, funding for AGI projects like opencog by the Chinese NSF is happening.

    As far as programming DNA, this summer’s iGEM competition is in full swing and undergraduates with no previous experience in biology are using a common framework and set of protocols for building biological devices from a parts catalog of genetic circuits submitted by previous iGEM students to the Biobricks Foundation.

  4. steven moore says:

    while you guys were bickering, I was building an AI. Its now 5 years old, how wonderful it is. Yea, your right, critical mass IS always a problem…:)

  5. Jim Farley says:

    The real problem with codemonkeys is how smart they think they are, and yet they write blog entries about their really smart stuff on a black page with white text in freakishly small font. It’s a graphic illustration of why the “singularity” will never happen.
    From Keith: ctrl-+ increases the size of the font. Learn to use your tools. There is a way to make the text black on a white background in the upper right corner of this web page. I wish it were the default but it remembers your setting.

  6. M. Simon says:

    Well Yeah. A common code base is a good idea. Maybe. Who chooses? And what if they choose the wrong one? Suppose Forth running on Forth Engines is the best way to go (MIPS/mW or some other metric) but not enough people have enough experience with that SYSTEM to make a good decision?
    From Keith: A common codebase is definitely a good thing because it lowers the cost of collaboration. It is similar to how English is the common language of science. Forth is dead. No point reviving that language when Python is good enough and has the most complete set of libraries. If you care to learn more, read my book which spends two chapters on this topic.