Linked by Thom Holwerda on Fri 19th Mar 2010 13:00 UTC, submitted by Jim Lynch
Thread beginning with comment 414534
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/21/13 21:38 UTC
Linked by Thom Holwerda on 05/20/13 11:29 UTC
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
Linked by Thom Holwerda on 04/18/13 11:21 UTC
More Features »
Sponsored Links



Member since:
2006-01-02
Programs aren't pervasively multhreaded, because the hardware and software platforms cause diminishing returns for the hours a programmer puts into the work.
So, we shouldn't make it easier to use resources in a more parallel fashion, because programmers aren't already doing it well.
Isn't that a bit of a chicken-and-egg situation?
By making it easier for the developer to make use of those resources, making parallel applications can become easier, as we'd see more of them being made. This idea is one of many to tackle that problem, this time by just getting out of the way.
Ideally, you won't end up needing to code for a bunch of cores, but will have the whole dev system, from the bottom up, making it easier to use many processes and threads than to not do so, making gains from having more of them as automatic as having a faster CPU is, today...but without using functional languages everywhere to do it.
Edited 2010-03-21 06:46 UTC