Anyway, I hope this posting motivates some to inform themselves of the principles by which their regular tools do their jobs.
In my mind, if you use something more than occasionally, you should have a good idea of its strengths and weaknesses. This, however, has nothing to do with cracking open the black box. It has to do with knowing the specs of the black box. That's just doing your homework.
The perfect example, in my mind, is a motherboard. I have an extremely basic, almost monkey-level, understanding of the circuitry my livelihood is based on. But, I do know how to read specs. So, I know what machine makes a better DB vs. web server. Yet, I can't draw a logic gate to save my life.
Another example would be a choice of webserver - Apache vs. IIS. There are very valid reasons to pick one over the other. Yet, I have never looked at a line of source code for either. In fact, I don't know .NET or ASP more than a week's worth of playing around. But, I can confidently recommend IIS over Apache, when it's warranted - because I know the specs.
Buried deep in the docs for 5.6.x is a statement saying that Perl's sort is implemented over qsort(). Back in CS 210, we learned that qsort() is pathological over nearly-sorted lists. That's just knowing the specs. I'm pretty sure you didn't read the code for the implementation of sort and work out how the box does things; you read the specs.
------
We are the carpenters and bricklayers of the Information Age.
Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose
I shouldn't have to say this, but any code, unless otherwise stated, is untested
In reply to Re: Bitten by the worst case (or why it pays to know whats inside the black box)
by dragonchild
in thread Bitten by the worst case (or why it pays to know whats inside the black box)
by demerphq
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |