Wow, that reply was really underwhelming. It doesn't even include one counter-point relevant to the subject (which is Flash, not me). I realize that I'm new to the language, but with Flash there's not that much to learn. If you can make a decent argument about any of the points I made on Flash, I'll listen. Otherwise, you're just wasting time.
I've programmed in a lot of languages. I just learned Flash a few weeks ago because I needed to port an iPhone game to Flash. From a developer's perspective, programming in Flash is like programming with half a language that only has half a run-time library. That wouldn't be so bad if it was fun to program in like some of the more modern scripting languages, but it's not.
Regarding performance, I found that the only way to make Flash code perform well is to write spaghetti code. I had a collision detection routine running really slowly, and when I hacked together a profiler for it (which is not easy because the language has no high-precision timers), I discovered that the function call overhead in Flash is obscenely high. I had to get rid of all getter methods (i.e. make all my read-only member variables public), replace convenience functions like Math.abs() and Math.max() with if-then-else statements, and take my hit test function and copy+paste its contents everywhere I wanted to call it. (I didn't see any macro or inline features, and as much as I hate to copy+paste, the hit really was that bad.)
IMO, if Adobe can't fix the language, they should put a bullet in it. If they won't do either (and they've had years), then I have no problem with other companies attempting to put a bullet in it.
Ever watch a documentary on how the Hawaiian islands were found by Polynesians with no instruments, and before they learned how to write and do any kind of math? The could find islands that were hundreds of miles away by watching for certain cloud patterns in the sky. Compared to that, even sailors who were completely brain dead could find land sailing around in the Mediterranean. I mean, any direction you go from any point, and you'll find land.
The Internet has never been private. If a packet leaves your computer, it can be seen at several points on the way to its destination. However, in the early days, there were virtually no organizations that had the CPU or storage capacity to log and report on every packet going through those routers, every firewall session, every web server hit, and so on, unless they were targeting your IP for some specific reason. The organizations that may have had that much bandwidth available had other uses for it.
Given the advances in computer hardware, it is much easier for companies to log and report on every hit to their web server, every session through their firewall, etc. With how much faster networks have gotten, it's probably still not feasible to log every packet, but it is feasible to inspect packets to look for specific types of sessions, and to log packets from sessions of interest. I work at a company that makes a network appliance that does something along those lines, and it's pretty easy. We can even monitor your Skype traffic (not listen to your calls, just see who you're chatting with).
If you want privacy that badly, give up the Internet, your cell phone, your GPS, your credit cards, and so on. Technology has made monitoring too easy for organizations to resist, and some organizations have found uses for it they never dreamed of in the first place, and they will be very unwilling to give it up.
It really depends on what kind of development they're doing. Speaking as an Enterprise Windows developer who has had to install clean OS's regularly (hurray for virtualization) and test products our with ActiveDirectory integration, I can say that sometimes development groups need their own domain controller to play with. In that case, give them their own domain and consider putting it on a network segment separate from the rest of the organization. Set up the routes and a domain trust relationship that allows them to get corporate email and access shared folders and printers, and you're all set.
Even if developers don't need their own sandbox to play in and don't know how to administer a domain controller, it may be a good idea to set it up that way for security reasons. Developers tend to be lax about in-house security, and it helps keep systems on the rest of the network from being able to access development files they have no business accessing. If they do any network testing, it also may keep them from killing your firewalls, servers, Internet bandwidth, etc. (that's one reason my group got moved to our own network segment with its own Internet connection;-) If they do any security testing, they also may install malware on purpose from time to time (that's another reason my group got moved to our own network segment;-).
If the LED's can handle additional current, what about a dimmer switch? If they can crank it up so it temporarily uses as many Watts as a normal bulb, it should generate the same amount of heat. Even if they can't get the power that high, higher brightness levels may be enough to be visible through the snow.
I was too old when that one came out, but either way "fun" is a relative term when it comes to games like that.
I made a math game for my son once that seemed cool to me. You're captain of the moon, which has several bases on it (the moon is a small sphere in the center of the screen in this game). Asteroid storms threaten your bases. The only way to stop them is to use a cannon to shoot rocks at them and deflect them away. The rocks are all the same size, but the asteroids aren't, so the amount of force you need to use when shooting is different for each asteroid (and each requires a multiplication to determine how much power). If you use too little, it slows the asteroid down (which gives you a bit more time to get the right answer). If you use too much, the asteroid breaks into two smaller asteroids, and you have two smaller problems to solve.
My son figured out how to cheat the game pretty quickly though. Each wave had a multiplication factor, so on wave 7, you're always solving for 7 * x. He would set the cannon to max power and blast all the big asteroids until they had shrunk down to 1, then he'd set the power to 7 and blast all the 1's.;-)
Heh. Toss in plenty of delicate problems where a simple mistake could cause everyone to die (followed up by hours of corpse recovery to get your equipment back), and the old EQ fans would be right at home playing it.;-)
After doing SimEarth, Maxis kicked around the idea of a SimMars. NASA was really excited about helping them (and helping build up PR on the space program), but Maxis killed the idea because they couldn't find a way to make a game about Mars fun without making it 100% fantasy. It's like trying to make a math game fun.
Advanced features do not automatically make a language great. That's like saying advanced graphics techniques automatically make a game great. Actually, I just noticed your handle is BadAnalogyGuy. Did you do that on purpose?;-)
Anyway, JavaScript is a horrible language (almost as bad as VBScript) and it needs to be phased out. I'd rather have client-side PHP than JavaScript, and I hate PHP. Ruby or Python would be the best IMO. From a language purist's viewpoint Ruby is more elegant, but Python has been around longer so it has a larger following.
I doubt the article explained the true nature of the "bug" correctly. I work on 3D modeling and rendering on large scales (http://sponeil.net/), so I am acquainted with a number of types of precision problems. These developers are definitely working with 3D modeling and physics (and probably rendering for simulations). This means they're using 3D vectors and 4D matrices/quaternions, which accumulate precision errors surprisingly fast. The physics equations require approximations that introduce even larger errors, and the slower the processor, the lower the quality of approximations. A 0.1-second time step provides pitiful precision for physics calculations, and if they'd had a better processor, they would've taken advantage of it to take more samples. There's also the fact that the timer on the processor may be a tiny bit off, and that error will accumulate over time. Even if it the timer were perfect, they may need to multiply floats by the "current time". As that number gets larger, the result loses bits of precision during the multiply. There are any number of similar problems they could be running into (and this problem is probably a combination of more than one).
Of course all of these problems can be solved in any number of ways, but this is a complex piece of software, it sounds like the processor is extremely limited, changes to the math require large amounts of testing (very expensive tests that at some point involve firing real missiles), and given how late the project was, you can be sure they had management breathing down their necks trying to get them to rush it out the door. Of course there are plenty of poor programmers out there, and I'm sure that was a factor, but probably not the largest factor. It sounds like they knew about this problem and management decided it wasn't worth the testing effort to try to fix it. After all, they had a "reboot every hour or so" workaround, which I agree is ludicrous, but the farther a project slips, the more management will start to think that certain problems are acceptable.
As a programmer, I can confirm that these programmers screwed up, but I would bet money on the fact that the management forced them to. There's no way programmers working on physics software would choose a processor limited to 24-bit registers unless that was the only choice they were given, so that decision must have been forced upon them by their bosses. I'm also certain that the decision that it was "good enough" to ship was not made by the programmers. Here's an interesting quote:
From: http://www.corpwatch.org/article.php?id=11110 "As usual with the Pentagon, cost is no object. But the Patriot is very expensive system and it's getting costlier all the time. Raytheon and Lockheed originally promised to deliver the new Patriot system for $3.7 billion dollars. Now the cost has soared to $7.8 billion. Each Patriot missile unit costs about $170 million. In the first Gulf War, an average of four missiles were launched against a single incoming Scud."
Even if that's grossly inaccurate, they saved a few bucks per multi-million dollar unit. That's like being penny wise but several million pounds foolish. While I agree it's not that hard to work around the 24-bit limitation, the decision to use such a limited processor was probably a major contributing factor to the schedule slips and cost overruns. Any time a project slips that badly, management will step in and force them to rush it out the door before it's ready. My bet is that the developers knew the problem was there, but they didn't have time to even look at it because they had bigger fish to fry when they were trying to get it out the door.
I'd go crazy a lot more quickly if they gave me Internet access in that scenario. Imagine having to wait 20 minutes after each click for results to show up in your web browser. Even worse, images embedded in a page would take an additional 20 minutes to show up because your browser won't know what image files to ask for until it receives the page with the embedded links. It would be like Chinese water torture, always wondering when the next page was going to hit. If I didn't lose my mind sooner, I'd lose it the first time I got a 404 message. It would definitely be better to not have Internet access at all.
It may not be too bad if NASA creates a customized browser and proxy server so that when you visit a new page, the proxy server crawls every link on that page and starts streaming them to the ship before you ask for them, and then crawls the links on those pages recursively using a breadth-first search pattern until the browser tells it which link you picked (at which point it picks a new root for the tree). The customized browser would continually listen for new files to be sent and cache them on the local drive. Even with relatively low bandwidth, the browsing experience should be fairly responsive as long as you keep following a chain of links, don't click too fast, and don't hit a page with like a million links. If you do something silly like try to fill out a web form (i.e. type a search term into Google), type a web site name into the address bar, or visit a dynamic web 2.0 site with a bunch of Ajax calls, it's back to the Chinese water torture.
When I say elevated, I don't mean like "aerobic workout" or "stressed out" kind of elevated. Your respiration and heart rate slow down when sitting, but for work it's better to keep it closer to a normal walking rate, IMO. Caffeine is not a very healthy way to do it, but it works for millions of people in a pinch.
Most people can't consciously control their breathing for hours while trying to put 100% of their concentration on coding, although I suppose it would be good to add:
7) Stop to take a few deep breaths every now and then.
What you need is focus. I have a hard time focusing if I'm even a little sleepy. When I was ten years younger I never got sleepy and I never had trouble staying focused, but now that I'm older and have kids sapping my energy during what used to be my "down" time, I have to struggle to keep my focus at work. Here are some tips that might help:
1) Go to bed early the night before. I know you're not used to it, but try it at least for a week.
2) Elevate your pulse to keep plenty of oxygen flowing to the brain. Exercising in the morning helps, but won't keep your pulse up all day, so take a few short breaks during the day to walk around a bit.
3) Coffee if you can stand it, Mountain Dew if you can't.
4) Play background music. Try to find music that's fast enough to keep the pulse elevated a little, but play it quietly enough that it won't break your concentration. I often play music so quietly that I can barely hear it when programming. Avoid radio stations because the break in flow during commercials will break your focus.
5) When writing something new (a document, an article, a program), getting started is often downright painful. Once you get past the first paragraph/section/class, things flow smoothly for a while. Every now and then you get stuck again, and when you're stuck, you usually just have to force your way through it. Sometimes it's better to skip the part you're stuck on and work on something else for a while, but when you're just getting started, you usually have to force your way through it.
6) Create a set of really small tasks with short deadlines. If your boss isn't putting pressure on you to get something done by the end of the week, put a little pressure on yourself. Zero stress often equates to zero motivation to get things done quickly. It is far better to stress yourself out a little than to be fired later because you worked for months with nothing to show for it.;-)
Great! Let's use the scientific method to test this hypothesis. Oh wait, nevermind.
Sorry, but it's hard not to be cynical about astrophysics. Dark matter sounds like something invented by a writer for a Japanese cartoon series, and the scientific explanation sounds about as likely to be true.
My sister was injured in an accident while sitting at a red light. Someone slammed into her from behind doing about 60. Trust me, you're just as much of a sitting duck in a car, and there are a lot more idiots and drunk drivers on the road than in the air. (Yes, I've read about the drunk pilots, but you're much more likely to die from some kind of mechanical failure in a plane than from pilot error, no matter how drunk he is.) Of course, we'll all be completely screwed if flying cars become a reality.
Probably the only good argument in favor of driving is that plane accidents are almost always fatal. On average, you'd probably be better off in a motorcycle accident than a plane accident, and I sure as hell would not want to be in a motorcycle accident.
Your post is off-topic relative to the point I was making (and to the point I was refuting). That one line of Ruby code by itself would not need a comment explaining WHY. It would be part of a small function or code block that would need a comment explaining WHY. That comment would not be specific to this one line of code, which is why your argument seems off-topic to me.
My point was that if you needed 10 lines of code (perhaps in C) to make a simple check like that, you would need an additional comment to explain WHAT those lines were doing. If you needed 100 (perhaps in assembler), you would need comments for each logical block you broke it up into, and then another to encapsulate the whole thing. The larger a block of code must be to do something, the more likely you are to need additional comments just to explain WHAT the code is doing. It goes without saying that those extra lines of code make it easier for bugs to slip in, and make the program harder to maintain. If the language you're using requires such verbosity everywhere, then it becomes a more expensive program to write and maintain (sometimes it is necessary, but sometimes it is not).
The argument that more verbose code is self-documenting and thus easier to read is complete BS. It would also be complete BS to say that shorter is always better. A lot of people have written extremely short Perl programs that they themselves had a hard time reading a short time later. For short code to be "better", it has to be clean enough to be easy for any programmer to figure out quickly. However, code cleanliness and readability was not one of the inputs for these graphs. That is why Perl looks better than both Python and Ruby on these graphs despite the fact that most programmers can't stand Perl (and for valid reasons).
Slashdot Mirror
Wow, that reply was really underwhelming. It doesn't even include one counter-point relevant to the subject (which is Flash, not me). I realize that I'm new to the language, but with Flash there's not that much to learn. If you can make a decent argument about any of the points I made on Flash, I'll listen. Otherwise, you're just wasting time.
I've programmed in a lot of languages. I just learned Flash a few weeks ago because I needed to port an iPhone game to Flash. From a developer's perspective, programming in Flash is like programming with half a language that only has half a run-time library. That wouldn't be so bad if it was fun to program in like some of the more modern scripting languages, but it's not.
Regarding performance, I found that the only way to make Flash code perform well is to write spaghetti code. I had a collision detection routine running really slowly, and when I hacked together a profiler for it (which is not easy because the language has no high-precision timers), I discovered that the function call overhead in Flash is obscenely high. I had to get rid of all getter methods (i.e. make all my read-only member variables public), replace convenience functions like Math.abs() and Math.max() with if-then-else statements, and take my hit test function and copy+paste its contents everywhere I wanted to call it. (I didn't see any macro or inline features, and as much as I hate to copy+paste, the hit really was that bad.)
IMO, if Adobe can't fix the language, they should put a bullet in it. If they won't do either (and they've had years), then I have no problem with other companies attempting to put a bullet in it.
Use it for target practice. The first country to blow it up wins a prize.
Not if the drug companies decide it is worth spending tons of money to suppress real cures (which they will).
Ever watch a documentary on how the Hawaiian islands were found by Polynesians with no instruments, and before they learned how to write and do any kind of math? The could find islands that were hundreds of miles away by watching for certain cloud patterns in the sky. Compared to that, even sailors who were completely brain dead could find land sailing around in the Mediterranean. I mean, any direction you go from any point, and you'll find land.
The Internet has never been private. If a packet leaves your computer, it can be seen at several points on the way to its destination. However, in the early days, there were virtually no organizations that had the CPU or storage capacity to log and report on every packet going through those routers, every firewall session, every web server hit, and so on, unless they were targeting your IP for some specific reason. The organizations that may have had that much bandwidth available had other uses for it.
Given the advances in computer hardware, it is much easier for companies to log and report on every hit to their web server, every session through their firewall, etc. With how much faster networks have gotten, it's probably still not feasible to log every packet, but it is feasible to inspect packets to look for specific types of sessions, and to log packets from sessions of interest. I work at a company that makes a network appliance that does something along those lines, and it's pretty easy. We can even monitor your Skype traffic (not listen to your calls, just see who you're chatting with).
If you want privacy that badly, give up the Internet, your cell phone, your GPS, your credit cards, and so on. Technology has made monitoring too easy for organizations to resist, and some organizations have found uses for it they never dreamed of in the first place, and they will be very unwilling to give it up.
Good post, but IMO it's a shame you left this one out:
Ruby and/or Rails sucks because:
8) It doesn't use spacing to delineate code blocks
Ruby and/or Rails is awesome because:
8) It doesn't use spacing to delineate code blocks
I've been working 7 days a week for the past two years. This article is making Rockstar sound pretty good to me (unless the pay is lower ;-).
Well duh...
(I am honestly surprised that I haven't seen someone post that comment yet.)
It really depends on what kind of development they're doing. Speaking as an Enterprise Windows developer who has had to install clean OS's regularly (hurray for virtualization) and test products our with ActiveDirectory integration, I can say that sometimes development groups need their own domain controller to play with. In that case, give them their own domain and consider putting it on a network segment separate from the rest of the organization. Set up the routes and a domain trust relationship that allows them to get corporate email and access shared folders and printers, and you're all set.
Even if developers don't need their own sandbox to play in and don't know how to administer a domain controller, it may be a good idea to set it up that way for security reasons. Developers tend to be lax about in-house security, and it helps keep systems on the rest of the network from being able to access development files they have no business accessing. If they do any network testing, it also may keep them from killing your firewalls, servers, Internet bandwidth, etc. (that's one reason my group got moved to our own network segment with its own Internet connection ;-) If they do any security testing, they also may install malware on purpose from time to time (that's another reason my group got moved to our own network segment ;-).
If the LED's can handle additional current, what about a dimmer switch? If they can crank it up so it temporarily uses as many Watts as a normal bulb, it should generate the same amount of heat. Even if they can't get the power that high, higher brightness levels may be enough to be visible through the snow.
I was too old when that one came out, but either way "fun" is a relative term when it comes to games like that.
I made a math game for my son once that seemed cool to me. You're captain of the moon, which has several bases on it (the moon is a small sphere in the center of the screen in this game). Asteroid storms threaten your bases. The only way to stop them is to use a cannon to shoot rocks at them and deflect them away. The rocks are all the same size, but the asteroids aren't, so the amount of force you need to use when shooting is different for each asteroid (and each requires a multiplication to determine how much power). If you use too little, it slows the asteroid down (which gives you a bit more time to get the right answer). If you use too much, the asteroid breaks into two smaller asteroids, and you have two smaller problems to solve.
My son figured out how to cheat the game pretty quickly though. Each wave had a multiplication factor, so on wave 7, you're always solving for 7 * x. He would set the cannon to max power and blast all the big asteroids until they had shrunk down to 1, then he'd set the power to 7 and blast all the 1's. ;-)
Heh. Toss in plenty of delicate problems where a simple mistake could cause everyone to die (followed up by hours of corpse recovery to get your equipment back), and the old EQ fans would be right at home playing it. ;-)
After doing SimEarth, Maxis kicked around the idea of a SimMars. NASA was really excited about helping them (and helping build up PR on the space program), but Maxis killed the idea because they couldn't find a way to make a game about Mars fun without making it 100% fantasy. It's like trying to make a math game fun.
Advanced features do not automatically make a language great. That's like saying advanced graphics techniques automatically make a game great. Actually, I just noticed your handle is BadAnalogyGuy. Did you do that on purpose? ;-)
Anyway, JavaScript is a horrible language (almost as bad as VBScript) and it needs to be phased out. I'd rather have client-side PHP than JavaScript, and I hate PHP. Ruby or Python would be the best IMO. From a language purist's viewpoint Ruby is more elegant, but Python has been around longer so it has a larger following.
I doubt the article explained the true nature of the "bug" correctly. I work on 3D modeling and rendering on large scales (http://sponeil.net/), so I am acquainted with a number of types of precision problems. These developers are definitely working with 3D modeling and physics (and probably rendering for simulations). This means they're using 3D vectors and 4D matrices/quaternions, which accumulate precision errors surprisingly fast. The physics equations require approximations that introduce even larger errors, and the slower the processor, the lower the quality of approximations. A 0.1-second time step provides pitiful precision for physics calculations, and if they'd had a better processor, they would've taken advantage of it to take more samples. There's also the fact that the timer on the processor may be a tiny bit off, and that error will accumulate over time. Even if it the timer were perfect, they may need to multiply floats by the "current time". As that number gets larger, the result loses bits of precision during the multiply. There are any number of similar problems they could be running into (and this problem is probably a combination of more than one).
Of course all of these problems can be solved in any number of ways, but this is a complex piece of software, it sounds like the processor is extremely limited, changes to the math require large amounts of testing (very expensive tests that at some point involve firing real missiles), and given how late the project was, you can be sure they had management breathing down their necks trying to get them to rush it out the door. Of course there are plenty of poor programmers out there, and I'm sure that was a factor, but probably not the largest factor. It sounds like they knew about this problem and management decided it wasn't worth the testing effort to try to fix it. After all, they had a "reboot every hour or so" workaround, which I agree is ludicrous, but the farther a project slips, the more management will start to think that certain problems are acceptable.
As a programmer, I can confirm that these programmers screwed up, but I would bet money on the fact that the management forced them to. There's no way programmers working on physics software would choose a processor limited to 24-bit registers unless that was the only choice they were given, so that decision must have been forced upon them by their bosses. I'm also certain that the decision that it was "good enough" to ship was not made by the programmers. Here's an interesting quote:
From: http://www.corpwatch.org/article.php?id=11110
"As usual with the Pentagon, cost is no object. But the Patriot is very expensive system and it's getting costlier all the time. Raytheon and Lockheed originally promised to deliver the new Patriot system for $3.7 billion dollars. Now the cost has soared to $7.8 billion. Each Patriot missile unit costs about $170 million. In the first Gulf War, an average of four missiles were launched against a single incoming Scud."
Even if that's grossly inaccurate, they saved a few bucks per multi-million dollar unit. That's like being penny wise but several million pounds foolish. While I agree it's not that hard to work around the 24-bit limitation, the decision to use such a limited processor was probably a major contributing factor to the schedule slips and cost overruns. Any time a project slips that badly, management will step in and force them to rush it out the door before it's ready. My bet is that the developers knew the problem was there, but they didn't have time to even look at it because they had bigger fish to fry when they were trying to get it out the door.
I'm still hoping one of these private companies will give the paraffin (candle wax) rockets a try:
http://science.nasa.gov/headlines/y2003/28jan_envirorocket.htm
http://www.nasa.gov/centers/ames/news/releases/2003/03images/paraffin/paraffin.html
I assume these rockets still still have some serious engineering kinks to be worked out, but it would be incredibly slick if they could make it work.
I'd go crazy a lot more quickly if they gave me Internet access in that scenario. Imagine having to wait 20 minutes after each click for results to show up in your web browser. Even worse, images embedded in a page would take an additional 20 minutes to show up because your browser won't know what image files to ask for until it receives the page with the embedded links. It would be like Chinese water torture, always wondering when the next page was going to hit. If I didn't lose my mind sooner, I'd lose it the first time I got a 404 message. It would definitely be better to not have Internet access at all.
It may not be too bad if NASA creates a customized browser and proxy server so that when you visit a new page, the proxy server crawls every link on that page and starts streaming them to the ship before you ask for them, and then crawls the links on those pages recursively using a breadth-first search pattern until the browser tells it which link you picked (at which point it picks a new root for the tree). The customized browser would continually listen for new files to be sent and cache them on the local drive. Even with relatively low bandwidth, the browsing experience should be fairly responsive as long as you keep following a chain of links, don't click too fast, and don't hit a page with like a million links. If you do something silly like try to fill out a web form (i.e. type a search term into Google), type a web site name into the address bar, or visit a dynamic web 2.0 site with a bunch of Ajax calls, it's back to the Chinese water torture.
When I say elevated, I don't mean like "aerobic workout" or "stressed out" kind of elevated. Your respiration and heart rate slow down when sitting, but for work it's better to keep it closer to a normal walking rate, IMO. Caffeine is not a very healthy way to do it, but it works for millions of people in a pinch.
Most people can't consciously control their breathing for hours while trying to put 100% of their concentration on coding, although I suppose it would be good to add:
7) Stop to take a few deep breaths every now and then.
What you need is focus. I have a hard time focusing if I'm even a little sleepy. When I was ten years younger I never got sleepy and I never had trouble staying focused, but now that I'm older and have kids sapping my energy during what used to be my "down" time, I have to struggle to keep my focus at work. Here are some tips that might help:
1) Go to bed early the night before. I know you're not used to it, but try it at least for a week.
2) Elevate your pulse to keep plenty of oxygen flowing to the brain. Exercising in the morning helps, but won't keep your pulse up all day, so take a few short breaks during the day to walk around a bit.
3) Coffee if you can stand it, Mountain Dew if you can't.
4) Play background music. Try to find music that's fast enough to keep the pulse elevated a little, but play it quietly enough that it won't break your concentration. I often play music so quietly that I can barely hear it when programming. Avoid radio stations because the break in flow during commercials will break your focus.
5) When writing something new (a document, an article, a program), getting started is often downright painful. Once you get past the first paragraph/section/class, things flow smoothly for a while. Every now and then you get stuck again, and when you're stuck, you usually just have to force your way through it. Sometimes it's better to skip the part you're stuck on and work on something else for a while, but when you're just getting started, you usually have to force your way through it.
6) Create a set of really small tasks with short deadlines. If your boss isn't putting pressure on you to get something done by the end of the week, put a little pressure on yourself. Zero stress often equates to zero motivation to get things done quickly. It is far better to stress yourself out a little than to be fired later because you worked for months with nothing to show for it. ;-)
Great! Let's use the scientific method to test this hypothesis. Oh wait, nevermind.
Sorry, but it's hard not to be cynical about astrophysics. Dark matter sounds like something invented by a writer for a Japanese cartoon series, and the scientific explanation sounds about as likely to be true.
Or maybe they just did a study of what people search for the most on the Internet.
My sister was injured in an accident while sitting at a red light. Someone slammed into her from behind doing about 60. Trust me, you're just as much of a sitting duck in a car, and there are a lot more idiots and drunk drivers on the road than in the air. (Yes, I've read about the drunk pilots, but you're much more likely to die from some kind of mechanical failure in a plane than from pilot error, no matter how drunk he is.) Of course, we'll all be completely screwed if flying cars become a reality.
Probably the only good argument in favor of driving is that plane accidents are almost always fatal. On average, you'd probably be better off in a motorcycle accident than a plane accident, and I sure as hell would not want to be in a motorcycle accident.
Your post is off-topic relative to the point I was making (and to the point I was refuting). That one line of Ruby code by itself would not need a comment explaining WHY. It would be part of a small function or code block that would need a comment explaining WHY. That comment would not be specific to this one line of code, which is why your argument seems off-topic to me.
My point was that if you needed 10 lines of code (perhaps in C) to make a simple check like that, you would need an additional comment to explain WHAT those lines were doing. If you needed 100 (perhaps in assembler), you would need comments for each logical block you broke it up into, and then another to encapsulate the whole thing. The larger a block of code must be to do something, the more likely you are to need additional comments just to explain WHAT the code is doing. It goes without saying that those extra lines of code make it easier for bugs to slip in, and make the program harder to maintain. If the language you're using requires such verbosity everywhere, then it becomes a more expensive program to write and maintain (sometimes it is necessary, but sometimes it is not).
The argument that more verbose code is self-documenting and thus easier to read is complete BS. It would also be complete BS to say that shorter is always better. A lot of people have written extremely short Perl programs that they themselves had a hard time reading a short time later. For short code to be "better", it has to be clean enough to be easy for any programmer to figure out quickly. However, code cleanliness and readability was not one of the inputs for these graphs. That is why Perl looks better than both Python and Ruby on these graphs despite the fact that most programmers can't stand Perl (and for valid reasons).