Quote:
Originally Posted by gaming_mouse
Isn't the thing you're describing just plain old procedural programming? Where the data and the methods that act on it are independent entities (as opposed to being kept together, as they are in OO-programming)?
Sounds like a rebranding effort to me....
EDIT: fwiw, i found this: http://gamesfromwithin.com/data-oriented-design
You're right that data-oriented might seem a bit like procedural programming... but I think there is an important difference, even if its a bit nuanced.
Imagine a factory with an assembly line... you can bring in efficiency experts to tell you that you can increase productivity if the workers have a wrench in each hand. Thats focusing on the procedure and that might be a big benefit.
But, its all moot if you cant get the raw materials into the factory fast enough to take advantage of your really efficient assembly line.
That's what data-oriented design is all about. Making sure you've always got a steady supply of raw materials.
Quote:
Originally Posted by daveT
I was beating around the Clojure bush on those questions, as I'm starting to dive into the language. ...
As for the other languages you list, they seem to be hardware-specific outside of C++11, but I think that it's all interesting stuff right now. Definitely an exciting time to study computer programming. What do you think the future will be? All C-based for the next 30 years before something else pops?
Clojure seems pretty cool... but as you note, its built on the JVM, so you still have that limitation.
Anything that makes concurrent programming easier, its going to be a good thing. Like I mentioned, thats where the hardware is headed.
But like I also mentioned, thats only half of it. The other part is SIMD.
If you look at how GPUs are architected, they essentially look like a collection of *really wide* registers... like hundreds or even thousands of bytes wide. This is sort of where CPUs are headed too, and if you want to take advantage of that, you've obviously got to have a language that can handle it.
Actually, of the languages I mentioned, only CUDA is really specific to a platform.
For the future? Yeah, I suppose C-like languages seem to be it... if only because they match and can adapt to the hardware so well.
It was interesting there for a while when there was a lot of interest in making "Java chips". But again, I just think the direction that hardware design has taken has really moved past where the Java bytecode is .
What Intel was doing with "Larrabee" probably would have suited Java very well. It was all the massive concurrency but without the SIMD (hundreds or even thousands of Pentium cores on a single die). But in the end, they havent been able to get it to compete with what nVidia and ATI have been doing.