Why I'd Start Coding Again
I use Python and Google as the primary examples in this article, although this idea could apply to other languages and commercial services. I picked Python because it is easy to read, powerful, and extensible. I picked Google because it has turned into a Bell Labs for software development and has hired many leading open source developers. Google could make an important contribution to software development, much as Sun did by promoting Java and Microsoft did by promoting Visual Basic.
I first wrote about this idea in Dr. Dobbs Journal in 1998. That article, entitled "Concept Oriented Programming," proposed extending object-oriented programming languages with a DNS-like system that would store reusable code, and that would enable developers to write tiny programs that load libraries as needed from the cloud. My original article is somewhat dated now, so I decided to revisit it in this O'Reilly piece, and to show some specific examples of how a hyperlinked version of Python would look. While this article is not a detailed technical specification, it clearly shows how this can be implemented. (Shortly before publication, I learned of UrlImport, a Python module that implements part of what I describe in this article.)
In plain English, you could write very lightweight programs that would load most of their underlying modules on the fly. Such a program might look like this:
import /widgets/foo.py as=foo import http://2_0_1.popupdialog.widgets.py.code.google.com as=popup crc=a6771234 x = foo.widget() x.say("Hello World") y = popup.widget() y.say("Well Hello There")
What I've done in this imaginary program is simple. In the first import statement, I load a locally stored library, just like a normal import. In the second import statement, I load a library from a network repository. I instantiate objects from each of these libraries and tell them to print a "Hello World" message.
The details of how the networked import command works are less important than what it enables you to do. Properly implemented, it will mean that you can write tiny programs that will grab whatever underlying code they need at runtime. No more bloated distributable packages. There are no more install scripts. Just send your program and say "run mywidget.pyc, have fun!".
Baked into the Box
One of the goals of this manifesto, or whatever you want to call this, is to have a networked programming language baked into every box. The runtime environment will be built in, much as Python is preloaded on Mac OS X.
With most languages, the standard library becomes ever more bloated with each new release. With this technique, we can radically downsize the runtime environment. All we need is the interpreter (updated to recognize network imports and a couple of other functions). It can get everything else it needs from networked repositories.
The goal is to make the runtime environment so small that it can be a part of any computing device.
Batteries Not Needed
Python's "Batteries Included" philosophy enables developers to do quite a lot without venturing beyond the standard libraries. With a fully networked language, we no longer need to distribute a large standard library with the runtime environment or applications. Everything you need will be stored in the public network.
The distinction between the standard library and extras developed by other authors will also go away. With today's languages, it is usually best to stay with the standard libraries if at all possible, to avoid headaches when you share the application with other users, to install it on other machines, etc. Distribution and installation headaches can be a powerful disincentive to use third-party code.
With a networked language, there will be no build or install process. You'll just share an application and it will get what it needs on the fly.
DNS for Objects
While the networked
import function could load from a simple HTTP file store or similar service (this will work fine), we could take this a step further to create a DNS namespace for code. This section is a bit of a sidebar to this article, so if you think this is too forward-looking and it's a distration to you, skip forward to the next section.
We could create a .code (or .turing) top-level domain. From there, we could create a DNS namespace for objects that works much like the namespace for Internet hosts. The second-level domains would be reserved for major language branches, for example, *.py.turing. Tertiary domains would go to anyone who wanted to host a code repository, while a std subdomain would be reserved for official releases and libraries. (For example, the official standard Python libraries would live in std.py.turing.)
Using this system would be as easy as including an
import statement in a program, and might read as:
import http://2_0_1.doodad.widgetcorp.py.turing as=doodad crc=aa123456
The runtime engine, when it sees an
import statement like this, will do a standard DNS lookup and go grab the file from the appropriate server, just as in the earlier example. The idea here is to create a persistent address space for reusable code.
This may or may not happen, and in any case, the
import statement can pull modules from any domain. Commercial organizations will likely host early implementations of this, but it's good to know that we can move in this direction if the idea catches on.