4 ms·

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

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).
- vilya 16y ago
  > 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? Computer vision and machine learning both benefit a lot from multiple cores. They seem to be really big growth areas at the moment and have the potential to dramatically change the way we interact with computers. It's already happening: recommendation engines on e-commerce sites are a great example of machine learning in practice. I believe we're going to see this sort of thing appearing in more and more places. Web browsers already take advantage of multiple cores, by the way. The Rust language is being developed by Mozilla because (one of the three reasons from the project FAQ) of dissatisfaction with the concurrency support in existing languages. I think there's a large opportunity cost to dismissing concurrency & parallelism at this moment.
  - Chris_Newton 16y ago
    > I think there's a large opportunity cost to dismissing concurrency & parallelism at this moment. I'm not dismissing the idea, nor claiming that it is not valuable for any application. Clearly that parallelism would have value to a significant number of projects, which perhaps don't make best use of the host hardware today. I'm just trying to keep the multi-core idea in perspective, relative to other ways our programming languages might improve. Better multi-core support can get you a constant factor speed-up in computationally expensive work, but Amdahl's Law tends to spoil even that. On the other hand, a language with a type system that allows you to prevent entire classes of programmer error could lead to a step change in security or robustness. A language expressive enough to capture the developer's intent in ways that today's programming models do not could lead to entirely new techniques for keeping designs flexible, supporting new rapid development processes, or it could create opportunities for optimisers that bring the performance of more expressive languages to a level where they compete with lower-level languages used in the same field today for speed reasons. I suspect that across the field of programming as a whole, such improvements would be far more widely applicable.
