Article Discussion
Time is the New Memory
Summary: In this interview, Clojure creator Rich Hickey suggests that the problems people associate with shared state are problems of time. He compares the lack of automatic time management in today's mainstream languages to the lack of automatic memory management in languages such as C++.
47 posts on 4 pages.      
« Previous 1 2 3 4 Next »
The ability to add new comments in this discussion is temporarily disabled.
Most recent reply: October 2, 2009 2:25 PM by Raoul
Raoul
Posts: 20 / Nickname: raoulduke / Registered: April 14, 2006 11:48 AM
Re: Time is the New Memory
October 2, 2009 2:21 PM      
> It seems to me that all advancements with respect to
> languages have somehow been rooted in removing choice. GC,
> a now trite example I think, said to developer's "Managing
> your own memory is hard. No, really, it's hard. Trust me.
> So I am not going to let you do it."

some people have said that <a href="http://lambda-the-ultimate.org/node/2990">gc is like stm</a>. there are probably some high-level parallels to be drawn.

memory and resource management are more complicated than just leaving it up to the GC. people forget that, and we end up with really crappy code.

and on the whole i really like GC, don't get me wrong.
Raoul
Posts: 20 / Nickname: raoulduke / Registered: April 14, 2006 11:48 AM
Re: Time is the New Memory
October 2, 2009 2:25 PM      
> 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.

only if you were a really good, careful, programmer in the first place. like, if you are the kind of person who draws little maps on grid paper when playing adventure games.

i love gc. really. but it is such a small part of the overall story of memory, let alone resources in general, management! ask any maintenance programmer who has had to try to fix the bloody memory leaks in a java/c#/lisp/python/whatever-gcd-language-you-like system.

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

here's the problem: semantics.

at the moment, we do not have an AI that can say what parts of code need to be in the same transaction (this is the "external" race problem i said before). therefore, we cannot have a miraculous approach to concurrency where we omit more code (per how you describe the wins of GC).

sincerely.
47 posts on 4 pages.
« Previous 1 2 3 4 Next »