> More importantly, the average programmer will have access > to parallel programming libraries like the stuff coming > out of M$ for .NET. There's likely a spate of such > libraries for Java and in the open source space as well > (although none come to mind!)
Until Amdahl's law is repealed, or to put it another way, when client code is inherently parallel, all the libraries in the world won't make sequential code, chopped up into little bitty pieces, be any faster than running said sequential code on one of the cores. It's simple arithmetic.
> > I think it is a matter of teaching and training. The world > is parallel.
Servers, sure. Clients, not so much. If that were true, then the Connection Machines, et al would have taken over the world. They didn't.
The industry needs to move toward strategies > to teach students and aged fogs like myself how to think > about exploiting parallelism.
Again, read up on the fate of massively parallel machines of the past. Note too, that those writing about Erlang, and such, concentrate on writing servers. That's not a coincidence.
> > I remember when Objects hit the corporate world (at least > my corner of it). There were folk saying that the average > programmer could not understand objects and could not > effectively develop good object-based applications.
I've been in that world, too. The OO that goes on there ain't OO in any meaningful way. javBOL is the reality.
Yes, > it's an open question as to whether or not the average > programmer 'understands' objects but it's a fact that > corporate America's IT shops are using object technologies > - maybe poorly - to develop mision-critical apps.
Ain't no maybe about it. And it defeats the purpose of OO. Read Holub.
> > I expect the same thing to happen with parallel > programming in the near future.
Not likely. OO, both in theory and certainly in practice, is largely about syntax. Corporate java, certainly, is awash in Data Objects and Action Objects. That ain't no OO. Real OO is inherently event driven, message passing, among autonomous full fledged Objects.
Parallel programming (and concurrent programming, which may or may not be the same thing), which is more efficient than the sequential equivalent, requires parallel semantics in the Real World being coded to. Again, servers fully qualify; standalone/client applications (not the OS supporting the client machine) not so much.
Those who proclaim that client coders will/should be learning parallel/concurrent languages/paradigms need to step forward and state the classes of problems which *require* these paradigms. And offer up some specific examples for those classes.
Flat View: This topic has 15 replies
on 2 pages
[
«
|
12
]
Previous Topic
