"Public investigation and legal notices allow spammers ample time to shut down their activities and hide their assets even before the investigation begins."
The old way to deal with this was to make the public notices in places where you had to look for -- like the basement cork-board of some oddly-located government building.
"It seems like what FTC is asking doesn't even come close to those two."
True, but any comparison to some other wrongdoing is irrelevant. This one is wrong, and it should be fought just like the rest.
Precisely. In fact, the whole point of defending rights is that you can't be selective on whose rights you defend. You have to defend even horrible things, which is why the ACLU is generally reviled -- they are the ones who typically step in when no one else will to defend some of the worst garbage born.
Spammers are basically evil. Yet they must be dealt with through legal means and with respect for the same rights we all ahve.
As another poster already mentioned, the FTC is hardly a "secret government agency." They are not in the habit of doing surveillance. Nor should they get into it. They should need a warrant just like everyone else.
Or at least, like everyone else USED to need... *sigh*
Not every organization, large or otherwise, has the in-house talent to do their own open-source maintenance and support. Maybe they have most of their machines running Windows, maybe not.
Beyond that, a lot of experienced tech executives, having been burned by a lack of support in the past, are not going to chance it without a service contract like the one Enterprise offers.
The arguments for and against are like the arguments for and against buying insurance, because the support contract is a form of insurance. You will never convince me that the full coverage I pay for on my vehicle isn't worth it, because at the moment my car was stolen and totalled, I received more money back than I'd ever paid the insurance company. On the other hand, you'll never convince my girlfriend -- who drives an '83 Accord -- that anything other than the minimum liability insurance the law requires is necessary.
We're both right, because our situations are different.
I've thought about this myself. The whole key to a slot machine or a fruit machine is that you need to be able to set the "payout" percentage, typically something high like 98%. 98% means that the player gets back $0.98 on every $1, assuming he plays an infinite amount of times.
The only way to guarantee this is by determining what the payout is as soon as the money's in the slot. The "pick high or low" and all of these other things are just meant to help keep the player interested, so that the player keeps playing.
Slot machines use other tricks, too: You can play on multiple lines, or you can play multiple coins for higher bonuses. Obviously the bonuses are multiples of the number of coins you play, so they have zero effect on probability. Multiple lines increases the probability you'll win per spin, but it doesn't affect the probability per coin, which is what matters to the proprietor.
This isn't a scam or cheating or anything like that. It is the same principle behind coin-op arcade machines: You pay to play. On a machine that has 98% payout and takes quarters, that means you pay (theoretically) half a cent every time you spin. In reality, you spend more or less than that depending on random outcomes, but over millions of plays on thousands of machines it means a good twopence on the pound for the Brits and two cents on the dollar for Americans.
Companies, that is. Not for the players.
No way you're getting away with that...
on
Today's SCO News
·
· Score: 3, Funny
Yeah, well at least we don't have to wait until we get to the last chapter of our novels to get to all the verbs.;)
...we had total control over the hardware and drivers that we released.
We released a full embedded product, and so there were no user options to give us any hassle that way.
And that decision was by design so that we could ensure that it was bug-free.
For example, if you pop an SD Card out in the middle of a write operation, you will corrupt the data, no matter how bug-free your software is. Solution? You physically block the SD Card slot. Since we had to build an external shell for a couple of additional components anyway, it was just a matter of remembering that we wanted to block the slot off.
With most software, most crashes are, at worst, merely frustrating. A crash in your car's ECU might cause it to spew out black smoke, but it will still run. A crash in the ABS firmware on the other hand...
With software like that, you pay extra for bug-free, and you should expect to get that. But for most of us, if my word processor goes kablooey, my girlfriend and I won't end up as a messy blood splotch on baked asphalt.
This allowance for bugginess is perfectly reasonable in almost all circumstances. ABS brake controllers and other similar "someone's life or livelihood is on the line" products are obviously exceptions. So although the industry may have conditioned people to expect a bit of bugginess, before the expectation came about there was a bit of common-sense weighing of priorities, and perfect software stability is all the way up there with, well, figuring out if my dress socks are black or navy blue in weak lighting...
A couple of months ago, the company I worked for spent a lot of time and effort developing a robust testing methodology. We had a software product that through blood sweat and tears would not crash unless you basically blasted the hardware in some way.
But that led to two problems. First, we only had so many people working, and resources spent testing and bugfixing were not being used to add new features. Second, the time it took to get it that robust delayed the product's release beyond the point where we could recover the investment. [Time developing] * [Cost of operating] was greater than [expected number of units sold] * [price per unit].
What ended up happening was that we lacked the features to justify the price and number of units we needed to sell to cover the cost of developing it. We had no bugs -- and we could be certain of it -- that would crash the machine.
As of last month, the company could no longer afford to pay me. I'm not there any more.
The moral of the story is that trying to make a bug-free product will bankrupt your company, especially a startup. Software tools have improved, but the benefit largely goes towards adding new whiz-bang features that sell the product for more money, not to being able to fix more bugs.
What we should do as engineers and managers of software products is to not be afraid of getting the product out the door with a few bugs in it if we want our company to do well; this business reality is ultimately why bugs will a big part of software for the forseeable future.
This is a small article in a relatively unknown magazine, and even there, Intuit's claim that the consumer backlash was "completely unexpected" tells the real tale:
They still don't get it.
This isn't about technology, rights or anything. This is about simple plain good business sense. This is about bad management. It is a fallacy for a company to think that their product is so delightful that people will put up with being treated like a criminal for the right to use it. Intuit only has one major competitor (H&R Block's Taxcut). The RIAA has thousands of small labels that are chomping at the bit in anticipation of the market the big labels are about to surrender.
The nice thing about a market economy is that the RIAA's folly is our opportunity. It's actually in the small labels' best interests for the RIAA and Microsoft to continue down the DRM path.
You just highlighted right there the #1 reason why I (almost) never cheated on tests by peeking at someone else's paper: God only knows what moron or lunatic happened to be sitting beside me that day, or what his/her motives were. I trusted my own ability to get the correct answer far better than anyone else's.
As a TA in college, and now with my girlfriend TA'ing, we see all the time where people have cheated by copying answers -- answers that are so bizarrely wrong that cheating is the only possible explanation for why three people got the same answer.
The main thing that's happened is that people have abandoned USENET in favor off web-based boards. These web-based boards are almost always moderated by the owner -- not moderated to the point where everypost must pass through a moderator, but to where potential problems can be flagged and dealt with. BBS software is the next evolutionary step of the internet newsgroup. But as people go to internet BBSes instead of USENET, USENET becomes more obscure, and thus the hellions are kept at bay basically by not knowing what USENET is.:)
In Diamond's book Guns, Germs and Steel (funny, we had a Jared Diamond article just yesterday)...
He talks about how growth of a community leads to a change in how the community has to be managed. At a certain point, you need a centralized government to manage the interactions between people, because you no longer have a community.
USENET actually allowed a much larger community than had ever been possible before, before things broke down and the need for some kind of governance emerged. On the other hand, you can't kill someone over USENET. It's not real life.
What happened to USENET was inevitable. It is not a critique of human nature to say so; this is what happens when societies reach a certain size when there is no governing force to maintain order.
The author is right on all points, and they are points I wish my boss understood, particularly about the programmer's need to rest and not be interrupted constantly!
The author seems to be speaking to people like me who already agree with him. A pair of sentences like "If that was the first thought in your head, then you've missed the whole point of this column. Start again at the top, and pay attention this time" read more like an accusation than instruction. My boss (and yours, too) would most likely get offended at this point and discard all the author had said. What use is information when presented without understanding the egos and pride of employers who have worked hard to build a company, through sweat, tears, sacrifice, and long hours?
Two years ago, I worked for a company that had a department in Egypt, and when layoffs occurred, they only occurred for us here. The Egyptians were skilled and intelligent, but they were not as well-trained in software engineering as the average US college graduate. They could write code, but they were not well-versed in different operating systems, and I probably would not expect them to have had any training in algorithmic complexity or other techniques that frequently help with design of a system.
But this was not an example of outsourcing. This was someone giving people in his former country a chance to succeed, and these people were not programmers of the level you'd expect to be graduating from a decent US university. These people were not given the tasks that those of us who were laid off were given; those tasks ended up being done by the founders, or no one at all.
This article is very cleverly written, and does a terrific job of trying to stir up trouble -- just look at the number of posts to this article!
Note that when comparing foreign wages to ours, the author of the article specifically chooses to mention -programmer- and -project manager- salaries.
Yet all of the "I.T." jobs that are being outsourced that the article mentions are for -call centers-. Tech support. The bottom of the barrel for I.T. The article also fails to disclose the sort of jobs the person it mentions was looking for and holding, and even then it has to give the disclaimer that her case is not normal!
I don't see demand in the United States for highly-skilled and trained Software Engineers diminishing. And the amount of code still needing to be written in the world is still growing much faster than the educated base of potential employees, as more and more things that were formerly done in hardware are moved to software, and more and more things are given interfaces that we can program new things for.
In short, no need to panic. This article is what used to be called "yellow journalism," trying to stir up discontent and political action where there is little evidence or story in fact.
Oh, I completely agree with you about OO usage in that respect. OO was a revolution; as with all revolutions, there was a lot of hype and hoopla that wasn't really relevant, and the business model aspect was, imho, all hype.
On the other hand we don't want to go all the way to the opposite extreme and say that OO is completely hype, and ignore the one simple idea -- that of being able to change the way an piece of code behaves without having to rewrite it completely or changing its source -- indeed, without even having access to the source. This is a very important step towards making code with resuable components.
We're not completely there yet, but AOP is yet another step in that direction, to where we just wire bits of existing functionality together without having to do a lot of extra work.
That's a fine prescription. When you find an employer who is willing to pay and wait for you to make your own GUI toolkit from scratch, that will be a terrific way to go.
If you're strapped for time and need to focus on the functionality of your application, you're probably going to use one of the pre-existing GUI toolkits -- MFC, Qt, whatever. And you may need to get it to do things where the properties and messages provided by the widgets aren't enough. And then you'll need to do this. It happens all of the time, and every time I've had to write a GUI.
I would like to see a semi-realistic example of this.
Try GUI programming sometime.
Let's say the default action of a button is to send a "clicked" signal or callback whenever the mouse button is released. Let's say I want to make a button that only does that when it's double-clicked.
An OO GUI framework buys me two things in this instance. First, I only have to re-implement the functionality I want to re-implement; by making a subclass of the basic button class, all other functions revert to the old implementation. So I won't have to re-write how the button is drawn for example.
And all I have to do to use my new button is to declare the buttons in my dialog as being of this class. I don't have to add code into the windowing system itself to make a call to the new code; it recognizes that it's the new code because of widget's type.
The goal of AOP is to take this a step further, to where I wouldn't even need to create objects of the new type -- I could just specify the new behavior for all buttons. But both of these are big advantages over purely procedural mechanisms.
The trouble is, Mr. Dinosaur, that sometimes behind these fads are some really good ideas.
The really good idea behind OOP, for example, was that you have language-level support for adding functionality to code without having to insert a call into that code.
The really good idea behind AOP is that if you need to make a module that is orthogonal to your existing functional decomposition, you can.
It doesn't matter in academia, where you largely make everything from scratch, but in the real world where code survives for ages, techniques like these are extremely helpful.
I had a chance to read about AOP a few years ago, when it was first being introduced.
Short answer: Yes, it is the Next Big Thing.
In the same sort of way that procedures were already implemented by experienced programmers long before languages like Pascal came to be,
In the same sort of way that experienced programmers used virtual function lookup tables and information hiding before OOP came about,
So is AOP. It is program-language-level support for the sorts of things experienced programmers do already... namely, code generation and automatic code modification.
Basically the reason OOP came about was that there was no means to add functionality to code without going into that code and inserting a call to the new functionality. Experienced programmers made virtual functions and lookup tables to solve this issue, but obviously this sort of code is complex and prone to error. So OOP brought forth program-language-level support for this sort of feature.
The problem that AOP addresses is this: As powerful as OOP is, it still relies on functional decomposition. The trouble is, sometimes one thing changes that cuts across functional boundaries. For example, the performance of an application, when ported to a new system, may need an entirely different set of performance tuning for the new app. Or more likely, you simply didn't see some aspect (there's that word) of your code changing often, and it would be impossible to separate it into a module without restructuring your entire code.
Now you can do a lot of inline #ifdef's and the like to do this by hand. Or, you can use some sort of dynamic code generation. But writing a dynamic code generator by hand is, like the virtual function table example above, tricky and always ad hoc.
The ultimate goal behind AOP is to make code generation generalized and done at the language level. So that you can modify things that occur across the boundaries of the existing functional decomposition.
Slashdot Mirror
"guarded by a panther?"
Precisely. Possibly even TWO panthers.
"Public investigation and legal notices allow spammers ample time to shut down their activities and hide their assets even before the investigation begins."
The old way to deal with this was to make the public notices in places where you had to look for -- like the basement cork-board of some oddly-located government building.
"It seems like what FTC is asking doesn't even come close to those two."
True, but any comparison to some other wrongdoing is irrelevant. This one is wrong, and it should be fought just like the rest.
Precisely. In fact, the whole point of defending rights is that you can't be selective on whose rights you defend. You have to defend even horrible things, which is why the ACLU is generally reviled -- they are the ones who typically step in when no one else will to defend some of the worst garbage born.
Spammers are basically evil. Yet they must be dealt with through legal means and with respect for the same rights we all ahve.
As another poster already mentioned, the FTC is hardly a "secret government agency." They are not in the habit of doing surveillance. Nor should they get into it. They should need a warrant just like everyone else.
Or at least, like everyone else USED to need... *sigh*
Not every organization, large or otherwise, has the in-house talent to do their own open-source maintenance and support. Maybe they have most of their machines running Windows, maybe not.
Beyond that, a lot of experienced tech executives, having been burned by a lack of support in the past, are not going to chance it without a service contract like the one Enterprise offers.
The arguments for and against are like the arguments for and against buying insurance, because the support contract is a form of insurance. You will never convince me that the full coverage I pay for on my vehicle isn't worth it, because at the moment my car was stolen and totalled, I received more money back than I'd ever paid the insurance company. On the other hand, you'll never convince my girlfriend -- who drives an '83 Accord -- that anything other than the minimum liability insurance the law requires is necessary.
We're both right, because our situations are different.
"In Nevada that machine would be illegal."
It would? Then how can it guarantee its payout percentage?
$.98 on every $1, an infinite number of times with a finite amount of money is zero, yes.
What is your point?
I've thought about this myself. The whole key to a slot machine or a fruit machine is that you need to be able to set the "payout" percentage, typically something high like 98%. 98% means that the player gets back $0.98 on every $1, assuming he plays an infinite amount of times.
The only way to guarantee this is by determining what the payout is as soon as the money's in the slot. The "pick high or low" and all of these other things are just meant to help keep the player interested, so that the player keeps playing.
Slot machines use other tricks, too: You can play on multiple lines, or you can play multiple coins for higher bonuses. Obviously the bonuses are multiples of the number of coins you play, so they have zero effect on probability. Multiple lines increases the probability you'll win per spin, but it doesn't affect the probability per coin, which is what matters to the proprietor.
This isn't a scam or cheating or anything like that. It is the same principle behind coin-op arcade machines: You pay to play. On a machine that has 98% payout and takes quarters, that means you pay (theoretically) half a cent every time you spin. In reality, you spend more or less than that depending on random outcomes, but over millions of plays on thousands of machines it means a good twopence on the pound for the Brits and two cents on the dollar for Americans.
Companies, that is. Not for the players.
Yeah, well at least we don't have to wait until we get to the last chapter of our novels to get to all the verbs. ;)
...we had total control over the hardware and drivers that we released.
We released a full embedded product, and so there were no user options to give us any hassle that way.
And that decision was by design so that we could ensure that it was bug-free.
For example, if you pop an SD Card out in the middle of a write operation, you will corrupt the data, no matter how bug-free your software is. Solution? You physically block the SD Card slot. Since we had to build an external shell for a couple of additional components anyway, it was just a matter of remembering that we wanted to block the slot off.
With most software, most crashes are, at worst, merely frustrating. A crash in your car's ECU might cause it to spew out black smoke, but it will still run. A crash in the ABS firmware on the other hand...
With software like that, you pay extra for bug-free, and you should expect to get that. But for most of us, if my word processor goes kablooey, my girlfriend and I won't end up as a messy blood splotch on baked asphalt.
This allowance for bugginess is perfectly reasonable in almost all circumstances. ABS brake controllers and other similar "someone's life or livelihood is on the line" products are obviously exceptions. So although the industry may have conditioned people to expect a bit of bugginess, before the expectation came about there was a bit of common-sense weighing of priorities, and perfect software stability is all the way up there with, well, figuring out if my dress socks are black or navy blue in weak lighting...
I think this is basically the right answer.
A couple of months ago, the company I worked for spent a lot of time and effort developing a robust testing methodology. We had a software product that through blood sweat and tears would not crash unless you basically blasted the hardware in some way.
But that led to two problems. First, we only had so many people working, and resources spent testing and bugfixing were not being used to add new features. Second, the time it took to get it that robust delayed the product's release beyond the point where we could recover the investment. [Time developing] * [Cost of operating] was greater than [expected number of units sold] * [price per unit].
What ended up happening was that we lacked the features to justify the price and number of units we needed to sell to cover the cost of developing it. We had no bugs -- and we could be certain of it -- that would crash the machine.
As of last month, the company could no longer afford to pay me. I'm not there any more.
The moral of the story is that trying to make a bug-free product will bankrupt your company, especially a startup. Software tools have improved, but the benefit largely goes towards adding new whiz-bang features that sell the product for more money, not to being able to fix more bugs.
What we should do as engineers and managers of software products is to not be afraid of getting the product out the door with a few bugs in it if we want our company to do well; this business reality is ultimately why bugs will a big part of software for the forseeable future.
This is a small article in a relatively unknown magazine, and even there, Intuit's claim that the consumer backlash was "completely unexpected" tells the real tale:
They still don't get it.
This isn't about technology, rights or anything. This is about simple plain good business sense. This is about bad management. It is a fallacy for a company to think that their product is so delightful that people will put up with being treated like a criminal for the right to use it. Intuit only has one major competitor (H&R Block's Taxcut). The RIAA has thousands of small labels that are chomping at the bit in anticipation of the market the big labels are about to surrender.
The nice thing about a market economy is that the RIAA's folly is our opportunity. It's actually in the small labels' best interests for the RIAA and Microsoft to continue down the DRM path.
So let's keep this news quiet, okay?
You just highlighted right there the #1 reason why I (almost) never cheated on tests by peeking at someone else's paper: God only knows what moron or lunatic happened to be sitting beside me that day, or what his/her motives were. I trusted my own ability to get the correct answer far better than anyone else's.
As a TA in college, and now with my girlfriend TA'ing, we see all the time where people have cheated by copying answers -- answers that are so bizarrely wrong that cheating is the only possible explanation for why three people got the same answer.
Sort of.
:)
The main thing that's happened is that people have abandoned USENET in favor off web-based boards. These web-based boards are almost always moderated by the owner -- not moderated to the point where everypost must pass through a moderator, but to where potential problems can be flagged and dealt with. BBS software is the next evolutionary step of the internet newsgroup. But as people go to internet BBSes instead of USENET, USENET becomes more obscure, and thus the hellions are kept at bay basically by not knowing what USENET is.
In Diamond's book Guns, Germs and Steel (funny, we had a Jared Diamond article just yesterday)...
He talks about how growth of a community leads to a change in how the community has to be managed. At a certain point, you need a centralized government to manage the interactions between people, because you no longer have a community.
USENET actually allowed a much larger community than had ever been possible before, before things broke down and the need for some kind of governance emerged. On the other hand, you can't kill someone over USENET. It's not real life.
What happened to USENET was inevitable. It is not a critique of human nature to say so; this is what happens when societies reach a certain size when there is no governing force to maintain order.
First, clean your ducts. Then, start using these babies in your a/c system. Problem solved. Make sure you replace them whenever they need it, too.
Nothing a wee bit of good duct maintenance can't solve.
The author is right on all points, and they are points I wish my boss understood, particularly about the programmer's need to rest and not be interrupted constantly!
The author seems to be speaking to people like me who already agree with him. A pair of sentences like "If that was the first thought in your head, then you've missed the whole point of this column. Start again at the top, and pay attention this time" read more like an accusation than instruction. My boss (and yours, too) would most likely get offended at this point and discard all the author had said. What use is information when presented without understanding the egos and pride of employers who have worked hard to build a company, through sweat, tears, sacrifice, and long hours?
Two years ago, I worked for a company that had a department in Egypt, and when layoffs occurred, they only occurred for us here. The Egyptians were skilled and intelligent, but they were not as well-trained in software engineering as the average US college graduate. They could write code, but they were not well-versed in different operating systems, and I probably would not expect them to have had any training in algorithmic complexity or other techniques that frequently help with design of a system.
But this was not an example of outsourcing. This was someone giving people in his former country a chance to succeed, and these people were not programmers of the level you'd expect to be graduating from a decent US university. These people were not given the tasks that those of us who were laid off were given; those tasks ended up being done by the founders, or no one at all.
This article is very cleverly written, and does a terrific job of trying to stir up trouble -- just look at the number of posts to this article!
Note that when comparing foreign wages to ours, the author of the article specifically chooses to mention -programmer- and -project manager- salaries.
Yet all of the "I.T." jobs that are being outsourced that the article mentions are for -call centers-. Tech support. The bottom of the barrel for I.T. The article also fails to disclose the sort of jobs the person it mentions was looking for and holding, and even then it has to give the disclaimer that her case is not normal!
I don't see demand in the United States for highly-skilled and trained Software Engineers diminishing. And the amount of code still needing to be written in the world is still growing much faster than the educated base of potential employees, as more and more things that were formerly done in hardware are moved to software, and more and more things are given interfaces that we can program new things for.
In short, no need to panic. This article is what used to be called "yellow journalism," trying to stir up discontent and political action where there is little evidence or story in fact.
Oh, I completely agree with you about OO usage in that respect. OO was a revolution; as with all revolutions, there was a lot of hype and hoopla that wasn't really relevant, and the business model aspect was, imho, all hype.
On the other hand we don't want to go all the way to the opposite extreme and say that OO is completely hype, and ignore the one simple idea -- that of being able to change the way an piece of code behaves without having to rewrite it completely or changing its source -- indeed, without even having access to the source. This is a very important step towards making code with resuable components.
We're not completely there yet, but AOP is yet another step in that direction, to where we just wire bits of existing functionality together without having to do a lot of extra work.
That's a fine prescription. When you find an employer who is willing to pay and wait for you to make your own GUI toolkit from scratch, that will be a terrific way to go.
If you're strapped for time and need to focus on the functionality of your application, you're probably going to use one of the pre-existing GUI toolkits -- MFC, Qt, whatever. And you may need to get it to do things where the properties and messages provided by the widgets aren't enough. And then you'll need to do this. It happens all of the time, and every time I've had to write a GUI.
I would like to see a semi-realistic example of this.
Try GUI programming sometime.
Let's say the default action of a button is to send a "clicked" signal or callback whenever the mouse button is released. Let's say I want to make a button that only does that when it's double-clicked.
An OO GUI framework buys me two things in this instance. First, I only have to re-implement the functionality I want to re-implement; by making a subclass of the basic button class, all other functions revert to the old implementation. So I won't have to re-write how the button is drawn for example.
And all I have to do to use my new button is to declare the buttons in my dialog as being of this class. I don't have to add code into the windowing system itself to make a call to the new code; it recognizes that it's the new code because of widget's type.
The goal of AOP is to take this a step further, to where I wouldn't even need to create objects of the new type -- I could just specify the new behavior for all buttons. But both of these are big advantages over purely procedural mechanisms.
The trouble is, Mr. Dinosaur, that sometimes behind these fads are some really good ideas.
The really good idea behind OOP, for example, was that you have language-level support for adding functionality to code without having to insert a call into that code.
The really good idea behind AOP is that if you need to make a module that is orthogonal to your existing functional decomposition, you can.
It doesn't matter in academia, where you largely make everything from scratch, but in the real world where code survives for ages, techniques like these are extremely helpful.
I had a chance to read about AOP a few years ago, when it was first being introduced.
Short answer: Yes, it is the Next Big Thing.
In the same sort of way that procedures were already implemented by experienced programmers long before languages like Pascal came to be,
In the same sort of way that experienced programmers used virtual function lookup tables and information hiding before OOP came about,
So is AOP. It is program-language-level support for the sorts of things experienced programmers do already... namely, code generation and automatic code modification.
Basically the reason OOP came about was that there was no means to add functionality to code without going into that code and inserting a call to the new functionality. Experienced programmers made virtual functions and lookup tables to solve this issue, but obviously this sort of code is complex and prone to error. So OOP brought forth program-language-level support for this sort of feature.
The problem that AOP addresses is this: As powerful as OOP is, it still relies on functional decomposition. The trouble is, sometimes one thing changes that cuts across functional boundaries. For example, the performance of an application, when ported to a new system, may need an entirely different set of performance tuning for the new app. Or more likely, you simply didn't see some aspect (there's that word) of your code changing often, and it would be impossible to separate it into a module without restructuring your entire code.
Now you can do a lot of inline #ifdef's and the like to do this by hand. Or, you can use some sort of dynamic code generation. But writing a dynamic code generator by hand is, like the virtual function table example above, tricky and always ad hoc.
The ultimate goal behind AOP is to make code generation generalized and done at the language level. So that you can modify things that occur across the boundaries of the existing functional decomposition.
Does that make any sense?
You're French, aren't you? :)
What about if the connection speed is inversely proportional to the number of connections from a given server?