Police Officer: This is a SPAM search!! We have a report that large amounts of Viagra scam mail has been sent from this house! We have a warrant to search the premesis! Get down on teh ground, NOW!!!
Erm... Those weren't cops, dude. Shoulda read the writing on the back of the jacket, and checked what the letters meant.
I agree with much of your post, but do you think maybe you're being a bit too negative?
The precise definition problem is not with obvious ads for viagra, get rich quick scams, debt consolidation and mortgages, porn, and so on. It's with the fringe cases.
That's true, of course, but simply ruling out the sexual and financial stuff would be a good start.
Anyone who administers mail lists, for example, will be able to tell you that even benign non-commercial lists regularily get complaints about being "spam". Many would call those end users "clueless", in that they [...] later forget they had ever expressed an interest and accuse the mail list operator of spamming them.
That's unfortunate when it happens, sure. OTOH, I've received plenty of e-mails in my time telling me that I've "opted in" to something that I most certainly haven't (because I never opt in to any commercial mailing list unless I'm having direct dealings with the company involved, and usually not even then). Thankfully, I've seen few of these in recent months, but it used to happen all the time.
Finally, I agree that it's best to have concrete tests, and as such making it illegal to forge identifying information in an e-mail could be useful. OTOH, a law that says, "You must include a valid, working unsubscribe address" doesn't really help much, does it? Surely anyone who's ever administered an e-mail system would advise against ever replying to any spam mail, so the law has just "legitimised" one of the spammers' favourite tactics for no benefit at all.
Do you cry because television stations have commercials without asking for your consent?
No, but then it doesn't cost me money to download commercials, the commercials go towards supporting the programmes I actually want to watch, commercials provide a useful break during longer programmes, and it takes me no effort to ignore a commercial without them building up until my TV no longer shows me programmes any more.
The sad thing is that the skills you attribute to "true C++ experts" -- avoiding memory leaks and such -- really aren't very difficult at all. It's just that reliable idioms for doing it have only become established over the past few years, and many people learn C++ from books whose authors haven't kept up to date, or lecturers who learned a decade ago and forgot that the software industry moves on a little in that time. There is absolutely no reason that C++ programmers shouldn't all learn a few basic skills from the start, and then not suffer the embarrassment of resource leaks, buffer over-runs and all the rest.
Such code is usually very inefficient, because a series of calculation opcodes without stack operations in between probably has to be executed serially [...] In contrast, stack operations (such as FXCH) are very cheap [...] proper use of them can often enable instruction-level parallelism, which may double or triple performance, since the latency of many instructions are two or three times higher than the throughput.
Yes, I knew that, thanks. I imagine Microsoft's optimising peeps know that too, hence the calculation instructions scattered through the stack set-up code that I mentioned and my use of the term "neatly co-ordinated". I don't know if their instruction order really is optimal; I imagine it's not perfect. But as I said, IME they do a better job than most of taking advantage of the FPU.
As for the Intel FPU FSIN/FCOS issue, yes, I'm painfully aware of that, too. When you run high precision automated numerical tests, as we do, such errors can really spoil your day. Numerical analysis can be tedious at the best of times, but when the basic instructions on your FPU introduce such massive inaccuracies under adverse conditions, it really sucks.
The issue of software emulation of those instructions goes far beyond the FSIN/FCOS bugs, though. Working to Java standards, there all kinds of 100% reproducibility requirements, where even the IEEE standards don't mandate that you get exactly the same answer on different platforms (due to round-up/round-down issues, for example). I can understand, and depending on circumstances would probably support, a serious math library providing software emulation for Intel FSIN/FCOS instructions to ensure decent accuracy. But those are two instructions, not the whole darn floating-point lib, and it's software emulation of the latter that produces the sort of bizarre results we're seeing in these benchmarks.
By that logic, C/C++ must suck really badly, because we all know how unreliable Windows 95 was.
Actually, C and C++ do suck as languages for writing operating systems. It's just that the more practical potential alternatives still suck even more.
It's kinda sad really. We've had near enough three decades of advances in programming language technology since C was invented, and yet we're still writing our most critical software in weak, cumbersome, unsafe languages that are just a step or two removed from assembly. Worse, much (thankfully not all) of the serious R&D in industry still seems to be based around these near-prehistoric monstrosities and the pseudoclones built on them. No wonder so few people are really innovating in the software world.
None of which negates your point that judging a language by a single project written in it is a daft thing to do, of course. I just happened to disagree with your counterexample.:-)
Incidentally, if you avoid platform, compiler and processor specific features, I suspect C++ is even more mind-bogglingly slow than Java.
And I suspect you have a deep misunderstanding.:-)
Did I mentioned that I am one of those guys who does write performance-critical maths code, and it does ship on more than a dozen platforms, and it pretty much doesn't use any of the specifics you mentioned?
I'm sorry, but I've played this game for a while. I have looked at the assembly output of numerous C++ compilers on different architectures to identify performance problems or compiler errors in low-level libraries, resolved tricky numerical analysis issues when computing the roots of quartics to double-precision accuracy, investigated writing what are effectively mini-interpreters for some repetitive coding tasks we do, including JIT and dynamic optimisation issues, made decisions about squeezing a precious 4 extra bytes into a data structure (precious when your structures might be used millions of times) or whether such-and-such a function can be non-virtual to save calling time, all against a background of automated numerical tests that squeek when your results on two platforms differ in the 14th sig fig or so.
The conclusions are crystal clear, and a language like Java will never even come close to producing the speed we need. Other radically different languages might; I have an interest in high-level, functional languages, and the interesting possibilities for compiler-provided optimisations there could make for some worthwhile experimentation at some stage. But not Java. It has too many "hard" down-sides, and precious little to make up for them in this context.
I agree with 2/3 of your replies, but you need to look up the difference between C++ destructors and Java's finalize(). Hint: one is useful, the other usually isn't.:-)
This is (once again) proof that Java is not slow, in fact it's really fast.
To be more accurate, it's proof that Java is not slow when performing trivial tasks.
These benchmarks test trivial operations, most of which can be done in just an instruction or two of machine code inside a loop on the test platform. Any language in a serious performance league should execute these at near identical speeds, modulo up-front time for JIT compilation. It would be laughable if a serious player didn't, and indeed it is laughable that two of the.Net languages were so much slower for I/O, that Java's new floating point performance is so abysmal, and that GCC has a performance so much slower than VC++.Net.
As the report acknowledges, benchmarking usefully is hard. Indeed, many very credible figures in the programming community refuse to compare languages directly in this fashion, precisely because it's so difficult to get any results that are realistically meaningful. To get a fair comparison of the raw performance of (to take everyone's pet holy war) C++ and Java, you'd have to write a much larger-scale test application in the field you were interested in, which would use not only trivial mathematical operations, but also wider optimisations for complex calculations, many function calls, various data structures and algorithms, and so on. I'm aware of no serious benchmarking exercise that has ever done this.
If you're writing security-crtitcal app then if you allocate memory on stack then you have more ways to smash the stack.
That's true, of course, but it's a bit of a straw man. The problem in that case is that you were writing a security-sensitive application using tools that allowed direct access to too much of the stack in the first place.
The questions are: how easy is it to get efficiency to that level, how often you need that level of efficiency, and how often to people actually bother to reach optimal efficiency.
I think you've pretty much nailed it there. You can write your own GC with whatever properties you like using manual memory management, but not the other way around. Hence, in extreme cases, a manual scheme implemented by skilled programmers with a well-customised design will always win.
It's a similar trade-off to "just-in-time" compilation that can do dynamic optimisation vs. a fully-compiled program with compile-time optimisation. You can always write the former using the latter if it's worth it.
In each case, extreme cases demand the manual, fully customisable solution. However, most real world problems are not that extreme. In the remaining cases, the safety and usability advantages of the more automated approach probably outweigh the fact that they're only X% as good.
For many math functions java uses a software implementation rather than using the built in hardware functions on the processer.
That would explain a lot then.
Any recent version of Visual C++ supports "intrinsics", i.e., conversions of a function call directly into a specific machine code instruction, or "perfect in-lining" if you prefer.
That means that if you use something like abs(x) in C++, these compilers would convert directly into an instruction to get x to the head of the floating point stack, then a FPU abs opcode, with no overheads at all. Same goes for trig functions and other variations supported by the FPU.
Moreover, IME the VC++ optimiser is quite smart about intrinsics, and in lengthy calculations will often arrange for the right values to be coming to the head of the stack in the correct order as cheaply as possible, even if it means planning ahead a few instructions. If you look at the assembly language output from VC++ for a numerical computation, it tends to have a series of instructions to stack what it needs, with the occasional calculation opcode thrown in between them, and then a whole series of neatly co-ordinated calculation opcodes at the end.
I don't see how any language that has function calling at all could keep up with this low-level, direct-to-FPU approach, and surely any language using software emulation of floating point code won't even come close.
I don't know whether VC# and VB.Net use the same trick, but given how much effort MS put into sharing things across the product range prior to releasing VS.Net, it must be a good bet. There are some advantages to writing platform-specific code.:-)
Sorry to insert a serious comment in a hilarious thread, but it's 2:30am and I'm a little drunk and finding something to do until the bedroom is... available. Happy new year, by the way.:-)
Did anyone else notice that, contrary to point 59 of the 101, you could in fact fix almost everything wrong with the Internet simply by removing the ability to be completely anonymous (even to administration/law enforcement agencies)? Obviously anonymity can be useful for a small number of legitimate purposes, but the vast majority of the time, we could live without it. In exchange for tracking down and punishing all but the very best spammers, crackers, virus distributers, credit card fraudsters, publishers of defamatory comments, fake doctors giving dangerous medical advice, and numerous other parasites, there must be a better compromise than what we have today...
The thing is, anyone who takes a step back and looks can see the problems with the UK government's transport policies, both nationally and in many places locally. It mostly comes down to one thing: the roads are overcrowded and cars are polluting beasts, so we'd like to reduce car use as much as possible, but no-one has yet come up with a genuinely plausible alternative. Our public transport infrastructure has suffered decades of underinvestment by successive governments, and can only carry perhaps 10% of what the road network handles daily, so any ideas about "getting people onto buses" or "more commuting by train" are bound to fail.
My own local area just had 65mil given to it for a guided bus scheme that has massive local opposition. A campaign group has shown that the models used (featuring buses accelerating faster than sports cars!) were... ahem... slightly unrealistic. And it won't have anything like enough capacity to make a useful difference anyway; as with other public transport systems, we're talking an order of magnitude here. The only problem is that certain senior local councillors have set their hearts on this, and will probably have retired by the time it comes in anyway, so will never be held accountable for their actions. They dismiss the detailed counter-proposal by the campaign group as unviable, though I've yet to see any hard evidence of why. It is curious, though, that they feel the need to do this every time the media runs a story on the scheme that's going ahead; they must feel very secure in their decision...
I rather doubt that any sort of popular revolution is going to be forthcoming, unless you're counting things like the petrol protests as revolutionary. It could easily cost people like seats in Parliament/on the councils, though, as long as someone steps up and names names right before the next elections.
Perhaps, but the incidence of carjacking is drastically lower than auto theft.
For now that may be true, but the balance is certainly shifting. In the UK, I understand that it's now more common for someone to break into a house and steal car keys than it is to break into a car; modern immobilisers and alarm systems make stealing the keys easier. It's also becoming more worthwhile to carjack, and IIRC something like 1,400 carjackings took place last year in the UK alone according to a report I saw the other day.
The basic problem is far more simple than that. At present, here in the UK, our road traffic laws are determined by two things: political correctness and the need to raise money without putting mainstream taxes up.
Our existing speed limits, and the current usage of speed cameras, have been shown repeatedly not to be in the best interests of road safety. This has been the conclusion of research not only by the pro-motoring groups, but even by the government's own Transport Research Laboratory! They are quite good for raising revenue by the back door, though, in spite of publicly advertised policies that mean they shouldn't any more.
As a further example of this attitude, the UK government just passed legislation that makes driving while on a mobile phone illegal. Except that, while I can now be fined for leaving my engine running (in neutral with handbrake applied) while calling someone inside a building to say I've arrived to pick them up -- not exactly dangerous, methinks -- using a hands-free kit isn't covered, even though it's pretty much as dangerous as a handheld according to all the research (because the distraction is what causes most of the problems, not the lack of a free hand). So it's a daft law. And worse, it's completely unnecessary: dangerous and/or inconsiderate driving was already illegal under existing law, and if it's not dangerous and/or inconsiderate, why should it be illegal anyway?
I have a lot of sympathy for our police service. The traffic officers do a very important job, I've met several (my driving instructor was ex-police, her husband still was) and they would all far rather spend their time making the roads safer than following any fad in political spin for the day. I guess your perspective is more down-to-earth when you're the guy who has to clean up a fatal pile-up, get miles of traffic moving again, and then presumably tell Mrs Jones that her husband won't be coming home because some idiot teenager went joyriding into the back of his car at 70mph on the motorway.
So, I can totally understand that the police want more powers to enforce the rules. Like the legal representatives in a court case, their job is very much to advocate one side of the argument, not to present a balanced perspective that also considers things like privacy and civil liberties. You can't blame them for trying to do their job as effectively as possible; if the balance is wrong, it's the political masters who gave too much power to the police who should be put against the wall.
Of course, a lot of the high-ranking police officers who wade in on subjects like this talk complete trash and are an embarrassment to the front line guys. I find it endlessly amusing that one very senior officer (now a Chief Constable -- the highest rank in our police service -- I believe) constantly goes on about how speeding is dangerous, when not so long ago my local Chief Constable was pulled over by his own traffic officers doing 95 in a 70. It was probably quite safe on the road concerned, but it was illegal nonetheless. And whence cometh the hypocrisy...
The basic problem with the whole idea of speed control is the same as it always has been, though. It is essential for road safety that any driver be 100% in control of their vehicle under normal circumstances. I used to be a very legal driver, sticking pretty religiously to speed limits, although I confess that given the number that have been reduced for no apparent reason recently, I no longer respect any speed limits, but rather judge a safe speed (whether above or below the limit) according to road conditions at the time. However, even in my super-legal phase, I broke the limit on a few occasions, typically a momentary burst of speed to avoid an accident where it was safer to power out of the way than to brake, or on one occasion, when I was transporting someone to hospital. (Incidentally, vehicles acting as an ambulance are, reasonably enough, exempt from speed limits under certain circumstances over here, so although a limiter in my
Often the only indication that they were done on paid time was that I sent them from my company email address.
That's fine if your employer is happy with this policy, but I suspect even with good employers, most people's contracts explicitly say that the company owns the copyright on anything you write during work time. Hence releasing it back into the original project without permission is breaking the rules, and both you and the project you're trying to help are likely to get in trouble if your employer finds out.:-(
Not only is it hard to define defect (and it is very obvious that some defects are worse than others), but this code review sounds like it only spots "grammatical" or style errors in the code.
It does indeed sound a bit like that, and with good reason. If you notice, the "indepedent review" was carried out by Reasoning, Inc., and we've heard of them before in these parts.
For the benefit of those who haven't seen this trollfest^H^H^H^H^H^H^H^H^Hstory in its previous incarnations, Reasoning's services spot what some people call "systematic" errors, things like NULL pointer dereferencing or the use of uninitialised variables. As many people note every time this subject comes up, any smart development team will use a tool like Lint to check their code anyway, as a required step before check-in and/or as a regular, automated check of the entire codebase, and so any smart development team should find all such errors immediately. IOWs, it's grossly unfair to compare open and closed source "code quality" on this basis. Any project that has errors like this in it at all isn't serious about quality, and it shouldn't take an external study to point this out.
Serious code quality is not dictated by how many mechanical errors there are that slip through because of weaknesses in the implementation language. Rather, it is indicated by how many "genuine" logic errors -- cases where the output differs unintentionally from the specifications -- there are. Of course, no automated process can identify those, but to get a meaningful comparison of code quality, you'd need to investigate that aspect, rather than kindergarten mistakes.
There are other objections to their principal metric as well. For starters, source code layout is not normally significant in C, C++ or Java, so any metric based on line count is going to be flawed at best. But the big objection is that they're talking about childish mistakes, and comparing supposedly world class software based on childish mistakes isn't helpful (except to dispel the myth that some big name products have sensible development processes).
Actually, there really is a top-selling book in the UK at present called "Eats, Shoots and Leaves", which takes a comic look at punctuation and why it still matters.
I was going to give an Amazon link for the curious, but apparently putting any variation on the title or a book, or its author, into their search box now produces nothing but a useless list of "featured" products. In two minutes of searching -- more than I'd waste if I were going to buy a book -- I couldn't find it.:-(
I think it's more than just cool things, it was original cool things. The Matrix had a new spin on man-against-machine, and the cool tricks, and Neo's discovery and progressive mastery of them, were part of that story. The first scene was one of the best beginnings to any film ever. The plot is coherent throughout, but it takes half of the film for you to work out what's really happening.
In contrast, the sequels were fairly routine man-against-machine sfx-fests. Any action inside the matrix, or outside it for that matter, was more an excuse for big special effects set pieces than an integral part of the story. Sure, they were more spectacular effects than many before them, but not particularly original, if only because The Matrix already did them, and more importantly, not particularly relevant.
In their own right, the sequels wouldn't have been bad action/sfx sci-fi movies, but they were nothing special. I guess it was just too tough an act to follow.
If I weren't posting here I'd mod you Insightful.:-)
I tried, and failed, to read LotR twice before. I never got beyond Chapter 19,534: The Never-Ending Party.
After the first film came out, I knew that it actually was the kind of story I enjoy, and started reading the books again, getting past the party this time. I have no regrets at all about doing it in that order, I don't compare the books to the films (or vice versa), and personally, I actually found the films more entertaining, though it was interesting to see the real background and omitted details that are present in the book.
While his portrayal of Elrond was pretty close to the mark, it still had some strange element of Agent Smith that crept into it.
OK, OK. I should have imagined him saying "As you can see, we've had our eye on you for some time now, Mister Baggins" in a very menacing voice, from behind cool elven shades.;-)
Slashdot Mirror
Erm... Those weren't cops, dude. Shoulda read the writing on the back of the jacket, and checked what the letters meant.
I agree with much of your post, but do you think maybe you're being a bit too negative?
That's true, of course, but simply ruling out the sexual and financial stuff would be a good start.
That's unfortunate when it happens, sure. OTOH, I've received plenty of e-mails in my time telling me that I've "opted in" to something that I most certainly haven't (because I never opt in to any commercial mailing list unless I'm having direct dealings with the company involved, and usually not even then). Thankfully, I've seen few of these in recent months, but it used to happen all the time.
Finally, I agree that it's best to have concrete tests, and as such making it illegal to forge identifying information in an e-mail could be useful. OTOH, a law that says, "You must include a valid, working unsubscribe address" doesn't really help much, does it? Surely anyone who's ever administered an e-mail system would advise against ever replying to any spam mail, so the law has just "legitimised" one of the spammers' favourite tactics for no benefit at all.
No, but then it doesn't cost me money to download commercials, the commercials go towards supporting the programmes I actually want to watch, commercials provide a useful break during longer programmes, and it takes me no effort to ignore a commercial without them building up until my TV no longer shows me programmes any more.
Fair enough, but the point you disputed was that in Java you can't use the RAII idiom. You can't. RAII relies on destructors because they are:
Neither of these applies to finalize().
OK, I see your point.
The sad thing is that the skills you attribute to "true C++ experts" -- avoiding memory leaks and such -- really aren't very difficult at all. It's just that reliable idioms for doing it have only become established over the past few years, and many people learn C++ from books whose authors haven't kept up to date, or lecturers who learned a decade ago and forgot that the software industry moves on a little in that time. There is absolutely no reason that C++ programmers shouldn't all learn a few basic skills from the start, and then not suffer the embarrassment of resource leaks, buffer over-runs and all the rest.
Yes, I knew that, thanks. I imagine Microsoft's optimising peeps know that too, hence the calculation instructions scattered through the stack set-up code that I mentioned and my use of the term "neatly co-ordinated". I don't know if their instruction order really is optimal; I imagine it's not perfect. But as I said, IME they do a better job than most of taking advantage of the FPU.
As for the Intel FPU FSIN/FCOS issue, yes, I'm painfully aware of that, too. When you run high precision automated numerical tests, as we do, such errors can really spoil your day. Numerical analysis can be tedious at the best of times, but when the basic instructions on your FPU introduce such massive inaccuracies under adverse conditions, it really sucks.
The issue of software emulation of those instructions goes far beyond the FSIN/FCOS bugs, though. Working to Java standards, there all kinds of 100% reproducibility requirements, where even the IEEE standards don't mandate that you get exactly the same answer on different platforms (due to round-up/round-down issues, for example). I can understand, and depending on circumstances would probably support, a serious math library providing software emulation for Intel FSIN/FCOS instructions to ensure decent accuracy. But those are two instructions, not the whole darn floating-point lib, and it's software emulation of the latter that produces the sort of bizarre results we're seeing in these benchmarks.
Actually, C and C++ do suck as languages for writing operating systems. It's just that the more practical potential alternatives still suck even more.
It's kinda sad really. We've had near enough three decades of advances in programming language technology since C was invented, and yet we're still writing our most critical software in weak, cumbersome, unsafe languages that are just a step or two removed from assembly. Worse, much (thankfully not all) of the serious R&D in industry still seems to be based around these near-prehistoric monstrosities and the pseudoclones built on them. No wonder so few people are really innovating in the software world.
None of which negates your point that judging a language by a single project written in it is a daft thing to do, of course. I just happened to disagree with your counterexample. :-)
And I suspect you have a deep misunderstanding. :-)
Did I mentioned that I am one of those guys who does write performance-critical maths code, and it does ship on more than a dozen platforms, and it pretty much doesn't use any of the specifics you mentioned?
I'm sorry, but I've played this game for a while. I have looked at the assembly output of numerous C++ compilers on different architectures to identify performance problems or compiler errors in low-level libraries, resolved tricky numerical analysis issues when computing the roots of quartics to double-precision accuracy, investigated writing what are effectively mini-interpreters for some repetitive coding tasks we do, including JIT and dynamic optimisation issues, made decisions about squeezing a precious 4 extra bytes into a data structure (precious when your structures might be used millions of times) or whether such-and-such a function can be non-virtual to save calling time, all against a background of automated numerical tests that squeek when your results on two platforms differ in the 14th sig fig or so.
The conclusions are crystal clear, and a language like Java will never even come close to producing the speed we need. Other radically different languages might; I have an interest in high-level, functional languages, and the interesting possibilities for compiler-provided optimisations there could make for some worthwhile experimentation at some stage. But not Java. It has too many "hard" down-sides, and precious little to make up for them in this context.
You think there are more Java programmers in the world than C++ programmers? Really?
I agree with 2/3 of your replies, but you need to look up the difference between C++ destructors and Java's finalize(). Hint: one is useful, the other usually isn't. :-)
To be more accurate, it's proof that Java is not slow when performing trivial tasks.
These benchmarks test trivial operations, most of which can be done in just an instruction or two of machine code inside a loop on the test platform. Any language in a serious performance league should execute these at near identical speeds, modulo up-front time for JIT compilation. It would be laughable if a serious player didn't, and indeed it is laughable that two of the .Net languages were so much slower for I/O, that Java's new floating point performance is so abysmal, and that GCC has a performance so much slower than VC++.Net.
As the report acknowledges, benchmarking usefully is hard. Indeed, many very credible figures in the programming community refuse to compare languages directly in this fashion, precisely because it's so difficult to get any results that are realistically meaningful. To get a fair comparison of the raw performance of (to take everyone's pet holy war) C++ and Java, you'd have to write a much larger-scale test application in the field you were interested in, which would use not only trivial mathematical operations, but also wider optimisations for complex calculations, many function calls, various data structures and algorithms, and so on. I'm aware of no serious benchmarking exercise that has ever done this.
That's true, of course, but it's a bit of a straw man. The problem in that case is that you were writing a security-sensitive application using tools that allowed direct access to too much of the stack in the first place.
I think you've pretty much nailed it there. You can write your own GC with whatever properties you like using manual memory management, but not the other way around. Hence, in extreme cases, a manual scheme implemented by skilled programmers with a well-customised design will always win.
It's a similar trade-off to "just-in-time" compilation that can do dynamic optimisation vs. a fully-compiled program with compile-time optimisation. You can always write the former using the latter if it's worth it.
In each case, extreme cases demand the manual, fully customisable solution. However, most real world problems are not that extreme. In the remaining cases, the safety and usability advantages of the more automated approach probably outweigh the fact that they're only X% as good.
That would explain a lot then.
Any recent version of Visual C++ supports "intrinsics", i.e., conversions of a function call directly into a specific machine code instruction, or "perfect in-lining" if you prefer.
That means that if you use something like abs(x) in C++, these compilers would convert directly into an instruction to get x to the head of the floating point stack, then a FPU abs opcode, with no overheads at all. Same goes for trig functions and other variations supported by the FPU.
Moreover, IME the VC++ optimiser is quite smart about intrinsics, and in lengthy calculations will often arrange for the right values to be coming to the head of the stack in the correct order as cheaply as possible, even if it means planning ahead a few instructions. If you look at the assembly language output from VC++ for a numerical computation, it tends to have a series of instructions to stack what it needs, with the occasional calculation opcode thrown in between them, and then a whole series of neatly co-ordinated calculation opcodes at the end.
I don't see how any language that has function calling at all could keep up with this low-level, direct-to-FPU approach, and surely any language using software emulation of floating point code won't even come close.
I don't know whether VC# and VB.Net use the same trick, but given how much effort MS put into sharing things across the product range prior to releasing VS.Net, it must be a good bet. There are some advantages to writing platform-specific code. :-)
Sorry to insert a serious comment in a hilarious thread, but it's 2:30am and I'm a little drunk and finding something to do until the bedroom is... available. Happy new year, by the way. :-)
Did anyone else notice that, contrary to point 59 of the 101, you could in fact fix almost everything wrong with the Internet simply by removing the ability to be completely anonymous (even to administration/law enforcement agencies)? Obviously anonymity can be useful for a small number of legitimate purposes, but the vast majority of the time, we could live without it. In exchange for tracking down and punishing all but the very best spammers, crackers, virus distributers, credit card fraudsters, publishers of defamatory comments, fake doctors giving dangerous medical advice, and numerous other parasites, there must be a better compromise than what we have today...
The thing is, anyone who takes a step back and looks can see the problems with the UK government's transport policies, both nationally and in many places locally. It mostly comes down to one thing: the roads are overcrowded and cars are polluting beasts, so we'd like to reduce car use as much as possible, but no-one has yet come up with a genuinely plausible alternative. Our public transport infrastructure has suffered decades of underinvestment by successive governments, and can only carry perhaps 10% of what the road network handles daily, so any ideas about "getting people onto buses" or "more commuting by train" are bound to fail.
My own local area just had 65mil given to it for a guided bus scheme that has massive local opposition. A campaign group has shown that the models used (featuring buses accelerating faster than sports cars!) were... ahem... slightly unrealistic. And it won't have anything like enough capacity to make a useful difference anyway; as with other public transport systems, we're talking an order of magnitude here. The only problem is that certain senior local councillors have set their hearts on this, and will probably have retired by the time it comes in anyway, so will never be held accountable for their actions. They dismiss the detailed counter-proposal by the campaign group as unviable, though I've yet to see any hard evidence of why. It is curious, though, that they feel the need to do this every time the media runs a story on the scheme that's going ahead; they must feel very secure in their decision...
I rather doubt that any sort of popular revolution is going to be forthcoming, unless you're counting things like the petrol protests as revolutionary. It could easily cost people like seats in Parliament/on the councils, though, as long as someone steps up and names names right before the next elections.
For now that may be true, but the balance is certainly shifting. In the UK, I understand that it's now more common for someone to break into a house and steal car keys than it is to break into a car; modern immobilisers and alarm systems make stealing the keys easier. It's also becoming more worthwhile to carjack, and IIRC something like 1,400 carjackings took place last year in the UK alone according to a report I saw the other day.
The basic problem is far more simple than that. At present, here in the UK, our road traffic laws are determined by two things: political correctness and the need to raise money without putting mainstream taxes up.
Our existing speed limits, and the current usage of speed cameras, have been shown repeatedly not to be in the best interests of road safety. This has been the conclusion of research not only by the pro-motoring groups, but even by the government's own Transport Research Laboratory! They are quite good for raising revenue by the back door, though, in spite of publicly advertised policies that mean they shouldn't any more.
As a further example of this attitude, the UK government just passed legislation that makes driving while on a mobile phone illegal. Except that, while I can now be fined for leaving my engine running (in neutral with handbrake applied) while calling someone inside a building to say I've arrived to pick them up -- not exactly dangerous, methinks -- using a hands-free kit isn't covered, even though it's pretty much as dangerous as a handheld according to all the research (because the distraction is what causes most of the problems, not the lack of a free hand). So it's a daft law. And worse, it's completely unnecessary: dangerous and/or inconsiderate driving was already illegal under existing law, and if it's not dangerous and/or inconsiderate, why should it be illegal anyway?
I have a lot of sympathy for our police service. The traffic officers do a very important job, I've met several (my driving instructor was ex-police, her husband still was) and they would all far rather spend their time making the roads safer than following any fad in political spin for the day. I guess your perspective is more down-to-earth when you're the guy who has to clean up a fatal pile-up, get miles of traffic moving again, and then presumably tell Mrs Jones that her husband won't be coming home because some idiot teenager went joyriding into the back of his car at 70mph on the motorway.
So, I can totally understand that the police want more powers to enforce the rules. Like the legal representatives in a court case, their job is very much to advocate one side of the argument, not to present a balanced perspective that also considers things like privacy and civil liberties. You can't blame them for trying to do their job as effectively as possible; if the balance is wrong, it's the political masters who gave too much power to the police who should be put against the wall.
Of course, a lot of the high-ranking police officers who wade in on subjects like this talk complete trash and are an embarrassment to the front line guys. I find it endlessly amusing that one very senior officer (now a Chief Constable -- the highest rank in our police service -- I believe) constantly goes on about how speeding is dangerous, when not so long ago my local Chief Constable was pulled over by his own traffic officers doing 95 in a 70. It was probably quite safe on the road concerned, but it was illegal nonetheless. And whence cometh the hypocrisy...
The basic problem with the whole idea of speed control is the same as it always has been, though. It is essential for road safety that any driver be 100% in control of their vehicle under normal circumstances. I used to be a very legal driver, sticking pretty religiously to speed limits, although I confess that given the number that have been reduced for no apparent reason recently, I no longer respect any speed limits, but rather judge a safe speed (whether above or below the limit) according to road conditions at the time. However, even in my super-legal phase, I broke the limit on a few occasions, typically a momentary burst of speed to avoid an accident where it was safer to power out of the way than to brake, or on one occasion, when I was transporting someone to hospital. (Incidentally, vehicles acting as an ambulance are, reasonably enough, exempt from speed limits under certain circumstances over here, so although a limiter in my
That's fine if your employer is happy with this policy, but I suspect even with good employers, most people's contracts explicitly say that the company owns the copyright on anything you write during work time. Hence releasing it back into the original project without permission is breaking the rules, and both you and the project you're trying to help are likely to get in trouble if your employer finds out. :-(
It does indeed sound a bit like that, and with good reason. If you notice, the "indepedent review" was carried out by Reasoning, Inc., and we've heard of them before in these parts.
For the benefit of those who haven't seen this trollfest^H^H^H^H^H^H^H^H^Hstory in its previous incarnations, Reasoning's services spot what some people call "systematic" errors, things like NULL pointer dereferencing or the use of uninitialised variables. As many people note every time this subject comes up, any smart development team will use a tool like Lint to check their code anyway, as a required step before check-in and/or as a regular, automated check of the entire codebase, and so any smart development team should find all such errors immediately. IOWs, it's grossly unfair to compare open and closed source "code quality" on this basis. Any project that has errors like this in it at all isn't serious about quality, and it shouldn't take an external study to point this out.
Serious code quality is not dictated by how many mechanical errors there are that slip through because of weaknesses in the implementation language. Rather, it is indicated by how many "genuine" logic errors -- cases where the output differs unintentionally from the specifications -- there are. Of course, no automated process can identify those, but to get a meaningful comparison of code quality, you'd need to investigate that aspect, rather than kindergarten mistakes.
There are other objections to their principal metric as well. For starters, source code layout is not normally significant in C, C++ or Java, so any metric based on line count is going to be flawed at best. But the big objection is that they're talking about childish mistakes, and comparing supposedly world class software based on childish mistakes isn't helpful (except to dispel the myth that some big name products have sensible development processes).
Actually, there really is a top-selling book in the UK at present called "Eats, Shoots and Leaves", which takes a comic look at punctuation and why it still matters.
I was going to give an Amazon link for the curious, but apparently putting any variation on the title or a book, or its author, into their search box now produces nothing but a useless list of "featured" products. In two minutes of searching -- more than I'd waste if I were going to buy a book -- I couldn't find it. :-(
I think it's more than just cool things, it was original cool things. The Matrix had a new spin on man-against-machine, and the cool tricks, and Neo's discovery and progressive mastery of them, were part of that story. The first scene was one of the best beginnings to any film ever. The plot is coherent throughout, but it takes half of the film for you to work out what's really happening.
In contrast, the sequels were fairly routine man-against-machine sfx-fests. Any action inside the matrix, or outside it for that matter, was more an excuse for big special effects set pieces than an integral part of the story. Sure, they were more spectacular effects than many before them, but not particularly original, if only because The Matrix already did them, and more importantly, not particularly relevant.
In their own right, the sequels wouldn't have been bad action/sfx sci-fi movies, but they were nothing special. I guess it was just too tough an act to follow.
If I weren't posting here I'd mod you Insightful. :-)
I tried, and failed, to read LotR twice before. I never got beyond Chapter 19,534: The Never-Ending Party.
After the first film came out, I knew that it actually was the kind of story I enjoy, and started reading the books again, getting past the party this time. I have no regrets at all about doing it in that order, I don't compare the books to the films (or vice versa), and personally, I actually found the films more entertaining, though it was interesting to see the real background and omitted details that are present in the book.
The UK disagrees. ;-)
(Cue extended debate about whether studies of "good" books are inevitably heavily biased towards those with recent high-profile cinematic versions...)
OK, OK. I should have imagined him saying "As you can see, we've had our eye on you for some time now, Mister Baggins" in a very menacing voice, from behind cool elven shades. ;-)