5 ms·

New languages are carried on the backs of new platforms. eg: unix & c; web & javascript. To predict the next big language, predict the next big platform. The u

• newgame 16y ago
  Yes, you are absolutely right. In fact I had started a chapter about the "far future" where I wanted to elaborate more on the computer architecture change and its effect on programming languages. But I thought the scope would become too large. If you are interested I gathered some links about the "far future": * https://channel9.msdn.com/posts/Charles/Jonathan-Edwards-Programming-Futures-and-Declarative-Objects/ https://channel9.msdn.com/posts/Charles/Jonathan-Edwards-Pro... * http://lambda-the-ultimate.org/node/4088 http://lambda-the-ultimate.org/node/4088 * http://lambda-the-ultimate.org/node/4090 http://lambda-the-ultimate.org/node/4090
• lkrubner 16y ago
  The next big platform is multiple cores/multiple CPUs. The next big language is functional and helps deal with consistency across time and across CPUs. Therefore, the next big language is Clojure. Rich Hickey said it best: "If somebody hands you something mutable—let's say it has methods to get this, get that, and get the other attribute—can you walk through those and know you've seen a consistent object? The answer is you can't, and that's a problem of time. Because if there were no other actors in the world, and if time wasn't passing between when you looked at the first, second, and third attribute, you would have no problems. But because nothing is captured of the aggregate value at a point in time, you have to spend time to look at the pieces. And while that time is elapsing, someone else could be changing it. So you won't necessarily see something consistent. For example, take a mutable Date class that has year, month, and day. To me, changing a date is like trying to change 42 into 43. That's not something we should be doing, but we think we can, because the architecture of classes is such that we could make a Date object that has mutable year, month, and day. Say it was March 31, 2009, and somebody wanted to make it February 12, 2009. If they changed the month first there would be, at some point in time, February 31, 2009, which is not a valid date. That's not actually a problem of shared state as much as it is a problem of time. The problem is we've taken a date, which should be just as immutable as 42 is, and we've turned it into something with multiple independent pieces. And then we don't have a model for the differences in time of the person who wants to read that state and the person who wants to change it." http://www.artima.com/articles/hickey_on_time.html http://www.artima.com/articles/hickey_on_time.html
  • Chris_Newton 16y ago
    > The next big platform is multiple cores/multiple CPUs. The next big language is functional and helps deal with consistency across time and across CPUs. So the popular opinion in the Internet echo chamber keeps telling me, but somehow I don't buy it. If you do, please try to answer this simple question: what single application of widespread importance benefits on a game-changing scale from running on multiple cores? It's not office productivity/business automation applications like word processors, spreadsheets, and accounting packages. They could run just fine on a typical desktop PC years ago. Sure, it's useful to run multiple applications simultaneously, but the OS can handle the scaling in that case. It's not mass information distribution/web applications. The bottlenecks there are typically caused by limited communications bandwidth or database issues. While concurrency is obviously a big factor internally in databases, most of us don't actually write database engines. It's not games. Most AAA titles today still don't scale up in that way, and one mid-range graphics card with its specialist processor would blow away a top-end quad-Xeon workstation when it comes to real-time rendering. Again, there is some degree of concurrency here, but many intensive graphics rendering problems are embarrassingly parallel in several ways, so again this isn't much of a challenge even for today's mainstream programming languages and design techniques. I suspect the most likely mainstream beneficiaries of better multi-core/multi-CPU support would be things where there really is heavy calculation going on behind the scenes and it's not always uniform: multimedia processing, CAD, etc. However, what about the alternative directions the industry might take? The Internet age has emphasized some basic realities of software development that as an industry we weren't good at recognising before. For one thing, many useful tools are not million-lines-of-code monsters but relatively simple programs with far fewer lines of code. It's knowing what those lines should do that counts. That means rapid development matters, and that in turn requires flexible designs and easy prototyping. For another thing, data matters far more than any particular piece of software. Protecting that data matters much more in a connected world with fast and widespread communications, so security is more important than ever, and we need software that doesn't crash, suffer data loss bugs, and so on. So I'm going to go out on a limb here and suggest that multi-core/multi-CPU is not in fact going to be the dominant factor in the success of near-future languages. I think flexibility and robustness are going to be far more important. It may turn out that the attributes of a more declarative programming style support these other factors as well. It may be that functional programming becomes the default for many projects as a consequence. But I don't think any future rise of functional programming will be driven by a compelling advantage to do with implementing modest concurrency on multi-core systems. That just isn't where the real bottlenecks are (in most cases).