I hope encryption can work until we find a way to dump the ISPs.
Remember this only applies to six of the largest ISPs. There are numerous smaller choices, which often provide better service anyway, though many of the good ones cost a little more. I wouldn't dream of using an ISP like BT after (a) the poor service I received when I did use them a few years ago, and (b) they have shown a willingness to participate in things like using Phorm. It's usually the big ISPs that have restrictions like packet shaping and high contention ratios as well.
For the record, I personally don't file share. I don't support Big Media on several counts, but I don't believe in breaking the law over such a trivial issue. Actually, I find it offensively hypocritical for people to claim file sharing is justified because "the music wasn't worth buying anyway" or some such nonsense: it's not worth buying, but it's enjoyable enough to bother downloading and listening to it? Give me a break, and stop trying to rationalise free-loading. (I do participate actively in campaigning and respond to government consultations on changing the law, which do make a difference. Most recently, attempts to increase copyright were stopped in their tracks, and legalisation of format shifting is imminent. There's a long way to go before copyright law is back to being properly balanced, but at least we're moving in the right direction through legitimate means and the proper legislative process.)
Anyway, the sort of behaviour the big ISPs are starting to exhibit inhibits legitimate uses from large downloads of legal software to using the BBC's "Listen Again" and "iPlayer" services. I pay for a high bandwidth, always-on Internet connection so I can use such services, and I expect my service provider to, well, provide that service. I also don't expect it to be spied upon, infected with advertising, or otherwise compromised. This is why I avoid the large ISPs like the plague.
I do wish armchair lawyers would stop propagating that crap on Slashdot. Britain does have a constitution, and it is written down. It's just not a single document labelled "Constitution".
Considering the bad press over Phorm not so long ago, which did make it to mainstream media and non-geeks, I suspect the big ISPs are paying lip service to this while their lawyers work out what their exposure to realistic lawsuits by Big Media is likely to be.
Yep, the colour laser printer thing is pretty scary, not least because customers aren't told about this deliberate surveillance.
I discovered the other day that an HP Colour LaserJet I use refuses to print without a supply of yellow toner even if the document to be printed is pure black-and-white, so it's not just spying on me, it's actually breaking my printer.
I'm flattered by your comments, but I'm afraid I'm not even remotely qualified to present at a conference, particularly not one on Agile ideas. I wish you luck, though. It's a bit far from the UK to come for a visit, so have a beer for me while you're there.:-)
My evidence is purely anecdotal, from various roles mentoring/training junior developers, helping out on forums for CS students, and the like. I have noticed a distinct trend in recent years for some of them to tell me point blank that unit tests make arbitrary changes safe (with no caveats or disclaimers given or, probably, assumed).
Usually, the people who do this are more enthusiastic than average. As a consequence, they tend to read books like Working Effectively With Legacy Code or some of the XP advocacy, but they also lack the experience to seek out other viewpoints and tend to accept what they read as authoritative.
I figure most keen novice programmers go through this sort of stage, with whatever the latest fad of the day may be. (It was patterns around the time I was getting into professional development, and while I think I avoided overdoing it too badly, I'm quite sure that if I looked back at my approach then with the benefit of hindsight, I would say I was as guilty as anyone.) One possible cure is time: when the next cycle of buzzwords comes around say 2–3 years later and our enthusiastic but inexperienced novice has a little more experience, they can't reconcile the new hype with their exising frame of reference, and start to see the bigger picture.
Reading more sources or finding good support from more experienced developers can fix things much sooner, as long as the mind is open to it. On-line forums like this one, or programming reddit, or the programming Usenet groups, can provide such some of that support. This is why I try to encourage people who do have a bit more experience to share it wisely. Even if it's a throwaway comment to you or me, you never know whether some impressionable young programmer is reading it and it starts them thinking.
If the London public transport system can route around planned maintenance, you're doing pretty well. Unexpected damage is pretty much always a show-stopper.:-(
For what it's worth, I think pretty much everything you wrote there is reasonable. I just wish you'd allowed for it more clearly in your previous post. While you may be aware of the realistic limitations of unit testing and you may take other steps to compensate, there are a lot of people around who think unit testing really is a silver bullet, and will stubbornly maintain that if they have unit tests they can basically do whatever they want and still be safe. I believe it is best to discourage such narrow thinking as much as possible. After all, one of us might be the guy who gets stuck with clearing up their mess later!;-)
Sorry to reply to my own comment, but I just realised I had mis-attributed who was saying what. In fact, the final comments by the guy from "Pun'd it" are indeed quite humorous.
I figured their name might be "Pun'd it", given the humorous nature of their comments.
But then I actually read their comments, and they are right on the money. Why on earth would most CIOs care about "cloud computing"? It's an idea whose time will probably never come, at least for most people. It's just another grand architectural vision, with lots of consultants talking about it and a few big companies signing up to offer facilities, but where would the real demand for it come from even if the money were available tomorrow?
And though it's heresy in these parts, I'm not surprised by the ambivalent attitude to OSS either. At best, in a perfect world, it provides similarly powerful software to what most businesses already run anyway, and saves the corporate licensing fees for a few key items. At worst, it provides inferior alternatives to software the company already uses, thus incurring a productivity hit, has substandard support when things go wrong, incurs a second productivity hit on the migration, and winds up costing more in support and retraining in the long term than the commercial alternatives. In the grand scheme of things, at a time like this, that's hardly a good sales pitch for OSS.
My first move would be to put a bunch of unit and acceptance tests around pricing and eligibility code. If we know we can't accidentally trigger a regulatory refiling, then we could change the system in other ways fearlessly.
Wishful thinking, perhaps? You can never make any change completely fearlessly in most projects. Unit tests can do a lot to help increase your confidence and catch bugs early, but they are not a substitute for knowing what you're doing and understanding its implications, and neither are they foolproof.
For one thing, it's impossible to get 100% test coverage for most projects. If you don't have full coverage, you can always break something in a gap.
For another thing, if you have a few thousand lines of code and you're worried enough about bugs to write a few thousand more lines of unit tests, how can you possibily be confident that the extra few thousand lines are themselves bug-free and testing what you think you're testing?
You should read the actual studies before trusting everything you see on Wikipedia. Almost all remotely scientific studies of pair programming effectiveness to date have been conducted with rather non-representative samples of the programming population, e.g., college students. They also tend to compare full time pair programming with no collaboration at all, which is unrealistic because most programmers will naturally seek a second opinion from a colleague at the times when it is most useful anyway. There is precious little research to date comparing the efficiency of two skilled and experienced programmers doing full-time pair programming with what they produce working alone except when they feel the need to collaborate in real time, and what there is isn't nearly as favourable.
Yep, the ol' infinite-loop-with-break trick is a classic way to avoid multiple returns without really avoiding them at all. See also "try {} catch (everything) {}" around the top level of a program to avoid having to deal with exceptions properly.
What saddens me is the number of places that still don't allow things like break and continue, so you have to mess around checking all kinds of flags awkwardly in your loop logic. A related horror is not allowing early returns right at the start of a block, substituting nineteen levels of nested-if logic with no else conditions instead.
Oh, and don't even mention trying to do a switch-case thing in Perl. }:-)
Some things are very useful in coding standards, IMHO. The problem is that mandating the finer points of brace placement and whitespace usage is not one of them.
For example, we write very portable C++ code at work, which is routinely built on several versions of several compilers running on several operating systems, where some of the combinations are state of the art and others are several years out of date. There are some standard language features that simply do not work properly on certain combinations, or that did not work properly back when this particular project was started, and which we therefore decide not to use at all to avoid either introducing portability problems now or having to retrofit all the legacy code to match what we'd like to do. These things go into our coding standard.
Anyone who wants to use a prohibited language feature can make a case for changing the standard, but will be expected to show that the feature now works correctly in all currently and reliably supported build environments. They will also be expected to show that using the feature where they want to won't undermine any more general conventions. A common example with new starters is that we refuse to use exceptions anywhere, ever, for one of our projects. It's not because exceptions wouldn't help: on the contrary, they would make things much cleaner and we'd jump at the chance to use them if we were starting over. But back when this project was started, using exceptions was unreliable on some platforms and had unacceptable performance penalties on others, and we aren't going to start retrofitting exception safety onto over a million lines of code now.
"If you need more than 3 levels of indentation, you're screwed anyway, and should fix your program."
<sarcasm>Oh well, if Linus says it, it must be true.</sarcasm>
I really hate this sort of dogmatic bullshit. Some algorithms are complicated, and don't factorise conveniently into self-contained chunks. It seems like every time we talk about function lengths or nesting depths or some similar issue, someone trots out the tired old lines about fitting on a screen, indenting to a certain level, or some such.
Now, let me be clear: most of the time, these aren't bad ideas as rules of thumb. I absolutely agree that you should pull code into a separate function if it's meaningful and self-contained enough that the purpose of the function is clear.
But if your code doesn't fit that description, for goodness' sake don't just yank out some part of it into a separate function because dogma told you to. That just spreads out an inherently complicated bit of logic so instead of at least being able to see it all in one place, you have to worry about jumping around into pointless functions that aren't self-contained or meaningful in their own right anyway, and is about the worst thing you can possibly do for readability and maintainability in difficult circumstances.
If anyone thinks they know better, I'd be interested to see your efficient generalised subgraph matching algorithm, and so, I would imagine, would a lot of the academic and professional mathematical community.
Sorry, but I simply don't believe you have really tried that experiment. I'm somewhat familiar with all of the arts you named, and it is nothing like the normal form of training in any of them. They are, in fact, typical examples of the kind of art I mentioned that often teaches some tactics for dealing with multiple opponents but doesn't really do the die-hard exercises to see how things work for real. More to the point, if you had, we would not be having this conversation.
And no, under normal circumstances, I don't believe you can fight your way out if you start out surrounded by 10 unarmed but serious attackers and all you have is a butterfly knife. You might inflict serious or fatal wounds on one or two before they take you down, but they will still easily take you down, because you have no meaningful advantage in range.
If you had a firearm or something like a katana or battle axe, and the environment was such that there was a space you could go through to escape where only one or two of your attackers are in the way and none of the others could grab you, and you had sufficient advantages in skill and fitness to overcome those one or two attackers within a moment and then run away faster than the others could pursue, then you might have a chance because you are really only fighting a small number of opponents and you have decisive advantages to make up for their greater numbers. And even then you'll still need a lot of luck.
Unfortunately, you're Batman, which means you aren't allowed to use lethal force, so that neat iaido sequence you were thinking of to kill both opponents almost instantly and make good your escape along the walled path they were blocking isn't allowed. Sorry.:-)
I think you have hit on a very important point there, perhaps unintentionally. You wrote:
When you are starting to learn something, does it really matter if you are working with the best of the best, or just with someone who knows the basics and can get you started without major mistakes?
It has been my experience that the difference between the "master" teachers and the "journeymen" is precisely that the masters will teach you the right thing, while the journeymen will teach you something that superficially looks, sounds or appears similar, but gets the effect in the wrong way (in the sense that you will need a different approach to improve further).
This is not to say that journeymen cannot be useful teachers. They have greater experience than the student, and perhaps can pass on the wisdom that multiple teachers of their own have shared with them. Usually this will help the student much more than harm them, and a student can learn a lot from such a teacher, particularly if they have access to multiple teachers so they can spot the inconsistencies that might betray a misunderstanding on the part of any one teacher.
However, the master has moved beyond this, combining the guidance of his teachers with his own experience of both practising and teaching the subject, and thus developing his own personal insights. Where the journeyman mostly repeats advice based on the understanding of others, the master understands the subject deeply himself and can therefore create advice on demand in each specific situation.
This makes a significant difference in at least two circumstances. One is where the journeyman teacher has never themselves progressed beyond a certain level of understanding, and they are teaching a way of doing something that can only get their students to the same level, where the master's approach would achieve the same effect at the same level of development but also allow for further growth. Thus the student picks up a bad habit, which must be unlearned and replaced with the better version before they can make further progress.
The other big difference is in a field where people must adapt. For example, if I were coaching a short, stocky, strong Batman, I would teach him very different fighting techniques to those I would teach to a tall, fast, agile Batman, to take advantage of his attributes. A journeyman teacher who is short, stocky and strong and has received advice from teachers that play to those strengths might not have good advice available to pass on to the tall, fast, agile student. The master, in contrast, has developed experience beyond their own learning and practice of the skill, studying alternative perspectives and forming a more rounded view of the subject, and so can customise their advice based on the specific needs of each student. Again, much of the advice during the first years of study would probably overlap, but the master will identify the differences immediately and again prevent the need for the student to go back and make adjustments later.
This is just IME, and YMMV. That, after all, is the point. Whether it is worth paying the greater costs of going to a master teacher from the start (not just in terms of money, but also travel time if there is no-one that good who lives near you, etc.) is debatable, because of course much of the subtlety of their understanding really is wasted on a beginner at first. However, other things being equal and money being no object since we're talking about Batman, there are definitely advantages to avoiding the journeyman teacher and learning from the master.
(Incidentally, I personally find the study of how different people learn, the stages of development a student goes through as they learn a new skill, and how best a teacher can help them, to be a fascinating area. There is a lot of interesting research about it, which you might like to explore if you're interested and haven't seen it already.)
I wondered whether someone would come up with that. You're going to need one heck of a weapon to take down ten opponents at close range before they get close enough to grab you, though.
Then again, you're Batman. Maybe you really do have some funky combination of flashbangs, smoke bombs, and defensive equipment that renders you immune to their effects.:-)
10 attackers is quite a few, and is very difficult, but not at all impossible if you're well trained and well prepared.
If you honestly believe everything you wrote in that post, then I can't help but think that you've trained some sort of martial art or self-defence class that teaches basic tactics for dealing with multiple opponents, but never really tried it in a free-for-all, full-contact, anything-goes experiment. I promise you, it's an experiment you'll only ever need to do once, because the result is absolutely guaranteed.
That's about six hours a day on most days for five years. With world class teaching and appropriate practice facilities, that sounds pretty consistent with what I've found in everything from playing a musical instrument to martial arts. Obviously there are going to be some prerequisites: someone is going to have to be fairly smart to become a world class chess player, or fairly tall to become a world class basketball player. But you can get seriously good at most things if you have the resources and you're willing to devote the time to it.
The thing I always regret with my hobbies is that I never appreciated the difference a really good teacher and training facilities can make when I was young enough to take advantage of them. By the time I found a teacher who could answer my deeper questions in most cases, I had already spent several years studying with mediocre teachers and without access to the best facilities, or in one case well over a decade just messing around and learning by experimentation without any guidance. These things do work up to a point — after all, someone had to work each difficult thing out first — but for most of my hobbies, I could probably have achieved in 1–2 years what in reality took me 5+ with a lesser teacher and limited facilites, or a decade of experimentation on my own.
...more than a couple of attackers, and you're in trouble. Facing ten bad guys, short of some super-exo-skeleton that boosts your strength and armours your body against instantaneous impact and sustained pressure and torsion, you're going down hard, quickly. And no, they don't always helpfully attack one or two at a time: watch half a dozen cops taking down a violent drunk some time.
And if you're facing multiple bad guys with no possibility of escape, the only credible strategy is to try to put at least all-but-one of them down so hard they no longer present a threat. That means at least knocked out or injured seriously enough that they can't fight, not the cutesy pain compliance stuff. If they are weak and clueless when it comes to fight, you are fit and highly skilled when it comes to fighting, you can find some sort of weapon, you are lucky with the environment, and there aren't too many of them, you might just do this for long enough to create an opportunity to escape. Maybe, if you're really lucky.
Slashdot Mirror
I hope encryption can work until we find a way to dump the ISPs.
Remember this only applies to six of the largest ISPs. There are numerous smaller choices, which often provide better service anyway, though many of the good ones cost a little more. I wouldn't dream of using an ISP like BT after (a) the poor service I received when I did use them a few years ago, and (b) they have shown a willingness to participate in things like using Phorm. It's usually the big ISPs that have restrictions like packet shaping and high contention ratios as well.
For the record, I personally don't file share. I don't support Big Media on several counts, but I don't believe in breaking the law over such a trivial issue. Actually, I find it offensively hypocritical for people to claim file sharing is justified because "the music wasn't worth buying anyway" or some such nonsense: it's not worth buying, but it's enjoyable enough to bother downloading and listening to it? Give me a break, and stop trying to rationalise free-loading. (I do participate actively in campaigning and respond to government consultations on changing the law, which do make a difference. Most recently, attempts to increase copyright were stopped in their tracks, and legalisation of format shifting is imminent. There's a long way to go before copyright law is back to being properly balanced, but at least we're moving in the right direction through legitimate means and the proper legislative process.)
Anyway, the sort of behaviour the big ISPs are starting to exhibit inhibits legitimate uses from large downloads of legal software to using the BBC's "Listen Again" and "iPlayer" services. I pay for a high bandwidth, always-on Internet connection so I can use such services, and I expect my service provider to, well, provide that service. I also don't expect it to be spied upon, infected with advertising, or otherwise compromised. This is why I avoid the large ISPs like the plague.
No, because Britain has no Constitution.
I do wish armchair lawyers would stop propagating that crap on Slashdot. Britain does have a constitution, and it is written down. It's just not a single document labelled "Constitution".
Considering the bad press over Phorm not so long ago, which did make it to mainstream media and non-geeks, I suspect the big ISPs are paying lip service to this while their lawyers work out what their exposure to realistic lawsuits by Big Media is likely to be.
Yep, the colour laser printer thing is pretty scary, not least because customers aren't told about this deliberate surveillance.
I discovered the other day that an HP Colour LaserJet I use refuses to print without a supply of yellow toner even if the document to be printed is pure black-and-white, so it's not just spying on me, it's actually breaking my printer.
I'm flattered by your comments, but I'm afraid I'm not even remotely qualified to present at a conference, particularly not one on Agile ideas. I wish you luck, though. It's a bit far from the UK to come for a visit, so have a beer for me while you're there. :-)
My evidence is purely anecdotal, from various roles mentoring/training junior developers, helping out on forums for CS students, and the like. I have noticed a distinct trend in recent years for some of them to tell me point blank that unit tests make arbitrary changes safe (with no caveats or disclaimers given or, probably, assumed).
Usually, the people who do this are more enthusiastic than average. As a consequence, they tend to read books like Working Effectively With Legacy Code or some of the XP advocacy, but they also lack the experience to seek out other viewpoints and tend to accept what they read as authoritative.
I figure most keen novice programmers go through this sort of stage, with whatever the latest fad of the day may be. (It was patterns around the time I was getting into professional development, and while I think I avoided overdoing it too badly, I'm quite sure that if I looked back at my approach then with the benefit of hindsight, I would say I was as guilty as anyone.) One possible cure is time: when the next cycle of buzzwords comes around say 2–3 years later and our enthusiastic but inexperienced novice has a little more experience, they can't reconcile the new hype with their exising frame of reference, and start to see the bigger picture.
Reading more sources or finding good support from more experienced developers can fix things much sooner, as long as the mind is open to it. On-line forums like this one, or programming reddit, or the programming Usenet groups, can provide such some of that support. This is why I try to encourage people who do have a bit more experience to share it wisely. Even if it's a throwaway comment to you or me, you never know whether some impressionable young programmer is reading it and it starts them thinking.
If the London public transport system can route around planned maintenance, you're doing pretty well. Unexpected damage is pretty much always a show-stopper. :-(
<Obligatory>We don't have sidewalks in London, you insensitive clod!</Obligatory>
We do a good line in pavements, but prolonged exposure to roadside air in London isn't exactly good for your health.
For what it's worth, I think pretty much everything you wrote there is reasonable. I just wish you'd allowed for it more clearly in your previous post. While you may be aware of the realistic limitations of unit testing and you may take other steps to compensate, there are a lot of people around who think unit testing really is a silver bullet, and will stubbornly maintain that if they have unit tests they can basically do whatever they want and still be safe. I believe it is best to discourage such narrow thinking as much as possible. After all, one of us might be the guy who gets stuck with clearing up their mess later! ;-)
Sorry to reply to my own comment, but I just realised I had mis-attributed who was saying what. In fact, the final comments by the guy from "Pun'd it" are indeed quite humorous.
I figured their name might be "Pun'd it", given the humorous nature of their comments.
But then I actually read their comments, and they are right on the money. Why on earth would most CIOs care about "cloud computing"? It's an idea whose time will probably never come, at least for most people. It's just another grand architectural vision, with lots of consultants talking about it and a few big companies signing up to offer facilities, but where would the real demand for it come from even if the money were available tomorrow?
And though it's heresy in these parts, I'm not surprised by the ambivalent attitude to OSS either. At best, in a perfect world, it provides similarly powerful software to what most businesses already run anyway, and saves the corporate licensing fees for a few key items. At worst, it provides inferior alternatives to software the company already uses, thus incurring a productivity hit, has substandard support when things go wrong, incurs a second productivity hit on the migration, and winds up costing more in support and retraining in the long term than the commercial alternatives. In the grand scheme of things, at a time like this, that's hardly a good sales pitch for OSS.
My first move would be to put a bunch of unit and acceptance tests around pricing and eligibility code. If we know we can't accidentally trigger a regulatory refiling, then we could change the system in other ways fearlessly.
Wishful thinking, perhaps? You can never make any change completely fearlessly in most projects. Unit tests can do a lot to help increase your confidence and catch bugs early, but they are not a substitute for knowing what you're doing and understanding its implications, and neither are they foolproof.
For one thing, it's impossible to get 100% test coverage for most projects. If you don't have full coverage, you can always break something in a gap.
For another thing, if you have a few thousand lines of code and you're worried enough about bugs to write a few thousand more lines of unit tests, how can you possibily be confident that the extra few thousand lines are themselves bug-free and testing what you think you're testing?
You should read the actual studies before trusting everything you see on Wikipedia. Almost all remotely scientific studies of pair programming effectiveness to date have been conducted with rather non-representative samples of the programming population, e.g., college students. They also tend to compare full time pair programming with no collaboration at all, which is unrealistic because most programmers will naturally seek a second opinion from a colleague at the times when it is most useful anyway. There is precious little research to date comparing the efficiency of two skilled and experienced programmers doing full-time pair programming with what they produce working alone except when they feel the need to collaborate in real time, and what there is isn't nearly as favourable.
Yep, the ol' infinite-loop-with-break trick is a classic way to avoid multiple returns without really avoiding them at all. See also "try {} catch (everything) {}" around the top level of a program to avoid having to deal with exceptions properly.
What saddens me is the number of places that still don't allow things like break and continue, so you have to mess around checking all kinds of flags awkwardly in your loop logic. A related horror is not allowing early returns right at the start of a block, substituting nineteen levels of nested-if logic with no else conditions instead.
Oh, and don't even mention trying to do a switch-case thing in Perl. }:-)
If you are using a language with lots of non-local gotos (or, 'exceptions' as they are now known)
Non-local gotos and exceptions are not the same thing.
Exceptions have been called exceptions for several decades.
Nice try at sounding clever, though.
Some things are very useful in coding standards, IMHO. The problem is that mandating the finer points of brace placement and whitespace usage is not one of them.
For example, we write very portable C++ code at work, which is routinely built on several versions of several compilers running on several operating systems, where some of the combinations are state of the art and others are several years out of date. There are some standard language features that simply do not work properly on certain combinations, or that did not work properly back when this particular project was started, and which we therefore decide not to use at all to avoid either introducing portability problems now or having to retrofit all the legacy code to match what we'd like to do. These things go into our coding standard.
Anyone who wants to use a prohibited language feature can make a case for changing the standard, but will be expected to show that the feature now works correctly in all currently and reliably supported build environments. They will also be expected to show that using the feature where they want to won't undermine any more general conventions. A common example with new starters is that we refuse to use exceptions anywhere, ever, for one of our projects. It's not because exceptions wouldn't help: on the contrary, they would make things much cleaner and we'd jump at the chance to use them if we were starting over. But back when this project was started, using exceptions was unreliable on some platforms and had unacceptable performance penalties on others, and we aren't going to start retrofitting exception safety onto over a million lines of code now.
The Linus says:
"If you need more than 3 levels of indentation, you're screwed anyway, and should fix your program."
<sarcasm>Oh well, if Linus says it, it must be true.</sarcasm>
I really hate this sort of dogmatic bullshit. Some algorithms are complicated, and don't factorise conveniently into self-contained chunks. It seems like every time we talk about function lengths or nesting depths or some similar issue, someone trots out the tired old lines about fitting on a screen, indenting to a certain level, or some such.
Now, let me be clear: most of the time, these aren't bad ideas as rules of thumb. I absolutely agree that you should pull code into a separate function if it's meaningful and self-contained enough that the purpose of the function is clear.
But if your code doesn't fit that description, for goodness' sake don't just yank out some part of it into a separate function because dogma told you to. That just spreads out an inherently complicated bit of logic so instead of at least being able to see it all in one place, you have to worry about jumping around into pointless functions that aren't self-contained or meaningful in their own right anyway, and is about the worst thing you can possibly do for readability and maintainability in difficult circumstances.
If anyone thinks they know better, I'd be interested to see your efficient generalised subgraph matching algorithm, and so, I would imagine, would a lot of the academic and professional mathematical community.
You'd better hope so. For loops and sparse data usually make a pretty inefficient combination...
And for bonus points, attempting to multiply by 0 probably yields an overflow. :-)
Sorry, but I simply don't believe you have really tried that experiment. I'm somewhat familiar with all of the arts you named, and it is nothing like the normal form of training in any of them. They are, in fact, typical examples of the kind of art I mentioned that often teaches some tactics for dealing with multiple opponents but doesn't really do the die-hard exercises to see how things work for real. More to the point, if you had, we would not be having this conversation.
And no, under normal circumstances, I don't believe you can fight your way out if you start out surrounded by 10 unarmed but serious attackers and all you have is a butterfly knife. You might inflict serious or fatal wounds on one or two before they take you down, but they will still easily take you down, because you have no meaningful advantage in range.
If you had a firearm or something like a katana or battle axe, and the environment was such that there was a space you could go through to escape where only one or two of your attackers are in the way and none of the others could grab you, and you had sufficient advantages in skill and fitness to overcome those one or two attackers within a moment and then run away faster than the others could pursue, then you might have a chance because you are really only fighting a small number of opponents and you have decisive advantages to make up for their greater numbers. And even then you'll still need a lot of luck.
Unfortunately, you're Batman, which means you aren't allowed to use lethal force, so that neat iaido sequence you were thinking of to kill both opponents almost instantly and make good your escape along the walled path they were blocking isn't allowed. Sorry. :-)
I think you have hit on a very important point there, perhaps unintentionally. You wrote:
When you are starting to learn something, does it really matter if you are working with the best of the best, or just with someone who knows the basics and can get you started without major mistakes?
It has been my experience that the difference between the "master" teachers and the "journeymen" is precisely that the masters will teach you the right thing, while the journeymen will teach you something that superficially looks, sounds or appears similar, but gets the effect in the wrong way (in the sense that you will need a different approach to improve further).
This is not to say that journeymen cannot be useful teachers. They have greater experience than the student, and perhaps can pass on the wisdom that multiple teachers of their own have shared with them. Usually this will help the student much more than harm them, and a student can learn a lot from such a teacher, particularly if they have access to multiple teachers so they can spot the inconsistencies that might betray a misunderstanding on the part of any one teacher.
However, the master has moved beyond this, combining the guidance of his teachers with his own experience of both practising and teaching the subject, and thus developing his own personal insights. Where the journeyman mostly repeats advice based on the understanding of others, the master understands the subject deeply himself and can therefore create advice on demand in each specific situation.
This makes a significant difference in at least two circumstances. One is where the journeyman teacher has never themselves progressed beyond a certain level of understanding, and they are teaching a way of doing something that can only get their students to the same level, where the master's approach would achieve the same effect at the same level of development but also allow for further growth. Thus the student picks up a bad habit, which must be unlearned and replaced with the better version before they can make further progress.
The other big difference is in a field where people must adapt. For example, if I were coaching a short, stocky, strong Batman, I would teach him very different fighting techniques to those I would teach to a tall, fast, agile Batman, to take advantage of his attributes. A journeyman teacher who is short, stocky and strong and has received advice from teachers that play to those strengths might not have good advice available to pass on to the tall, fast, agile student. The master, in contrast, has developed experience beyond their own learning and practice of the skill, studying alternative perspectives and forming a more rounded view of the subject, and so can customise their advice based on the specific needs of each student. Again, much of the advice during the first years of study would probably overlap, but the master will identify the differences immediately and again prevent the need for the student to go back and make adjustments later.
This is just IME, and YMMV. That, after all, is the point. Whether it is worth paying the greater costs of going to a master teacher from the start (not just in terms of money, but also travel time if there is no-one that good who lives near you, etc.) is debatable, because of course much of the subtlety of their understanding really is wasted on a beginner at first. However, other things being equal and money being no object since we're talking about Batman, there are definitely advantages to avoiding the journeyman teacher and learning from the master.
(Incidentally, I personally find the study of how different people learn, the stages of development a student goes through as they learn a new skill, and how best a teacher can help them, to be a fascinating area. There is a lot of interesting research about it, which you might like to explore if you're interested and haven't seen it already.)
That's why we make firearms.
I wondered whether someone would come up with that. You're going to need one heck of a weapon to take down ten opponents at close range before they get close enough to grab you, though.
Then again, you're Batman. Maybe you really do have some funky combination of flashbangs, smoke bombs, and defensive equipment that renders you immune to their effects. :-)
10 attackers is quite a few, and is very difficult, but not at all impossible if you're well trained and well prepared.
If you honestly believe everything you wrote in that post, then I can't help but think that you've trained some sort of martial art or self-defence class that teaches basic tactics for dealing with multiple opponents, but never really tried it in a free-for-all, full-contact, anything-goes experiment. I promise you, it's an experiment you'll only ever need to do once, because the result is absolutely guaranteed.
That's about six hours a day on most days for five years. With world class teaching and appropriate practice facilities, that sounds pretty consistent with what I've found in everything from playing a musical instrument to martial arts. Obviously there are going to be some prerequisites: someone is going to have to be fairly smart to become a world class chess player, or fairly tall to become a world class basketball player. But you can get seriously good at most things if you have the resources and you're willing to devote the time to it.
The thing I always regret with my hobbies is that I never appreciated the difference a really good teacher and training facilities can make when I was young enough to take advantage of them. By the time I found a teacher who could answer my deeper questions in most cases, I had already spent several years studying with mediocre teachers and without access to the best facilities, or in one case well over a decade just messing around and learning by experimentation without any guidance. These things do work up to a point — after all, someone had to work each difficult thing out first — but for most of my hobbies, I could probably have achieved in 1–2 years what in reality took me 5+ with a lesser teacher and limited facilites, or a decade of experimentation on my own.
...more than a couple of attackers, and you're in trouble. Facing ten bad guys, short of some super-exo-skeleton that boosts your strength and armours your body against instantaneous impact and sustained pressure and torsion, you're going down hard, quickly. And no, they don't always helpfully attack one or two at a time: watch half a dozen cops taking down a violent drunk some time.
And if you're facing multiple bad guys with no possibility of escape, the only credible strategy is to try to put at least all-but-one of them down so hard they no longer present a threat. That means at least knocked out or injured seriously enough that they can't fight, not the cutesy pain compliance stuff. If they are weak and clueless when it comes to fight, you are fit and highly skilled when it comes to fighting, you can find some sort of weapon, you are lucky with the environment, and there aren't too many of them, you might just do this for long enough to create an opportunity to escape. Maybe, if you're really lucky.
But it's a fun read, I'll give it that. :-)