What will come in 2020

Everyone seems to be doing these 19 year predictions. Seems a year late, but who am I to argue?

What will we see in the far-flung year 2020?

Unlike everyone else I don't plan to hold back. I'm not going to say simple, easy to guess, things like "The internet will have twice as many users" as some people are saying.

1. Robots will walk among us. They might only be doing very simple things, but they will be as commonplace as Mall Kiosks with Flat Panel Displays.

2. Speaking of the Mall, it will be the only place left that retail stores are still profitable on their own.

3. Everything will be online and wireless. I mean everything. Your shoes, your car, your kid's toys, everything that has data to collect, will collect it and post it online.

5. PCs will all but vanish. Only programmers and enthusiasts will still have them. Maybe gamers.

6. Most things will be powered wirelessly if it makes sense to. Which it makes sense for almost everything.. Maybe not a washing machine...

7. You will buy everything online, even when you are buying it at a store.

8. The lines between what is a device, and what is not, will have all but vanished.

9. TV will be on its last legs as a viable medium, or perhaps vanish entirely.

And some maybes

10. You might have brain interfaces, both input, and output.

11. You might have human-intelligence level AI.

12. You might be seriously considering cutting off perfectly good parts in favor of robot ones.

13. You might be backing up your mind.

14. We may be sharing our thoughts.

The Myth of Speed: Why Compiled Code isn't Faster on the Web

It is a standard argument that compiled code is always faster than interpreted code. This is of course completely true from a technical stand point, however the meaning of speed in this context is valueless. Speed, when you talk to a programmer, means something very different than it does to anyone else; and this difference is a stone cold killer.

Why Programmers are Wrong

When programmers talk of speed, they are talking about machine time. They are ultimately talking about microseconds. Microseconds, when repeated, add up to hours and hours of wasted time. Increasing the Speed of a process reduces all kinds of hardware costs and reduces the wasted time of users, right? Well, not really. There was a time when this held true; but these days the most costly portion of the development process is the programmer's time.

Let's back up. Certainly a faster program will save the user time? If we were talking about a desktop application, that is absolutely true, especially when we talk about speeding up a process that will run a million times as the user waits. One millisecond of saved time in a process turns into one million milliseconds, or 17 minutes. However, our Web applications NEVER do these kinds of tasks. If they did, those applications wouldn't get used. Users on the Web won't wait 17 seconds, let alone 60 times that. Web apps work differently. They poll a database for the 10 records that will be shown, and save the processing for the next 10 to the next request. 10 milliseconds extra won't matter, that is 30-40 times faster than you can blink your eye. Saving that millisecond here won't save the user any time at all.

However, saving a millisecond for each of a million customers will still save 17 minutes of machine time; so it is still a cost saving measure! But what costs more; the less than 0.1% more hardware you'll need, or the time of the ~$100,000 a year programmer? Is it worth it for spend a day? A week? Is 0.1% of your hardware worth $2000? In some situations, yes; in most, no.

So what does this have to do with compiled code?

Compiled code can be 1-10% faster than Interpreted code. 1% faster if your language intelligently caches the compiled version of often run code, and it is coded to take advantage of that caching; 10% if you are writing messy code in a language without such caching. This sounds like a no-brainer but you must remember that this is 1-10% of only the processing time. It ignores the time consuming parts of the Web equation entirely.

First, the user clicks on a link sending a request to your server, this might take 50-250 milliseconds. Next, the server will decode that request and start the process of running whatever program is needed to generate the response data, here is where your code goes; it should ideally take less than 1 second to process, that's 1000 milliseconds. Finally, that data needs to be sent across the internet to the user. If that user has a 1Mb connection, and you are transferring 650KB of data that is around 5050-6250 milliseconds. So the total time is roughly 5-6 seconds

If it were 10% of 5 seconds, it would only mean .5 seconds less time, but it is 10% of the 1 second of processing time only. We are talking about such small amounts of user time here that they are inconsequential.

But it gets so much worse

