So you have to be paranoid and check the class definition just in case.
So I have two responses to your general comment, though they are related.
You don't need to check the class definition at all -- you just need to know that one of the operands is an object. That's all. IMO, that's the only* difference between an overloaded operator call and a normal function call.
Once you're at that point, I don't see any difference between calling the function "+" and calling the function "doSomethingSimple". If you're paranoid enough about the class defining "+" in a way that will cause it to open sockets and thus you have to check the class definition to see if it does, you should be equally paranoid that "doSomethingSimple" will do the same thing and you have to check the class definition anyway.
The second part of my response is this: why do you CARE what "+" does internally? I can think of two reasons.
First, because you're concerned about efficiency. I've already said why I think this is a red herring, especially because I suspect most overloaded operator functions will be inlined to something efficient in general other way.
The second reason is because you want to know whether "+" is a good name for that function. But again I don't see how this differs from normal functions. If I call a function add and write a.add(b) instead of a + b, why are you more suspicious about the latter? I can come up with bad names without operator overloading plenty easily enough. Hell, I come up with bad function names for my non-overloaded functions far more often than bad function "names" for my operators. (And that even neglects the personal opinion that the normal convention of a.add(b) for a + b -- e.g. like what's used in Java's complex class -- feels wrong to me. a.add(b) feels way more like a += b than a + b to me. But again -- this isn't the fault of Java not supporting operator overloading per se, but rather the fault of Sun's function naming.)
* Okay, there is one other difference. Operator overloading is cool and tempting to use. It invites abuse way more than function naming does. But some high-profile cases aside (in particular, the proposal to overload the comma operator or whatever it was to load containers, a la Vector v = 4, 5, 6, 7, 8; or something), it certainly seems to me that, in practice, programmers are actually able to hold their tongues pretty well. Strangely enough, the biggest exception to this, I feel, is the bitshift overloading in iostreams. And IMO, that's easy enough to learn and brings about enough benefits (I/O type safety, non-repetition of type information, and extensibility vs a printf-style interface, and way less syntactic overhead vs repeated function calls) that it's probably the best solution even though it's not entirely satisfactory.
I'm a pretty big defender of C++ if only because it often gets trashed, but I think "if you don't like operator overloading, don't use it" isn't a particularly helpful or even accurate position to take. The problem is that you basically never write a program in a vaccum; you basically always use libraries. Does one of the libraries you want use operator overloading? If so, then you either have to use operator overloading or find a different library.
Hell, when your language's canonical "hello world" program uses operator overloading, I think it's safe to say that it's just something you'll have to deal with in that language. The standard library uses it all over -- iostreams, containers, etc.
If the OP was concerned about semantics, then why the specification that particularly matters for low-level coding?
And of course if we go there, then I feel even more strongly about my position because "I think the benefits (when used properly) far outweigh the problems (when abused)" describes my position as well, except I probably would have italicized "far".
This is off-topic from this particular thread of the discussion, but I also remembered the other objection to C++ that's developed: language interop (using C++ stuff in other languages) is usually nigh impossible. From what I can tell the best way to do language interop to C++ is to write a C wrapper for the C++ stuff, then interface to the C wrapper.
I used to be a huge C++ fan, though that has waned over the years as I've used better-designed languages and have also seen other people struggle with C++'s testier features.
That said -- I'd still take C++ over plain C for essentially anything in a heartbeat. (Basically the only exception would be stuff like microcontroller programming or other environments where there isn't really a good C++ compiler.) RAII alone is enough to seal that deal.
I don't buy most of the arguments of C over C++. For instance, take your statement that "IMHO C++ seems not very good at very low-level programming; since with C++ it's not always obvious what a compiler might want to do with '+' thanks to operator overloading and rather convoluted implicit casting rules."
But with modern compilers, I feel it's already very not obvious what the compiler is going to do with your code. What function calls are inlined? What loops are unrolled? For what I think is a reasonably dramatic example of this, take the following snippet:
int main(int argc, char** argv) {
int y = 50;
if (argc > 1) {
y = 100;
}
return y; }
and compile with optimization on. Look at the resulting assembly. There's no branch! (I'm assuming a variant of x86 or x64 here.)
If you're on a 64-bit system with GCC you'll probably see a cmov (conditional move) instruction, which kind of makes sense. But you don't even need that instruction to be available for it to omit an actual control-flow jump. Recompile with -m32 and look at the assembly again. Much longer, but still no branch. Instead, it uses one of the setxx instructions (setg in my case) and a bit of bit twiddling.
In my opinion, today's optimizers make the generated code so far removed from what you type into your editor that saying "+ can do anything!" is a drop in the bucket.
Nokia used to make some of the best phones out there. Maybe they still do. But they've mostly left the US market after getting patent-trolled so hard by Qualcomm; and they're still clinging to Symbian anyway.
The N900, which doesn't run Symbian and is available in the US (though you may "have to" buy unlocked; I don't know if carriers offer it; I view "unlocked" as a positive, which is while I'll presumably never buy an iPhone) is a pretty spiffy phone. It's Maemo. Linux-based, but not Android, and actually way more open than Android phones are. Hell, you can run 'apt-get'.
Well, to be honest, the N900 does feel a little dated nowadays, but it was pretty top-notch when it first came out over a year ago.
ARM-based devices are set to take more then 10% of all US Internet browsing in 2011 with no signs of slowing down anytime soon.
Not just that, but nVidia just announced their Project Denver, which is an ARM core integrated with their graphics and aimed at the desktop. And as mentioned in the same article (and expanded on), Windows 8 will have ARM support.
I have a strong personal bias against x86 and would be reasonably delighted to see ARM start to take over on the desktop in the next few years, but only time will tell if that will occur.
I would have to do the math to make sure, but at some latitude a human being could quite easily outwalk the sunrise... Heck on the equator I think a person could outwalk the sunrise, if you assume it rotates a hundred times slower and the circumference is quite smaller.
Mercury's equatorial circumference is 9529.1 mi and it's day is 1,407.5 hrs. (Source)
Divide and you get that Mercury's terminator moves at 2.08 mph at the equator. So sure, you could pretty easily outwalk that for some time.
I was just reminded that the other problem I had with the new gun mechanics in ME2 was that I felt they took a big dump on the world. There was a reasonable mechanic in ME1 for why the guns behaved the way they did. Then they made up some crap in ME2 about how the Citidel folks analyzed the Geth weapons and found out they worked this other way, so they copied them. But why did they do that? Forget gameplay for a second and go in-world -- it seems to me the overheating mechanics would be far more attractive. Why did they trade a superior system for an inferior one? (They try to skirt this issue in the codex by saying "but they are actually better" but this feels very much the story shoe-horned around the mechanic in a not-very-believable way. Put a thermal dissipation upgrade on the Spectre assault rifle in ME1 and that thing can fire continuously for a couple minutes.)
What's worse, the in-game mechanics I don't even think matches the story very well. (I could be misremembering exactly how they described it; it's been a while and I'm not ever sure I read all the appropriate codex entries.) The ammo clips are technically heat sinks or whatever to remove heat. But then whey don't weapons cool down on their own if you give them some time? Suppose you can fire n shots in a "clip". I can see why you'd need to eject the heat sink after those shots -- but what if you fire n-1 shots, then take a long rest? Wouldn't that heat dissipate, and you'd essentially get those n-1 shots back? (Granted, just about every FPS gets something like this "wrong".) Or why can't I pick up clips that I've used and dropped on the ground, once they've had a chance to cool off?
I have nothing against the mechanic -- God knows I've played enough HL2, for instance -- but I felt that in the ME universe this made no sense, and then Bioware wove up a crappy explanation for it. I might have been happier if the codex entry actually said "this is different from ME 1 because we felt it would be better gameplay" and not come up with such nonsense.
Addition of heat pack "ammunition" is a case of YMMV over the use of weapon overheating, though it is rarely cited as a negative beyond in-game physics.
I cite it as a negative because I like playing one of the classes that goes with the sniper rifle -- and then I felt like I could almost never use the sniper rifle because you can only carry 10 shots! (At least until quite aways into the game when you get a different style gun that gives you far more weaker shots.)
So that mechanic actually had a significant impact on the way that I played the game, in a manner I strongly disliked.
(I also disliked the removal of some of the RPG aspects, but I and others have commented on that elsewhere in this story.)
I don't think "you have to play the 'unlock' minigame" was the only complaint of the OP: there was also the problem (which I had as well) that those games stay more-or-less the same difficulty as you go through the game. In ME1, the decrypt minigame definitely got harder -- they added more bits into the circles -- as you went along. It actually wasn't terribly uncommon for me to actually miss one of the harder puzzles in ME1, but I think that happened all of one or two times in ME2.
Difference is, IW's story sucked. ME2's story is just as good or better.
To each his own I guess... I thought ME1's story was rather better. Maybe because it was setting up the arc while I can't really tell what ME2 is doing to the overall story. Maybe because I found the ending to ME2, for lack of a better word, dumb. Maybe it's because I put too much weight on the conversations with Soverign and Vigil in ME1 and didn't think ME2 had anything like it. I dunno.
I'm not saying it was a bad story, just a step down.
Personally I prefer ME2 to ME1 simply because the RPG system, while a noble attempt, sucked great big donkey balls in ME1. Shuffling through giant piles of useless gear, debating over meaningless (without consulting an outside source) stats, and having to jump between several screens just to equip your useless tag-along morons... hideous.
It is too bad that the inventory system in ME1 was as horrid as it was, because that really was pretty awful. However, I disagree a little on the stats. I guess I can't say with confidence that I would have been able to make good use of all of the differing stats in ME1, but I did feel like ME2 went way overboard in oversimplifying. The best example of this is the removal of one of the decisions you have to make in almost all the Bioware RPGs: do I put character points into the "persuade/intimidate" skill, and thus achieve (among other things) the ability to avert some conflicts, or do I put my character points into skills that will help me better deal with the conflicts?
I probably put too much weight in that decision too considering that you're not exactly going to be devoid of conflicts in any case, but it is a case where I feel they removed an interesting decision you used to have to make.
I don't make that many phone calls or texts, so I have a dirt-cheap prepaid plan. Now, in an ideal world, I'd carry one less device and(as noted above) use my prepaid SIM in a full phone. That isn't supported, so I suck it up and carry a $20 Motorola dumbphone when I need it.
I'm in the same boat as you... except I do exactly that. I bought an unlocked Nokia N900 and have used it now with both AT&T and T-Mobile prepaid. What's the hang up?
Saying that the smartest programmers you know "are the ones who know their low-level stuff" is not a very supportive reason for that sequence of teaching. All it says is that, when all is said and done, they had learned those things at some point. Did they start there? Did they end there? Who knows? Did they know those things because they actually had the interest to learn them for the same reasons that they are the best programmers you know? Is there, in fact, not really a causal relation at all?
I have given this a lot of thought over the years (I'm not in a position to actually test the hypotheses, so I don't have empirical evidence to support my position) and I understand where you are coming from. (There was a/. post a long time ago about this book and I think it's a really interesting approach.)
That said, I think in general it would fail miserably. There are a bunch of drawbacks. First, if you write in assembly you are basically completely tied to a particular platform. If you use a higher-level language -- even just bumping it up to C -- then the students have the freedom to use "whatever" they want. Your lab computers have Linux and they have Windows? No good if you teach assembly. Your lab has Windows and they have OS X? No good. Your lab has recent Apples and they have an old G5? No good. Want to allow them to work on their choice of platform? Have fun grading. Logistically, this is very difficult. (C isn't perfect in this regard -- but it is pretty darn close compared to assembly if you stay away from C99-specific features.)
The second problem is more pedagogical. If the students aren't actually interested in learning, they aren't going to learn. And I think it'd be much easier to get most of them interested if they can actually program something that is useful and/or cool. You can spout off all you want about how "why we're doing all this will make sense in a year or two" and it won't help. Programs that are one of those two things are usually at least mildly complex, and thus the low-levelness of asm would be a true hindrance in achieving that goal.
Personally, I think you'd have far more success (in terms of both students continuing through the curriculum and in terms of understanding of the material) if you approached the material you suggest in the opposite order: start out with a language that is actually reasonable to use for creating neat stuff, show them how to create neat stuff, then gradually unroll the layers.
Better yet, find the text for a high school AP Computer Science class from the late 90s/early 00s. C++ tailored for teenagers. Uses a bit of custom libraries to make it easier, but delves in to most basic concepts you'll need at later levels(class creation, recursion, pointers, etc).
The custom libraries it uses (apvector, apmatrix, apstring,...) and the fact that it was developed before C++ was standardized and thus gets some things "wrong" makes me strongly disagree with this suggestion. Hell, I suspect you are likely to not even be able to write the "hello world" program in a typical C++ APCS book because it'll tell you to include . I know that would be true of the book we used in the class I took.
I'm sure you could find a book that would be way easier to learn from than going through an APCS book and trying to figure out how to use it with any compiler made in the last decade.
You're missing the point: it's almost always a bad idea to store the unhashed password, period. The problem isn't so much "they'll send you your password" (though that's bad too) but more "what if their password database is compromised?"
I use and recommend PasswordSafe, but it's not without its drawbacks. If you rely on it then you need your database to use the websites (e.g. there's no way I could tell you my bank password 'cause I don't even know it); so if you don't have your DB available you can't do anything. To keep it available you need to worry about synchronizing the file across multiple computers (something I doubt at least PasswordSafe does if you change both files at once) and stuff like that.
Jailbreaking became legally protected recently. Disabling functionality when a jailbreak is detected seems like it might open Apple to a class action lawsuit.
Only for a much narrower sense of "legally protected" than you seem to think. The protection bars prosecution under the DMCA, but there's absolutely nothing that says phone manufacturers have to make it easy for you or can't take anti-jailbreaking countermeasures.
I'm sure they're legally allowed to say that jailbreaking voids the warranty, but I'm not sure they're willing to risk crippling a jailbreaker's device with an api flag.
I'm actually not so sure of the first part, though IANAL either. I'd be much more inclined to think the complete opposite of what you indicate: I wouldn't be surprised if Apple wouldn't mind that in the end.
Slashdot Mirror
So you have to be paranoid and check the class definition just in case.
So I have two responses to your general comment, though they are related.
You don't need to check the class definition at all -- you just need to know that one of the operands is an object. That's all. IMO, that's the only* difference between an overloaded operator call and a normal function call.
Once you're at that point, I don't see any difference between calling the function "+" and calling the function "doSomethingSimple". If you're paranoid enough about the class defining "+" in a way that will cause it to open sockets and thus you have to check the class definition to see if it does, you should be equally paranoid that "doSomethingSimple" will do the same thing and you have to check the class definition anyway.
The second part of my response is this: why do you CARE what "+" does internally? I can think of two reasons.
First, because you're concerned about efficiency. I've already said why I think this is a red herring, especially because I suspect most overloaded operator functions will be inlined to something efficient in general other way.
The second reason is because you want to know whether "+" is a good name for that function. But again I don't see how this differs from normal functions. If I call a function add and write a.add(b) instead of a + b, why are you more suspicious about the latter? I can come up with bad names without operator overloading plenty easily enough. Hell, I come up with bad function names for my non-overloaded functions far more often than bad function "names" for my operators. (And that even neglects the personal opinion that the normal convention of a.add(b) for a + b -- e.g. like what's used in Java's complex class -- feels wrong to me. a.add(b) feels way more like a += b than a + b to me. But again -- this isn't the fault of Java not supporting operator overloading per se, but rather the fault of Sun's function naming.)
* Okay, there is one other difference. Operator overloading is cool and tempting to use. It invites abuse way more than function naming does. But some high-profile cases aside (in particular, the proposal to overload the comma operator or whatever it was to load containers, a la Vector v = 4, 5, 6, 7, 8; or something), it certainly seems to me that, in practice, programmers are actually able to hold their tongues pretty well. Strangely enough, the biggest exception to this, I feel, is the bitshift overloading in iostreams. And IMO, that's easy enough to learn and brings about enough benefits (I/O type safety, non-repetition of type information, and extensibility vs a printf-style interface, and way less syntactic overhead vs repeated function calls) that it's probably the best solution even though it's not entirely satisfactory.
I'm a pretty big defender of C++ if only because it often gets trashed, but I think "if you don't like operator overloading, don't use it" isn't a particularly helpful or even accurate position to take. The problem is that you basically never write a program in a vaccum; you basically always use libraries. Does one of the libraries you want use operator overloading? If so, then you either have to use operator overloading or find a different library.
Hell, when your language's canonical "hello world" program uses operator overloading, I think it's safe to say that it's just something you'll have to deal with in that language. The standard library uses it all over -- iostreams, containers, etc.
If the OP was concerned about semantics, then why the specification that particularly matters for low-level coding?
And of course if we go there, then I feel even more strongly about my position because "I think the benefits (when used properly) far outweigh the problems (when abused)" describes my position as well, except I probably would have italicized "far".
This is off-topic from this particular thread of the discussion, but I also remembered the other objection to C++ that's developed: language interop (using C++ stuff in other languages) is usually nigh impossible. From what I can tell the best way to do language interop to C++ is to write a C wrapper for the C++ stuff, then interface to the C wrapper.
I used to be a huge C++ fan, though that has waned over the years as I've used better-designed languages and have also seen other people struggle with C++'s testier features.
That said -- I'd still take C++ over plain C for essentially anything in a heartbeat. (Basically the only exception would be stuff like microcontroller programming or other environments where there isn't really a good C++ compiler.) RAII alone is enough to seal that deal.
I don't buy most of the arguments of C over C++. For instance, take your statement that "IMHO C++ seems not very good at very low-level programming; since with C++ it's not always obvious what a compiler might want to do with '+' thanks to operator overloading and rather convoluted implicit casting rules."
But with modern compilers, I feel it's already very not obvious what the compiler is going to do with your code. What function calls are inlined? What loops are unrolled? For what I think is a reasonably dramatic example of this, take the following snippet:
and compile with optimization on. Look at the resulting assembly. There's no branch! (I'm assuming a variant of x86 or x64 here.)
If you're on a 64-bit system with GCC you'll probably see a cmov (conditional move) instruction, which kind of makes sense. But you don't even need that instruction to be available for it to omit an actual control-flow jump. Recompile with -m32 and look at the assembly again. Much longer, but still no branch. Instead, it uses one of the setxx instructions (setg in my case) and a bit of bit twiddling.
In my opinion, today's optimizers make the generated code so far removed from what you type into your editor that saying "+ can do anything!" is a drop in the bucket.
Nokia used to make some of the best phones out there. Maybe they still do. But they've mostly left the US market after getting patent-trolled so hard by Qualcomm; and they're still clinging to Symbian anyway.
The N900, which doesn't run Symbian and is available in the US (though you may "have to" buy unlocked; I don't know if carriers offer it; I view "unlocked" as a positive, which is while I'll presumably never buy an iPhone) is a pretty spiffy phone. It's Maemo. Linux-based, but not Android, and actually way more open than Android phones are. Hell, you can run 'apt-get'.
Well, to be honest, the N900 does feel a little dated nowadays, but it was pretty top-notch when it first came out over a year ago.
ARM-based devices are set to take more then 10% of all US Internet browsing in 2011 with no signs of slowing down anytime soon.
Not just that, but nVidia just announced their Project Denver, which is an ARM core integrated with their graphics and aimed at the desktop. And as mentioned in the same article (and expanded on), Windows 8 will have ARM support.
I have a strong personal bias against x86 and would be reasonably delighted to see ARM start to take over on the desktop in the next few years, but only time will tell if that will occur.
Um apparently I can't use a calculator and my arithmetic result sanity check routines failed... 9529/1407 is 6.8 mph, not 2.08.
So you could outrun the sunrise for a bit, but couldn't outwalk it.
I would have to do the math to make sure, but at some latitude a human being could quite easily outwalk the sunrise... Heck on the equator I think a person could outwalk the sunrise, if you assume it rotates a hundred times slower and the circumference is quite smaller.
Mercury's equatorial circumference is 9529.1 mi and it's day is 1,407.5 hrs. (Source)
Divide and you get that Mercury's terminator moves at 2.08 mph at the equator. So sure, you could pretty easily outwalk that for some time.
Agreed. I made some comments about the weapons here and in my reply to myself. The reply was in part prompted by your post actually.
I was just reminded that the other problem I had with the new gun mechanics in ME2 was that I felt they took a big dump on the world. There was a reasonable mechanic in ME1 for why the guns behaved the way they did. Then they made up some crap in ME2 about how the Citidel folks analyzed the Geth weapons and found out they worked this other way, so they copied them. But why did they do that? Forget gameplay for a second and go in-world -- it seems to me the overheating mechanics would be far more attractive. Why did they trade a superior system for an inferior one? (They try to skirt this issue in the codex by saying "but they are actually better" but this feels very much the story shoe-horned around the mechanic in a not-very-believable way. Put a thermal dissipation upgrade on the Spectre assault rifle in ME1 and that thing can fire continuously for a couple minutes.)
What's worse, the in-game mechanics I don't even think matches the story very well. (I could be misremembering exactly how they described it; it's been a while and I'm not ever sure I read all the appropriate codex entries.) The ammo clips are technically heat sinks or whatever to remove heat. But then whey don't weapons cool down on their own if you give them some time? Suppose you can fire n shots in a "clip". I can see why you'd need to eject the heat sink after those shots -- but what if you fire n-1 shots, then take a long rest? Wouldn't that heat dissipate, and you'd essentially get those n-1 shots back? (Granted, just about every FPS gets something like this "wrong".) Or why can't I pick up clips that I've used and dropped on the ground, once they've had a chance to cool off?
I have nothing against the mechanic -- God knows I've played enough HL2, for instance -- but I felt that in the ME universe this made no sense, and then Bioware wove up a crappy explanation for it. I might have been happier if the codex entry actually said "this is different from ME 1 because we felt it would be better gameplay" and not come up with such nonsense.
Addition of heat pack "ammunition" is a case of YMMV over the use of weapon overheating, though it is rarely cited as a negative beyond in-game physics.
I cite it as a negative because I like playing one of the classes that goes with the sniper rifle -- and then I felt like I could almost never use the sniper rifle because you can only carry 10 shots! (At least until quite aways into the game when you get a different style gun that gives you far more weaker shots.)
So that mechanic actually had a significant impact on the way that I played the game, in a manner I strongly disliked.
(I also disliked the removal of some of the RPG aspects, but I and others have commented on that elsewhere in this story.)
I don't think "you have to play the 'unlock' minigame" was the only complaint of the OP: there was also the problem (which I had as well) that those games stay more-or-less the same difficulty as you go through the game. In ME1, the decrypt minigame definitely got harder -- they added more bits into the circles -- as you went along. It actually wasn't terribly uncommon for me to actually miss one of the harder puzzles in ME1, but I think that happened all of one or two times in ME2.
Difference is, IW's story sucked. ME2's story is just as good or better.
To each his own I guess... I thought ME1's story was rather better. Maybe because it was setting up the arc while I can't really tell what ME2 is doing to the overall story. Maybe because I found the ending to ME2, for lack of a better word, dumb. Maybe it's because I put too much weight on the conversations with Soverign and Vigil in ME1 and didn't think ME2 had anything like it. I dunno.
I'm not saying it was a bad story, just a step down.
Personally I prefer ME2 to ME1 simply because the RPG system, while a noble attempt, sucked great big donkey balls in ME1. Shuffling through giant piles of useless gear, debating over meaningless (without consulting an outside source) stats, and having to jump between several screens just to equip your useless tag-along morons... hideous.
It is too bad that the inventory system in ME1 was as horrid as it was, because that really was pretty awful. However, I disagree a little on the stats. I guess I can't say with confidence that I would have been able to make good use of all of the differing stats in ME1, but I did feel like ME2 went way overboard in oversimplifying. The best example of this is the removal of one of the decisions you have to make in almost all the Bioware RPGs: do I put character points into the "persuade/intimidate" skill, and thus achieve (among other things) the ability to avert some conflicts, or do I put my character points into skills that will help me better deal with the conflicts?
I probably put too much weight in that decision too considering that you're not exactly going to be devoid of conflicts in any case, but it is a case where I feel they removed an interesting decision you used to have to make.
I sort of wanted to add that I didn't know that there were phones that used SIM cards but still weren't interchangable like that. I guess I was wrong.
Ah, okay. Even the Wikipedia article says "other GSM handsets will not accept TracFone SIM cards, even if unlocked".
I don't make that many phone calls or texts, so I have a dirt-cheap prepaid plan. Now, in an ideal world, I'd carry one less device and(as noted above) use my prepaid SIM in a full phone. That isn't supported, so I suck it up and carry a $20 Motorola dumbphone when I need it.
I'm in the same boat as you... except I do exactly that. I bought an unlocked Nokia N900 and have used it now with both AT&T and T-Mobile prepaid. What's the hang up?
Saying that the smartest programmers you know "are the ones who know their low-level stuff" is not a very supportive reason for that sequence of teaching. All it says is that, when all is said and done, they had learned those things at some point. Did they start there? Did they end there? Who knows? Did they know those things because they actually had the interest to learn them for the same reasons that they are the best programmers you know? Is there, in fact, not really a causal relation at all?
I have given this a lot of thought over the years (I'm not in a position to actually test the hypotheses, so I don't have empirical evidence to support my position) and I understand where you are coming from. (There was a /. post a long time ago about this book and I think it's a really interesting approach.)
That said, I think in general it would fail miserably. There are a bunch of drawbacks. First, if you write in assembly you are basically completely tied to a particular platform. If you use a higher-level language -- even just bumping it up to C -- then the students have the freedom to use "whatever" they want. Your lab computers have Linux and they have Windows? No good if you teach assembly. Your lab has Windows and they have OS X? No good. Your lab has recent Apples and they have an old G5? No good. Want to allow them to work on their choice of platform? Have fun grading. Logistically, this is very difficult. (C isn't perfect in this regard -- but it is pretty darn close compared to assembly if you stay away from C99-specific features.)
The second problem is more pedagogical. If the students aren't actually interested in learning, they aren't going to learn. And I think it'd be much easier to get most of them interested if they can actually program something that is useful and/or cool. You can spout off all you want about how "why we're doing all this will make sense in a year or two" and it won't help. Programs that are one of those two things are usually at least mildly complex, and thus the low-levelness of asm would be a true hindrance in achieving that goal.
Personally, I think you'd have far more success (in terms of both students continuing through the curriculum and in terms of understanding of the material) if you approached the material you suggest in the opposite order: start out with a language that is actually reasonable to use for creating neat stuff, show them how to create neat stuff, then gradually unroll the layers.
I suspect you are likely to not even be able to write the "hello world" program in a typical C++ APCS book because it'll tell you to include .
Let's try that again: "it'll tell you to include <iostream.h>".
Better yet, find the text for a high school AP Computer Science class from the late 90s/early 00s. C++ tailored for teenagers. Uses a bit of custom libraries to make it easier, but delves in to most basic concepts you'll need at later levels(class creation, recursion, pointers, etc).
The custom libraries it uses (apvector, apmatrix, apstring, ...) and the fact that it was developed before C++ was standardized and thus gets some things "wrong" makes me strongly disagree with this suggestion. Hell, I suspect you are likely to not even be able to write the "hello world" program in a typical C++ APCS book because it'll tell you to include . I know that would be true of the book we used in the class I took.
I'm sure you could find a book that would be way easier to learn from than going through an APCS book and trying to figure out how to use it with any compiler made in the last decade.
You're missing the point: it's almost always a bad idea to store the unhashed password, period. The problem isn't so much "they'll send you your password" (though that's bad too) but more "what if their password database is compromised?"
I use and recommend PasswordSafe, but it's not without its drawbacks. If you rely on it then you need your database to use the websites (e.g. there's no way I could tell you my bank password 'cause I don't even know it); so if you don't have your DB available you can't do anything. To keep it available you need to worry about synchronizing the file across multiple computers (something I doubt at least PasswordSafe does if you change both files at once) and stuff like that.
Jailbreaking became legally protected recently. Disabling functionality when a jailbreak is detected seems like it might open Apple to a class action lawsuit.
Only for a much narrower sense of "legally protected" than you seem to think. The protection bars prosecution under the DMCA, but there's absolutely nothing that says phone manufacturers have to make it easy for you or can't take anti-jailbreaking countermeasures.
I'm sure they're legally allowed to say that jailbreaking voids the warranty, but I'm not sure they're willing to risk crippling a jailbreaker's device with an api flag.
I'm actually not so sure of the first part, though IANAL either. I'd be much more inclined to think the complete opposite of what you indicate: I wouldn't be surprised if Apple wouldn't mind that in the end.
Which is even more of a reason that jurors shouldn't be looking at it.
And when do the prosecution and defense get to cross examine those experts?