I wouldn't spend a lot of time writing stuff in assembly, unless you find it fun, but knowing enough to debug through object code is golden (especially in C++ when you're just not sure what the compiler is doing with your perfectly clear code - oh, wait, that's what the standard meant?).
Has it mattered to you yet that a cache line on an Intel Core cpu is 32 bytes yet? Oh, the joy of cache-aligned lookup tables, the utter insanity of trying to write platform-ifdef-ed macros with #pragmas inside. : )
For someone who started with C, that can be confusing at first, but that behavior is entirely unsurprising to someone who started with Java. "Of course the size of a reference to a char is different from foo.size(), but how can a reference to a char possibly be a string?"
It used to be common that I had to cope with C programmers struggling to write code in a language with exceptions for the first time (oh, the Pokemon code, when will it end!), but those days are over. Now it's people for whom exceptions are natural, but who would have no clue where to even start with creating a binary wire protocol or serialization format.
Well, I only know this stuff second hand, but Facebook's dev motto used to be "go fast and break stuff". They had a very hard time hiring senior devs for some reason. Recently, they've had a bit of a (recruiting world) push to let people know that their new motto is "go fast with stable infra". I hear there used to be a banner on the wall proclaiming "don't test, just ship", but to be fair I haven't seen that myself.
And as soon as you work for Facebook or Amazon, you will never have any use for 'bit bashing' again.
I can say with certainly that this is false in both cases. Both companies do "under the covers" work, e.g. the/. story currently on the front page about Facebook. There's still a job market for low-level devs, and you've got to start somewhere. Even in Java, you might need to write a decent override of Object.hashCode() for your class (and reversing the bit order is a handy tool in your toolbox for that), and the days of needing to cram just a little bit more information into a text-only field aren't behind us yet.
While it's true that you don't need to understand how Java's Integer.bitCount() and Integer.reverse() and so on actually work in order to use them, you likely won't even be aware that they exist or what they're good for unless you've played with the bits enough to have that mental model in the first place.
You do know that sort of obsessive language-lawyering is exactly what turns people off to exploring C, right?
Someone well-versed in Java won't be surprised that arrays know their own size. That's not the interesting lesson here, for someone who's never seen the difference between big- and little-endian in a debugger.
Well, I can only try to generalize from the students I've interviewed and worked wit, but that's not a small sample.
There's plenty of "databases and algorithms", but that's all abstractions these days. Even back when I rode my dinosaur to college, it was only the better schools that made you write a toy OS in C, and write a C compiler, to get a CS degree. Now that stuff has mostly fallen by the wayside, and students learn "OS concepts" writing Java code.
Most students I've talked to recently took one semester of "C programming", but just did the sorts of things in C they already knew how to do in Java (except awkwardly in C), and didn't understand the point of the class (and perhaps the class was pointless). In my generation, almost everyone wrote a bignum implementation either as a college assignment or just for fun when teaching themselves before that. Now, no one does. It's quite odd.
If you have 1 million Linux machines deployed, with full Linux-specific software stacks on each, it's cheaper and easier (and most likely faster) to fix the problems you see in Linux than to move the fleet to a new OS.
Facebook's dev shop culture is all about banging out code as fast as possible for the problem in front of them, then moving on. Forward planning isn't really the thing there, from what I hear (though I think you're no longer discouraged from testing your code before it goes live, that's a recent change). Moving to BSD might well be a better long term plan, but it would take years to get there and they don't really think on that timescale, from the rumors I hear anyhow.
Java schools are a menace, but since it's nearly impossible to find grads with a "real" programming curriculum any more, I think we've just sort of given up and accepted our fate as needing to teach new college hires everything.
If you can code - really write code beyond simple toy assignments - in any language, you're already doing above average. But if you want to be top tier, you really need to understand the crufty details of what compilers do and how they do it. While there are no lack of Java jobs, you're really missing something if you don't have a good mental model of computers at the machine language level, and if you've never done any "bit bashing" (working with unsigned ints as arrays of bits, not as numbers).
My suggestion for getting a rounded education is to go write some C code. Write code to count the '1' bits in an unsigned int -- no googling the answer! -- and then keep brainstorming for ways to optimize that (when you can snatch the bitcount with "n%63", you will be ready to leave the temple). Write code to do other bit-bashing - reverse the bits in a word, find the base-2 log of an int, and so on. Write your own "bignum" implantation from scratch, to have a larger problem to solve with lots of corner cases and ugly cruft.
These are toy problems, and they won't teach you all the stuff you can learn in Java about "software engineering", but they'll cover and important gap. Most importantly of all - debug through all your solutions and get comfortable with debugging. Debug through the generated object code, stepping through one instruction at a time until you understand what's happening. Debug through the object of non-optimized vs highly optimized code.
Don't stop until you're totally comfortable with bit-bashing, with pointers and pointer-array equivalency, and so on. Once you start debugging through C code, especially the object, natural geek curiosity will serve you well to cover the gaps in a Java-only background.
Sokal fired the first volley in the prank war. No prank war ever ends with the first prank. Naturally, the offended postmodernists felt obligated to publish nonsense paper in a physics journal, and I remember a Slashdot article about their success in a string theory journal. Wikipedia doesn't list it in the list of pranks following the Sokal hoax, but surely we can't question the unimpeachable accuracy and multiple layers of editorial fact checking of Slashdot, can we?
Long damn time - the tail end of the "greatest generation" is till hanging on. The Boomers have just started to drain the treasury, and won't die off until that has been completed.
Very well put - I was trying to figure out how to say this, but that nails it.
String Theory is a toolkit - an infinite set of theories. You can specify some of the tunable parameters and get a specific testable theory, but there's no non-arbitrary way to do that. So many physicist-decades sunk into something which "might be useful one day".
You can say it's all math, not physics, and so uselessness is fine, but then the problem is it's pretty bad math - no elegance, most equations aren't solvable yet.
String theory started as an attempt to simplify the standard model to a few primitives, but it has totally failed in that regard.
There isn't enough of a market to support all the people who want to be paid for almost every kind of entertainment; heck, that's probably true for half of all career choices.
Sure, but the point is: the American religious never objected to stem cell research in general, only quite specifically to embryonic stem cell stuff. And, really, it is a bit creepy, and I think it's great that it's starting to look like embryonic stem cells aren't all that important to the field after all, and maybe humanity can give that particular sort of creepiness a miss (imagine e.g. a situation where the only way to get a cure for your illness was to conceive an embryo for harvest - just so many kinds of creepy there).
Questions of medical ethics, especially in research, shouldn't be lightly brushed aside regardless of where they come from. Finding an approach where such questions just aren't relevant is welcomed.
String theory became extremely dodgy for a while there - in fact, it went totally off the rails IMO. There were physics journal articles with long philosophical rants and no equations. When the "get random nonsense published" prank war hit physics, it's no surprise it was a string theory journal that fell for it.
This is what happens to any science without new data coming in. When the Superconducting Supercollider was cancelled, particle physics began getting a little nutty, and by the time you had mid-career physicists with who had only published works never to be challenged by experiment, well, it's an object lesson in how not to do science.
But the LHC was the needed fix. Theory and experiment are now re-coupled, and I hear that sanity is returning aggressively. Meanwhile the other end of physics, cosmology, has the most accurate data ever to work with, thanks to the CMBR probes, and has been making huge strides for a decade now (cosmology with significant digits, who'd have thought?).
Sure, maybe the Gigafactory could be built on the ruins of Detroit suburbs - that's cheap land. You need a place for all the workers to live safely - let's call it "New Detroit", bringing many jobs. And you'd need new ideas about security. Being a Musk project, we'd have some sort of robotic security - some sort of "robo-cop", so to speak, to guard New Detroit. Maybe you could make a movie about this novel idea!
Well, since your analysis of Reanagomics is so wrong, I can only assume your analysis of Abe is equally screwy, but my point was it's all so damn subjective - we can't even agree on economic events of the 80s. All we know objectively is that we don't know any sure recipe for getting out from under.
But one is legitimate and the other is a uneducated, unprofessional person with a bias. The difference between a reporter and a web logger (I refuse to use your made-up garbage word) is huge, and publishers have a responsibility to note the difference between the two.
Sure, the blogger is educated and often very fact-checked by his commenters, while the reporter has a journalism degree instead of an education and just makes shit up that never gets checked: sure we all know that. I was just being polite to the poor dinosaurs - no need to add insult to injury.
Cheap cameras only get better. They were able to reconstruct voice from a good 60 Hz camera. If a policeman wanted to game the system, he could use a good camera to avoid the need for a warrant. Much like the NSAs "we capture everything, but only look at the data with (later) probable cause" excuse, someone might try an equally disturbing "we capture video, and only reconstruct the audio with (later) probable cause" in an attempt to game the system similarly. Uggh.
Investigative journalism is labor-intensive. Whether we end up calling the person doing that a "reporter" or a "blogger" doesn't matter - there's a market for it.
The atmosphere is not a yes/no thing. There's not much drag in LEO, but it's not 0. Over time, orbits there decay. And the more non-circular an orbit (as tends to be the case from explosions), the more likely it will pass through thicker atmosphere at perigee. Just one more case where if violence isn't solving your problem, you're not using enough of it.
You joke, but the Japanese have tried that, and almost every other economic idea imaginable over the past 25 or so years of recession. It shows how far our collective understanding of economics is from anything useful. The only dependable advice is "don't pick up that much debt in the first place". Advice which every modern nation seems determined to ignore at any cost (well, not just modern, most throughout history as well).
Being able to do this from a recording is the magic. There are many places where video is recorded but not audio. Being able to recover the audio much later would be special. Also worrying, in places where you can record video but not audio without a warrant.
They were able to get decent voice from a 60 Hz camera. I'm guessing the camera didn't record all pixels simultaneously, and so the differences between when each pixel sampled were enough to work with.
Oh? Shame you haven't helped others like Mozilla with that. It would sure be nice if you could spread your magical immunity from human error out to others, but apparently you're too professional to share that wisdom.
Best practices for avoiding leaks of important stuff are well known (and, really, Mozilla didn't suck here). But they had insufficient code or process review somewhere, to have had this leak. Normally, I'm all for rapid, agile development, but when it comes to the important stuff don't do that. Go slow. Get 20 people to review the change. Come back after a week or a month and review it again. It's important, don't rush it. There's very little most of us work on that's actually important, since most people don't work on life safety code, but user personal info counts.
Sounds like the process that was supposed to scrub this info was failing for quite some time. Where was the monitoring? Where was the alerting? If a process is important, you don't let it fail silently.
None of this is rocket science. You know how some guys go on about the difference between "software engineering" and "coding"? Yeah, sometimes it's not just BS.
Slashdot Mirror
I wouldn't spend a lot of time writing stuff in assembly, unless you find it fun, but knowing enough to debug through object code is golden (especially in C++ when you're just not sure what the compiler is doing with your perfectly clear code - oh, wait, that's what the standard meant?).
Has it mattered to you yet that a cache line on an Intel Core cpu is 32 bytes yet? Oh, the joy of cache-aligned lookup tables, the utter insanity of trying to write platform-ifdef-ed macros with #pragmas inside. : )
For someone who started with C, that can be confusing at first, but that behavior is entirely unsurprising to someone who started with Java. "Of course the size of a reference to a char is different from foo.size(), but how can a reference to a char possibly be a string?"
It used to be common that I had to cope with C programmers struggling to write code in a language with exceptions for the first time (oh, the Pokemon code, when will it end!), but those days are over. Now it's people for whom exceptions are natural, but who would have no clue where to even start with creating a binary wire protocol or serialization format.
Well, I only know this stuff second hand, but Facebook's dev motto used to be "go fast and break stuff". They had a very hard time hiring senior devs for some reason. Recently, they've had a bit of a (recruiting world) push to let people know that their new motto is "go fast with stable infra". I hear there used to be a banner on the wall proclaiming "don't test, just ship", but to be fair I haven't seen that myself.
And as soon as you work for Facebook or Amazon, you will never have any use for 'bit bashing' again.
I can say with certainly that this is false in both cases. Both companies do "under the covers" work, e.g. the /. story currently on the front page about Facebook. There's still a job market for low-level devs, and you've got to start somewhere. Even in Java, you might need to write a decent override of Object.hashCode() for your class (and reversing the bit order is a handy tool in your toolbox for that), and the days of needing to cram just a little bit more information into a text-only field aren't behind us yet.
While it's true that you don't need to understand how Java's Integer.bitCount() and Integer.reverse() and so on actually work in order to use them, you likely won't even be aware that they exist or what they're good for unless you've played with the bits enough to have that mental model in the first place.
You do know that sort of obsessive language-lawyering is exactly what turns people off to exploring C, right?
Someone well-versed in Java won't be surprised that arrays know their own size. That's not the interesting lesson here, for someone who's never seen the difference between big- and little-endian in a debugger.
Well, I can only try to generalize from the students I've interviewed and worked wit, but that's not a small sample.
There's plenty of "databases and algorithms", but that's all abstractions these days. Even back when I rode my dinosaur to college, it was only the better schools that made you write a toy OS in C, and write a C compiler, to get a CS degree. Now that stuff has mostly fallen by the wayside, and students learn "OS concepts" writing Java code.
Most students I've talked to recently took one semester of "C programming", but just did the sorts of things in C they already knew how to do in Java (except awkwardly in C), and didn't understand the point of the class (and perhaps the class was pointless). In my generation, almost everyone wrote a bignum implementation either as a college assignment or just for fun when teaching themselves before that. Now, no one does. It's quite odd.
If you have 1 million Linux machines deployed, with full Linux-specific software stacks on each, it's cheaper and easier (and most likely faster) to fix the problems you see in Linux than to move the fleet to a new OS.
Facebook's dev shop culture is all about banging out code as fast as possible for the problem in front of them, then moving on. Forward planning isn't really the thing there, from what I hear (though I think you're no longer discouraged from testing your code before it goes live, that's a recent change). Moving to BSD might well be a better long term plan, but it would take years to get there and they don't really think on that timescale, from the rumors I hear anyhow.
Java schools are a menace, but since it's nearly impossible to find grads with a "real" programming curriculum any more, I think we've just sort of given up and accepted our fate as needing to teach new college hires everything.
If you can code - really write code beyond simple toy assignments - in any language, you're already doing above average. But if you want to be top tier, you really need to understand the crufty details of what compilers do and how they do it. While there are no lack of Java jobs, you're really missing something if you don't have a good mental model of computers at the machine language level, and if you've never done any "bit bashing" (working with unsigned ints as arrays of bits, not as numbers).
My suggestion for getting a rounded education is to go write some C code. Write code to count the '1' bits in an unsigned int -- no googling the answer! -- and then keep brainstorming for ways to optimize that (when you can snatch the bitcount with "n%63", you will be ready to leave the temple). Write code to do other bit-bashing - reverse the bits in a word, find the base-2 log of an int, and so on. Write your own "bignum" implantation from scratch, to have a larger problem to solve with lots of corner cases and ugly cruft.
These are toy problems, and they won't teach you all the stuff you can learn in Java about "software engineering", but they'll cover and important gap. Most importantly of all - debug through all your solutions and get comfortable with debugging. Debug through the generated object code, stepping through one instruction at a time until you understand what's happening. Debug through the object of non-optimized vs highly optimized code.
Don't stop until you're totally comfortable with bit-bashing, with pointers and pointer-array equivalency, and so on. Once you start debugging through C code, especially the object, natural geek curiosity will serve you well to cover the gaps in a Java-only background.
Sokal fired the first volley in the prank war. No prank war ever ends with the first prank. Naturally, the offended postmodernists felt obligated to publish nonsense paper in a physics journal, and I remember a Slashdot article about their success in a string theory journal. Wikipedia doesn't list it in the list of pranks following the Sokal hoax, but surely we can't question the unimpeachable accuracy and multiple layers of editorial fact checking of Slashdot, can we?
Long damn time - the tail end of the "greatest generation" is till hanging on. The Boomers have just started to drain the treasury, and won't die off until that has been completed.
They've put in a .00035 second speed bump on trades. I can't disagree with that at all, and it has little to do with my point.
Very well put - I was trying to figure out how to say this, but that nails it.
String Theory is a toolkit - an infinite set of theories. You can specify some of the tunable parameters and get a specific testable theory, but there's no non-arbitrary way to do that. So many physicist-decades sunk into something which "might be useful one day".
You can say it's all math, not physics, and so uselessness is fine, but then the problem is it's pretty bad math - no elegance, most equations aren't solvable yet.
String theory started as an attempt to simplify the standard model to a few primitives, but it has totally failed in that regard.
There isn't enough of a market to support all the people who want to be paid for almost every kind of entertainment; heck, that's probably true for half of all career choices.
Sure, but the point is: the American religious never objected to stem cell research in general, only quite specifically to embryonic stem cell stuff. And, really, it is a bit creepy, and I think it's great that it's starting to look like embryonic stem cells aren't all that important to the field after all, and maybe humanity can give that particular sort of creepiness a miss (imagine e.g. a situation where the only way to get a cure for your illness was to conceive an embryo for harvest - just so many kinds of creepy there).
Questions of medical ethics, especially in research, shouldn't be lightly brushed aside regardless of where they come from. Finding an approach where such questions just aren't relevant is welcomed.
String theory became extremely dodgy for a while there - in fact, it went totally off the rails IMO. There were physics journal articles with long philosophical rants and no equations. When the "get random nonsense published" prank war hit physics, it's no surprise it was a string theory journal that fell for it.
This is what happens to any science without new data coming in. When the Superconducting Supercollider was cancelled, particle physics began getting a little nutty, and by the time you had mid-career physicists with who had only published works never to be challenged by experiment, well, it's an object lesson in how not to do science.
But the LHC was the needed fix. Theory and experiment are now re-coupled, and I hear that sanity is returning aggressively. Meanwhile the other end of physics, cosmology, has the most accurate data ever to work with, thanks to the CMBR probes, and has been making huge strides for a decade now (cosmology with significant digits, who'd have thought?).
Sure, maybe the Gigafactory could be built on the ruins of Detroit suburbs - that's cheap land. You need a place for all the workers to live safely - let's call it "New Detroit", bringing many jobs. And you'd need new ideas about security. Being a Musk project, we'd have some sort of robotic security - some sort of "robo-cop", so to speak, to guard New Detroit. Maybe you could make a movie about this novel idea!
Well, since your analysis of Reanagomics is so wrong, I can only assume your analysis of Abe is equally screwy, but my point was it's all so damn subjective - we can't even agree on economic events of the 80s. All we know objectively is that we don't know any sure recipe for getting out from under.
But one is legitimate and the other is a uneducated, unprofessional person with a bias. The difference between a reporter and a web logger (I refuse to use your made-up garbage word) is huge, and publishers have a responsibility to note the difference between the two.
Sure, the blogger is educated and often very fact-checked by his commenters, while the reporter has a journalism degree instead of an education and just makes shit up that never gets checked: sure we all know that. I was just being polite to the poor dinosaurs - no need to add insult to injury.
Cheap cameras only get better. They were able to reconstruct voice from a good 60 Hz camera. If a policeman wanted to game the system, he could use a good camera to avoid the need for a warrant. Much like the NSAs "we capture everything, but only look at the data with (later) probable cause" excuse, someone might try an equally disturbing "we capture video, and only reconstruct the audio with (later) probable cause" in an attempt to game the system similarly. Uggh.
Investigative journalism is labor-intensive. Whether we end up calling the person doing that a "reporter" or a "blogger" doesn't matter - there's a market for it.
The atmosphere is not a yes/no thing. There's not much drag in LEO, but it's not 0. Over time, orbits there decay. And the more non-circular an orbit (as tends to be the case from explosions), the more likely it will pass through thicker atmosphere at perigee. Just one more case where if violence isn't solving your problem, you're not using enough of it.
You joke, but the Japanese have tried that, and almost every other economic idea imaginable over the past 25 or so years of recession. It shows how far our collective understanding of economics is from anything useful. The only dependable advice is "don't pick up that much debt in the first place". Advice which every modern nation seems determined to ignore at any cost (well, not just modern, most throughout history as well).
Being able to do this from a recording is the magic. There are many places where video is recorded but not audio. Being able to recover the audio much later would be special. Also worrying, in places where you can record video but not audio without a warrant.
They were able to get decent voice from a 60 Hz camera. I'm guessing the camera didn't record all pixels simultaneously, and so the differences between when each pixel sampled were enough to work with.
Oh? Shame you haven't helped others like Mozilla with that. It would sure be nice if you could spread your magical immunity from human error out to others, but apparently you're too professional to share that wisdom.
Best practices for avoiding leaks of important stuff are well known (and, really, Mozilla didn't suck here). But they had insufficient code or process review somewhere, to have had this leak. Normally, I'm all for rapid, agile development, but when it comes to the important stuff don't do that. Go slow. Get 20 people to review the change. Come back after a week or a month and review it again. It's important, don't rush it. There's very little most of us work on that's actually important, since most people don't work on life safety code, but user personal info counts.
Sounds like the process that was supposed to scrub this info was failing for quite some time. Where was the monitoring? Where was the alerting? If a process is important, you don't let it fail silently.
None of this is rocket science. You know how some guys go on about the difference between "software engineering" and "coding"? Yeah, sometimes it's not just BS.