Compiled code is more time consuming to develop. It has a lot to do with the nature of the specific languages, but in general an interpreted language can get away with a variety of tricks that a compiled language will be too rigid to support. For example: the weak typing of PHP versus the strong typing of .Net; while weak typing can open new security issues if not taken into account, it also lends itself to very quick and flexible coding, especially if the language has a large quantity of only subtly different types (I'm looking at you, C#).

Where should we spend our programmer's time?

On the Web, the most important place you can spend your time is between the server and the user. Reduce the number of connections, the size of files, and the need to request them again. Use AJAX or cron jobs to avoid making the user wait for things that are slow. If you want to reduce hardware, forget optimization for milliseconds and invest in intelligent caching, or ideally memory caching. Avoid repeated processing wherever you can. It is betterto waste time removing all the white space from your output html, css, and js than it would be to use that programming time to speed up a process.

iPad: The Hot Pocket of Computers

Now that I own and have lived with my iPad for a few days, one thing is perfectly clear. The iPad is unlike anything else in the computer world. It is not a testosterone fueled rampage of facemelting, bleeding-edge technology. It is simply the easiest way yet to get online, email, and entertain.

Anyone technical, much like a chef, will turn up their nose. My hotPocket is made of poor ingredients, doesn't taste as good, and all around isn't as good as a home-made meal. But it goes from freezer to gullet in 3 minutes flat. It isn't sexy alone, it simply gets out of the way of the rest of my life.

The iPad is the same. It doesn't bother the user to learn a recipe, or knife skills, or how to pan-sear. You just take it out, nuke it, and consume that movie on netflix.

The iPad lets average people do so much more than they otherwise could.

So, as I write this post on my iPad, I feel joy. Because all I did was load the squarespace app and type it out, then press save. My hotPocket tastes just right.

Visions of the Singualrity 3

We have now covered what it means to be human, and some ways that humans could become exponentially smarter or hive-minded. But what about the possibility of computers or other machines becoming intelligent all on their own?

As we have advanced artificial intelligence over the years, and understood our own intellect in the process, we have further and further relegated our own gifts to the mundane, as universal intelligence has become the only factor that makes us the real smarties in the room. Most, if not all, of our core intelligences have been conquered separately by AI:

• Mobility


• Pattern Recognition


• Science


• Natural Language


• Creativity

The list could be endless, but the ending truth is that all of these things are limited only by current processing speeds. Even the fact that no one AI entity can do everything we can is ultimately a question of speed. Eventually, even if no more ground is broken into how our brain works, machines will be able to brute-force simulate us.

Is simulation the same as true Machine Intelligence? Strictly, yes. But this path leads back to the same things we talked about last time. More interestingly is the fact that AI should be able to out-performs us even quicker than we can simulate ourselves.

Humans ultimately do a lot of things the hard way. Our brains are not set up to crunch numbers quickly, but computers are. A well-constructed universal AI would draw from all disciplines of the Artificial Intelligence community. From Perceptrons to Genetic Programming to Finite State Machines and Expert Systems; and an ideal system would grow and change and find new ways to solve old problems. It would compile tried and true operation for speed and employ reduction routines to weed out magic. (By magic, I mean aspects of code that don't actually make the process better, they were simply there because they were when the process was first evolved. Like prayer in the creation of a Katana.)

How does this all come together?

There are a few clear paths to human enhancement; which is not true of machine intelligence. It isn't even clear what kinds of AI will be the backbone of the first universally intelligence machines. However, I see a couple more likely avenues.

One thrilling option is the creation of competing entities in a physical or virtual space. Through some genetic process, such as Genetic Programming, these entities would each be given random code to control their various senses and manipulators, the best survivors would be mixed and mutated to create new entities in a new world and over time intelligence may arise in them. Given access to various additional schemes, such as facial recognition engines, natural language dictation and decoding, and other tools; this AI could learn to recognize objects by name and shape, even individual people, and converse with them. I like this path because it doesn't really require any new kinds of AI or even enhancements to our existing techniques. It simply requires horsepower.

Another option is through Perceptrons, which can become more numerous and speedy in their simulation of the actions of neurons. There are holes here, however, as the learning and usage phases of perceptrons are strictly separated. Someone must initiate a training process for these systems to be able to learn a task, and then that task can be performed. Imagination Engines begin to show more promise, but they also have lengthy and tightly controlled training phases. To be a viable avenue to real universal AI, it will need to be able to self regulate this training. It would need to be able to self-guide.

Undoubtedly there are more paths to AI enlightenment, it is only a matter of time before one is born. Once a single intelligent machine exists, more will quickly follow. They will become smarter at an exponetial rate and we will either have to join them, or be left behind in the evolutionary arms race.

One wonders if they would tolerate us? This is the scary stuff of The Terminator, or Blade Runner or The Matrix; but does it have to be that way? Could we co-exist?

Javascript Parallax

As I decided to use this technique for the background of this blog, I thought I might make a few notes about it.

Parallax is what you call the apparent loss of speed of objects moving parallel to you as they get farther away from you. What this ultimately means for us is, using some simple Javascript, we can create the illusion of depth in the page by moving backgrounds or elements relative to the scrolling of the page or mouse location.

This principal has a wide range of graphic design applications, such as the background of this blog. The code can be simple and small, requiring only a couple of additional divs, and could with CSS3 not even require that much.

Beyond being pretty, there are a host of potential uses for parallax. In fact, scrollbars are a psudeo-parallax design idiom. Other uses might include menus that scroll past the user more slowly than the content, and 3D-esque interfaces that use mouse-pointer-location to display and hide submenus or to move the entire menu out of the way.