|
Re: Time is the New Memory
|
Posted: Sep 22, 2009 11:14 PM
|
|
Hi Carson,
> The current state of affairs is this: most of the time I > can be stupid. When something concurrent comes up, I have > to be smart for a bit to get something out of > java.util.concurrent.* set up, and then I can forget about > it. > > The proposed solution is that I change the way I code > everywhere to make the concurrent case easier to deal with > for the library, language and hardware developers. > I think the proposal (by which I mean Rich's idea of language support for auto-time management) is intended to make the case easier to deal with for you, not for them--primarily the concurrent case but also the sequential one. > But I'm already doing pretty well over here in > Imperative-stan, with the web server and database doing a > lot of the concurrency heavy lifting for me. I don't want > or need to change anything to get my web app running > pretty well. Or at least well enough. So why should I > adopt an awkward programming methodology across the board > when I'm doing pretty well, day to day, without it? > If you're not feeling concurrent pain and aren't overwhelmed by accidental complexity, then you indeed have no need to change anything. But it doesn't sound like you're really doing much concurrent programming, where you're trying to do concurrent things directly. If the library is doing it for you, then that's a good thing. A big design goal for J2EE was to take care of threads so business programmers could focus on writing *sequential* business logic.
But not all apps are like that. I am just polishing off the 1.0 release of ScalaTest, and it is a concurrent app. I use one Scala actor, a bunch of stuff from java.util.concurrent, one class that's synchronized, and one that uses wait/notify (and is synchronized too of course). The rest is sequential: a mix of imperative and functional style, but leaning primarily towards the functional style because I felt it made my code better.
I'm also not sure functional programming is as much awkward as it is unfamiliar to the mainstream. I.e., it is awkward to people because they are unfamiliar with it. I find it awkward sometimes, especially when I would need to use recursion to be full-on functional. I do use recursion sometimes, but since I'm working in Scala, I can also just use a while loop and a var, and I do that from time to time. I make sure it is all local, so each thread would get its own copy, then it's perfectly fine to do it the way its done in Imperative-stan.
If you forget the word "functional" and just say final variables, immutable objects, and methods that just return a value based on just the passed data without having any side effects, that really doesn't sound that unfamiliar or awkward. String is an immutable object. Is java.lang.String awkward for Java programmers to use? How about String.valueOf(5)? That's a pure function. I just operates on its input, returns a value, has no side effects. I doubt that's awkward for Java programmers, and neither are final variables. What is awkward, probably however, is using recursion instead of looping. Recursion isn't that hard to understand and I figure most Java programmers know what it means and how to do it, but it's not the way we usually have done things in Imperative-stan, so we're not used to it.
> Compare with the proposed analogy, the advent of GC: > pre-GC I had to be pretty smart all the time. Then GC > came along and, to a reasonable approximation, I could be > pretty stupid all the time. (Or apply my admittedly > limited brain power to problems other than memory > management.) I wrote the same code I always did, but just > left off the memory management bits. > > That's dramatically different than proposing I change my > entire programming style. GC was an unqualified, > sand-pounding, sing-it-from-the-hilltops win with a > negative cost: they *paid* me not to write code! > Glorious. > > Until I see a concurrency proposal that is that big of a > win with very little cost, I'll remain skeptical of wide > adoption. STM might be it, but it's going to have to be > dead simple (from the users perspective) STM that melts > into the background for most developers. And I remain > skeptical that this is, finally, the moment that > functional programming has been waiting for. > My sense is that there isn't one answer to concurrency, that we'll need a good toolbox from which to choose. Java provides locks and monitors in the language, and java.util.concurrent offers quite a few options in the standard library. Scala adds in actors and will add more things in the future. Clojure also provides several different options, CAS, STM, Agents. Plain old immutable objects and pure functions are helpful too. But I don't see any silver bullets. > As always, worse is better, >
|
|