developerWorks: This is a special series of the developerWorks podcast with Andy Glover, a developer, author, speaker and entrepreneur. Andy is managing partner at Beacon 50, a regular contributor to several technical publications including developerWorks.
He writes the Java™ development 2.0 column. He's also creator of the award-winning easyb, a behavior-driven development framework. And here he talks to a variety of experts in the Java and related technologies community on topics ranging from closure to open source business intelligence and even .NET.
Glover: Alex Miller is with Revelytix and he's building semantic web products in Clojure, but prior to that he was also with Terracotta and BEA Systems. But more importantly, Alex is a fellow author at developerWorks. What more, he's a speaker at various conferences and actually runs his own conference called Strange Loop [strange loop | finding oneself unexplainedly back where one started - Ed.]. Alex, thanks for joining us tonight.
Miller: My pleasure.
Glover: So we wanted to kind of query your deep knowledge about kind of concurrency in various languages. You've written some articles obviously for IBM developerWorks about GPars and then you had written some articles in the last two years for JavaWorld, if I remember correctly, about using like various libraries in Java and actors in Erlang if I remember correctly as well.
Miller: That's correct.
Glover: So, why don't we take a step back and kind of, how did we get there. Can you describe why are talking about actors and concurrency and agents, and why are Erlang and Scala, why are they coming to the fold now?
Miller: Sure, so it's mostly changes in hardware that have been driving things over the years. And for the bulk of sort of my career computers got faster all the time. And if something wasn't fast enough, you just waited a year and then your machine was twice as fast and everything ran twice as fast and your boss was happy.
And unfortunately, somewhere around 2003, 2004, we started to hit some physical limits and things kind of, you know, things like the speed of light and things like that.
Glover: Has that changed recently?
Miller: It hasn't changed and that's the problem. [LAUGHTER]
So we got to the point where the die scales got so small that there were so many transistors on a chip and all of a sudden we got to a point where the signal could not propagate across the entire chip in the course of a clock cycle.
Clock cycles were getting faster and faster and the chips were getting more and more transistors, they're farther and farther apart. And so that and then also the ability to dissipate heat. As you put more and more things on the chip, it gets hotter and hotter and you don't want to melt a hole in your laptop.
Glover: Or your lap.
Miller: Or your lap.
So we kind of reached some limits that have affected the physical architecture. And while Moore's Law continues unabated and we continue to stuff twice as many transistors on to a chip every year and a half just like we have been doing for 20 or 30 years, those are not necessarily going to make things faster these days, they're not getting, they're going, we got to a point where we had to start just putting more cores on the same chip.
And that transition kind of occurred somewhere around 2003 or 2004 and that's why our computers today are not ... if you look at the actual gigahertz speed of the chips, they pretty much flatlined and in some cases they've actually gone down since that time. Otherwise, we'd have 10GHz chips right now and we don't.
So instead what we get is we've got, you know, your server class machine might have 8 cores or 16 cores or Intel's got some 80 core boxes or chips coming out and I don't think it's going to be too long before you have server class machines with hundreds or thousands of cores in them.
Glover: Wow. So the free lunch is over, right?
Miller: Right. So Herb Sutter wrote the article in 2005 saying the free lunch is over, it was a seminal article in the field and it kind of opened everybody's eyes, threw some curves that made it really obvious what was happening. And people said "hey, maybe we should start thinking about this stuff."
Glover: So when you say we should start thinking about this stuff, we come back to the subject of threading and parallelism and Java has always had a threading model in it. So what's the big deal? Why can't we just go on happily and start adding threads to our applications?
Miller: Well, in some ways, we can. So the basic primitives are there and most of the systems in the world today are based on the fundamental paradigm of threads and shared state and locks.
So you see that model and see C++ and Posix threads, things like that, you see it in Java, you see it in other languages. And that's what most people are familiar with and those primitives are ... continue to be perfectly adequate to build a concurrent, multi-threaded system.
The down side is that they're really easy to use in ways that create different bugs. So it's very easy to create systems that have race conditions and deadlocks and all sorts of concurrency problems. Performance issues. You know, it's pretty easy to write concurrent code, but it's hard to make it work and make it fast.
Glover: Right. Yes, make it work correctly, yes, exactly.
Miller: So a lot of people have been casting about for ... are there other ways that we can describe what we want to do in a way that allows it to be, to work across multiple cores but do that in a way that cuts down on the possibility of things like race conditions and deadlocks and those kinds of problems.
Glover: So describe some of these models then. Something that comes to mind obviously that I've written about at IBM developerWorks is the actor model, but I know that that's certainly not the only job out there so to speak. What's out there?
Miller: Yes actors has been, has gotten a lot of notoriety because of Erlang where that's sort of the fundamental basis of the system. And then sort of picking up the torch from there, Scala, another JDM language [Java Development Model] has made that sort of the core of most of their concurrency story, although you're certainly not precluded from using other models. That's sort of built into the libraries and the most common way that people write concurrent code in Scala.
So and the actor model, basically takes the idea of what if we had something that was lighter weight than a thread. So what if we had this thing, it's usually called a process which is an unfortunate name because it collides with the sort of heavyweight processes where we think about an operating system. But for the purposes of this discussion, consider process to be a lightweight, less-than-a-thread sort of a construct.
So Erlang starts from the premise of saying let's assume that processes are incredibly cheap to create. So you can create one very fast. They use a very small amount of memory and we're going to do everything by sending messages between processes.
And so that's kind of the core basis of the actor model is that instead of having a shared state, we have only immutable state and we allow actors, these different lightweight little entities to share state by passing immutable messages between then.
And because all the data is immutable, you never have a possibility of a race condition because no two threads are actually ever reading the same data. So it kind of eliminates that problem.
You don't actually eliminate the deadlock problem, it's just as easy to create a cycle of waiting ... processes waiting for things to occur and actors as it is to create them in a system based on threads and locks. But there are ways to compose it just as there are in the thread world to sort of reduce the possibility of that by using things like timed waits and retries and there's lot of techniques for that.
So that's become one model, one way to sort of model the world.
And the article that I wrote about the Groovy library GPars— and that's G-P-A-R-S but it's pronounced "jeepers," I kind of think of Scooby-Doo with that one. So GPars also has an implementation of actors and you can find implementations in a number of other languages as well. So that's one model.
Another model that has gotten some currency in some languages is software transactional memory.
Miller: So there are some Java-based STM systems. There's one called Multiverse and I think there's another couple of them that I don't remember the names of. And basically the idea with software transactional memory is that you build your memory access system just like you build the core of a relational database.
So in a database like Oracle® or something like ... or DB2® or something, you might have the ability to sort of have different transactions come into the system and see the state at the point they came into the system, do some work, and then apply all of those changes as a unit into the model. And it's at a high level; it is kind of similar to what you do with locks. The basic difference though is that you're not actually holding the lock while you're doing that work, you're sort of more describing the work and then it all gets applied as a unit to the shared memory.
And that's a model that's used by ... Clojure actually has a core STM system that's used; it's a lot different than what people have traditionally researched and worked on as STM. It's used in pretty limited ways, so it's not really the core of ... you can do a lot of programming without it in Clojure. So it's somewhat more limited in use and scope.
Haskell has an STM system built into it. So that's another language that uses it extensively. And then there are, like I said, there's libraries for several systems. And I believe the Multiverse or some other STM is going to be included in GPars in the near future as well. So I know that's one of the hot items they want to add.
Glover: So it seems to me that GPars is trying to become kind of the end-all, be-all of concurrency options.
Miller: Well, I think it's great actually because it's sort of, if I were to describe GPars in short I would say that it's a Groovy concurrency library that provides DSLs, sort of domain specific languages, for popular concurrency models. So it actually has like a ... provides a more complete set of concurrency models than you can find in almost any other language which is pretty exciting.
Glover: Yes, I know, certainly, certainly.
Miller: And that's really why I wrote the article with it because I was able to write the article, cover many different concurrency models, stay in one language or one library. The example, because Groovy is so concise, and I think it's very readable, especially if you're coming from a Java background, I don't think you'll have any trouble reading most of the Groovy examples even if they have syntax that's unfamiliar to you.
I think that you'll find that that's, you know, you can kind of understand what's going on there. It's kind of Java-like in many respects. So, it's great for an article like that.
Glover: So, let me ask this. You know when we talk about alternate languages like Groovy or Clojure or Scala that run on the JVM, invariable there'll be a portion of the population says well Java's already got all this stuff with the concurrent library or libraries in the concurrent package that was added, I think in Java 5. So where does that leave us? Are those libraries good enough? What are you thoughts there?
Miller: Well, obviously, there are other things to do or people wouldn't be doing them. But I think there are some ... there's great stuff in the Java concurrency library and not enough people are familiar with what's there and what's coming.
Glover: Yes, I would agree to that, I'm one of them.
Miller: Yes, so I mean, I wish that as a place to start there's great fundamental libraries there and so I've encouraged people to explore those a little bit more. And the basic executor library that was added as part of Java 5 and it's in the
Java.util.concurrent [class package], an excellent way to build sort of parallel work processes.
So if you've got a bunch of work you want to dump in the queue and have a bunch of threads do that work, it's the perfect solution for that kind of a thing. And that's what it was designed to do and the abstractions are good and the support is really good for most of the things you might want to do with it are there. I mean, anybody can find nitpicks with it but I think as far as covering that space, they do a pretty good job.
One place where that kind of falls down a little bit is that it was sort of originally it was designed, you know, it came out I don't know when Java 5 came out, probably 2004, 5, something like that. So it was a while ago and what was prevalent then was 2- and 4-core boxes were really the ... that was the most common thing you'd see back then.
It was really designed for tasks that were being put into a thread library that were sort of transaction sized. So they're somewhat chunky and they might wait for I/O or they might be CPU-intensive tasks and it was things that were in the, up to the sort of 8- to 16-thread or core area. That's sort of the sweet spot for the executor library.
And because it works off of ... the executors work off of a single queue, what you'll find is that as you scale up past that point and you start to add dozens or hundreds of threads on there, that the central queue becomes a contention point. So all those threads have to pull work off of the queue and that means they're all blocking on the exact same lock. So that becomes an obstacle in the concurrency because you've got lots of threads waiting for each other.
So Doug Lea for several years now has been working on this idea called Fork Join [example] and it's basically designed to handle a much larger number of concurrent threads. So it's designed for greater concurrency. It's designed for tasks that have dependencies on each other, so if you have a task that might actually spawn some other tasks and then it needs to go do that work and then wait for those things to be finished and then go back to doing what it was doing.
So if you think of computations that are inherently tree-like, where you have a node and then it spawns a new child nodes and it needs to wait for those childs to complete ... children to complete? ... that's a common situation and that's something that the Fork-Join algorithm is optimized for. And it also is sort of more focused towards CPU-intensive tasks on large parallel data sets.
So it's a little bit different focus and so if you happen to have these kinds of problems, like I've got a million orders and I need to process through them and do something and I want to do that in parallel and I might have to get to an order and then it has child orders, I need to go process those or ... you know, I'm just making something up, but that sort of a situation is really the kind of problem that Fork Join is designed to solve.
Glover: I see.
Miller: So it's sort of the next phase, really. It's attacking a greater level concurrency, more complicated kinds of tasks and algorithms and that kind of stuff.
Miller: Yes, so Doug Lea did the original work, I don't know, at this point, probably four, five years ago, I'm not really sure. And that's being done under the JSR 166Y. So JSR 166, the original one, was the JSR that handled the Java concurrency editions and Java 5.
And then in Java 6, they did a JSR 166X which was some maintenance updates, and that included things like concurrent skip lists, map and set and the decks was the other big one, the doubled-ended queues, queue interface, and there's a couple of implementations there. Those are the big additions in Java 6.
And then in Java 7, they've been working on JSR 166Y and that actually has been around in some form or another for several years now. I think I did a presentation about it in 2007 or 8 or something like that. So it's been around for a while. And it looks like the Fork Join work will definitely go into JDK 7 depending on what actually happens with JDK 7 and Java 7.
Glover: Yes, if and when that comes out.
Miller: And then there's an additional abstraction layer over that called
ParallelArray. That has been in and out over time and it was pulled out at one point because of the lack of Clojure support in Java. Now that they've added some of that back into it, the Lambda Project, I don't know whether, I don't know what the current status is whether parallel array will be in JDK 7 or not. That would be a good question for Brian Goetz.
Glover: There we go, there we go. Well, so you know, speaking of some of these things like Fork Join and
ParallelArray, those are in GPars, yes?
Miller: Yes, so GPars uses the published version of JDK of the JSR 166Y library and they're not the only ones using that. The Scala actors system is actually also based on the Fork Join library. And there are people who are poking around at it for supporting some things in Clojure. I'm pretty sure that parts of the Fortress Project that was Sun Research but now I guess it's Oracle Research that Guy Steele works on that are based on Fork Join. So there's lots of people that are building out on it already.
Glover: Okay. Well that's good. Hopefully it doesn't change then.
Miller: It's been changing a little bit slowly. And I think they just published a round of updates to it and I believe that's expected to be the last major round of updates to it.
Glover: So, another kind of I guess framework for dealing with concurrency that you mention in the article is agents, specifically, I guess, based on the Clojure model of agents. Can you tell us more about that?
Miller: Yes. So in some ways from a high level they sound kind of like actors. So in the Clojure world, they're usually quick to say, to start talking about agents by saying, first of all they're not actors.
Glover: Okay, yes, yes. They're agents instead.
Miller: Yes. So and the difference there is that in actors, typically your actor is sort of an active, living entity. When it's running, it's bound to a thread, and it doesn't necessarily ... because it's lightweight it doesn't usually get bound to a thread for the lifetime, although there are ways to do that in most actor systems. But in general, most actors are these lightweight processes that are sort of scheduled off to treads as they need to be scheduled off to threads.
An agent, on the other hand, is typically not an actor of process that's mapped to a thread. And so in Clojure, it's really a function that's hiding access to a piece of state. So if you want to change that state, you basically send a function to the agent and say, here's a function that you can apply to obtain the new value of the state. And you can do that synchronously or asynchronously.
One of the nice things is that because of the Clojure model of using immutable persistent data structures. So immutable, I think we know what that means. Persistent in this it's not like persistent to a database, but it's really like persistent to, meaning that the data in the data structure sticks around. And when you change, in quotes, the data structure, what you get back is a new version of the data structure that shares most of the data with the old version of it. So the fact that that old data sticks around is sort of the persistent part of it.
Glover: I see.
Miller: So what that means is when I have this piece of state, maybe I've got a map that's held by the agent. And then I send in a function that says alter the map by adding a new key and a new value. Then the new state of that agent is going to be that new map with the new key and value and all the old keys and values in it. But it's actually going to share all of that old keys with the old version of the map.
And the nice thing about this model is that at any time, anyone can read the value that's held by the agent without obtaining a lock, because it's a series of snapshots and each snapshot is immutable. So at any time it doesn't matter whether you get the exact one that sees the changes from the last version, you'll get the one that's current enough. In a concurrent world it doesn't make sense to believe that you always have the absolute newest version.
Glover: Right. Exactly.
Miller: So it sort of, it allows reads to be extremely cheap and it allows writes to be safe and those are very important properties for lots of different kinds of data. So that's Clojure agents. GPars agents are actually a little bit different and I think they're actually changing ... well, I don't know that for sure.
But I think in GPars, they actually are implemented using the actor functionality under the hood. So they might actually be bound to threads, I don't remember now the details of that. So they are a little bit different than Clojure agents.
Miller: And then there's some other functionality that you can usually get, like if you want to be notified of state changes, then you can do things like that. That's something you can do in Closure but you can't do in the current released version of GPars, but that is a new feature that's on the way. Things like that.
[END PART 1 of PODCAST] [BEGIN PART 2 of PODCAST]
Miller: I don't know anything about Oz so I'll not pretend that I do. And the notion of data flow variables, I believe did not originate in Oz, although that usually given as sort of the canonical programming language example but uses them a lot. But I don't really know Oz well enough to say that one way or another.
So the idea behind data flow variables is that you declare this sort of variable and it will be assigned a value exactly once. And you are allowed to try to obtain the value of it and when you do that, you'll basically block until the value is available.
And so you can think of programming this system is kind of like, sort of the usual example that people give is it's kind of like a spreadsheet. And that's a useful way to I think, I'm not sure that's actually a great example of it, but it's a pretty good mental model to think about, that you have some cell on a spreadsheet and you put a formula there and when you supply values and the cell is referred to by that formula, then the value in the cell with the formula shows up. You see the value all of a sudden.
And as you change values, they sort of propagate. And that's the part that actually doesn't translate well into data flow because they're single use variables in data flows. So once you set the value, it never gets changed again after that.
So that's kind of limiting in some ways. So sort of the more useful thing that's built over the top of that is this thing ... in GPars, this thing called data flow streams. And the streams allow you to have that propagation effect and set up this channel where a thread in one place can put something on a stream and that value can be read on the other side.
And sort of the best corollary to this in the Java concurrent library is the synchronous queue which is not a really super well known part of the concurrency library, but it's one that I've used a lot for very similar purposes.
So the synchronous queue is actually a zero length queue, which initially sounds stupid, right? Because the whole idea of a queue is that you can pass things through it from producers to consumers, right?
So in a synchronous queue, when a producer tries to put something on to the queue because it has zero length, it has to block. And if a consumer comes and tries to read from the queue, the queue can't hold anything so it has to block.
So in that case, what it forces is that for a value to be transferred from producer to consumer, both the producer and the consumer have to show up at the same time. Or they can show up in either order, but once they both get there, the value is transferred and then they unlink. So it's a great way to transfer a value across threads.
Like there's lots of cases where you want to do this, where I'm going to spit off a bunch of threads and they're each computing something and when they're done computing I want to transfer their value back to me. So you can do that by putting it in a thread safe data structure, and this is one way to do it, is to sort of transfer that value through a synchronous queue.
So I think of that as being very similar to the data flow variable. I'm not sure, nobody else, I've never talked to anybody else about this, so I'm not sure what other people think, but that's my mental model of it. [LAUGHTER]
And then the data flow streams are actually very similar to something that's being added in JDK 7 in the concurrency library which is called a transfer queue. And it's actually a new queue interface that's being added, I think the only one that's being added in JDK 7.
And it's basically the idea of this ... it's the exact same idea as the
SynchronousQueue except that it's not zero length. You can actually stuff multiple things into it. But it still has some of the same properties as far as meeting producers and consumers to kind of meet to get that functionality.
Glover: So, I guess, where does this leave a developer? So we talked about agents and actors and various
Java.util.concurrent libraries, queues, data streams. Is it one size fits all or are each of these somewhat better designed for certain domains? What are your opinions there?
Miller: I think that's something that people are trying to figure out. [LAUGHTER] So I mean, I have used a number of these different models for different things. I think, I mean in certain cases spitting up a thread and using locks is perfectly okay. I think for cases where you want to have a pool of workers working off of a queue, the ideas behind executors and behind fork join are excellent. And that's an excellent paradigm for that kind of a batch computation or background processing and those kinds of things. Those are great tools for that kind of work.
As far as passing data values and coordinating them between threads, I think dataflows are really interesting. It's taking me a long time to sort of wrap my head around what they are and where they're useful. But one place where I see people starting to use it a lot, especially the GPars support for it, is in concurrent testing.
So cases where you basically create a data flow variable and you give it to a thread or you give data flow variables to a bunch of threads and then you launch them off to do a bunch of concurrent stuff. And then at some point you want to check assertions, right?
Miller: And when you're writing concurrent test, it's often very complicated to properly assert in remote threads that something has happened and handle all the proper exception handling and make sure that the main thread knows about it and can report those failures.
And so what data flow variables allow you to do is that the main thread just launches all these threads that are doing things, and at the end it's just asserting things on the data flow variables. And those will block until the other thread eventually figures, gets to a point where it can assert all those things. So it's a great tool for writing multithreaded unit tests, if you happen to need to do that.
Glover: Yes, no, yes, this is very ... it makes sense.
Miller: Agents people have found that's a great way to deal with and particularly with asynchronous coordinated state changes, especially in Clojure, the sort of secret sauce there that works in tandem with the STM system, so they work together. So that's a model that for some problems works really well in Clojure.
And then actors, obviously there's lots of people doing interesting stuff with actors these days. Most prominently in Scala. If you've heard of the Scala Akka library that Jonas Boner and a lot of those guys have been working on, that's a fantastic library that integrates the concepts of actors and STM to create transactional actors and do things like that.
Glover: Oh, okay.
Miller: And they're doing some amazing work. So that's a really fascinating library and a fascinating place to look.
I think that a lot of these models, though, are still pretty low level. So I don't know, going back to your original question, as far as what is a developer supposed to do. I think that in a lot of cases the answer is not to use any of these necessarily but to have, to write a library or a platform that allows you to avoid having to think about those problems as much as possible.
So and you see that in a lot of enterprise Java frameworks or if you look at different web frameworks, most of those try to abstract you from needing to care about concurrency at all. So they give you ... you supply code that is run in a single threaded contact. And they supply libraries that allow you to exchange state and store state and things like that and those concurrency concerns are handled at the framework at the library level.
Glover: Interesting. Yes, every time I think about ... it comes to mind the servlet model or even EJBs for all their aspersions that have been cast towards EJB, you know, you never had to deal with threads in EJB.
Miller: So, yes, I mean that was one of the key features of that model, is that it abstracts you from needing to worry about many of the concurrency issues.
Glover: So aside from obviously reading your article here on developerWorks, where are some other avenues or places that developers can get information about some of these models?
Miller: I really think that's it, you read my article.
Glover: That's right, I hear you, you're done.
Miller: No, obviously my article is just a taste of many different interesting things to go look at. So if you're interesting in just general concurrency topics, Java Concurrency in Practice by Brian Goetz and others is a phenomenal bible for the Java concurrency model. So you really can't ask for a better book or a better resource for that. I've read it many times, still continue to pick it up as I need to.
There are a number of good books out there that have come out in the last few years. They're not all necessarily Java books, but there's like, there's one called The Art of ... it's either The Art of Concurrency or The Art of Multiprocessor Programming, something like that. There's a really good C++ multithreading, I'm sorry, I don't actually know the names of many of these off the top of my head.
Glover: No problem, no problem.
Miller: But as far as there are a number of Clojure books out now that go over the Clojure model pretty well. Same for Scala so if you want to take sort of the language-centric approach. There's not any good book out there for GPars concurrency as far as I know.
Miller: So if you want to write one, that would be a great opportunity. I'm not going to, I'll leave that open. [LAUGHTER]
Glover: And where can we get GPars? Is that off Codehaus?
Miller: Yes, if you search for GPars it's easy to find. You can get it off of all your favorite neighborhood repository or wherever else you find JARs and that has integrations into all the popular places you would want it to be integrated in the Groovy world. So in places like Grails and Griffon and Gradle will have plug-ins or integration with GPars.
Glover: Excellent, excellent. And then, can't jump off just yet. I want to know Strange Loop: Are there any interesting talks regarding concurrency happening this year?
Miller: Of course. That's obviously the main benefit of running your own conference is you get to have exactly the talks that you want to have. So the conference reflects my interests pretty directly because it's mostly under my control.
Glover: So, are you giving all the talks?
Miller: No, I wouldn't want that. Nobody would want that, I think. And yes, sort of the downside to that is that when you run your own conference you tend to plan your dream conference and you don't actually have a chance to go to any of the talks.
Glover: Exactly, yes.
Miller: So its actually a horrifying nightmare in that regard. But, yes, there are several concurrency talks. Steve Harris from Terracotta will be talking about the Terracotta tool kit which is a sort of distributed concurrent programming toolkit to build scalable Java systems.
There will be a great talk by, I'm blanking on his name right now. The guy that does node.js.
Glover: Oh, node.js is awesome. I can't remember his name either.
Miller: Ryan Dahl, I'm sorry. So he's doing a talk on parallel programming with node.js.
Glover: Yes, he's from Google, right?
Miller: No, he's at Joyent.
Glover: Wasn't the node.js guys the same ones behind V8?
Miller: You're beyond my level of knowledge. So I don't know.
Glover: That's cool. Yes, okay, all right.
Miller: And then, one of the keynotes, one of the ones that I'm most excited about, is Guy Steele will be talking about parallel programming and his ideas about where parallel programming is going and how it should be integrated into programming language or how it shouldn't.
And Guy Steele, for those of you who don't know, is pretty much a legend in the programming language community. He was involved in the very, very early days of Lisp and Fortran and Scheme and C and ... [LAUGHTER] ...also worked on standardizing ECMAscript and Java for several years.
And now currently works on ... and he literally, every single one of those languages he either helped create or helped standardize and was on the original spec committee for all of those specs. So he's been in the thick of it for as long as anybody has been in the thick of it.
And he these days works on this language called Fortress which I mentioned earlier. Fortress is really a fascinating language. It's sort of, the idea behind it is really focused on the same audience that Fortran was focused on. So it's focused on the scientific community that needs to do parallel programming and scientific computing and that sort of thing.
And I think its being developed under some DARPA grants along with some other languages that are from other companies that are also sort of involved in the same grant programs.
And the basic idea is, there are lots of interesting ideas in it because it's a research language, but one of the ones that I find really fascinating is that it's sort of very over eagerly concurrent. So in general, every feature of the language is concurrent by default.
So if you write a four loop, by default all of the iterations of the four loop run in parallel. [LAUGHTER] And you can do things to make it not do that, but that's sort of the default mode.
And if you, for instance, call a function that has a bunch of expressions that are being evaluated as being arguments to the function, all of the expressions are evaluated in parallel by default. So it sort of pushes this sort of idea of concurrency really far to sort of see what pops out of it.
Glover: Yes and you have to jump through hoops to not to be concurrent. That's interesting.
Miller: Yes. And there are lots of other interesting ideas in the language. So he's been thinking about this sort of notion of writing concurrent programs that run on parallel processors and how that affects our programming languages really deeply and that's what his keynote is going to be about. So I'm super excited about hearing that one because it mashes up with many of my interests and someone that I find to be really a hero of mine in the programming world.
Glover: Yes, yes. I'm sure you speak for a lot of us. If there are listeners out there that can't attend Strange Loop, will you post slides or videos or anything?
Miller: Yes, the bulk of the slides will be posted, assuming that based on interest from speakers and things like that, but last year I was able to publish virtually all of them, so I expect to do that.
And then I'm also partnering with InfoQ to report video for probably about 30 or 40 percent of the talks, including the keynotes and Guy Steele's keynote that I mentioned. So those will be available over time as they get published.
Glover: Excellent. Well, Alex, I speak for all listeners when I say, thanks for your time, thanks for educating us on the various different models out there. I found it very interesting. I have some things I need to now go look up and study. So I'm sure, again, I speak for everyone listening that this was awesome. Thank you for your time.
Miller: Oh, no problem, I'm happy to do it.
developerWorks: That was Andy Glover and this is the developerWorks podcast. Follow us on iTunes and at ibm.com/developerWorks. And specifically keep track of Andy's interview series at ibm.com/developerWorks/java. Thanks for listening.