If they lose the appeal, do they have to pay interest from the date of the original decision?
I don't think so, and it was always somewhat expected that this legal action would be drawn out. The money in question is peanuts anyway.
The interesting point here is whether Microsoft's legal tactics will work more than once in Europe. It seems the top brass over here are willing to tell them where to go; from accounts I've read, they did exactly that to Microsoft's CEO during last-minute negotations. In that case, it's a good bet that this was the "warning shot". MS will probably lose the appeal (I though it was a maximum of three more years for the fullest possible legal process to run, BTW) and on the basis of that result, any future misbehaviour along similar lines will rapidly be slapped with a much bigger fine from a solid, established legal basis.
If I am a small or niche vendor though and a viable free as in beer OS solution then I can pretty much kiss my business goodbye and find something else to do.
That would be a very serious concern, but for that "viable free as in beer OS solution" bit. Generally speaking, the OSS projects that have succeeded are those that bring in the mass support necessary for OSS's advantages in rapid development and maintenance to shine through: Linux, Mozilla, OpenOffice, Internet tools, CD rippers, etc. In those mass-market application areas, there are viable OSS alternatives.
However, for the smaller, niche vendors that you mention, I'm not sure I see the opposition. I can't think of a single OSS product that successfully dominates a small-scale niche. By definition, that market is unlikely to attract a wide base of volunteer support, and without that, OSS has no selling points.
Re:Don't elevate the status of 'Think Tanks'
on
When Think Tanks Attack
·
· Score: 2, Insightful
The status of a 'Think Tank' report is no different to comments on Slashdot although they might be better researched and spell-checked. [Emphasis added]
Don't count on it. I suspect the average/. reader (neglecting the Open Source R0x0rs idiots) is far more widely read about these issues than most of the people who write drivel on behalf of MS, and quite capable of doing their own research.
Presumably Microsoft must convince someone to buy their stuff with tactics like this, or they wouldn't spend so much money on it. I can't say I've ever met that person, though.
Re:Thats why we need to change the interview proce
on
Resumes for New Grads?
·
· Score: 1
I find your sig particularly ironic in light of that comment.
Did it not occur to you that there's more to finding the right person for a job than looking for the most years of experience in the most skills (by a specified name)?
Say everytime a virus has to be removed from a Windows box because a user clicked an attachment a little value increments by one. Once it reaches 10 or so the computer starts throwing up helpful hints...
For large corporations, I always quite liked the idea of sending occasional spoofed e-mails with dodgy attachments, similar to your average e-mail virus. If a user opens the attachment, MIS gets notified, and a "three strikes" rule applies.
The first time, they get a polite warning about their behaviour and how damaging it could be if that had been a real virus, and a friendly reminder to read the corporate IT policy. You're not trying to piss these people off and alienate them, you're trying to educate them.
The second time, they get another warning, and all non-essential access revoked for a week: no personal mail, no web browsing, nothing. You might mention that this is the sort of thing that viruses try to do to everyone in the company, which is why it's so important not to run attachments carelessly.
The third time, they get the book thrown at them: automatic formal disciplinary procedures, loss of all personal usage privileges and direct monitoring of their usage by MIS, etc.
Of course, you need some very senior people on your side to make this work, particularly because managers are often the most incompetent in this respect. However, if your CIO has any clout at all, a quick explanation about the impacts of a real virus on the company and the most likely way to get one should get the CFO and CEO on-side.
The nice thing about this approach is that it's fair. No-one who's not a liability will be affected. Anyone who's simply naive will be given a friendly reminder of the danger, and how to avoid it. You have to screw up spectacularly several times before really bad stuff happens. And if you really are that stupid, inconsiderate or incompetent, the rest of the organisation doesn't have to suffer the risk you bring to their livelihoods.
Their case in point was an employee--not a contractor, but a full-time employee--that brought his home PC in and attached it to the corporate network. [...] Of course he didn't know it, but he had a virus which spread like wildfire and infected hundreds if not thousands of PC's.
Didn't those MIS experts think to install anti-virus software on any of those hundreds-if-not-thousands of PCs?!
Remember, you have to write something that can give the reader a grasp of who you are in 10 seconds. Otherwise, the whole thing will end up in the trash basket.
That's very true.
Actually, as I understand it from people who do this for a living, you have around 20 seconds to make a first impression on a very quick scan. That's mostly first-page stuff: does this person have roughly the right mix of skills, and do they have roughly the right level of professional and academic experience?
If you don't get circular-filed at that point, you'll probably get a reasonable, slightly deeper reading: they'll look at the more specific details of past work experience and higher academic qualifications. If you mentioned a web site and your CV is being read by a real person not an HR computer, they might take a look at this stage, too. If they're still reading worthwhile stuff after a couple of minutes, you're probably shortlisted.
CVs might include more (relevant!) detail than that so that they can form the basis for a conversation at interview, but remember that it's a conversation starter. It should provide the interviewer(s) with a neat list of things to start talking about, and you should be able to expand on any of them as they wish when you meet them in person. You don't need to tell your whole life story!
I'd prefer the one who left the building quickly and efficiently, confident that the fire wardens would have set up an automatic alarm so the fire service were already on the way (but they'd be calling to check anyway), that the IT group had set up off-site back-ups so the important tapes weren't in the building anyway, and that the designated person would be checking everyone was assembled correctly outside, so he'd better get his ass out there before they think he's missing.
You're looking for a manager, and the manager's role is to make sure everyone doing the "real work" knows what they have to do, and is able to do it.
If I'm a manager, and I can't manage people who are smarter and more capable than I am, that I am the organizational bottleneck. It is imperative to be able to work with people who are smarter than you are.
That's so true. I'm reminded of one of the most touching scenes in The West Wing (seris 1, episode 12, "He Shall From Time To Time"):
President Bartlet: If anything happens... You got a best friend?
Secretary of Agriculture: Yes, sir.
President Bartlet: Is he smarter than you?
Secretary of Agriculture: [Laughs] Yes, sir.
President Bartlet: Would you trust him with your life?
Secretary of Agriculture: Yes, sir.
President Bartlet: That's your chief of staff.
I'm a huge fan of that series for many reasons, but the way they sometimes make a point like this so clearly and accurately is definitely one of them.
if there are 900 applications in the pile, and you have to pare down the list almost immeadiately to a more manageable fifty candidates or so, how do you make the cut?
If you want 50 out of 900, you probably just pick all the comprehensible and not obviously lying CVs you've got, and you're done.:-)
But seriously... Of course you have to filter, but HR drones who do it with tick-boxes and don't know what the job actually involves are the worst kind of counterproductive. In particular, they frequently fail to understand the relationships between different-sounding skills in IT, and consequently can't gauge how well an applicant's skill set really matches up to the requirements of the job (assuming they even understand the latter).
Basically, HR tend to look for all the direct matches, but you'll be very lucky to find a perfect match for both the technical skills and the context you'll use them in. Usually the difficult -- but more important -- part is looking at the supporting skills. Has this person used the right technical skills in other contexts (and if so, how close are those contexts to yours)? Have they used related technical skills in the right context, so they have experience of that problem domain and its quirks? What is their breadth of related skills overall; how adaptable is this candidate in practice?
To give a concrete example, suppose you need an intermediate-level programmer for a particular development project, which is written in Java. Most HR people I've encountered will look at a CV, look for experience using Java, and just bin those with the fewest years of experience or something equally black and white. A significant number would fail to appreciate that any J2SE or J2EE mentioned on the CV is Java work, and give it no credit at all.
Now, someone who understood would be looking for what parts of Java were used. There's a world of difference between writing end-user apps with Swing and writing back-end J2EE code! They'd be looking for whether the previous uses had been in related contexts or not, and they'd be looking for general experience with things like OO programming languages, distributed systems, use of Java-related tools or other programming languages with similar characteristics, etc.
Of course, as well as technical skills, you're also looking for any useful soft skills: is this candidate used to working in a large/small team; do they have any management/leadership experience that might be relevant to this position; do they have "customer-facing" experience? Often these will be far more important distinctions between similarly technically qualified candidates than an extra year using this or that specific tool.
The thing that always gets me is that a lot of HR people claim this is all too difficult to do in practice, and with 900 candidates you have to shortlist before you can look at this level of detail. What I don't understand is what value the HR people add at all, if they're just going to run the CVs through an automated system without giving them even a minute of informed personal attention each to get the right people on the shortlist. You pay your HR people to facilitate getting the right people into your organisation. Giving each potential candidate that minute or two during shortlisting, so the more technically knowledgable people can then interview the best directly, is exactly what a good HR department is for.
In the case of hiring, you could get near-perfect information by individually interviewing all 1000 applicants. But that would cost quite a bit more than interviewing only the top 10%. If you interview the entire field, what are the chances that someone not in that top 10% will bring enough value to the company to compensate for the much higher costs from interviewing more people?
I think there are two points to make here:
The sort of tick-box filters used by incompetent HR departments to find the "top" 10% often do nothing of the sort. I've seen plenty of schemes that would weed out pretty much everybody I'd want to work with in favour of certification monkeys, for example.
In a field like software development or system administration, someone in the (genuine) top 10% of the employee base really can be worth several times what an average worker is, if the work will benefit from their higher skill level.
Of course, it costs more to employ someone Really Good(TM), so that's quite a big if in the second point there.
And yes, programmers cost a lot more than hardware.
Yes we do, so it's a shame that dev tools suffer from the same syndrome: pretty much all of the big name compilers now take longer to produce output code than they did a couple of years ago, for negligible real world benefits in output code quality. When it takes half an hour just to build your app for a test run, you learn how much it costs to pay developers real quick...
BCPL. I was lectured on Comparative Programming Languages by the guy who designed it.
<Off-topic>
He must be teaching a different course these days; we were lectured on co-routines by the same man. Funnily enough, our course had the same name, though...;-)
That specific syntax looks like OCaml to me, though pretty much any functional language is going to support a near-identical construction, and plenty of other languages let you apply a function to a series of arguments similarly elegantly.
The AC beat me to it, but my immediate reaction was also that the line full of += expressions wasn't exactly a great argument for statement separators on this basis.
I care about how fast it runs the hundredth time and onward with "representative" data, whatever that means;-)
Sure, if you're going to run code hundreds of times on similar data sets, it's probably worth the overhead of dynamic optimisation. The thing is, not much real code actually does that, and you need to be doing it a lot to justify slowing everything down by a significant factor because of the overhead of the profiling process. In your particular environment, I can see that there might be big wins, but for most people I doubt there ever will be, hence my suggestion that most of the talk about run-time optimisation is hype propagated by buzzword-a-holics.
When Longhorn/Avalon finally gets released, the adoption I expect will be slow. We just spent all this money becoming proficient with.NET. Why change to the new system now? Unless you need the new features,.NET should cover most needs of application and web developers.
Of course, you can make exactly the same argument against switching to.NET in the first place. When you've got VB6, VC++ and MFC, Java, Perl and CPAN, and several other established technologies in the marketplace, each with a large developer base who already know their tools well, you need a compelling advantage to justify retraining all those people and rewriting all that code to use.NET instead. Given the obvious disadvantages of doing so -- it costs time and money, it's not a proven technology, it ties you into Microsoft products, etc. -- why would anyone bother, unless they needed a particular feature only available in.NET (which almost no-one does)?
Maintaining reverse compatibility is the right thing to do today. It's the right thing to do tommorow. It's the right thing to do next week.
But it is not free, and the costs grow exponentially with each iteration.
That's only if every new version has to support every old version. In practice, that is rarely a necessity; as long as you provide an upgrade path, it doesn't much matter if you only support the last version or two directly.
For example, contrary to the article's claim about VB.Net vs. VB6, I think Microsoft's first spectacular compatibility failure in recent times was when they changed the file format between Office 95 and Office 98. After a bazillion users complained that they couldn't work with their old data post-upgrade, Microsoft (eventually) released the missing functionality to do the conversion.
Of course, it would have been better to incorporate that from the start, but failing that, tools to convert between successive major versions usually suffice.
Maybe the same place as the worthwhile contexts where web hosting actually adds value? That is, there are a few specialist ones, but mostly they don't exist.
You're claiming that MSDN is impossible to read? I've been a programmer working in Windows development for years, using Win32 APIs, MFC, and various other bits and pieces. Say what you like about the interfaces themselves, Microsoft's documentation is, and always has been, comprehensive and remarkably well organised for something on that scale. Compared to typical *nix man pages or trying to sort out perldoc, it's paradise, and why the top-level poster thought giving the source code was at all equivalent to giving good documentation I have no idea.
If you mean hand-optimised, by a perfect developer with infinite time available to effectively generate his own run-time framework, then perhaps not.
If you mean the output produced by any contemporary optimising C++ compiler on realistic code, then I'm afraid you're rather behind the curve on compiler technology.
I certainly agree that running on a VM with JIT compilation should theoretically be a comparable speed to pre-compiled code (other things being equal). However, I think many people here are putting way too much faith in dynamic optimisation at run-time.
Sure, the VM could watch the code for the most-executed paths and re-optimise for them on the fly. Of course, that's pretty much equivalent to active profiling the first few runs through the code. As anyone who's waited while an instrumented executable profiles a large data set at 1/10 or less of its usual speed can tell you, active profiling is slow. In order to be of any real value at all, you'd have to run-time optimise only the most frequently executed code, with a good choice of how many runs to profile before you recompile it. Anything else is just never going to give you a worthwhile return on your "investment" in profiling overhead.
Basically, there are plenty of theoretically sound and practically evident ways for a VM/JITC approach to be as fast or even faster than a traditional compile-only approach, but run-time optimisation is not one of them; it's much more hype than silver bullet.
If one program uses profiling information to run faster than another, it runs faster nonetheless. [...] when I care about how fast a program runs I care about how fast it runs, not how fast it would run in some hypothetical nonexistent environment.
But do you care how fast it runs the first time, or the second time with identical data?
I wrote another post recently, on a similar theme. In that case I was contrasting Perl and C, but the same arguments would apply here pretty much unchanged.
That said, these benchmarks are still just as unrepresentative as they were the first time, still contain random and pointless differences, and still look like C++ written by a Java programmer (using new to create the objects in the methcall example is just weird in C++, for example). To be of any value in a language comparison, you'd need tests doing realistic tasks on a reasonably large scale with roughly equivalent algorithms; trivial code snippets like these wouldn't tell you anything except what you wanted to see in them anyway.
Slashdot Mirror
I don't think so, and it was always somewhat expected that this legal action would be drawn out. The money in question is peanuts anyway.
The interesting point here is whether Microsoft's legal tactics will work more than once in Europe. It seems the top brass over here are willing to tell them where to go; from accounts I've read, they did exactly that to Microsoft's CEO during last-minute negotations. In that case, it's a good bet that this was the "warning shot". MS will probably lose the appeal (I though it was a maximum of three more years for the fullest possible legal process to run, BTW) and on the basis of that result, any future misbehaviour along similar lines will rapidly be slapped with a much bigger fine from a solid, established legal basis.
Hey, I can dream, can't I?
That would be a very serious concern, but for that "viable free as in beer OS solution" bit. Generally speaking, the OSS projects that have succeeded are those that bring in the mass support necessary for OSS's advantages in rapid development and maintenance to shine through: Linux, Mozilla, OpenOffice, Internet tools, CD rippers, etc. In those mass-market application areas, there are viable OSS alternatives.
However, for the smaller, niche vendors that you mention, I'm not sure I see the opposition. I can't think of a single OSS product that successfully dominates a small-scale niche. By definition, that market is unlikely to attract a wide base of volunteer support, and without that, OSS has no selling points.
Don't count on it. I suspect the average /. reader (neglecting the Open Source R0x0rs idiots) is far more widely read about these issues than most of the people who write drivel on behalf of MS, and quite capable of doing their own research.
Presumably Microsoft must convince someone to buy their stuff with tactics like this, or they wouldn't spend so much money on it. I can't say I've ever met that person, though.
I find your sig particularly ironic in light of that comment.
Did it not occur to you that there's more to finding the right person for a job than looking for the most years of experience in the most skills (by a specified name)?
For large corporations, I always quite liked the idea of sending occasional spoofed e-mails with dodgy attachments, similar to your average e-mail virus. If a user opens the attachment, MIS gets notified, and a "three strikes" rule applies.
The first time, they get a polite warning about their behaviour and how damaging it could be if that had been a real virus, and a friendly reminder to read the corporate IT policy. You're not trying to piss these people off and alienate them, you're trying to educate them.
The second time, they get another warning, and all non-essential access revoked for a week: no personal mail, no web browsing, nothing. You might mention that this is the sort of thing that viruses try to do to everyone in the company, which is why it's so important not to run attachments carelessly.
The third time, they get the book thrown at them: automatic formal disciplinary procedures, loss of all personal usage privileges and direct monitoring of their usage by MIS, etc.
Of course, you need some very senior people on your side to make this work, particularly because managers are often the most incompetent in this respect. However, if your CIO has any clout at all, a quick explanation about the impacts of a real virus on the company and the most likely way to get one should get the CFO and CEO on-side.
The nice thing about this approach is that it's fair. No-one who's not a liability will be affected. Anyone who's simply naive will be given a friendly reminder of the danger, and how to avoid it. You have to screw up spectacularly several times before really bad stuff happens. And if you really are that stupid, inconsiderate or incompetent, the rest of the organisation doesn't have to suffer the risk you bring to their livelihoods.
Didn't those MIS experts think to install anti-virus software on any of those hundreds-if-not-thousands of PCs?!
That's very true.
Actually, as I understand it from people who do this for a living, you have around 20 seconds to make a first impression on a very quick scan. That's mostly first-page stuff: does this person have roughly the right mix of skills, and do they have roughly the right level of professional and academic experience?
If you don't get circular-filed at that point, you'll probably get a reasonable, slightly deeper reading: they'll look at the more specific details of past work experience and higher academic qualifications. If you mentioned a web site and your CV is being read by a real person not an HR computer, they might take a look at this stage, too. If they're still reading worthwhile stuff after a couple of minutes, you're probably shortlisted.
CVs might include more (relevant!) detail than that so that they can form the basis for a conversation at interview, but remember that it's a conversation starter. It should provide the interviewer(s) with a neat list of things to start talking about, and you should be able to expand on any of them as they wish when you meet them in person. You don't need to tell your whole life story!
This is a fascinating question.
I'd prefer the one who left the building quickly and efficiently, confident that the fire wardens would have set up an automatic alarm so the fire service were already on the way (but they'd be calling to check anyway), that the IT group had set up off-site back-ups so the important tapes weren't in the building anyway, and that the designated person would be checking everyone was assembled correctly outside, so he'd better get his ass out there before they think he's missing.
You're looking for a manager, and the manager's role is to make sure everyone doing the "real work" knows what they have to do, and is able to do it.
That's so true. I'm reminded of one of the most touching scenes in The West Wing (seris 1, episode 12, "He Shall From Time To Time"):
President Bartlet: If anything happens... You got a best friend?
Secretary of Agriculture: Yes, sir.
President Bartlet: Is he smarter than you?
Secretary of Agriculture: [Laughs] Yes, sir.
President Bartlet: Would you trust him with your life?
Secretary of Agriculture: Yes, sir.
President Bartlet: That's your chief of staff.
I'm a huge fan of that series for many reasons, but the way they sometimes make a point like this so clearly and accurately is definitely one of them.
If you want 50 out of 900, you probably just pick all the comprehensible and not obviously lying CVs you've got, and you're done. :-)
But seriously... Of course you have to filter, but HR drones who do it with tick-boxes and don't know what the job actually involves are the worst kind of counterproductive. In particular, they frequently fail to understand the relationships between different-sounding skills in IT, and consequently can't gauge how well an applicant's skill set really matches up to the requirements of the job (assuming they even understand the latter).
Basically, HR tend to look for all the direct matches, but you'll be very lucky to find a perfect match for both the technical skills and the context you'll use them in. Usually the difficult -- but more important -- part is looking at the supporting skills. Has this person used the right technical skills in other contexts (and if so, how close are those contexts to yours)? Have they used related technical skills in the right context, so they have experience of that problem domain and its quirks? What is their breadth of related skills overall; how adaptable is this candidate in practice?
To give a concrete example, suppose you need an intermediate-level programmer for a particular development project, which is written in Java. Most HR people I've encountered will look at a CV, look for experience using Java, and just bin those with the fewest years of experience or something equally black and white. A significant number would fail to appreciate that any J2SE or J2EE mentioned on the CV is Java work, and give it no credit at all.
Now, someone who understood would be looking for what parts of Java were used. There's a world of difference between writing end-user apps with Swing and writing back-end J2EE code! They'd be looking for whether the previous uses had been in related contexts or not, and they'd be looking for general experience with things like OO programming languages, distributed systems, use of Java-related tools or other programming languages with similar characteristics, etc.
Of course, as well as technical skills, you're also looking for any useful soft skills: is this candidate used to working in a large/small team; do they have any management/leadership experience that might be relevant to this position; do they have "customer-facing" experience? Often these will be far more important distinctions between similarly technically qualified candidates than an extra year using this or that specific tool.
The thing that always gets me is that a lot of HR people claim this is all too difficult to do in practice, and with 900 candidates you have to shortlist before you can look at this level of detail. What I don't understand is what value the HR people add at all, if they're just going to run the CVs through an automated system without giving them even a minute of informed personal attention each to get the right people on the shortlist. You pay your HR people to facilitate getting the right people into your organisation. Giving each potential candidate that minute or two during shortlisting, so the more technically knowledgable people can then interview the best directly, is exactly what a good HR department is for.
I think there are two points to make here:
Of course, it costs more to employ someone Really Good(TM), so that's quite a big if in the second point there.
It won't help; all the Java job ads want 15+ years now. I hear you can get a job programming C# if you've got 9 years' experience in that, though.
Yes we do, so it's a shame that dev tools suffer from the same syndrome: pretty much all of the big name compilers now take longer to produce output code than they did a couple of years ago, for negligible real world benefits in output code quality. When it takes half an hour just to build your app for a test run, you learn how much it costs to pay developers real quick...
<Off-topic>
He must be teaching a different course these days; we were lectured on co-routines by the same man. Funnily enough, our course had the same name, though... ;-)
</Off-topic>
That specific syntax looks like OCaml to me, though pretty much any functional language is going to support a near-identical construction, and plenty of other languages let you apply a function to a series of arguments similarly elegantly.
The AC beat me to it, but my immediate reaction was also that the line full of += expressions wasn't exactly a great argument for statement separators on this basis.
I hope you're running on an ASCII system, then. ;-)
Sure, if you're going to run code hundreds of times on similar data sets, it's probably worth the overhead of dynamic optimisation. The thing is, not much real code actually does that, and you need to be doing it a lot to justify slowing everything down by a significant factor because of the overhead of the profiling process. In your particular environment, I can see that there might be big wins, but for most people I doubt there ever will be, hence my suggestion that most of the talk about run-time optimisation is hype propagated by buzzword-a-holics.
Of course, you can make exactly the same argument against switching to .NET in the first place. When you've got VB6, VC++ and MFC, Java, Perl and CPAN, and several other established technologies in the marketplace, each with a large developer base who already know their tools well, you need a compelling advantage to justify retraining all those people and rewriting all that code to use .NET instead. Given the obvious disadvantages of doing so -- it costs time and money, it's not a proven technology, it ties you into Microsoft products, etc. -- why would anyone bother, unless they needed a particular feature only available in .NET (which almost no-one does)?
That's only if every new version has to support every old version. In practice, that is rarely a necessity; as long as you provide an upgrade path, it doesn't much matter if you only support the last version or two directly.
For example, contrary to the article's claim about VB.Net vs. VB6, I think Microsoft's first spectacular compatibility failure in recent times was when they changed the file format between Office 95 and Office 98. After a bazillion users complained that they couldn't work with their old data post-upgrade, Microsoft (eventually) released the missing functionality to do the conversion.
Of course, it would have been better to incorporate that from the start, but failing that, tools to convert between successive major versions usually suffice.
Maybe the same place as the worthwhile contexts where web hosting actually adds value? That is, there are a few specialist ones, but mostly they don't exist.
You're claiming that MSDN is impossible to read? I've been a programmer working in Windows development for years, using Win32 APIs, MFC, and various other bits and pieces. Say what you like about the interfaces themselves, Microsoft's documentation is, and always has been, comprehensive and remarkably well organised for something on that scale. Compared to typical *nix man pages or trying to sort out perldoc, it's paradise, and why the top-level poster thought giving the source code was at all equivalent to giving good documentation I have no idea.
That depends what you mean by "optimized C++".
If you mean hand-optimised, by a perfect developer with infinite time available to effectively generate his own run-time framework, then perhaps not.
If you mean the output produced by any contemporary optimising C++ compiler on realistic code, then I'm afraid you're rather behind the curve on compiler technology.
I certainly agree that running on a VM with JIT compilation should theoretically be a comparable speed to pre-compiled code (other things being equal). However, I think many people here are putting way too much faith in dynamic optimisation at run-time.
Sure, the VM could watch the code for the most-executed paths and re-optimise for them on the fly. Of course, that's pretty much equivalent to active profiling the first few runs through the code. As anyone who's waited while an instrumented executable profiles a large data set at 1/10 or less of its usual speed can tell you, active profiling is slow. In order to be of any real value at all, you'd have to run-time optimise only the most frequently executed code, with a good choice of how many runs to profile before you recompile it. Anything else is just never going to give you a worthwhile return on your "investment" in profiling overhead.
Basically, there are plenty of theoretically sound and practically evident ways for a VM/JITC approach to be as fast or even faster than a traditional compile-only approach, but run-time optimisation is not one of them; it's much more hype than silver bullet.
But do you care how fast it runs the first time, or the second time with identical data?
I wrote another post recently, on a similar theme. In that case I was contrasting Perl and C, but the same arguments would apply here pretty much unchanged.
That said, these benchmarks are still just as unrepresentative as they were the first time, still contain random and pointless differences, and still look like C++ written by a Java programmer (using new to create the objects in the methcall example is just weird in C++, for example). To be of any value in a language comparison, you'd need tests doing realistic tasks on a reasonably large scale with roughly equivalent algorithms; trivial code snippets like these wouldn't tell you anything except what you wanted to see in them anyway.