It's true that debugging templates can be a royal PITA, but that's really down to the quality of your development environment, and things are improving. The thing is, you only have to debug the templated code in your library once, and then you get cleaner higher level code forever -- and that cleaner code is much easier to debug thanks to templates and operator overloading, because the logic errors are easier to spot.
Incidentally, anyone who uses Visual Studio might care to note that you can do a lot with AUTOEXP.DAT to simplify debugging when working with complex UDTs, templated or otherwise.
Well there is that effect of a people taking bad language features and accepting them as good things because they can do very clever things with them which are un-intended conscequences of language features.
Indeed. That effect is responsible for many of the most useful advances in programming technique since forever.
Java's generics are not even close to the power of C++ templates. They are glorified macros to fix a bug in the type system that should never have been there.
Not so, of course, one might argue that Templates were added to C++ to patch a hole in there Object Oriented system that should not have been there.
One might argue that, but it wouldn't have the same relevance. C++ is designed, from the start, to be a multi-paradigm language. By Stroustrup's own admission, templates probably should have gone in earlier. However, as it stands today (and has for many years) C++ is not a purely OO language, nor meant to be one. Keeping the fundamental types clear of the OO baggage is one reason compiled code in C++ can be so efficient.
Java, on the other hand, has hyped OO from day one. It maintains that everything is an Object, and non-OO programming is inferior. Hell, for years, Java evangelists have claimed that templates are a bodge and they don't need them. In that context, having your primitive types not being Objects is just plain out of place. It leads to rather absurd concepts like the wrapper types, and those in turn to "boxing", which is a poor man's excuse in a language that doesn't properly distinguish between value and reference semantics.
The only thing I can think of reading your opinion is that you are young, were not around when C++ was first introduced, did not know its progression, do not have a keen understanding of why we have strong typing or OOPs, or what each is for.
I'm afraid I'd like a little more credit than that. I've been using C++ for more than a decade and Java for several years, and I've got more than a passing familiarity with ML, Python, Perl, various assembly languages and several more besides. I have an active interest in language design, and am familiar with a lot of the background theory, including structured programming, lambda calculus, formal type deduction systems and the principles of OO.
And by the way, you seem to confuse the concepts of strong/weak type systems with static/dynamic ones. There's a very significant difference, and all four combinations are possible.
I love replies like this. For some strange reason, you assume that because I know about C++, I don't know about Java, or I expect one to behave like the other. You are mistaken.
In fact, if you take a step back and look again, you'll see that the resource management issues to which I alluded go far beyond memory leaks. They also encompass closing files, releasing locks in multi-threaded apps, closing database handles, closing sockets, etc. Garbage collection, as provided by Java, doesn't help at all with these things, and that considerably limits its use and reduces the potential safety benefits for real world code.
As for why wrappers around primitives are "safety features", I'm afraid you've got me there. How is requiring a wrapper to make them fit into the type system cleanly improving safety? Dozens of other languages manage just fine without.
You must *NOT* rely on filanizers to do the clean-up. That is a bad Java practice.
Yes, I know, thanks. Actually, relying on finalizers to do anything is a bad idea, given the lack of guarantee about when they will (not) run. In fact, they're a rather pointless feature, possibly useful for diagnostic purposes but not much else.
You should use try-finally blocks for that:
Yes. And that means that every time you use a resource, you must wrap the use in a try block and remember to add a finally section to release the resources. This frequently means duplicating the same resource release code everywhere -- assuming you never forget it, since you've got a serious bug if you do.
This is not safer than the high-level alternatives, or even than RAII in C++.
If you'd taken the time to read any of my other posts, you'd realise that I do understand the differences between C++ and Java. I have even commented in this thread on their superficial similarities and real differences, and the need to use each as it was intended.
Nevertheless, I stand by my original point. You do need an excessive amount of casting in Java (1.4), which is inherently less safe than the alternatives offered by numerous other languages (not just C++).
Similarly, you do need to use finally an excessive amount because Java's garbage collection mechanism is only good for avoiding memory leaks, not resource leaks in general.
If you have some technique or idiom for avoiding these problems, please share it, because I'm sure a lot of Java programmers would like to hear it.
Re:You're missing something
on
Does C# Measure Up?
·
· Score: 2, Interesting
I agree completely: a lot of it is down to the maturity of optimisation technology for the language in question. This is part of the reason that some high level languages -- OCaml, for example -- can generate code of a comparable speed to low-level beasts like C and C++: with a simpler underlying model, it's easier to perform good optimisations. It's also the reason C is still faster than C++ for some things, even though theoretically, C++ should never be slower.
I was including dynamic optimisation (during the program run) within the "late optimisation" idea, but in practice, I get the impression it's not used much yet. It's far easier to do platform-specific optimisation on installation or loading, effectively, just doing the optimisation phase of a compile late. Effective dynamic optimisation is a very hard thing to do, because you have the overheads of monitoring code speed to overcome before you can even hold your own, never mind gain an advantage. I suspect that in time, dynamically optimising run-times will gain a much stronger foothold in the market, but probably not until a lot more research has been done.
The conclusion, as ever, must be that good programmers can do well in any decent language, and bad programmers will shoot themselves in the foot in any language.
The great irony, of course, is that a big selling point of Java was its ease of use. They took out all the "over-complicated" bits of C++, to make it faster to learn and less prone to programmer errors. If you're going to get the same sort of problems coming up in Java as in C++, you might as well stick to the latter and at least make the power and flexibility available for the good guys...
(I'm only considering that specific selling point here. Obviously there are other relevant issues to consider when choosing which language to use as well.)
Give or take a few quirks, most recent (last five years, say) C++ compilers support all the major features acceptably well for most purposes. There are only a few issues that cause significant problems: the infamous export, Koenig look-up and partial specialisation of templates come to mind. None of these features is used very often anyway, though.
Coding standards that forbid the use of templates, exceptions and half the standard library in C++ are common, but way out of date.
By the way, I write code for a living that gets shipped on more than a dozen different C++ platforms. Alas, some of them are well pre-standard, and so don't support even basic template or exception mechanics properly, which sucks. But this is an issue we've looked into in some detail, so I'm pretty confident in my statements above.
Programmer cycles are much more expensive if your end product runs too slowly to be useful, and nobody buys it.
Performance still matters in a lot more areas than many people seem to give credit for: scientific apps, graphics, high load server work, firmware and instrument control software, games of course, any smart AI, heavy duty data processing... If performance for other things really no longer matters, why do today's applications somehow run as slowly on 2GHz+ PCs as they did on 200MHz boxes a few years ago? Sure, some of it is feature creep... but not that much.
When people say things like "performance no longer matters" and "processor cycles are cheap", I get the impression that the pinnacle of their programming expertise is writing UIs for databases.
No matter what you say, C is *always* faster. You *cannot* write a loop in C#, and claim that it will run faster than a comprable loop in C.
Actually, in practice, no it's not and yes you can.
What you're ignoring is the "late optimisation" effect of virtual-machine and intermediate language execution models. The installer or run-time can take intermediate code and convert it to native code, just as a C compiler would, but with full knowledge of the environment in which that code is going to run. That allows for specific optimisations based on the execution environment that are rarely, if ever, practical for C-based programs. (How many C programs ship with different optimised executables for each Pentium and Athlon series processor, for example?)
You seem to be writing as someone who knows how things are supposed to work, who has a certain mindset and isn't prepared to look outside it. So-called just-in-time compilers actually have a lot of potential. They aren't, in general, as fast as something like C or C++ yet. However, in theory they could actually be faster once they've matured and caught up, because they can do all the same low-level optimisation tricks as a C or C++ compiler, with more knowledge of the target environment to get the best out of them.
Anyone played Quake II.Net?
on
Does C# Measure Up?
·
· Score: 2, Interesting
Microsoft have had a.Net version of Quake II mentioned on their developer pages for some time now. It's a port to Visual C++.Net 2003, using the CLR.
Has anyone tried this? It's presumably managed C++ rather than C#, but it should give a fair indication of the performance you'd get from C# if it's using the same run-time framework. If they can get comparable performance in a FPS using the.NET run-time, it might be worth looking at for games development after all...
In C++, casts are rarely necessary. When they are, tools like dynamic_cast allow for the same useful run-time type checking as Java et al support.
In Java, you can't even pull an object out of a container without a cast, and you can't even use a basic type in a generic container without some sort of wrapper object.
In C++, the RAII idiom lets you ensure the safe release of any resource type. In Java, you have to write the same finally blocks all over just to make up for the fact that finalizers don't work.
Java is "more safe" than C++?
Now that was funny.
#insert <obligatory_Java _generics_rant>
on
Does C# Measure Up?
·
· Score: 4, Interesting
Java SDK v1.5 (not yet released) contains support for 'generics', which are very much like C++ templates for Java:
I really can't believe this thread. Why do people always come up with this worn out line whenever someone suggests that C++ templates are an advantage? And how come so many people have done so in replying to the same post? All but the first are (-1, Redundant), and the first is (-1, Ill-informed).
OK, please, read this carefully, for I shall write it only once (in this thread):
Java's generics are not even close to the power of C++ templates. They are glorified macros to fix a bug in the type system that should never have been there.
C++ templates were at that level around a decade ago. Today, they're used not only to create generic containers (for which they are, no doubt, very useful) but also, via metaprogramming techniques, as the tool underlying most of the really powerful developments in C++ for the past few years: expression templates, high performance maths libraries, etc.
If you didn't already know that, please read it again and understand it before proceeding.
Java's generics don't even come close to the same power. They're a cheap knock-off, aimed at just one of the uses of C++ templates, which fixes a glaring flaw in the previous Java language. For that, they serve their purpose well, but please don't pretend they're anything more.
I don't think C++ programmers have ever underestimated the value of garbage collection; Stroustrup mentions it himself in several relevant texts, and garbage collectors have been available for C++ for years, for those who want them. Of course, garbage collection isn't nearly so important in a language with automatic variables and deterministic destruction, which is probably why few people actually use those libraries.
C++ and Java will never be the same language, or even close. They are aimed at two different markets, they have different strengths and weaknesses adapted to those markets, and it's rather unlikely that those markets will converge. The similarity pretty much ends at syntax and basic OO concepts.
Having everything (with the exception of native datatypes that can be wrapped into classes) be a descendant of a superclass is a far more elegant solution than using c++'s hackish and syntactically awkward template feature.
Of course it is. That's why Java's adding generics now, I guess: to fix the loopholes that approach didn't cause.
Not everything is an Object; didn't you first textbook tell you?
FWIW, I don't get my information from TV. Most of my opinion is formed from a small number of people I've encountered who work in this area, either in person or on-line: a former member of a British special forces unit who had counter-terrorism responsibilities, serving police officers, a member of a big city SWAT team from the US, and one or two other guys who obviously had been there and done that. I met most of them via a common interest in martial arts, in case you're wondering.
Now, to answer your points...
Certainly these people have had far more training than TV propaganda. They have their own practice houses and other scenarios, and they expect to spend several hours a week training.
Now, if you read the thread carefully, you'll see that the point is using anti-terrorism legislation against non-terrorist criminals. It's not unlikely that by the time the guys making the entry got their instructions, the targets would be "suspected terrorists". The point of this whole thread is that they don't call and treat you as a regular criminal. They file you under "terrorist", and as such they gain all sorts of draconian powers they've no right to be using in cases that aren't immediate matters of national security.
I'm sorry, but you just don't sound like the guys I've talked to, and since I have no idea who you are, that makes me suspicious. What exactly is your role? Who do you train, and in what capacity? And if coming into your house at any time of day would be problematic, what would one of the teams you've trained do to get in to someone else's house that was similarly protected?
Yes, I'll believe the result of the next election unless I have a good reason not to, for two simple reasons.
Firstly, it's very unlikely that an implausible result could occur without being investigated.
Secondly, you have to trust someone or something, some time. If you can't trust the electoral mechanics in a democracy, what can you trust? (No-one isn't a very helpful answer to that question.)
Let's teach future American programmers proper security before they graduate and start writing professional software.
I hate to break this to you, but expecting a newly graduated kid to be a solid performer from day one is unrealistic. They never have been. You weren't. I wasn't. The kids going through now won't be.
Software development hasn't (yet?) developed any sort of "apprenticeship" framework for the new kids on the block to learn practical, real-world skills from old hands. Their knowledge is, inevitably, mostly theoretical. They won't understand everything that was in their course properly, and even if they do understand something in theory, they won't necessarily appreciate the practical implications. The best you can hope for is someone who enjoys their subject, and thus has developed good general knowledge of the field and perhaps done some relevant part-time or summer job work.
If you're taking people on who aren't up to the standards you require at the time, and you're suffering bugs down the line as a result, then you need to review your recruitment process with HR, and you need to review your training process with the line managers responsible for overseeing new starters. Failure to do this is just plain bad management, and bitching about how degrees are worthless "these days" is a rather pathetic attempt to pass the buck. In reality, the blame rests squarely on the shoulders of the managers who haven't developed their resources effectively, and addressing that basic problem is the only way you're going to improve the situation.
If they were going after someone they thought was going to be an armed terrorist, they'd probably go in the early hours of the morning. You'd be asleep, and it would be dark. Depending on the circumstances, they might enter quietly, or they might enter in numbers from multiple points of access after throwing the gas in ahead of them. Either way, they would have a point man and at least one back-up covering you before you'd even registered that someone else was in the room, and unlike you, they would be alert, able to see clearly, and fully aware of the situation.
I don't care how accurate you are when you're shooting on the range, if you pulled that gun out from under your pillow and tried to aim at one of them, you'd be dead before the gun hit the mattress. The guys they send after serious baddies regularly spend hours and hours training for forced entries to arrest hostile subjects -- exactly the sort of bad-ass you're pretending to be. What the hell makes you think you're better at their game than they are?
If you live in the UK, keep the faith. The one good thing about a first past the post electoral system is that the same small shift in the vote that gives one party a disproportionate amount of power can reverse, and take a disproportionate amount of power from them if only a few more people vote another way.
I should perhaps clarify. I'm not taking a swipe at Hudson; his achievements are impressive. I'm just pointing out that there are other people who arguably have a better track record in ICFP contests, and pondering how well they might expect to do out of it.
We can only hope 4 year terms run in the bush family. And I voted for dubya.
I know the feeling. I voted for Blair's lot... the first time.
The second time around, their majority in a lot of constituencies halved. They still have a heavy majority in the UK parliament, but they're a lot more cautious about advocating dumb things, several of which have quietly dropped by the wayside recently.
Next time, he's very unlikely to get an absolute majority unless something radical happens between now and the election. Such is the price of abusing a position of unique authority and letting the electorate find out. For Blair, the Achilles heel will be spin. For Bush, it may be civil liberties. Time will tell...
If it did happen, you wouldn't even know what hit you. If you reached for that gun, you'd be dead before the safety was off.
Of course, this sort of mistaken identity can and does happen anyway, but if you're labelled a terrorist before you even start, it's a good bet that they'll shoot first and ask questions never.
Slashdot Mirror
It's true that debugging templates can be a royal PITA, but that's really down to the quality of your development environment, and things are improving. The thing is, you only have to debug the templated code in your library once, and then you get cleaner higher level code forever -- and that cleaner code is much easier to debug thanks to templates and operator overloading, because the logic errors are easier to spot.
Incidentally, anyone who uses Visual Studio might care to note that you can do a lot with AUTOEXP.DAT to simplify debugging when working with complex UDTs, templated or otherwise.
Indeed. That effect is responsible for many of the most useful advances in programming technique since forever.
One might argue that, but it wouldn't have the same relevance. C++ is designed, from the start, to be a multi-paradigm language. By Stroustrup's own admission, templates probably should have gone in earlier. However, as it stands today (and has for many years) C++ is not a purely OO language, nor meant to be one. Keeping the fundamental types clear of the OO baggage is one reason compiled code in C++ can be so efficient.
Java, on the other hand, has hyped OO from day one. It maintains that everything is an Object, and non-OO programming is inferior. Hell, for years, Java evangelists have claimed that templates are a bodge and they don't need them. In that context, having your primitive types not being Objects is just plain out of place. It leads to rather absurd concepts like the wrapper types, and those in turn to "boxing", which is a poor man's excuse in a language that doesn't properly distinguish between value and reference semantics.
I'm afraid I'd like a little more credit than that. I've been using C++ for more than a decade and Java for several years, and I've got more than a passing familiarity with ML, Python, Perl, various assembly languages and several more besides. I have an active interest in language design, and am familiar with a lot of the background theory, including structured programming, lambda calculus, formal type deduction systems and the principles of OO.
And by the way, you seem to confuse the concepts of strong/weak type systems with static/dynamic ones. There's a very significant difference, and all four combinations are possible.
I love replies like this. For some strange reason, you assume that because I know about C++, I don't know about Java, or I expect one to behave like the other. You are mistaken.
In fact, if you take a step back and look again, you'll see that the resource management issues to which I alluded go far beyond memory leaks. They also encompass closing files, releasing locks in multi-threaded apps, closing database handles, closing sockets, etc. Garbage collection, as provided by Java, doesn't help at all with these things, and that considerably limits its use and reduces the potential safety benefits for real world code.
As for why wrappers around primitives are "safety features", I'm afraid you've got me there. How is requiring a wrapper to make them fit into the type system cleanly improving safety? Dozens of other languages manage just fine without.
Yes, I know, thanks. Actually, relying on finalizers to do anything is a bad idea, given the lack of guarantee about when they will (not) run. In fact, they're a rather pointless feature, possibly useful for diagnostic purposes but not much else.
Yes. And that means that every time you use a resource, you must wrap the use in a try block and remember to add a finally section to release the resources. This frequently means duplicating the same resource release code everywhere -- assuming you never forget it, since you've got a serious bug if you do.
This is not safer than the high-level alternatives, or even than RAII in C++.
No, they aren't, because C++'s template mechanisms go beyond the generics applications. That's kinda the point.
If you'd taken the time to read any of my other posts, you'd realise that I do understand the differences between C++ and Java. I have even commented in this thread on their superficial similarities and real differences, and the need to use each as it was intended.
Nevertheless, I stand by my original point. You do need an excessive amount of casting in Java (1.4), which is inherently less safe than the alternatives offered by numerous other languages (not just C++).
Similarly, you do need to use finally an excessive amount because Java's garbage collection mechanism is only good for avoiding memory leaks, not resource leaks in general.
If you have some technique or idiom for avoiding these problems, please share it, because I'm sure a lot of Java programmers would like to hear it.
I agree completely: a lot of it is down to the maturity of optimisation technology for the language in question. This is part of the reason that some high level languages -- OCaml, for example -- can generate code of a comparable speed to low-level beasts like C and C++: with a simpler underlying model, it's easier to perform good optimisations. It's also the reason C is still faster than C++ for some things, even though theoretically, C++ should never be slower.
I was including dynamic optimisation (during the program run) within the "late optimisation" idea, but in practice, I get the impression it's not used much yet. It's far easier to do platform-specific optimisation on installation or loading, effectively, just doing the optimisation phase of a compile late. Effective dynamic optimisation is a very hard thing to do, because you have the overheads of monitoring code speed to overcome before you can even hold your own, never mind gain an advantage. I suspect that in time, dynamically optimising run-times will gain a much stronger foothold in the market, but probably not until a lot more research has been done.
The conclusion, as ever, must be that good programmers can do well in any decent language, and bad programmers will shoot themselves in the foot in any language.
The great irony, of course, is that a big selling point of Java was its ease of use. They took out all the "over-complicated" bits of C++, to make it faster to learn and less prone to programmer errors. If you're going to get the same sort of problems coming up in Java as in C++, you might as well stick to the latter and at least make the power and flexibility available for the good guys...
(I'm only considering that specific selling point here. Obviously there are other relevant issues to consider when choosing which language to use as well.)
Give or take a few quirks, most recent (last five years, say) C++ compilers support all the major features acceptably well for most purposes. There are only a few issues that cause significant problems: the infamous export, Koenig look-up and partial specialisation of templates come to mind. None of these features is used very often anyway, though.
Coding standards that forbid the use of templates, exceptions and half the standard library in C++ are common, but way out of date.
By the way, I write code for a living that gets shipped on more than a dozen different C++ platforms. Alas, some of them are well pre-standard, and so don't support even basic template or exception mechanics properly, which sucks. But this is an issue we've looked into in some detail, so I'm pretty confident in my statements above.
Oh, please... You're just making a major issue out of a minor detail.
Programmer cycles are much more expensive if your end product runs too slowly to be useful, and nobody buys it.
Performance still matters in a lot more areas than many people seem to give credit for: scientific apps, graphics, high load server work, firmware and instrument control software, games of course, any smart AI, heavy duty data processing... If performance for other things really no longer matters, why do today's applications somehow run as slowly on 2GHz+ PCs as they did on 200MHz boxes a few years ago? Sure, some of it is feature creep... but not that much.
When people say things like "performance no longer matters" and "processor cycles are cheap", I get the impression that the pinnacle of their programming expertise is writing UIs for databases.
Actually, in practice, no it's not and yes you can.
What you're ignoring is the "late optimisation" effect of virtual-machine and intermediate language execution models. The installer or run-time can take intermediate code and convert it to native code, just as a C compiler would, but with full knowledge of the environment in which that code is going to run. That allows for specific optimisations based on the execution environment that are rarely, if ever, practical for C-based programs. (How many C programs ship with different optimised executables for each Pentium and Athlon series processor, for example?)
You seem to be writing as someone who knows how things are supposed to work, who has a certain mindset and isn't prepared to look outside it. So-called just-in-time compilers actually have a lot of potential. They aren't, in general, as fast as something like C or C++ yet. However, in theory they could actually be faster once they've matured and caught up, because they can do all the same low-level optimisation tricks as a C or C++ compiler, with more knowledge of the target environment to get the best out of them.
Microsoft have had a .Net version of Quake II mentioned on their developer pages for some time now. It's a port to Visual C++ .Net 2003, using the CLR.
Has anyone tried this? It's presumably managed C++ rather than C#, but it should give a fair indication of the performance you'd get from C# if it's using the same run-time framework. If they can get comparable performance in a FPS using the .NET run-time, it might be worth looking at for games development after all...
In C++, casts are rarely necessary. When they are, tools like dynamic_cast allow for the same useful run-time type checking as Java et al support.
In Java, you can't even pull an object out of a container without a cast, and you can't even use a basic type in a generic container without some sort of wrapper object.
In C++, the RAII idiom lets you ensure the safe release of any resource type. In Java, you have to write the same finally blocks all over just to make up for the fact that finalizers don't work.
Java is "more safe" than C++?
Now that was funny.
I really can't believe this thread. Why do people always come up with this worn out line whenever someone suggests that C++ templates are an advantage? And how come so many people have done so in replying to the same post? All but the first are (-1, Redundant), and the first is (-1, Ill-informed).
OK, please, read this carefully, for I shall write it only once (in this thread):
Java's generics are not even close to the power of C++ templates. They are glorified macros to fix a bug in the type system that should never have been there.
C++ templates were at that level around a decade ago. Today, they're used not only to create generic containers (for which they are, no doubt, very useful) but also, via metaprogramming techniques, as the tool underlying most of the really powerful developments in C++ for the past few years: expression templates, high performance maths libraries, etc.
If you didn't already know that, please read it again and understand it before proceeding.
Java's generics don't even come close to the same power. They're a cheap knock-off, aimed at just one of the uses of C++ templates, which fixes a glaring flaw in the previous Java language. For that, they serve their purpose well, but please don't pretend they're anything more.
I don't think C++ programmers have ever underestimated the value of garbage collection; Stroustrup mentions it himself in several relevant texts, and garbage collectors have been available for C++ for years, for those who want them. Of course, garbage collection isn't nearly so important in a language with automatic variables and deterministic destruction, which is probably why few people actually use those libraries.
C++ and Java will never be the same language, or even close. They are aimed at two different markets, they have different strengths and weaknesses adapted to those markets, and it's rather unlikely that those markets will converge. The similarity pretty much ends at syntax and basic OO concepts.
Of course it is. That's why Java's adding generics now, I guess: to fix the loopholes that approach didn't cause.
Not everything is an Object; didn't you first textbook tell you?
FWIW, I don't get my information from TV. Most of my opinion is formed from a small number of people I've encountered who work in this area, either in person or on-line: a former member of a British special forces unit who had counter-terrorism responsibilities, serving police officers, a member of a big city SWAT team from the US, and one or two other guys who obviously had been there and done that. I met most of them via a common interest in martial arts, in case you're wondering.
Now, to answer your points...
Certainly these people have had far more training than TV propaganda. They have their own practice houses and other scenarios, and they expect to spend several hours a week training.
Now, if you read the thread carefully, you'll see that the point is using anti-terrorism legislation against non-terrorist criminals. It's not unlikely that by the time the guys making the entry got their instructions, the targets would be "suspected terrorists". The point of this whole thread is that they don't call and treat you as a regular criminal. They file you under "terrorist", and as such they gain all sorts of draconian powers they've no right to be using in cases that aren't immediate matters of national security.
I'm sorry, but you just don't sound like the guys I've talked to, and since I have no idea who you are, that makes me suspicious. What exactly is your role? Who do you train, and in what capacity? And if coming into your house at any time of day would be problematic, what would one of the teams you've trained do to get in to someone else's house that was similarly protected?
Yes, I'll believe the result of the next election unless I have a good reason not to, for two simple reasons.
Firstly, it's very unlikely that an implausible result could occur without being investigated.
Secondly, you have to trust someone or something, some time. If you can't trust the electoral mechanics in a democracy, what can you trust? (No-one isn't a very helpful answer to that question.)
I hate to break this to you, but expecting a newly graduated kid to be a solid performer from day one is unrealistic. They never have been. You weren't. I wasn't. The kids going through now won't be.
Software development hasn't (yet?) developed any sort of "apprenticeship" framework for the new kids on the block to learn practical, real-world skills from old hands. Their knowledge is, inevitably, mostly theoretical. They won't understand everything that was in their course properly, and even if they do understand something in theory, they won't necessarily appreciate the practical implications. The best you can hope for is someone who enjoys their subject, and thus has developed good general knowledge of the field and perhaps done some relevant part-time or summer job work.
If you're taking people on who aren't up to the standards you require at the time, and you're suffering bugs down the line as a result, then you need to review your recruitment process with HR, and you need to review your training process with the line managers responsible for overseeing new starters. Failure to do this is just plain bad management, and bitching about how degrees are worthless "these days" is a rather pathetic attempt to pass the buck. In reality, the blame rests squarely on the shoulders of the managers who haven't developed their resources effectively, and addressing that basic problem is the only way you're going to improve the situation.
Who are you kidding?
If they were going after someone they thought was going to be an armed terrorist, they'd probably go in the early hours of the morning. You'd be asleep, and it would be dark. Depending on the circumstances, they might enter quietly, or they might enter in numbers from multiple points of access after throwing the gas in ahead of them. Either way, they would have a point man and at least one back-up covering you before you'd even registered that someone else was in the room, and unlike you, they would be alert, able to see clearly, and fully aware of the situation.
I don't care how accurate you are when you're shooting on the range, if you pulled that gun out from under your pillow and tried to aim at one of them, you'd be dead before the gun hit the mattress. The guys they send after serious baddies regularly spend hours and hours training for forced entries to arrest hostile subjects -- exactly the sort of bad-ass you're pretending to be. What the hell makes you think you're better at their game than they are?
If you live in the UK, keep the faith. The one good thing about a first past the post electoral system is that the same small shift in the vote that gives one party a disproportionate amount of power can reverse, and take a disproportionate amount of power from them if only a few more people vote another way.
I should perhaps clarify. I'm not taking a swipe at Hudson; his achievements are impressive. I'm just pointing out that there are other people who arguably have a better track record in ICFP contests, and pondering how well they might expect to do out of it.
I know the feeling. I voted for Blair's lot... the first time.
The second time around, their majority in a lot of constituencies halved. They still have a heavy majority in the UK parliament, but they're a lot more cautious about advocating dumb things, several of which have quietly dropped by the wayside recently.
Next time, he's very unlikely to get an absolute majority unless something radical happens between now and the election. Such is the price of abusing a position of unique authority and letting the electorate find out. For Blair, the Achilles heel will be spin. For Bush, it may be civil liberties. Time will tell...
If it did happen, you wouldn't even know what hit you. If you reached for that gun, you'd be dead before the safety was off.
Of course, this sort of mistaken identity can and does happen anyway, but if you're labelled a terrorist before you even start, it's a good bet that they'll shoot first and ask questions never.