Hacker News new | past | comments | ask | show | jobs | submit login

We can't keep stepping backwards to support changing processor technologies. Concurrency should be abstracted away from the programmer, and handled on a compiler level, irrespective of your programming language.



I think the fact that we need to step back when processor technology changes shows that we (the software community) lack a truly pervasive concurrent programming model. Does Clojure really offer a truly orthogonal solution to this problem?

And when I say "problem" I'm really talking about the scalability of fine-grained concurrency techniques formalized by Dikjstra (http://en.wikipedia.org/wiki/Semaphore_(programming)).

I agree that programmers will eventually have to be relieved of concerns such as critical section but we will never escape questions like "what are the parallel aspects of this algorithm (or library or application)". A compiler will never "discover" large-scale concurrency patterns in any mainstream language (at least to my reckoning). Maybe interpreted languages will ultimately lead the way.


sure, and you can get a very minor boost. the problem is that the computer can only safely do so much concurrently. if you think otherwise, then go ahead and make a compiler that supports concurrency "irrespective of your programming language" in a way that is sane and performs well.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: