相关中文链接http://kb.cnblogs.com/page/59978/

不远的将来 程序语言是怎样的

Computing Thoughts
Programming in the Mid-Future
by Bruce Eckel
March 10, 2010

Extremely dynamic

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.

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

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

Security via suspicious systems

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.

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

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

Reusability on a vast scale br>

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.

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

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 should 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 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).

Digg | del.icio.us | Reddit