Programming in the Mid-Future
Programming in the Mid-Future
by Bruce Eckel
March 10, 2010
Summary
In 25 years or so, we'll look at the current morass as only a small step above assembly-language programming. Here's what I think programming will be like then.
Further in the future than what I'm describing here, our IDEs might just hack into our brainstems to produce a Matrix-like world within which we manipulate programming ideas. There are a number of breakthroughs required for that to happen, and breakthroughs are difficult to predict, and their fallout is even more difficult to know.
Here's how far forward I can see now. Most of these points really just address problems that we have now, so I'm not being particularly clairvoyant. But for some reason humans seem to accept their problems and limitations. Perhaps it's just because of the effort necessary to change, and the fact that the toys we have now are still somewhat new so we're transfixed by how shiny they are, not noticing the problems they don't solve and, worse, how they limit us. I encountered this at the beginning of my career, programming hardware with assembly language while yearning to move to so-called "higher level languages" like C. There was a lot of suspicion and resistance, and that may be the throttle, the limiting factor, when trying to move the technology of programming forward, rather than the technology itself. (You could also argue that the suspicion and resistance is learned, from too many companies trying to make a quick buck by promising magic).
There is a significant and growing class of programming problems that static languages can't solve. Programming is going to become more and more dynamic. This doesn't mean that code analysis tools are not valuable; far from it. But we will discover (are discovering) that dynamic analysis is more powerful than static analysis, so things will continue to move in that direction.
Objects will manage their own processes; right now we call these "active objects" but in the future this idea will be incorporated into the basic idea of an object (you can't really say that an object models reality unless it has its own process).
Even if Moore's law gets a reboot from new technology, we've started down the path of multiple cores and farms of machines, and that won't stop. There are lots of problems that, as much as a faster single processor might be helpful, a bunch of fast processors will be better. And I would also argue that tons of processors is a better model of the world.
The problem is that currently, parallelism is virtually impossible to get right (I won't re-argue this here, I've done it elsewhere). While it's theoretically possible that a handful of experts exist that can deal with some level of concurrent complexity, there is always a limit to what those people can manage. And they are rare, and parallelism is becoming common.
What I mean by "stupidly parallel" is that a brand-new student programmer can create objects that run in parallel without bugs, while knowing little or nothing about parallel programming. It will just be part of the atmosphere of programming that parallelism happens and you don't have to tie your brain in knots to get it right.
Eventually the idea that we have to "store something to disk" will go away; the difference between memory and disk will be seen as an arbitrary artifact of the past. You'll just have data, and the data will be accessible for as long as you need it. It will live on your machine and in the cloud, as necessary, and you won't have to think about whether it's being garbage collected or swapped.
You'll just make objects and use them, and the objects will contain data as necessary.
This is really just a continuation of the previous point. Programmers won't have to think about storage, period. Right now there's a lot of time spent on issues that should be automated, and this is one of them.
Tests are a form of program analysis. We know that test coverage produces better programs, but we're still on the leading edge of how to create tests. JUnit has traditionally required too much boilerplate and rote work, and that has slowed the test creation process (I like Python's Nose, which uses reflection to minimize coding).
Eventually we'll be able to create tools that recognize patterns in the code you write, and automatically apply tests to those patterns. The only tests you'll have to write are the ones that aren't in the database, and when you write them they'll go into the database so no one has to write them again.
The reason I call it "swarm" is that I imagine it like a swarm of bees. You create an object (which I think will still be the basic granularity of component in the future; it will be much more than today's objects but we'll still think in terms of objects), and the tests will swarm over that object looking for places to apply themselves (the same way that chemicals look for the appropriate receptors in your brain). You'll only need to add tests for the empty spaces. Testing will become faster, more thorough, and far more automated.
I initially wrote about this idea in a science fiction story. A robot receives ideas visually, by signals passing through the eyes (no physical contact). The ideas -- new code, basically -- pass into a kind of limbo where they are analyzed for suspicious content. I think not only swarm testing would come into play, but logical testing, checking whether an object does what it says it will do. Only after it is thoroughly tested will it be incorporated into the program.
Note that this not only helps in system integration for your own code, but allows much greater use of off-the-shelf components as well.
Data stores, too, will just become another kind of object, integrated into the objects where they are used. In confluence with the aforementioned transparent storage, data stores are just objects where you can store data and later ask for it. You won't have to re-code every time you need a new one, just slap it in without a lot of effort. In addition, you won't have to think ahead of time about scaling issues for your data store. There will be no rewrite when going from a small data store to a large one. Data stores will become a non-issue.
The point of data storage is that sometime later we want to query it. But we get lost in the details of how it should be structured rather than keeping this fundamental idea in mind.
Progress has been made in this area. The transition from hierarchical data to SQL was a big step. Programming systems like LINQ and SQLAlchemy have provided better abstractions to separate the programmer from the underlying structure of the data. You're able to make a query that the engine dynamically optimizes. Who knows, in the future querying your database efficiently might end up being as easy as doing a Google search.
The future object incorporates the concept of "component" and will be the basic unit of code. It manages its own processes and comes with its own swarm of tests. The interface between components and other components (thus, components and systems) becomes universal. Adding a new component to a system becomes as easy as adding ingredients to a recipe. Component discovery will have its own search engine.
I actually hope it will be even better than this.
I think you'll be able to throw components into a soup, and they'll wire themselves together, negotiating or asking for advice when two components have overlapping functionality. The result will just be a larger object/component, that you'll either use in a bigger system or as a standalone application. Naturally, swarm testing applies at all levels.
UIs are stored and categorized in a way that it makes it easy to search for them. UIs capture and display data, so the intermediate connection to the main program is a data store, which that program queries and updates. This is basically a more sophisticated form of MVC, but without miring you in all the redundant low-level boilerplate every time you create a UI -- there's no reason we should have to repeat ourselves constantly this way, and no reason that programmers shouldn't benefit from great UIs without having to be UI experts.
Most of the time you'll be able to select UIs from a list and paste them into your system. If you need to make a new one, or modify an existing one, the result becomes a new entry in the UI store.
This follows from the other features that I've described above, but it's worth emphasizing. When you write a program, it will work in the small and in the large without modification. We currently spend way too much effort on scaling issues, which should be transparent, and eventually it will be.
The collection of features described above solves problems of program complexity, especially those that appear when a program gets large and sophisticated. Programming in the future will eliminate the concept of scale, so that adding features to an existing program will be unaffected by how big or complex that program is.
Yes, big ideas. We can't necessarily think about how to solve these problems yet. But just imagine what programming would be like in such a world.
What other features do you imagine we'll see in the future? (I plan to hold a session on this topic at next week's Java Posse Roundup).
Have an opinion? Readers have already posted 87 comments about this weblog entry. Why not add yours? RSS Feed
If you'd like to be notified whenever Bruce Eckel adds a new entry to his weblog, subscribe to his RSS feed.
Digg 
del.icio.us
 |
Bruce Eckel (http://www.bruceeckel.com/) provides development assistance in Python with user interfaces in Flex. He is the author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM (available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000, Volume 2 with Chuck Allison, 2003), C++ Inside & Out (Osborne/McGraw-Hill 1993), among others. He's given hundreds of presentations throughout the world, published over 150 articles in numerous magazines, was a founding member of the ANSI/ISO C++ committee and speaks regularly at conferences. |