I started in FORTRAN (without a number), then SNOBOl, ALGOL, PL/1, 'C', Pascal, C++, Java(ugh!), and now Perl (last 8 years). And the one constant to be found here is that each language attempted to "abstract away" some complexity from the language it is attempting to usurp. And in "dumbing down" or "abstracting" the understanding of the basic concepts, the programmer is required to understand less and less of the fundamental concepts.

Just look at what the answer to my question has brought out. " use 'require' rather than 'use' in threads to control bloat"; that is something you would never find in a book, since it would require the reader to know too much about the underlying concepts, implementations and philosophies. And the implementation of Threads:shared hasn't even been touched. I really want a "thread shared Hash that is tied to a dbm', but I am settling for my own disk journaling system to recover from any "unplanned termination".

And would many of the readers have the foundation in 'computer science' to understand memory management or the complexities of parameter passing or 'varargs' ( or how about 'varargs' on a risc processor, with no stack)? Yet, to solve the hard problems, the programmer must understand what lies beneath. Dive below the abstraction!

I love Perl, and abstraction is great; but we should never forget how to program assembler in a linear address space!

A real world example that may have lost $1,000,000
http://www.codeproject.com/KB/showcase/IfOnlyWedUsedANTSProfiler.aspx