Verification Languages: 3 points to ponder beyond "which one?"

The authors are very right in observing that the selection of a mere tool/language does not mean you are almost there when it comes to verifying a meaningful chip.
There are several tool independent steps which must be taken in the right direction even before a tool/language is selected :
a) Verification begins at the architecture definition stage in the form of performance modeling and designing for verification. A meticulous tool independent plan for this is a must.
b) A thorough tool independent test plan that covers all stages of design from block level RTL -> chip integration->gate level netlist->system level validation->FPGA->eval boards is a must.
c) Evolving an assertion & a coverage methodology is a must.
d) Running application code is a must.
One can then select a language, keeping all the above requirements in mind.
But even then, no matter what language/tool is selected, the final quality of the verification platform cannot be better than the skills of the verification engineers.

I like the analysis and the questions asked. I get the feeling that many people don't really inquire "Do we know what we're getting ourselves into?" on the onset of the project. Schedules are frequently set by wishing, rather than in-depth analysis.
I think that one of the biggest mistakes in verification is poor definition of the expected outcome of the project. This is a double edged sword, on the one hand if you don’t clearly state what features in which configuration are important than people might skip one of the critical ones, but overstating and defining an amorphous “0 bug goal” can have your engineers rat-holing for weeks in inconsequential spec gibberish.
Back to languages; Once you have defined a clear project goal, it will be easier to research which language gives you the capabilities to define your simulation goals (functional coverage points), create meaningful random data, and execute your project smoothly.