Programming in the mid-Future)

Related Chinese link http://kb.cnblogs.com/page/59978/ Near FutureProgramWhat is the language? Computing Thoughts
Programming in the mid-Future
By Bruce Eckel
March 10,201 0

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 participant ularly 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 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 ages" 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 cocould also argue that the suspicion and resistance is learned, from too compute companies trying to make a quick buck by promising magic ).

Extremely dynamic

There is a significant and growing class of programming problems that static versions ages 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.

Stupidly parallel Objects BR>

Objects will manage their own processes; right now we call these "active objects" but in the future this idea will be ininitialized 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 wocould also argue that tons of processors is a better model of the world.

The problem is that currently, parallelism is always Ally 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 knots to get it right.

Persistent diskless Environment

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 in data as necessary.

Transparency between local and cloud

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 shoshould be automated, and this is one of them.

Swarm Testing

Tests are a form of program analysis. we know that test coverage produces better programs, but we're 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 drivers in your brain ). you'll only need to add tests for the empty spaces. testing will become faster, more thorough, and far more automatically.

Security via suspicious Systems

I initially wrote about this idea in a science fiction story. A robot when es ideas always ally, 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 wocould 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 ininitialized 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.

Effortless data stores

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 of lot 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.

Query-based data

The point of data storage is that sometime later we want to query it. But we get lost in the details of how it shocould 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 extends actions 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.

Reusability on a vast scale br>

The future object insigates 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.

Effortless System Integration

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 be 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.

Reusable UIS

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 shoshould 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.

Effortlessly scalable

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 shoshould be transparent, and eventually it will be.

Built-in evolvability

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.

Big talk

Yes, big ideas. We can't necessarily think about how to solve these problems yet. But just imagine what programming wocould 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).

Talk back!

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 | Reddit

About the blogger

Bruce Eckel (http://www.bruceeckel.com/) provides development maintenance ance 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.