andrewvc 16y ago
Maybe, but I have my reservations. I think the attitude that the future is the tech that extracts the best performance with the least work out of future hardware is mistaken. Clojure may be a great language for a multi-core world, but I'm not sure multiple cores will be needed for the vast majority of apps in the future. I'm sure some sectors will find clojure to be amazing for their purposes, but by and large, I doubt it will be as big a language as Python, Java or Ruby. For instance, I doubt it will become a big player in the web app world. Clojure's great support for concurrency only applies to a single machine. If your problem is squeezing maximum performance out of a single box w/ multiple cores this is great, but for something like a web application where processing a single request across multiple cores is generally unnecessary clojure's benefits don't really apply. Each thread/process in a web app is totally isolated from the others, and IPC must happen over a network, not in memory. IMHO the most interesting tech for concurrent web app programming is using Redis as a data structures server.
- derefr 16y ago
  > I'm not sure multiple cores will be needed for the vast majority of apps in the future. Thre's no alternative if we want to keep being "lazy" (i.e. yesterday's "Computers are Fast" observation—or using programming techniques that produce code that is slow now, knowing it will be faster on future hardware, like games tend to do.) CPUs will soon stop getting faster, so we will have to instead rely on there being an increasing number of them if we want to keep thinking that "Computers are Fast" (or, in its future conception, "Computers are Wide.") As an alternate argument, consider the brain. So many futurists have said something to the effect that, if we have a general-strong-AI-like architecture to work upon, procedural programming will be abstracted away, as much as digital electronics abstract away voltages. However, if we ever want to create something brain-like (assuming a general-strong-AI would best be modeled as something brain-like), we're not going to do it on one (or even a "scarce" number of) cores.
  - andrewvc 16y ago
    The reality is we have more CPU power on personal computers these days than most people know what to do with, that's why mobile is making so many gains. Most people run a browser, the end. If they have a mobile or an iPad they run apps that use almost no CPU power, and are fancier interfaces to web services than a browser is able to be. Since app development is moving towards mobile devices that means battery power is a concern. SMP often has overhead in terms of power consumption, it should be something you must resort to. So, my tablet's fancy drawing program might need to use Clojure to maximize its speed (and maybe not), but its twitter client doesn't need the advanced concurrency mechanisms of Clojure. Sure, there will still be plenty of desktop computers running complex simulations that might really benefit from something like Clojure. But that'll be the exception. Just my $0.02
purpledove 16y ago
Clojure, like Lisp, has terrible syntax that is difficult for human beings to read. This is one of the reasons the academic community kept Lisp alive - independence from industry, ability to weed out weaker programmers, flexibility. I'm well aware that I'm posting this on Hacker News, a site founded by an individual who made gazillions on a website powered by Lisp --- I think it is safe to say that it is the exception rather than the rule. In order to be widely accepted, a language must do many things well enough. If it fails badly at one particular thing, in this case syntax readability, its ability to gain followers will be severely diminished. It may, however, gain a strong following in academia. If you disagree, then do this thought experiment: who currently uses serious parallel processing power? I can think of a few: Blizzard's WoW servers, government research labs, and bio-informatics operations. How would you convince them to try out Clojure? What problem do they have that Clojure solves so much better than anything else out there that it would gain a foothold? By the way, I learned CS from Abelson and Sussman and Scheme was my language of choice between 1996 and 2004.
- djacobs 16y ago
  What syntax? Or to rephrase: What (scant) syntax there is, I'm in love with.
gaius 16y ago
But the problem is that the instant you venture out of Clojure and into a third-party JAR all those assumptions about purity go out of the window. Clojure's strength is also its weakness in that regard. Haskell does make real guarantees about what does I/O and what doesn't.
- swannodette 16y ago
  This is potentially being addressed in an in-development Clojure feature called Pods.
code_duck 16y ago
Why would that make it Clojure rather than Erlang or Scala?

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

vilya 16y ago
> 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? Computer vision and machine learning both benefit a lot from multiple cores. They seem to be really big growth areas at the moment and have the potential to dramatically change the way we interact with computers. It's already happening: recommendation engines on e-commerce sites are a great example of machine learning in practice. I believe we're going to see this sort of thing appearing in more and more places. Web browsers already take advantage of multiple cores, by the way. The Rust language is being developed by Mozilla because (one of the three reasons from the project FAQ) of dissatisfaction with the concurrency support in existing languages. I think there's a large opportunity cost to dismissing concurrency & parallelism at this moment.
- Chris_Newton 16y ago
  > I think there's a large opportunity cost to dismissing concurrency & parallelism at this moment. I'm not dismissing the idea, nor claiming that it is not valuable for any application. Clearly that parallelism would have value to a significant number of projects, which perhaps don't make best use of the host hardware today. I'm just trying to keep the multi-core idea in perspective, relative to other ways our programming languages might improve. Better multi-core support can get you a constant factor speed-up in computationally expensive work, but Amdahl's Law tends to spoil even that. On the other hand, a language with a type system that allows you to prevent entire classes of programmer error could lead to a step change in security or robustness. A language expressive enough to capture the developer's intent in ways that today's programming models do not could lead to entirely new techniques for keeping designs flexible, supporting new rapid development processes, or it could create opportunities for optimisers that bring the performance of more expressive languages to a level where they compete with lower-level languages used in the same field today for speed reasons. I suspect that across the field of programming as a whole, such improvements would be far more widely applicable.

andrewvc 16y ago

Maybe, but I have my reservations. I think the attitude that the future is the tech that extracts the best performance with the least work out of future hardware is mistaken. Clojure may be a great language for a multi-core world, but I'm not sure multiple cores will be needed for the vast majority of apps in the future. I'm sure some sectors will find clojure to be amazing for their purposes, but by and large, I doubt it will be as big a language as Python, Java or Ruby. For instance, I doubt it will become a big player in the web app world. Clojure's great support for concurrency only applies to a single machine. If your problem is squeezing maximum performance out of a single box w/ multiple cores this is great, but for something like a web application where processing a single request across multiple cores is generally unnecessary clojure's benefits don't really apply. Each thread/process in a web app is totally isolated from the others, and IPC must happen over a network, not in memory. IMHO the most interesting tech for concurrent web app programming is using Redis as a data structures server.

derefr 16y ago
> I'm not sure multiple cores will be needed for the vast majority of apps in the future. Thre's no alternative if we want to keep being "lazy" (i.e. yesterday's "Computers are Fast" observation—or using programming techniques that produce code that is slow now, knowing it will be faster on future hardware, like games tend to do.) CPUs will soon stop getting faster, so we will have to instead rely on there being an increasing number of them if we want to keep thinking that "Computers are Fast" (or, in its future conception, "Computers are Wide.") As an alternate argument, consider the brain. So many futurists have said something to the effect that, if we have a general-strong-AI-like architecture to work upon, procedural programming will be abstracted away, as much as digital electronics abstract away voltages. However, if we ever want to create something brain-like (assuming a general-strong-AI would best be modeled as something brain-like), we're not going to do it on one (or even a "scarce" number of) cores.
- andrewvc 16y ago
  The reality is we have more CPU power on personal computers these days than most people know what to do with, that's why mobile is making so many gains. Most people run a browser, the end. If they have a mobile or an iPad they run apps that use almost no CPU power, and are fancier interfaces to web services than a browser is able to be. Since app development is moving towards mobile devices that means battery power is a concern. SMP often has overhead in terms of power consumption, it should be something you must resort to. So, my tablet's fancy drawing program might need to use Clojure to maximize its speed (and maybe not), but its twitter client doesn't need the advanced concurrency mechanisms of Clojure. Sure, there will still be plenty of desktop computers running complex simulations that might really benefit from something like Clojure. But that'll be the exception. Just my $0.02

purpledove 16y ago

Clojure, like Lisp, has terrible syntax that is difficult for human beings to read. This is one of the reasons the academic community kept Lisp alive - independence from industry, ability to weed out weaker programmers, flexibility. I'm well aware that I'm posting this on Hacker News, a site founded by an individual who made gazillions on a website powered by Lisp --- I think it is safe to say that it is the exception rather than the rule. In order to be widely accepted, a language must do many things well enough. If it fails badly at one particular thing, in this case syntax readability, its ability to gain followers will be severely diminished. It may, however, gain a strong following in academia. If you disagree, then do this thought experiment: who currently uses serious parallel processing power? I can think of a few: Blizzard's WoW servers, government research labs, and bio-informatics operations. How would you convince them to try out Clojure? What problem do they have that Clojure solves so much better than anything else out there that it would gain a foothold? By the way, I learned CS from Abelson and Sussman and Scheme was my language of choice between 1996 and 2004.

djacobs 16y ago
What syntax? Or to rephrase: What (scant) syntax there is, I'm in love with.

gaius 16y ago

But the problem is that the instant you venture out of Clojure and into a third-party JAR all those assumptions about purity go out of the window. Clojure's strength is also its weakness in that regard. Haskell does make real guarantees about what does I/O and what doesn't.

swannodette 16y ago
This is potentially being addressed in an in-development Clojure feature called Pods.

code_duck 16y ago

Why would that make it Clojure rather than Erlang or Scala?