I wouldn't call it a fault per se. You must also acknowledge that the lower the level of abstraction the more work the programmer has to do, and the more details the programmer must manage e.g. big endian vs little endian ordering, 64 bit vs 32 bit development, etc, functions & libraries vs first principle code. I think an analogy that fits this scenario is you don't have to know how an engine works to drive a car. Although if you do know how an engine works, you'll probably be a better driver. On Wed, Jul 8, 2009 at 8:52 AM, wesley kiriinya <kiriinya2000@yahoo.com>wrote:
Just sharing another thought from the programming world.
Lattely I've been forced to look into assembly programming. And with awe and surprise I was struck! I came to appreciate the processor and what it goes through.
More importantly I came to appreciate the connection of what happens in the processor and what is stored in memory. I was especially struck with the hoops the processor has to go through in order to fetch data from data structures in memory which are as a result of high level programming language features.
I will take a simple case of data alignment. Those in the Java world are probably in a worse of case because they cannot choose the alignment for data allocated in memory (or may be Java does it for simple cases). The processor loves when the memory address of the data it fetches is aligned to a memory address value that is a multiple of the size of the data type. For example an integer is 4 bytes in size therefore an interger data should be in a memory address value that's a multiple of 4. For data structures then the alignment is according to the size of the data structure and this is where a high level programming language might screw up. Due to inheritance and polymophism a virtual table for function mapping is created in memory and the programmer has no control of that therefore the class data structure might not be aligned.
High level languages seem to be created for the purpose of making modelling of real world concepts easier for the programmer, thus OOP. They seem to ignore the other world, the processor world. However compilers attempt to optimize the code for the processor but not always archieving the optimizations.
Above is just a simple case. It's not completely explained but it introduces the idea. It probably won't make sense to someone who doesn't know C++ and processor stuff but atleast it's information for those willing to go under the hood!
This doesn't matter for applications that are not concerned about performance.
O_O.
_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks Other services @ http://my.co.ke Other lists ------------- Skunkworks announce: http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks-announce Science - http://lists.my.co.ke/cgi-bin/mailman/listinfo/science kazi - http://lists.my.co.ke/cgi-bin/mailman/admin/kazi/general