You are being quite subjective. Take for example the Cassini mission, launched in October 1997, primary mission ended in June 2008 (nearly 11 years). Dawn mission: launched in September 2007, primary mission ends in July 2015 (nearly 8 years). That doesn't take into account the development time. I think you'll find many scientists that are willing to commit a murder for that kind of grants. True, many missions are fueled explicitly with expectations of extensions. and that is a perfectly logical choice: once you've done a certain amount of science, you should be able to prove the health of your instrument and be able to demonstrate that continued observations will increase the science output. This kind of audit is perfectly defensible, it reduces waste and helps to optimize the overall budget.
None of those try to study or gain a better understanding of the natural world. You said it yourself, it's electrical engineering. You could also say that mathematical formulas are used to describe the natural world. While true, that doesn't imply that math is a science. I think the best field where you could make a case is in modelling, e.g. of galaxy formation, climate change and such. Here computer simulations are really becoming a third pillar alongside theoretical science and experimental science. If you look more closely, in simulating you are just testing that your model of reality is complete with all it complex interactions (or if you are missing something), or try to make some predictions based on the results of your model. Then again, you could continue to argue about this ad nauseam. Personally, I find this kind of pigeon holing not very interesting. By changing the definitions ever so slightly, you could get very different classifications. Whether it is science, engineering, math, logic, or computer science, I love them all equally and it eventually comes down to "all for one and one for all". Bicker all you want.
The first mistake he made, is the include statement. The stdio.h was between brackets so slashdot saw it as an unrecognized html-tag and dumped it, it seems.
As far as the defines go:
FUCK YOU -> SUCK MY DICK DUMB BITCH -> void main() { printf("fuck you); }
So he did also forgot a an end quote in the printf statement. And, depending on the compiler, it might also complain about main not returning an int value. So while it might not compile the first time, the bugs are easily fixed as the intent is obvious.
All in all this is bad coding style, I give it a 4/20 (points mainly come from using descriptive macro names).
PS: My professional deformation might be getting a bit out of control.
I was just addressing the issue of power consumption. I assume that an architecture that's basically horrible in terms of design will have some implementation and power issues (as a rule of thumb). The recompilation issue is entirely different, but an interesting point to bring up. Is it really that hard? From my experience, it isn't. The major difficulty in cross-compiling is with different environments, not the CPU architecture (except for the very lowest levels). But if you're dealing with server farms, e.g. linux servers, the work has already been done, linux runs fine on ARM. The only possible hurdle I can imagine is with optimized code that optimizes for cache hits on a specific processor. But these kind of optimizations tend to break even between different versions of the same architecture. I don't know how widely they are used in datacenters.
I'm not planning to install a datacenter in the near future, so I haven't studied it in-depth. But I'm sure the big players will do just that, and if they do make the switch, it won't be for fanboy reasons, but for hard economic facts. So I'll let that be the proof, and postpone any poor judgement from my part until later notice. The only thing I can say is that from my experience with ARM programming (including assembly), the architecture is much cleaner than x86. And a clean design has a tendency to be more efficient. Not much to go on, I agree, but it indicates to me that ARM might have a lot of potential.
This is a common scenario. Basically not one organisation should depend on a single person. To deal with such a scenario, I would suggest you approach Bob and ask him "what if you get hit by a bus tomorrow?". His response will reveal his personality. Either he depends on the power he has accumulated, or he will understand the problem. In the former case you are in a big deal of trouble, in the latter case you might brainstorm together and find a practical solution.
Which one? I read "Surely you're joking, Mr. Feynman", it was quite funny. But I'm totally missing the part where he's a male chauvinist pig. Is it because he went to titty bars? Are you a male chauvinist pig if you like watching boobies? Really, I don't know what you're talking about.
Really? Have you ever watched lectures by Feynman (see my earlier posts)? I think your point is based upon the fact that Feynman is dead and dead people don't answer questions from reporters well.
Comparing Feynman to Kaku is a bit like blasphemy to me. Feynman was able to make rock solid arguments that silenced all opposition (see e.g. the Challenger accident investigation). Kaku, on the other hand seems to be fascinated by what-if scenario's, theoretical possibilities and the like. Not that it's not entertaining or thought-provoking, but it's not the same thing by far. Kaku doesn't explain current science well, he's just good at extrapolating.
I agree that Michio Kaku is a bit "way out there". But in regard to Neil Tyson, I have nothing but praise. Search youtube for his interviews, this man really knows how to spread scientific thinking and knows why it is important.
I recently installed xubuntu on my portable after getting sick of the ubuntu desktop. I must say, I'm quite happy with the switch. It boots and runs very fast, and I think my battery life is a bit longer now too. The desktop is functional and traditional, "fancy features weirdo's" have not ruined the project yet.
This presumes that people who know how to program are willing to do things for you that they might reasonably expect you to do for yourself.
Indeed. In some companies this might be a problem. If that's the case, it's a mentality problem, not a technical one. Where I worked, increasing productivity has always been appreciated. I believe that's the right attitude.
Personally I don't hate "amateur" programmers coming up with a solution that makes my hair stand up right. I applaud it. If it saves them time, they'll use it. If not, I hope they recycle the bits (especially the 1's, they pollute a lot more than 0's). But seriously, you bring up some important points:
1) Is the effort spent worth the time gained? That's something you should *always* ask yourself. Even for seasoned programmers this is not always a clear-cut case. Personally I found this technique quite useful: consider the worst case. If in this case you lose some time, is it a lot? No? Then try to automate (depending on your concrete workload and other factors of course - this is an exercise you'll have to make yourself). Rationale: You might lose a bit of time, but if you do this consistently, on average you break even or gain time. But more importantly: you'll gain experience in automation tasks and software tools. This will help you make better judgments later on.
2) Every line of code written will have to be maintained. This is a big issue in some cases. Never assume you will live forever, nor work forever for that company. If the tools you create are mission-critical to the company, it should be discussed with higher management. At the last place I worked, an employee created a full system for automating hardware production in Delphi. When he left, there was nobody to maintain it. However, since it was so central to the company (it really increased efficiency), they hired another Delphi programmer to take it over. Not everything is that complicated however. You can use personal scripts that won't be missed but still save you some time. Worst case: your successor will do it all manually again until he gets annoyed and writes his own scripts, or he discovers yours in a backup.
I must say I find your attitude toward learning a bit depressing, though, personally I grab every opportunity to learn something new. Especially if it has direct implications on my job performance, but not even limited to that.
Uhm, did I tell you to inform your boss? You can get all your work done (without errors once you perfected the script), AND read slashdot full-time. Win-win.
You don't or you can't? Because even when I'm not coding, just in day-to-day computer use, I often write scripts to batch-process or automate various things. I have found this highly beneficial. I don't want to break you down, I just want to know your reasoning. Personally, I can highly recommend learning scripting, be it bash/awk/php (yes, I wrote php scripts)/powershell/whatever, I'm sure you'll benefit from it.
PS: YOu don't really need to know how to program, if you can just identify tasks that are braindead and repetitive, that's already a plus. Then you can go and talk to someone who does know how to program, explain the problem, and this person might come up with a simple solution for you. It all boils down to this. Unfortunately, many people are not trained to identify automatable jobs.
Slashdot Mirror
Curiosity rover confirms: Mars soil tastes like dirt!
You are being quite subjective. Take for example the Cassini mission, launched in October 1997, primary mission ended in June 2008 (nearly 11 years). Dawn mission: launched in September 2007, primary mission ends in July 2015 (nearly 8 years). That doesn't take into account the development time. I think you'll find many scientists that are willing to commit a murder for that kind of grants.
True, many missions are fueled explicitly with expectations of extensions. and that is a perfectly logical choice: once you've done a certain amount of science, you should be able to prove the health of your instrument and be able to demonstrate that continued observations will increase the science output. This kind of audit is perfectly defensible, it reduces waste and helps to optimize the overall budget.
None of those try to study or gain a better understanding of the natural world. You said it yourself, it's electrical engineering. You could also say that mathematical formulas are used to describe the natural world. While true, that doesn't imply that math is a science.
I think the best field where you could make a case is in modelling, e.g. of galaxy formation, climate change and such. Here computer simulations are really becoming a third pillar alongside theoretical science and experimental science. If you look more closely, in simulating you are just testing that your model of reality is complete with all it complex interactions (or if you are missing something), or try to make some predictions based on the results of your model.
Then again, you could continue to argue about this ad nauseam. Personally, I find this kind of pigeon holing not very interesting. By changing the definitions ever so slightly, you could get very different classifications. Whether it is science, engineering, math, logic, or computer science, I love them all equally and it eventually comes down to "all for one and one for all". Bicker all you want.
Sciences deal with understanding the natural world. CS doesn't. It's more closely related to logic and mathematics, neither of which are sciences.
"Computer science is not a science, and it's not about computers" - Hal Abelson.
The first mistake he made, is the include statement. The stdio.h was between brackets so slashdot saw it as an unrecognized html-tag and dumped it, it seems.
As far as the defines go:
FUCK YOU -> SUCK MY DICK DUMB BITCH -> void main() { printf("fuck you); }
So he did also forgot a an end quote in the printf statement. And, depending on the compiler, it might also complain about main not returning an int value. So while it might not compile the first time, the bugs are easily fixed as the intent is obvious.
All in all this is bad coding style, I give it a 4/20 (points mainly come from using descriptive macro names).
PS: My professional deformation might be getting a bit out of control.
But maybe the police does care to catch the criminals involved...
I was just addressing the issue of power consumption. I assume that an architecture that's basically horrible in terms of design will have some implementation and power issues (as a rule of thumb).
The recompilation issue is entirely different, but an interesting point to bring up. Is it really that hard? From my experience, it isn't. The major difficulty in cross-compiling is with different environments, not the CPU architecture (except for the very lowest levels). But if you're dealing with server farms, e.g. linux servers, the work has already been done, linux runs fine on ARM.
The only possible hurdle I can imagine is with optimized code that optimizes for cache hits on a specific processor. But these kind of optimizations tend to break even between different versions of the same architecture. I don't know how widely they are used in datacenters.
I'm not planning to install a datacenter in the near future, so I haven't studied it in-depth. But I'm sure the big players will do just that, and if they do make the switch, it won't be for fanboy reasons, but for hard economic facts. So I'll let that be the proof, and postpone any poor judgement from my part until later notice.
The only thing I can say is that from my experience with ARM programming (including assembly), the architecture is much cleaner than x86. And a clean design has a tendency to be more efficient. Not much to go on, I agree, but it indicates to me that ARM might have a lot of potential.
I don't think MIPS per CPU is the biggest concern in datacenters, it's MIPS per Watt. In that sense, ARM may outclass x86.
This is a common scenario. Basically not one organisation should depend on a single person. To deal with such a scenario, I would suggest you approach Bob and ask him "what if you get hit by a bus tomorrow?". His response will reveal his personality. Either he depends on the power he has accumulated, or he will understand the problem. In the former case you are in a big deal of trouble, in the latter case you might brainstorm together and find a practical solution.
Which one? I read "Surely you're joking, Mr. Feynman", it was quite funny. But I'm totally missing the part where he's a male chauvinist pig. Is it because he went to titty bars? Are you a male chauvinist pig if you like watching boobies? Really, I don't know what you're talking about.
Really? Have you ever watched lectures by Feynman (see my earlier posts)? I think your point is based upon the fact that Feynman is dead and dead people don't answer questions from reporters well.
If you like Feynman, I hope you have watched these lectures, the video quality isn't great but the content more than makes up for it.
Comparing Feynman to Kaku is a bit like blasphemy to me. Feynman was able to make rock solid arguments that silenced all opposition (see e.g. the Challenger accident investigation). Kaku, on the other hand seems to be fascinated by what-if scenario's, theoretical possibilities and the like. Not that it's not entertaining or thought-provoking, but it's not the same thing by far. Kaku doesn't explain current science well, he's just good at extrapolating.
I agree that Michio Kaku is a bit "way out there". But in regard to Neil Tyson, I have nothing but praise. Search youtube for his interviews, this man really knows how to spread scientific thinking and knows why it is important.
I recently installed xubuntu on my portable after getting sick of the ubuntu desktop. I must say, I'm quite happy with the switch. It boots and runs very fast, and I think my battery life is a bit longer now too. The desktop is functional and traditional, "fancy features weirdo's" have not ruined the project yet.
If your thesis is braindead and repetitive, sure:
for i in `seq 10000`; do echo -n "blah "; done
Citation needed
This presumes that people who know how to program are willing to do things for you that they might reasonably expect you to do for yourself.
Indeed. In some companies this might be a problem. If that's the case, it's a mentality problem, not a technical one. Where I worked, increasing productivity has always been appreciated. I believe that's the right attitude.
Personally I don't hate "amateur" programmers coming up with a solution that makes my hair stand up right. I applaud it. If it saves them time, they'll use it. If not, I hope they recycle the bits (especially the 1's, they pollute a lot more than 0's). But seriously, you bring up some important points:
1) Is the effort spent worth the time gained? That's something you should *always* ask yourself. Even for seasoned programmers this is not always a clear-cut case. Personally I found this technique quite useful: consider the worst case. If in this case you lose some time, is it a lot? No? Then try to automate (depending on your concrete workload and other factors of course - this is an exercise you'll have to make yourself).
Rationale: You might lose a bit of time, but if you do this consistently, on average you break even or gain time. But more importantly: you'll gain experience in automation tasks and software tools. This will help you make better judgments later on.
2) Every line of code written will have to be maintained. This is a big issue in some cases. Never assume you will live forever, nor work forever for that company. If the tools you create are mission-critical to the company, it should be discussed with higher management. At the last place I worked, an employee created a full system for automating hardware production in Delphi. When he left, there was nobody to maintain it. However, since it was so central to the company (it really increased efficiency), they hired another Delphi programmer to take it over. Not everything is that complicated however. You can use personal scripts that won't be missed but still save you some time. Worst case: your successor will do it all manually again until he gets annoyed and writes his own scripts, or he discovers yours in a backup.
I must say I find your attitude toward learning a bit depressing, though, personally I grab every opportunity to learn something new. Especially if it has direct implications on my job performance, but not even limited to that.
PS: I love your sig :-).
Uhm, did I tell you to inform your boss? You can get all your work done (without errors once you perfected the script), AND read slashdot full-time. Win-win.
You're right. But you could always write a script to flip the axes, might come in handy if you encounter similar graphs ;-).
You don't or you can't? Because even when I'm not coding, just in day-to-day computer use, I often write scripts to batch-process or automate various things. I have found this highly beneficial. I don't want to break you down, I just want to know your reasoning. Personally, I can highly recommend learning scripting, be it bash/awk/php (yes, I wrote php scripts)/powershell/whatever, I'm sure you'll benefit from it.
PS: YOu don't really need to know how to program, if you can just identify tasks that are braindead and repetitive, that's already a plus. Then you can go and talk to someone who does know how to program, explain the problem, and this person might come up with a simple solution for you. It all boils down to this.
Unfortunately, many people are not trained to identify automatable jobs.