Indeed. Plus there is higher mechanical stress if you have a fan that kicks in when it's running hotter, as with my laptop... so real moving parts are involved too.
Sorry, I was just trying to follow the general thread of reasoning here. You first posted essentially saying that we shouldn't complain he was held without due process because he is (or could be) guilty. (The "material witness" point is really just a bit of a lame technicality -> one need only consider the underlying REASON why American citizens have 'due process' in the first place to realise that it ONLY makes sense if there AREN'T technical workarounds to it. American citizens have right to due process - period. There is no "if this yes, if that no", if that was the case, then you might as well throw due process out totally). Humans (and that includes the judge) WILL abuse the system if it is closed - you CANNOT just trust a small handful of people to not abuse the system, if you look at history, you'd realise that would be stupid.
So, WindBourne thought your thoughts were dangerous (dangerous in that if enough people thought the same, US society would be in trouble). So he says thats why he still supports the ACLU, i.e. to protect against these dangerous thoughts.
So your response was to counter that we shouldn't defend this man because he is capable of jihad, apparently thinking that WindBourne was making the mistake of thinking that he must be innocent, in other words thinking that WindBourne was defending *Hawash* and not Hawash's *general rights* (to due process). So what I'm saying is, whether or not Hawash is guilty has nothing to do with WindBourne's point, that Hawash (and EVERY US citizen) still has rights to due process.
What has that got to do with defending the right of every US citizen to due process? So maybe he is guilty; you are saying that we should throw out everybody's rights now, because violating one person's rights actually caught a real criminal in this case? I recommend you go read up on the principles on which your country was founded.
Don't confuse defending the man's rights with defending the man. Maybe he is guilty, but that doesn't make the lack of due process any less noxious. Remember, the rights to due process are your rights too, and that of every other US citizen. You want to excuse this incident because he is guilty? Fine, just don't complain next time its you held without due process for something you didn't do.
Even if he is guilty, which would be very unfortunate especially in this case, that is entirely beside the point. The important point here is the loss of rights under which US citizens can now be detained in this manner. This is what people are protesting, and the point stands that this is a serious problem whether or not he is actually guilty in this case.
Sadly, if it turns out that he is guilty, then many people will forget the important point here - because they will inevitably confuse the concept of defending his basic rights (that all US citizens are supposed to share), with the concept of defending him.
Its not so much about the *trees*, its more about the complex ecosystems that live within a natural forest. These generally don't survive in an "unnatural" forest. Google for, I don't know, "forest ecosystems" if you want to learn more.
I feel exactly the same as you - we need to push technologies to solve these problems. But clearly nobody has started up that factory yet which manufactures and sells "bio-engineered high-density cellulose" material. If someone could find a way to do this that was cheaper than wood, they could make a lot of money. And perhaps South American economies (and some of the other rainforest countries) might be pushed to try build other areas of their economy, rather than relying as heavily on wood exports. They are essentially raping their vast natural resources for a quick buck, its really sad:(. Most of the demand for the wood comes from the developed world (e.g. countries like Nigeria sell their chopped down trees straight to Asian countries, which have it processed in other Asian countries and then they sell it to countries like the US. What is also sad is that one day, when those countries have completely destroyed those natural resources and the wood supply runs dry, then it will probably be a US company that suddenly gets the incentive to create the cheap artificial wood. And the poor countries will still be poor, but won't even have their trees left anymore to sell. They don't seem to have the vision, the resources or the will to make it sustainable - only the greed and shortsightedness of a small handful of people at the top..
Many logging companies do, although mostly they do it because it makes business sense to do so (i.e. "Our property size is limited, and we need to still have trees to cut down 5 years from now"). But there is a definite problem when a resource is perceived as being "essentially unlimited", and/or when people are too poor or greedy to care that a resource is being depleted. A perfect example is the rainforests, which will, at the current rates of destruction, be gone within our lifetimes. Yet the people who are cutting them down probably tell themselves, "well there is so much rainforest left that there will still be plenty left by the time I retire, and by then it will be someone else's problem". Additionally they may be saying, "I need to feed my family", and the logging companies will be saying "there is so much rainforest there to still be chopped down that if we try do it responsibly, other companies will be able to log cheaper and faster" (tragedy of the commons).
Since you didn't read the whole article, I'll help you:
"Underlying his task is the question of how to turn the study of history into a science. He notes the distinction between the "hard sciences" such as physics, biology, and astronomy -- and what we sometimes call the "social sciences," which includes history, economics, government. The social sciences are often thought of as a pejorative. In particular many of the so-called hard scientists such as physicists or biologists, don't consider history to be a science. The situation is even more extreme because, he points out, even historians themselves don't consider history to be a science. Historians don't get training in the scientific methods; they don't get training in statistics; they don't get training in the experimental method or problems of doing experiments on historical subjects; and they'll often say that history is not a science, history is closer to an art."
The lack of an ability to define something in very concrete terms does not imply that we should not attempt to study it in as rigorous and "scientific" a manner as possible. Psychology, for example, is full of such "fuzziness", but nobody can rationally deny that the study of psychology as a science is still beneficial to society.
Finding good people is far harder than you seem to think it is.
I never once made ANY claims about how difficult it is to find good people. I know it is difficult, WHERE DID I SAY IT WASN'T?!?
Come back when you feel like debating claims that I did make, rather than a bunch of claims you seem to somehow think I made. You must be confusing me with someone else.
So obviously you should fire everyone except those people who know assembly
Don't put words in my mouth. You are being obtuse. If you read my post, you will see I never said anything even remotely like what you are claiming I said.
Indeed! Apart from the necessity of having a good "overall" design, one should generally optimise "defensively", i.e. as long as the program is running "too slowly", one should regularly run it through a profiler (a decent one like Intel's, NOT Microsoft's little toy profiler) to find out which parts of your code are currently the slowest, and work on those. Then basically repeat this process until your program runs "fast enough" (the definition of which will depend on the application, the client, the organization's own personal ideas about quality, and unfortunately, deadlines).
I fully agree, optimising some arbitrary sort routine that already only takes 0.00001% of program execution time is stupid, you would be just throwing your own time and money away.
All it really says is that their interest in programming is not like your interest in programming
True. But in general, you usually find that even with people who are programming only with 'higher level' systems (e.g. even SQL) that the people who are the best at it are usually the ones who do have a good understanding of everything that is happening "behind the scenes". They tend to be faster corders, write better code, and have a much better understanding of where bottlenecks appear (e.g. understanding why some particular SELECT queries are running very slow) and how best to fix them (redundant data? stored procedures? optimize the query? locking issues? or some "broader" network system design issue? Or whatever.).
It really depends what you're writing, how critical speed is, and how much the application needs to be optimized. I'm developing 3D graphics software development toolkit, where you REALLY have to know where every little bottleneck could appear. Something as seemingly harmless as simply having a constructor in your 3D vector class can kill your apps. (Obviously not having a constructor is dangerous, so we provide a version with a constructor and one without, and the programmers need to make sure they know what they are doing). You need to look very carefully at all sorts of aspects, such as possible speed hits of pass-by-copy to functions, where all your inline functions are etc (not having inline functions in crucial spots can also kill your 3D apps), caching aspects etc.
3D graphics is obviously a relatively "extreme" case, where you simply cannot just rely on a good optimising compiler, but there are others. For example, you might be required to write a text 'search' function for a very large database (e.g. the Oxford English Dictionary 2nd Ed software has a search system that allows text searches on over 600 MB of text data to be completed in under a second or so.. probably not unlike Google's I would guess). So for these systems, you also really need to know what you are doing, you cannot just "throw some code at the compiler" and "hope for the best", that just wouldn't be good enough.
There are cell towers all over the place - anywhere you can get coverage, in fact. So if the cancer rate happens to go up in any village anywhere, for whatever reason (e.g. due to mutagenic nasties in the creek), then there is a very good chance that there will be a cell tower nearby.
If cell towers were the cause of the increase, wouldn't we be seeing increase in cancer rates all over the entire developed world, wherever there are cell towers? And gee, we haven't. If anything, the cancer rate remaining steady in 99.99999 of places that have cell towers seems like pretty good empirical evidence suggesting that cell towers probably cause NO increase in cancer rates.
But what's the difference between a heap and a stack who should I care?
Basically, you need to know the difference if you ever want to write really good, efficient code, particularly in C/C++. Its basically about the fact that in order to do so, you really need to know what is going on "behind the scenes" / "under the hood" etc with the compiler. You can't write "good", highly optimized C++ code without at least a solid understanding of how the compiler turns your code into assembly code, and how the CPU executes that assembly code (e.g. stack, registers, cache etc). If you don't truly understand what is happening 'behind the scenes', you not only end up making design mistakes that impact performance, but you also will never really be able to do as good a job at optimizing the C++ code. (This could be seen as a problem with C++, i.e. that you basically need to know assembly to use it properly, but thats the way it is).
Stack is temporary storage space where function parameters and variables with function scope are created. When the function returns, the variables are popped from the stack (not physically, the stack pointer just gets incremented). Anyway, the point is, stack memory is rather limited (usually about 1 or 2MB in an application today). So, a fairly common programming error that you see from not-so-clued-up programmers is to use the stack (variables local to a function, function parameters) for thing that really belong on the heap (new/delete/malloc/free). Heap memory is effectively "unlimited", and persists across functions until manually freed by the programmer. Now, the clueless programmer might know new, delete, malloc, free etc, but doesn't understand when he is using the stack or the heap. So they make mistakes like the following:
void foo()
{
char toobig[10000000];...
}
And next thing they are knocking on your door asking why their program crashes on that otherwise innocent-looking (or so they think) code. The array is allocated on the stack, and the stack basically overflows immediately. They should have used new/delete or malloc/free.
So why is this so bad? Not because it is bad per se, but because it reveals a fairly deep lack of understanding of 'how to program'. Seeing this mistake is, in a way, a very useful benchmark of a programmers level of knowledge. Basically, if you are seeing a graduate comp sci. student on your team make such a beginner mistake, you know that they are very far behind, and will need a LOT more training and experience to become really good programmers. But more importantly, if a comp sci graduate doesn't know the difference between a stack and a heap, it also usually means that they lazy: they have never wanted to have a 'deep' level of knowledge of programming. And this laziness is an indication that you probably don't want that person working for you.
This isn't all necessarily that important for many types of applications. For "typical" VB or Java apps, it isn't. But for any serious C++ project, you generally do not want such a programmer on your team; you rather want the sort of person who is actually willing to learn these basics either in university/college or on their own time.
An analogy: its like a car repair place hiring a mechanic who has a general idea of how an internal combustion engine works, but doesn't understand details (e.g. doesn't understand what distribute timings are about). Its not as if you won't be able to get useful work out of that person -- but you are always going to have to do a fair amount of "hand-holding" in order to get it ("bring that here, put that there, unscrew this" etc).
It shouldn't be the job of your senior programmers to be teaching the jr programmers the difference between a stack and a heap. That is something that ANY Comp Sci graduate SHOULD already know. If a Comp Sci graduate doesn't even know such basics by the time he/she graduates, then typically this means that they are just plain lazy, and training isn't going to solve this. Usually, it just means that you are going to end up burning a lot of money/man-hours while your hard-working, clued-up programmers spend time "training" the lazy programmers and/or spend time fixing the broken code that was supposed to be the jr programmers job.
Its one thing to train people who are hard-working and willing to learn. And you definitely need to do some amount of teaching/mentoring of jr programmers, always. But that means teaching them complex, job-specific issues, not COS 101 basics.
Lazy programmers just do not 'train' well. They are always back at your door, asking you "how do I do XYZ again? I know you told me, but I can't quite remember.. where do I set that option again? What was that function again? What does __cdecl mean again? Could you come help me quickly"? Blah blah, etc etc.
The point about assembly is not so much that assembly skills should directly be used, but that anyone who is serious about programming will already have learnt some assembly, even in their free time. If a programmer has never done assembly, it says something about their lack of interest in programming, which in turn says something about whether or not you want them on your team. Its not black & white, of course, but there is a lot of truth in this generalisation.
Indeed... honestly, Kwil's post was certainly not a troll. It was a good point, was accurate, and completely on-topic. *sigh*
Re:That's what theoretical CS is all about
on
Innovation on the Edge?
·
· Score: 2, Insightful
Computer scientists don't live in a vacuum. Most of the computer science researchers I know have particular real-world problems that they are trying to solve. Sometimes they also have intent of directly commercializing the stuff, sometimes they leave that to others.. but in almost every case I know of, they are aware of the problems they are trying to solve and are very aware of at least some of the potential real-world applications.
"Smart quotes" are "standard ASCII"!?! WTF!? What are they teaching kids in school these days? Get an education, man. Smart quotes were a Microsoft violation of ISO character set standards (hint: nothing to do with ASCII whatsoever, apart from some not-coincidental overlap of the standards). Microsoft said, "hey, we're putting these characters there and we're calling it ISO even though its not. The rest of the world will have to fall in line with us because we're Microsoft". Standard embrace/extend stuff, as usotsuki pointed out.
But these weren't 'edgy' or 'scandalous' or 'rebellious'. These were conceptualized and designed specifically for the purpose of becoming the widespread commercial productivity tools that they are now. Their success wasn't a spin-off; it was already commercially focused.
The other large areas of development (KDE, GNOME, Mozilla, the kernel) are simply trying to catch up to existing commercial software (Windows, IE, Solaris/BSD).
Are you sure? Let me ask you this. Which of these desktops supported skins first, Windows or KDE/Gnome? (Linux window managers supported skins before Windows even supported a gradient effect in the window titlebar). Which supported thumbnails views in the file manager first? Which 'virtualized' the file system in the file manager first? There are plenty of things that Microsoft has been lagging behind in (they were already far behind Mac when Windows 1.0 was released, and they've always been behind, e.g. it took them over 10 years just to copy the Mac's trash-can).
Microsoft added multi-user logon and built-in remote access capabilities to Windows XP. Linux/UNIX had these years ago. Who is playing catch-up?
Actually, the way I see it is, both are playing catch-up with each other, just in different areas. Linux has generally been playing catch-up with regard to user experience, while Microsoft has generally been playing catch-up with regard to networking and multi-user capabilities.
Slashdot Mirror
Indeed. Plus there is higher mechanical stress if you have a fan that kicks in when it's running hotter, as with my laptop ... so real moving parts are involved too.
Sorry, I was just trying to follow the general thread of reasoning here. You first posted essentially saying that we shouldn't complain he was held without due process because he is (or could be) guilty. (The "material witness" point is really just a bit of a lame technicality -> one need only consider the underlying REASON why American citizens have 'due process' in the first place to realise that it ONLY makes sense if there AREN'T technical workarounds to it. American citizens have right to due process - period. There is no "if this yes, if that no", if that was the case, then you might as well throw due process out totally). Humans (and that includes the judge) WILL abuse the system if it is closed - you CANNOT just trust a small handful of people to not abuse the system, if you look at history, you'd realise that would be stupid.
So, WindBourne thought your thoughts were dangerous (dangerous in that if enough people thought the same, US society would be in trouble). So he says thats why he still supports the ACLU, i.e. to protect against these dangerous thoughts.
So your response was to counter that we shouldn't defend this man because he is capable of jihad, apparently thinking that WindBourne was making the mistake of thinking that he must be innocent, in other words thinking that WindBourne was defending *Hawash* and not Hawash's *general rights* (to due process). So what I'm saying is, whether or not Hawash is guilty has nothing to do with WindBourne's point, that Hawash (and EVERY US citizen) still has rights to due process.
What has that got to do with defending the right of every US citizen to due process? So maybe he is guilty; you are saying that we should throw out everybody's rights now, because violating one person's rights actually caught a real criminal in this case? I recommend you go read up on the principles on which your country was founded.
Don't confuse defending the man's rights with defending the man. Maybe he is guilty, but that doesn't make the lack of due process any less noxious. Remember, the rights to due process are your rights too, and that of every other US citizen. You want to excuse this incident because he is guilty? Fine, just don't complain next time its you held without due process for something you didn't do.
Even if he is guilty, which would be very unfortunate especially in this case, that is entirely beside the point. The important point here is the loss of rights under which US citizens can now be detained in this manner. This is what people are protesting, and the point stands that this is a serious problem whether or not he is actually guilty in this case.
Sadly, if it turns out that he is guilty, then many people will forget the important point here - because they will inevitably confuse the concept of defending his basic rights (that all US citizens are supposed to share), with the concept of defending him.
Should you be responsible for a faulty CPU when you took every reasonable effort to protect it from overheating?
If you're overclocking, yes. Otherwise, no.
Its not so much about the *trees*, its more about the complex ecosystems that live within a natural forest. These generally don't survive in an "unnatural" forest. Google for, I don't know, "forest ecosystems" if you want to learn more.
I feel exactly the same as you - we need to push technologies to solve these problems. But clearly nobody has started up that factory yet which manufactures and sells "bio-engineered high-density cellulose" material. If someone could find a way to do this that was cheaper than wood, they could make a lot of money. And perhaps South American economies (and some of the other rainforest countries) might be pushed to try build other areas of their economy, rather than relying as heavily on wood exports. They are essentially raping their vast natural resources for a quick buck, its really sad :(. Most of the demand for the wood comes from the developed world (e.g. countries like Nigeria sell their chopped down trees straight to Asian countries, which have it processed in other Asian countries and then they sell it to countries like the US. What is also sad is that one day, when those countries have completely destroyed those natural resources and the wood supply runs dry, then it will probably be a US company that suddenly gets the incentive to create the cheap artificial wood. And the poor countries will still be poor, but won't even have their trees left anymore to sell. They don't seem to have the vision, the resources or the will to make it sustainable - only the greed and shortsightedness of a small handful of people at the top..
Then why haven't The Onion been shut down long ago? They are a for-profit, and often parody existing corporations.
Many logging companies do, although mostly they do it because it makes business sense to do so (i.e. "Our property size is limited, and we need to still have trees to cut down 5 years from now"). But there is a definite problem when a resource is perceived as being "essentially unlimited", and/or when people are too poor or greedy to care that a resource is being depleted. A perfect example is the rainforests, which will, at the current rates of destruction, be gone within our lifetimes. Yet the people who are cutting them down probably tell themselves, "well there is so much rainforest left that there will still be plenty left by the time I retire, and by then it will be someone else's problem". Additionally they may be saying, "I need to feed my family", and the logging companies will be saying "there is so much rainforest there to still be chopped down that if we try do it responsibly, other companies will be able to log cheaper and faster" (tragedy of the commons).
Since you didn't read the whole article, I'll help you:
"Underlying his task is the question of how to turn the study of history into a science. He notes the distinction between the "hard sciences" such as physics, biology, and astronomy -- and what we sometimes call the "social sciences," which includes history, economics, government. The social sciences are often thought of as a pejorative. In particular many of the so-called hard scientists such as physicists or biologists, don't consider history to be a science. The situation is even more extreme because, he points out, even historians themselves don't consider history to be a science. Historians don't get training in the scientific methods; they don't get training in statistics; they don't get training in the experimental method or problems of doing experiments on historical subjects; and they'll often say that history is not a science, history is closer to an art."
The lack of an ability to define something in very concrete terms does not imply that we should not attempt to study it in as rigorous and "scientific" a manner as possible. Psychology, for example, is full of such "fuzziness", but nobody can rationally deny that the study of psychology as a science is still beneficial to society.
Finding good people is far harder than you seem to think it is.
I never once made ANY claims about how difficult it is to find good people. I know it is difficult, WHERE DID I SAY IT WASN'T?!?
Come back when you feel like debating claims that I did make, rather than a bunch of claims you seem to somehow think I made. You must be confusing me with someone else.
So obviously you should fire everyone except those people who know assembly
Don't put words in my mouth. You are being obtuse. If you read my post, you will see I never said anything even remotely like what you are claiming I said.
Premature optimisation can be a waste of time.
Indeed! Apart from the necessity of having a good "overall" design, one should generally optimise "defensively", i.e. as long as the program is running "too slowly", one should regularly run it through a profiler (a decent one like Intel's, NOT Microsoft's little toy profiler) to find out which parts of your code are currently the slowest, and work on those. Then basically repeat this process until your program runs "fast enough" (the definition of which will depend on the application, the client, the organization's own personal ideas about quality, and unfortunately, deadlines).
I fully agree, optimising some arbitrary sort routine that already only takes 0.00001% of program execution time is stupid, you would be just throwing your own time and money away.
All it really says is that their interest in programming is not like your interest in programming
True. But in general, you usually find that even with people who are programming only with 'higher level' systems (e.g. even SQL) that the people who are the best at it are usually the ones who do have a good understanding of everything that is happening "behind the scenes". They tend to be faster corders, write better code, and have a much better understanding of where bottlenecks appear (e.g. understanding why some particular SELECT queries are running very slow) and how best to fix them (redundant data? stored procedures? optimize the query? locking issues? or some "broader" network system design issue? Or whatever.).
It really depends what you're writing, how critical speed is, and how much the application needs to be optimized. I'm developing 3D graphics software development toolkit, where you REALLY have to know where every little bottleneck could appear. Something as seemingly harmless as simply having a constructor in your 3D vector class can kill your apps. (Obviously not having a constructor is dangerous, so we provide a version with a constructor and one without, and the programmers need to make sure they know what they are doing). You need to look very carefully at all sorts of aspects, such as possible speed hits of pass-by-copy to functions, where all your inline functions are etc (not having inline functions in crucial spots can also kill your 3D apps), caching aspects etc.
3D graphics is obviously a relatively "extreme" case, where you simply cannot just rely on a good optimising compiler, but there are others. For example, you might be required to write a text 'search' function for a very large database (e.g. the Oxford English Dictionary 2nd Ed software has a search system that allows text searches on over 600 MB of text data to be completed in under a second or so .. probably not unlike Google's I would guess). So for these systems, you also really need to know what you are doing, you cannot just "throw some code at the compiler" and "hope for the best", that just wouldn't be good enough.
There are cell towers all over the place - anywhere you can get coverage, in fact. So if the cancer rate happens to go up in any village anywhere, for whatever reason (e.g. due to mutagenic nasties in the creek), then there is a very good chance that there will be a cell tower nearby.
If cell towers were the cause of the increase, wouldn't we be seeing increase in cancer rates all over the entire developed world, wherever there are cell towers? And gee, we haven't. If anything, the cancer rate remaining steady in 99.99999 of places that have cell towers seems like pretty good empirical evidence suggesting that cell towers probably cause NO increase in cancer rates.
But what's the difference between a heap and a stack who should I care?
Basically, you need to know the difference if you ever want to write really good, efficient code, particularly in C/C++. Its basically about the fact that in order to do so, you really need to know what is going on "behind the scenes" / "under the hood" etc with the compiler. You can't write "good", highly optimized C++ code without at least a solid understanding of how the compiler turns your code into assembly code, and how the CPU executes that assembly code (e.g. stack, registers, cache etc). If you don't truly understand what is happening 'behind the scenes', you not only end up making design mistakes that impact performance, but you also will never really be able to do as good a job at optimizing the C++ code. (This could be seen as a problem with C++, i.e. that you basically need to know assembly to use it properly, but thats the way it is).
Stack is temporary storage space where function parameters and variables with function scope are created. When the function returns, the variables are popped from the stack (not physically, the stack pointer just gets incremented). Anyway, the point is, stack memory is rather limited (usually about 1 or 2MB in an application today). So, a fairly common programming error that you see from not-so-clued-up programmers is to use the stack (variables local to a function, function parameters) for thing that really belong on the heap (new/delete/malloc/free). Heap memory is effectively "unlimited", and persists across functions until manually freed by the programmer. Now, the clueless programmer might know new, delete, malloc, free etc, but doesn't understand when he is using the stack or the heap. So they make mistakes like the following:
void foo() { char toobig[10000000]; ...
}
And next thing they are knocking on your door asking why their program crashes on that otherwise innocent-looking (or so they think) code. The array is allocated on the stack, and the stack basically overflows immediately. They should have used new/delete or malloc/free.
So why is this so bad? Not because it is bad per se, but because it reveals a fairly deep lack of understanding of 'how to program'. Seeing this mistake is, in a way, a very useful benchmark of a programmers level of knowledge. Basically, if you are seeing a graduate comp sci. student on your team make such a beginner mistake, you know that they are very far behind, and will need a LOT more training and experience to become really good programmers. But more importantly, if a comp sci graduate doesn't know the difference between a stack and a heap, it also usually means that they lazy: they have never wanted to have a 'deep' level of knowledge of programming. And this laziness is an indication that you probably don't want that person working for you.
This isn't all necessarily that important for many types of applications. For "typical" VB or Java apps, it isn't. But for any serious C++ project, you generally do not want such a programmer on your team; you rather want the sort of person who is actually willing to learn these basics either in university/college or on their own time.
An analogy: its like a car repair place hiring a mechanic who has a general idea of how an internal combustion engine works, but doesn't understand details (e.g. doesn't understand what distribute timings are about). Its not as if you won't be able to get useful work out of that person -- but you are always going to have to do a fair amount of "hand-holding" in order to get it ("bring that here, put that there, unscrew this" etc).
Then teach/mentor your jr. level programmers.
It shouldn't be the job of your senior programmers to be teaching the jr programmers the difference between a stack and a heap. That is something that ANY Comp Sci graduate SHOULD already know. If a Comp Sci graduate doesn't even know such basics by the time he/she graduates, then typically this means that they are just plain lazy, and training isn't going to solve this. Usually, it just means that you are going to end up burning a lot of money/man-hours while your hard-working, clued-up programmers spend time "training" the lazy programmers and/or spend time fixing the broken code that was supposed to be the jr programmers job.
Its one thing to train people who are hard-working and willing to learn. And you definitely need to do some amount of teaching/mentoring of jr programmers, always. But that means teaching them complex, job-specific issues, not COS 101 basics.
Lazy programmers just do not 'train' well. They are always back at your door, asking you "how do I do XYZ again? I know you told me, but I can't quite remember .. where do I set that option again? What was that function again? What does __cdecl mean again? Could you come help me quickly"? Blah blah, etc etc.
The point about assembly is not so much that assembly skills should directly be used, but that anyone who is serious about programming will already have learnt some assembly, even in their free time. If a programmer has never done assembly, it says something about their lack of interest in programming, which in turn says something about whether or not you want them on your team. Its not black & white, of course, but there is a lot of truth in this generalisation.
Indeed... honestly, Kwil's post was certainly not a troll. It was a good point, was accurate, and completely on-topic. *sigh*
Computer scientists don't live in a vacuum. Most of the computer science researchers I know have particular real-world problems that they are trying to solve. Sometimes they also have intent of directly commercializing the stuff, sometimes they leave that to others .. but in almost every case I know of, they are aware of the problems they are trying to solve and are very aware of at least some of the potential real-world applications.
"Smart quotes" are "standard ASCII"!?! WTF!? What are they teaching kids in school these days? Get an education, man. Smart quotes were a Microsoft violation of ISO character set standards (hint: nothing to do with ASCII whatsoever, apart from some not-coincidental overlap of the standards). Microsoft said, "hey, we're putting these characters there and we're calling it ISO even though its not. The rest of the world will have to fall in line with us because we're Microsoft". Standard embrace/extend stuff, as usotsuki pointed out.
But these weren't 'edgy' or 'scandalous' or 'rebellious'. These were conceptualized and designed specifically for the purpose of becoming the widespread commercial productivity tools that they are now. Their success wasn't a spin-off; it was already commercially focused.
The other large areas of development (KDE, GNOME, Mozilla, the kernel) are simply trying to catch up to existing commercial software (Windows, IE, Solaris/BSD).
Are you sure? Let me ask you this. Which of these desktops supported skins first, Windows or KDE/Gnome? (Linux window managers supported skins before Windows even supported a gradient effect in the window titlebar). Which supported thumbnails views in the file manager first? Which 'virtualized' the file system in the file manager first? There are plenty of things that Microsoft has been lagging behind in (they were already far behind Mac when Windows 1.0 was released, and they've always been behind, e.g. it took them over 10 years just to copy the Mac's trash-can).
Microsoft added multi-user logon and built-in remote access capabilities to Windows XP. Linux/UNIX had these years ago. Who is playing catch-up?
Actually, the way I see it is, both are playing catch-up with each other, just in different areas. Linux has generally been playing catch-up with regard to user experience, while Microsoft has generally been playing catch-up with regard to networking and multi-user capabilities.
I'm a perfectionist!
Judging by the quality of their products, I doubt that saying this ever gets anyone a job at Microsoft anyway.