As always, you can't make a blanket statement as to what is or isn't a fair use.
I'm not so sure. The copyright bargain is pretty simple in principle, and it's also pretty simple in principle to establish what (ethically speaking) we might regard as fair use.
For example, I might make a blanket statement that an individual who has a legitimately obtained copy of a work should be free to use that work however they see fit in private for their own benefit, regardless of any literal copying or transformative editing involved.
I might also make a blanket statement that it is reasonable to prohibit redistribution of a legitimately obtained work that is subject to copyright or any derivative work, in any way that materially disadvantages the copyright holder, to anyone else without the copyright holder's consent.
In fact, I think if we could agree those two basic principles, there are very few exceptions required. I think the US does better in law than most places here, by at least codifying four generic principles rather than numerous specific, non-adapting exemptions. But even in the US, I think things are too complicated.
Sorry to be the one to break this to you, Mr. Cotton, but the only approach you're going to find that works is making your product inexpensive and easy to use.
The problem with this argument is that it overlooks the fundamental nature of all intellectual property: it always cheap to share it after someone's produced it. In an Internet-enabled world, the marginal cost of distribution is close to zero. However, that doesn't pay the rent for everyone who produced it in the first place, nor reward investors who supported the guys who made it but also supported many other who didn't.
Giving people a fair reward for producing and sharing their work is what things like copyright are (supposed to be) all about, and I've met few people who found this idea unethical when they thought about it. Indeed, when they thought about it, most people I've talked to have found the idea of ripping someone off rather unethical. As the article demonstrates, most people don't really understand the motivation behind copyright. They assume that when they rip things off it's just big business that loses out, or see copyright infringement as a victimless crime because "no-one lost anything". Once these people start to consider the many smaller players in the system who personally lose out as well, or someone points out that "big business" is what's supporting their pensions (or not), only a minority of people seem to look at things the same way.
This isn't to say that I know lots of people who support the industry practices and abusive copyright-related laws that have become so common in the recent past. But if the people I've talked to are at all typical (who knows?) then almost everyone would be willing to pay a fair price if it's genuinely going to the people who brought them works they find useful and/or enjoyable, even if they know they could rip the same content illegally for free.
Yes, copyleft should be protected exactly as much as traditional commercial, closed source products and for exactly the same reasons. If a limited time guarantee that people will follow the GPL is enough to get developers to release their work, then that's a fair deal. Once the time limit is up, anyone is free to take that work, build on it, and release it in whatever form they see fit (including without the source code, if they want). This is the copyright bargain, and the free-as-in-FSF world is as entitled to its protection as anyone else.
Wanting to abolish copyright law in favour of all arts being state-funded is just a misguided pipe-dream.
It doesn't even sound very dreamy to me. It's basically another flavour of socialism, which would inevitably suffer from the same major problem of any socialist policy: when you start redistributing the wealth via government enforcement, you hurt those who are successful and benefit those who are not, thus reducing (or, taken to the logical extreme, outright removing) any incentive to be successful. In this context, being successful pretty much means making works that people want. Why bother with niceties like making your product better when you're going to get paid the same anyway?
The only alternative to blanket state funding is some sort of on-merit scheme, as you get with things like research grants in some places today. But then who decides what is meritorious and what is meretricious? I know I wouldn't want either pop culture or highbrow critics deciding on what I was going to get to watch/read/listen to!
We have market economics for a reason. It's not perfect, but it's a pretty good way of finding what people want. And the thing about copyright, which none of the alternative approaches often suggested around here can match, is that it effectively allows the costs of an expensive but good product to be shared between many people, each of whom may enjoy the benefit of that work for a much smaller cost. If something costs more to make, then in order to return a profit it requires either more people to benefit from it, or that people perceive a greater benefit and so are willing to pay more for it. Isn't a system that rewards making works with wider and/or stronger appeal a good thing?
Thanks for the information. It's a shame the post I replied to didn't mention any of that, and sounded as though it was fine to share content pretty much arbitrarily in Sweden.
You know there is such a thing as noise cancelling headphones...
As I write this, I am in fact wearing a decent pair of noise-cancelling headphones. And guess what? They don't cancel 100% of the noise. To drown out the TV my other half is watching at the other end of the room, I have music on. But I don't like to listen to music at work, as I find it distracting. Quiet is better for me.
I went through a phase of buying the hype about open plan offices improving communication. I'm still convinced there is a genuine benefit there. But the more I work in that sort of environment, the more I find the distractions outweigh that benefit. Most of the incidental communication could be achieved just as well by inviting all relevant people to comment on relevant documents or on-line discussions when it's convenient, or mentioning a new subject of interest by the water cooler to see if anyone else is familiar with it already.
On the other hand, a trivial distraction that disrupts the concentration can take several minutes to get over, which is pretty much a killer for productivity. Worst of all, it hits your best developers disproportionately, because your best people may be literally an order of magnitude more productive than your average. A few average guys interrupting one of your best a handful of times on one day, while apparently taking only a few minutes out of a day, could easily waste the equivalent of a week of average developer time. And all because no-one gave the smart guy a door to close.
That's interesting. Since Sweden is a signatory to the relevant WIPO treaties (notably TRIPS), if what you describe really is legal there then Sweden is almost certainly violating its international agreements. I don't imagine that will last long if the deviation starts to cause perceived damage to other signatory states.
Indeed it is. As I said, my problem is not with LINQ itself, but with the people who are over-hyping it (and, yes, giving poor examples along the way).
Yes, all of this stuff is C++ specific. VC++6 was a decent IDE for its time. When the first version of VS.Net came out, the architecture behind VS moved to a common core for all languages. That was fine if you were using something like C# or VB.Net, as they were new and you had all the.Net trickery to support them. However, a lot of useful stuff from VC++6, such as the browse toolbar I mentioned, couldn't be readily supported in this new multi-lingual architecture and therefore got dropped as MS effectively moved to the least common denominator.
The problem is, while there is a lot of compensating value in more recent VS releases for those using the new.Net languages, the C++ world has been pretty much left out in the cold. In the debugger, we get modest improvements in autoexp.dat, but the managed folks get full visualizers. C++ (and C++/CLI, where applicable) have lagged behind in getting proper designers for forms and such. The help system is so horribly bloated and.Net-centric now that while MSDN used to be the poster child of good technical reference material it is now almost literally useless for a C++ developer. And yes, as mentioned before, the IDE's performance and usability absolutely sucks compared to VC++6, to the point where I have seen experienced developers confront management with some hard facts and refuse to use the "upgraded" versions until compelled to do so.
My bank has a copy of my recognised signature on file, which would be checked if they were asked to do something a bit more drastic than setting up a routine direct debit. Legally speaking there's no requirement that I'm aware of to sign my name the same way on different official documents, but practically there is at least some safeguard there. It's just that it's not economic to use that safeguard routinely for relatively trivial transactions, when a bit of sampling and acceptable losses if things are missed will do.
I agree with many of your criticisms of MFC, but isn't it a bit of a joke to attack MFC for using message maps and macros if you're advocating Qt (completely with signals, slots, and not just macros but a whole preprocessor!) as an alternative?
I think you forgot a few. For one thing, VC6 is actually responsive as an IDE, and doesn't go into a trance for several minutes at the slightest provocation. For another, the online help is actually helpful: if you look up a C++ library function, for example, it tells you about the library function, and not some completely irrelevant class with a vaguely similar name in the.Net framework (after taking half a minute to fire up the help system before it does anything else). Then there's the browse toolbar, which was simple and effective, yet strangely is still missing several.Net-friendly versions later despite widespread criticism of its removal.
Yes, at my office we also have people who prefer to use VC++ 6. Sure, there are some minor advantages in the later versions, but I think (and we've measured these things where it matters) that most of those you cited are over-rated. Many of us long for the days when we have a simple, responsive, usable IDE.
Just for the record, I think LINQ is a neat idea, and as a general principle I'm all in favour of strong abstractions and useful syntactic sugar in programming languages if these make code easier to understand and quicker to develop.
However, I'm worried by a lot of the hype about LINQ that's been flying around in recent months. Earlier this week, I found a code sample in a blog post showing how to use LINQ to find all the items less than 10 in a list. It went something like this:
from n in mylist
where (n => n < 10)
select (n => n)
For reference, here's the equivalent expression in Haskell:
filter (<10) mylist
That's obviously a much more elegant representation of the idea, and while it's not as generic, you also have things like map and reduce available, and a lot more if you need it.
If you don't like the functional syntax, Python's list comprehensions also provide a bit of flexibility, with less redundant clutter than the LINQ:
[n for n in mylist if n < 10]
Even using the standard library algorithms in C++98 — where, let's face it, the use of iterators and of algorithms with predicates is pretty unwieldy in the absence of good syntactic sugar — the code is about the same size as the LINQ version:
This isn't intended to be a criticism of LINQ, because LINQ can do far more than just a simple filter operation on a single list. Rather, I am criticising those who over-hype a new technology as if it is the One True Way to solve all remotely related programming problems, and then apply a powerful, generic approach to a simple problem giving a ludicrously over-engineered result. See also: design patterns, template metaprogramming in C++, dynamically typed languages and web frameworks, monads for trivial I/O in Haskell, etc. Like all these other things, LINQ has a lot of potential to improve development when used in the right context, but I fear it will be overused just because it's new and heavily hyped.
Firefox on it's own in the default configuration will protect your users from a lot of stuff (ActiveX installers come to mind), but I've found that some stuff will still get through.
Of course, as TFA observes, so-called protection of users from legitimate ActiveX-based systems on numerous corporate intranets may also have something to do with it not being adopted. I'm writing this in Firefox on my lunch break, but if I log into our corporate intranet this afternoon, I'll be using IE, because Firefox simply doesn't work. Security issues don't much matter if the necessary functionality isn't there at all.
I don't see how the person who's identity was used is affected by this.
Unfortunately, although that person may not ultimately lose money, they still have to waste time getting their money back and clearing up any consequential mess. In a financial case like this, that might mean things like damaged credit or the hassle of a formal tax investigation, both of which can be very stressful and time consuming. In other cases, criminal records have been involved, and that can really screw up your life, not least because many employers are going to fire first and ask questions later in that sort of discussion.
One could reasonably argue that this is because credit systems tend to be pretty screwed up and tax officers have way too much power to arbitrarily investigate people without compensating those people for the time it wastes. After all, we used to call arbitrary forced labour "slavery", and while I hesitate to use that word here since it's obviously not on the same scale, I think the same moral principle applies. In any case, this is how the system is today, and one of the major problems with identity theft is that it often leaves the real person on the wrong side of The System.
And any bank and its imbecile staff that allows you to pretend to be someone you aren't because they can't be arsed to properly check[1] should be liable for the loss themselves.
Yes, they know that, but it's just the cost of doing business for them. That's why it's very unlikely that anyone other than a computer ever even looks at the signature on most small (in banking terms) value cheques. It's cheaper to pay up in the odd cases where someone gets had and challenges it than it is to employ a small army of people to actually read all the signatures on everyone's cheques. Much the same principle probably applies here, via the Direct Debit Guarantee: it's cheaper to wait for something dubious to get challenged and then go after the registered recipient than it is to double-check every single DD that gets set up.
Of course, whether it's ethical for the custodians of your cash to behave in this way, given that fixing any problems now relies on you to find them and report them, is another question. But from the banks' point of view, it's just basic accounting.
Just as a point of relevance here, Clarkson was victim to a fraudulent direct debit, not a standing order. While both are useful for similar things, the mechanics in the two cases are quite different.
A standing order is normally some sort of regular payment you set up yourself for a constant amount, such as a monthly rent payment to a landlord. A direct debit is set up by the recipient and can vary in amount and date it is collected, and is typically used for paying things like utility bills, where the money owed varies a bit from month to month.
The key difference, for the purposes of debunking the hype here, is that because of the obvious danger in letting a third party instruct your bank on your behalf and then withdraw your money remotely, all direct debits are covered by the Direct Debit Guarantee. Among other things, this says that if something goes wrong, your bank must refund your missing money first and ask questions later. A corollary of the latter is that Clarkson is unlikely to have any trouble getting his missing money back here, ironic and amusing as the incident is.
Sure, but this is a relative scale. Compared to process scheduling or memory allocation, TCP/IP really doesn't matter that much. The performance overhead from writing such code in a marginally higher level language that is safe from buffer overflows is likely to be small as well.
Congratulations. I believe you've just given the first legitimate criticism of refactoring in any post I've read so far in this discussion. The merge issue is a genuine problem, and counsels a little hesitation before changing too many trivial things. In any case, it's almost certainly a good idea to check in any substantial refactoring work separately from the follow-up work that motivated it and actually changes behaviour.
That said, I don't think even the merge issue is that big a problem. If you only refactor code when it's useful preparation before doing some bug fixing or new development, some of that code is going to change anyway and you're going to be at risk of conflicts with any other developers working in the same area anyway.
Wouldn't it be cool if these folks who keep coming up with refactoring IDEs could come up with a language-sensitive, refactoring-aware diff/match tool to match? Now that would be a tool worth having for developers.
This is refactoring, turning bad code that typically ends out being more expensive (server load) for the company into cheaper, better, faster, less buggy, code.
No, it isn't.
By definition, refactoring does not change behaviour, at all. Not for the worse. Not for the better.
Now, once you've finished refactoring the code into a more manageable shape, it should be easier to fix bugs or add new features. You might even discover new bugs in the course of the refactoring, and be able to address those when you do whatever you came to do in the first place. But these things are not themselves refactoring. It simply isn't what the word means.
Slashdot Mirror
As always, you can't make a blanket statement as to what is or isn't a fair use.
I'm not so sure. The copyright bargain is pretty simple in principle, and it's also pretty simple in principle to establish what (ethically speaking) we might regard as fair use.
For example, I might make a blanket statement that an individual who has a legitimately obtained copy of a work should be free to use that work however they see fit in private for their own benefit, regardless of any literal copying or transformative editing involved.
I might also make a blanket statement that it is reasonable to prohibit redistribution of a legitimately obtained work that is subject to copyright or any derivative work, in any way that materially disadvantages the copyright holder, to anyone else without the copyright holder's consent.
In fact, I think if we could agree those two basic principles, there are very few exceptions required. I think the US does better in law than most places here, by at least codifying four generic principles rather than numerous specific, non-adapting exemptions. But even in the US, I think things are too complicated.
Sorry to be the one to break this to you, Mr. Cotton, but the only approach you're going to find that works is making your product inexpensive and easy to use.
The problem with this argument is that it overlooks the fundamental nature of all intellectual property: it always cheap to share it after someone's produced it. In an Internet-enabled world, the marginal cost of distribution is close to zero. However, that doesn't pay the rent for everyone who produced it in the first place, nor reward investors who supported the guys who made it but also supported many other who didn't.
Giving people a fair reward for producing and sharing their work is what things like copyright are (supposed to be) all about, and I've met few people who found this idea unethical when they thought about it. Indeed, when they thought about it, most people I've talked to have found the idea of ripping someone off rather unethical. As the article demonstrates, most people don't really understand the motivation behind copyright. They assume that when they rip things off it's just big business that loses out, or see copyright infringement as a victimless crime because "no-one lost anything". Once these people start to consider the many smaller players in the system who personally lose out as well, or someone points out that "big business" is what's supporting their pensions (or not), only a minority of people seem to look at things the same way.
This isn't to say that I know lots of people who support the industry practices and abusive copyright-related laws that have become so common in the recent past. But if the people I've talked to are at all typical (who knows?) then almost everyone would be willing to pay a fair price if it's genuinely going to the people who brought them works they find useful and/or enjoyable, even if they know they could rip the same content illegally for free.
Yes, copyleft should be protected exactly as much as traditional commercial, closed source products and for exactly the same reasons. If a limited time guarantee that people will follow the GPL is enough to get developers to release their work, then that's a fair deal. Once the time limit is up, anyone is free to take that work, build on it, and release it in whatever form they see fit (including without the source code, if they want). This is the copyright bargain, and the free-as-in-FSF world is as entitled to its protection as anyone else.
Hey! Our political opponents never stop trying to think of new ways to make us look bad, and neither do we.
Wanting to abolish copyright law in favour of all arts being state-funded is just a misguided pipe-dream.
It doesn't even sound very dreamy to me. It's basically another flavour of socialism, which would inevitably suffer from the same major problem of any socialist policy: when you start redistributing the wealth via government enforcement, you hurt those who are successful and benefit those who are not, thus reducing (or, taken to the logical extreme, outright removing) any incentive to be successful. In this context, being successful pretty much means making works that people want. Why bother with niceties like making your product better when you're going to get paid the same anyway?
The only alternative to blanket state funding is some sort of on-merit scheme, as you get with things like research grants in some places today. But then who decides what is meritorious and what is meretricious? I know I wouldn't want either pop culture or highbrow critics deciding on what I was going to get to watch/read/listen to!
We have market economics for a reason. It's not perfect, but it's a pretty good way of finding what people want. And the thing about copyright, which none of the alternative approaches often suggested around here can match, is that it effectively allows the costs of an expensive but good product to be shared between many people, each of whom may enjoy the benefit of that work for a much smaller cost. If something costs more to make, then in order to return a profit it requires either more people to benefit from it, or that people perceive a greater benefit and so are willing to pay more for it. Isn't a system that rewards making works with wider and/or stronger appeal a good thing?
Thanks for the information. It's a shame the post I replied to didn't mention any of that, and sounded as though it was fine to share content pretty much arbitrarily in Sweden.
Ask a Klingon if he's a good programmer, and he's likely to remove your head with a bat'leth for insulting his honour...
I think your modesty is your most endearing quality.
You know there is such a thing as noise cancelling headphones...
As I write this, I am in fact wearing a decent pair of noise-cancelling headphones. And guess what? They don't cancel 100% of the noise. To drown out the TV my other half is watching at the other end of the room, I have music on. But I don't like to listen to music at work, as I find it distracting. Quiet is better for me.
I went through a phase of buying the hype about open plan offices improving communication. I'm still convinced there is a genuine benefit there. But the more I work in that sort of environment, the more I find the distractions outweigh that benefit. Most of the incidental communication could be achieved just as well by inviting all relevant people to comment on relevant documents or on-line discussions when it's convenient, or mentioning a new subject of interest by the water cooler to see if anyone else is familiar with it already.
On the other hand, a trivial distraction that disrupts the concentration can take several minutes to get over, which is pretty much a killer for productivity. Worst of all, it hits your best developers disproportionately, because your best people may be literally an order of magnitude more productive than your average. A few average guys interrupting one of your best a handful of times on one day, while apparently taking only a few minutes out of a day, could easily waste the equivalent of a week of average developer time. And all because no-one gave the smart guy a door to close.
That's interesting. Since Sweden is a signatory to the relevant WIPO treaties (notably TRIPS), if what you describe really is legal there then Sweden is almost certainly violating its international agreements. I don't imagine that will last long if the deviation starts to cause perceived damage to other signatory states.
That is just poor code.
Indeed it is. As I said, my problem is not with LINQ itself, but with the people who are over-hyping it (and, yes, giving poor examples along the way).
Yes, all of this stuff is C++ specific. VC++6 was a decent IDE for its time. When the first version of VS.Net came out, the architecture behind VS moved to a common core for all languages. That was fine if you were using something like C# or VB.Net, as they were new and you had all the .Net trickery to support them. However, a lot of useful stuff from VC++6, such as the browse toolbar I mentioned, couldn't be readily supported in this new multi-lingual architecture and therefore got dropped as MS effectively moved to the least common denominator.
The problem is, while there is a lot of compensating value in more recent VS releases for those using the new .Net languages, the C++ world has been pretty much left out in the cold. In the debugger, we get modest improvements in autoexp.dat, but the managed folks get full visualizers. C++ (and C++/CLI, where applicable) have lagged behind in getting proper designers for forms and such. The help system is so horribly bloated and .Net-centric now that while MSDN used to be the poster child of good technical reference material it is now almost literally useless for a C++ developer. And yes, as mentioned before, the IDE's performance and usability absolutely sucks compared to VC++6, to the point where I have seen experienced developers confront management with some hard facts and refuse to use the "upgraded" versions until compelled to do so.
My bank has a copy of my recognised signature on file, which would be checked if they were asked to do something a bit more drastic than setting up a routine direct debit. Legally speaking there's no requirement that I'm aware of to sign my name the same way on different official documents, but practically there is at least some safeguard there. It's just that it's not economic to use that safeguard routinely for relatively trivial transactions, when a bit of sampling and acceptable losses if things are missed will do.
I agree with many of your criticisms of MFC, but isn't it a bit of a joke to attack MFC for using message maps and macros if you're advocating Qt (completely with signals, slots, and not just macros but a whole preprocessor!) as an alternative?
The ONLY advantages to VC6 are: [snip]
I think you forgot a few. For one thing, VC6 is actually responsive as an IDE, and doesn't go into a trance for several minutes at the slightest provocation. For another, the online help is actually helpful: if you look up a C++ library function, for example, it tells you about the library function, and not some completely irrelevant class with a vaguely similar name in the .Net framework (after taking half a minute to fire up the help system before it does anything else). Then there's the browse toolbar, which was simple and effective, yet strangely is still missing several .Net-friendly versions later despite widespread criticism of its removal.
Yes, at my office we also have people who prefer to use VC++ 6. Sure, there are some minor advantages in the later versions, but I think (and we've measured these things where it matters) that most of those you cited are over-rated. Many of us long for the days when we have a simple, responsive, usable IDE.
Just for the record, I think LINQ is a neat idea, and as a general principle I'm all in favour of strong abstractions and useful syntactic sugar in programming languages if these make code easier to understand and quicker to develop.
However, I'm worried by a lot of the hype about LINQ that's been flying around in recent months. Earlier this week, I found a code sample in a blog post showing how to use LINQ to find all the items less than 10 in a list. It went something like this:
from n in mylist
where (n => n < 10)
select (n => n)
For reference, here's the equivalent expression in Haskell:
filter (<10) mylist
That's obviously a much more elegant representation of the idea, and while it's not as generic, you also have things like map and reduce available, and a lot more if you need it.
If you don't like the functional syntax, Python's list comprehensions also provide a bit of flexibility, with less redundant clutter than the LINQ:
[n for n in mylist if n < 10]
Even using the standard library algorithms in C++98 — where, let's face it, the use of iterators and of algorithms with predicates is pretty unwieldy in the absence of good syntactic sugar — the code is about the same size as the LINQ version:
find_if(mylist.begin(), mylist.end(), bind2nd(less<int>(), 10))
This isn't intended to be a criticism of LINQ, because LINQ can do far more than just a simple filter operation on a single list. Rather, I am criticising those who over-hype a new technology as if it is the One True Way to solve all remotely related programming problems, and then apply a powerful, generic approach to a simple problem giving a ludicrously over-engineered result. See also: design patterns, template metaprogramming in C++, dynamically typed languages and web frameworks, monads for trivial I/O in Haskell, etc. Like all these other things, LINQ has a lot of potential to improve development when used in the right context, but I fear it will be overused just because it's new and heavily hyped.
Firefox on it's own in the default configuration will protect your users from a lot of stuff (ActiveX installers come to mind), but I've found that some stuff will still get through.
Of course, as TFA observes, so-called protection of users from legitimate ActiveX-based systems on numerous corporate intranets may also have something to do with it not being adopted. I'm writing this in Firefox on my lunch break, but if I log into our corporate intranet this afternoon, I'll be using IE, because Firefox simply doesn't work. Security issues don't much matter if the necessary functionality isn't there at all.
I don't see how the person who's identity was used is affected by this.
Unfortunately, although that person may not ultimately lose money, they still have to waste time getting their money back and clearing up any consequential mess. In a financial case like this, that might mean things like damaged credit or the hassle of a formal tax investigation, both of which can be very stressful and time consuming. In other cases, criminal records have been involved, and that can really screw up your life, not least because many employers are going to fire first and ask questions later in that sort of discussion.
One could reasonably argue that this is because credit systems tend to be pretty screwed up and tax officers have way too much power to arbitrarily investigate people without compensating those people for the time it wastes. After all, we used to call arbitrary forced labour "slavery", and while I hesitate to use that word here since it's obviously not on the same scale, I think the same moral principle applies. In any case, this is how the system is today, and one of the major problems with identity theft is that it often leaves the real person on the wrong side of The System.
And any bank and its imbecile staff that allows you to pretend to be someone you aren't because they can't be arsed to properly check[1] should be liable for the loss themselves.
Yes, they know that, but it's just the cost of doing business for them. That's why it's very unlikely that anyone other than a computer ever even looks at the signature on most small (in banking terms) value cheques. It's cheaper to pay up in the odd cases where someone gets had and challenges it than it is to employ a small army of people to actually read all the signatures on everyone's cheques. Much the same principle probably applies here, via the Direct Debit Guarantee: it's cheaper to wait for something dubious to get challenged and then go after the registered recipient than it is to double-check every single DD that gets set up.
Of course, whether it's ethical for the custodians of your cash to behave in this way, given that fixing any problems now relies on you to find them and report them, is another question. But from the banks' point of view, it's just basic accounting.
Just as a point of relevance here, Clarkson was victim to a fraudulent direct debit, not a standing order. While both are useful for similar things, the mechanics in the two cases are quite different.
A standing order is normally some sort of regular payment you set up yourself for a constant amount, such as a monthly rent payment to a landlord. A direct debit is set up by the recipient and can vary in amount and date it is collected, and is typically used for paying things like utility bills, where the money owed varies a bit from month to month.
The key difference, for the purposes of debunking the hype here, is that because of the obvious danger in letting a third party instruct your bank on your behalf and then withdraw your money remotely, all direct debits are covered by the Direct Debit Guarantee. Among other things, this says that if something goes wrong, your bank must refund your missing money first and ask questions later. A corollary of the latter is that Clarkson is unlikely to have any trouble getting his missing money back here, ironic and amusing as the incident is.
Sure, but this is a relative scale. Compared to process scheduling or memory allocation, TCP/IP really doesn't matter that much. The performance overhead from writing such code in a marginally higher level language that is safe from buffer overflows is likely to be small as well.
Aw, shucks. I was all set to post the Python version for you, but tragically it seems someone already beat me to it. :-)
The worst part of refactoring, it breaks merges.
Congratulations. I believe you've just given the first legitimate criticism of refactoring in any post I've read so far in this discussion. The merge issue is a genuine problem, and counsels a little hesitation before changing too many trivial things. In any case, it's almost certainly a good idea to check in any substantial refactoring work separately from the follow-up work that motivated it and actually changes behaviour.
That said, I don't think even the merge issue is that big a problem. If you only refactor code when it's useful preparation before doing some bug fixing or new development, some of that code is going to change anyway and you're going to be at risk of conflicts with any other developers working in the same area anyway.
Wouldn't it be cool if these folks who keep coming up with refactoring IDEs could come up with a language-sensitive, refactoring-aware diff/match tool to match? Now that would be a tool worth having for developers.
This is refactoring, turning bad code that typically ends out being more expensive (server load) for the company into cheaper, better, faster, less buggy, code.
No, it isn't.
By definition, refactoring does not change behaviour, at all. Not for the worse. Not for the better.
Now, once you've finished refactoring the code into a more manageable shape, it should be easier to fix bugs or add new features. You might even discover new bugs in the course of the refactoring, and be able to address those when you do whatever you came to do in the first place. But these things are not themselves refactoring. It simply isn't what the word means.
Sorry. To steal someone else's explanation:
/|\ <-- You
-- Joke --->
o
/ \
(The symbols I used in the blanked word are all notorious line noise syntax in Perl.)