Yeah, I started to argue that point as well, but my reply was already getting long enough without chasing down that rabbit trail. FWIW, I'm not especially good at programming in C, although the C-like language that the Arduino uses is pretty brain-dead simple.
Ummm...your example isn't exactly far fetched. Most places I've worked would not allow employees to use POVs to drive on company business. It wasn't a Lincoln Town Car, it was a Dodge pickup in one case and whatever fleet minivan was available in another, but the principle applies: you're on company time, you're driving a company owned, company insured vehicle.
Yes, I have to deal with other human beings. Most of the time, that is not only not a problem, it's actually enjoyable. However, the rest of the time...
Let me tell you a story. Once upon a time, an IT department had surplus equipment that they were disposing of. An RF tech working for the company asked if he could take one of the surplus laptops home, and IT told him yes, so long as he understood that the hard drive had been removed and destroyed (per company policy), and IT would provide absolutely no support for this laptop, since it was well out of warranty and would become his personal -- rather than work -- device. The RF tech acknowledged that he understood and was agreeable to these conditions...until he got the laptop home. Then he began pestering IT for a hard drive, just to verify that it was working. After that had been refused (numerous times), he began pestering IT for a memory upgrade for the laptop, which was also refused, also numerous times. In fact, at one point, the RF tech followed the desktop support guy down to the lunch room during the IT guy's lunch break, repeating his request for memory over and over and over like a spoiled two year old in the candy aisle at WallMart, until, fed up, the IT guy finally got HR involved. True story, I kid you not, and no, I was not the desktop support guy.
You may think you're being clever by sarcastically commenting how IT might actually have to learn to deal with human beings. However, I maintain that rather than being whiny, outcasts devoid of social skills, actually IT often displays exceptional restraint, WELL beyond the call of duty, by simply not smacking the snot out of an ignoramus who sincerely deserves it.
Just so long as the CxO's provide IT with the budget and staff to implement the application and network changes to support all the latest toys, that's fine. In my world, however, that's typically not the case.
For some reason IT folks think that all us iPhone toting folks are demanding that they support my iPhone. I don't expect you to support it, and most others don't either...It'd be nice if you could spend a few minutes helping me to figure out how to make my email work on the thing...
Ummm...make up your mind. Do you expect me to support your device, or can you figure it out yourself?
I don't expect you do this for every crazy piece of hardware out there...
So if someone has a different brand, screw them, but for you, on your chosen platform, I should be able to help you set up the services you need? You do realize that this attitude is common to every other user on the network, right? Which means, yeah, actually I do have to do this for every crazy piece of hardware out there.
Look, here's the deal...even if I never, ever have to touch your iPhone because you really CAN set up every configuration option blindfolded, in the dark, with one hand tied behind your back, I'm still responsible for keeping corporate data secure. That means, it's my butt on the line when you leave your iPhone at the bar and the confidential data you weren't supposed to have on there in the first place is now unaccounted for. It's my butt on the line when your Windows XP Home laptop -- which is still running the stock anti-virus and a/v database that Best Buy installed when you bought it four years ago -- introduces a virus into the network, infecting 37% of the other "Bring-Your-Own" devices (although, thank God, the servers are all patched and running current A/V, so they are safe).
Personally, I'd like to see the bring-your-own-device movement take off, and I can see several ways in which it can SANELY be implemented. In fact, we are starting to move in that direction where I work. But sorry, until I can honestly say that I'm reasonably certain that I have identified the likely risks of allowing users to bring their own devices, and I have taken all of the reasonable precautions to bring those risks to acceptable levels, the policy is "not on my network". I understand that may piss off some users. I can live with that. I can't, however, live with implementing a half-4$$ed BYOD policy, thus knowingly, willfully and intentionally putting my company's data at unnecessary risk.
I've had good luck with the Samsung drives as well. While OP is catching a lot of flack for his claim of a 95% failure rate, I have to say, I recently had a rather large (~15-20TB) RAID array in a server that had an extremely high number of hard drive failures. It wasn't 95%, but I probably replaced at least a third of the drives in that array...maybe more. Fortunately, the server manufacturer replaced them under warranty, and when I finally asked if there were any known issues with that make and model of drive, they admitted that there was indeed a problem with the firmware. IIRC, they were Western Digital SATA drives, but it's been over a year now since I had the last failure so I could be mistaken.
Just to be clear, since after re-reading my earlier comment, I see how it could be misunderstood -- I think you guys can do it. I was responding to the naysayers' claims that a 1-month delay is proof you can't do it. The way I see it, your commitment to providing a great product at a phenomenal price might mean I have to have a little more patience before I get my hands on one. That's understandable, and IMHO, it will be totally worth the wait.
IMHO, yes, and you gave the use case yourself: "Arduinos are programmed in a scaled-down version of C. C is fine for simple things, but gets more difficult when dealing with complex algorithms." As I've said elsewhere, I've already got two Arduino Unos, but I'd still like a Raspberry Pi for a couple of more complex projects that would be difficult to implement on the Arduino. OTOH, a Raspberry Pi would be overkill for most of the things I've already done with an Arduino. Actually, I'm not even sure how you would connect a Raspberry Pi to something like an IR sensor, a BMP085 temperature/air pressure sensor, or a string of LEDs. Maybe I missed it, but are there even raw CMOS or TTL level outputs on the Raspberry Pi without having to break out USB or video outputs?
even with multiple arduinos, there's only so much you can do.
Yep. I've got one Arduino, with another currently en route, but I definitely want a Raspberry Pi as well. The Arduino is great for certain things -- for example, the one I have at home just became the beginnings of a home weather station this weekend -- and I plan to use the second one for miscellaneous hardware hacking and eventually for use on some model rocketry/RC experiments. However, the Pi seems to be better suited for some of the rocketry/RC experiments I would like to try, like running a USB web cam across a WiFi link in flight. That might be possible on an Arduino using an XBee and one of the various camera shields, but frankly, it sounds like a lot more work than it's worth on an Arduino.
To put this in terms of the requisite/. car analogy, sure...it's possible to take a pile of raw materials *only* and build a custom car, but realistically, are you really going to turn raw rubber into your own tires, or are you just going to go to the local tire shop and buy a set of Goodyears (or Pirelli, or...)?
"You can have it now. You can have it cheap. You can have it good. Pick any two."
If the Raspberry Pi can actually meet the design specs at the target price (or even anywhere near the target price), waiting another month or two for them to become available will definitely be worth it. Best of luck to you guys (and gals) at the Foundation. I, for one, will be eagerly awaiting the announcement that they are available for sale.
Thanks a lot, Mr. Coward. I just laughed coffee all over my keyboard at work, and now I have to explain to my boss how that happened, and why I need a new keyboard! (Seriously, well played, sir. Well played, indeed!)
I'd fly one in a heartbeat, assuming I had the skill, of course...I'm (so far) strictly a fixed-wing pilot:-)
First, I seriously doubt one of those blades would even remotely decapitate the pilot. As I've already discussed in the comments to this article, I think the likelihood of a blade breaking is very, very remote. Even if a blade were to fail, did you see the size of those blades? I doubt they would have the mass to penetrate deeply even if a blade broke and even if it were to fail in such a way as to fly towards the pilot. Second, yeah, an unbalanced rotor is a pretty big deal, but I think it would be trivial to design a circuit to detect excessive vibration in the motor and shut off power to that one motor if such a condition were to occur.
I'd be more concerned about a complete loss of power, for example, due to battery failure. I imagine this particular device doesn't do auto-rotation very well, and it's about as aerodynamic as a brick, so I suspect it doesn't glide any better. Consequently, I'd feel a lot better with a ballistic recovery chute on board, although that can be problematic to engineer on rotary-wing aircraft. Unfortunately, I didn't see one on TFA.
First, let me say that I agree that the pilot should probably be under the blades, although I'm more concerned about stability. Lots of people have commented on the possibility of broken propellers, and yes, that is something to consider. However, I'd say it's less of a factor than most people on/. seem to think. I've got somewhere between 900 and 1000 hours of pilot in command time* in about 20 years and guess how many in-flight propeller failures I've seen in that time?
None.
Zero.
Not. One. Single. Failure.
Even the propeller that a friend of mine dragged along the runway during a botched landing bent, but didn't break. For the record, she recognized that something was wrong, and added power to "go around", and flew another approach and landing after curling up the last four inches of the propeller blade, but it didn't fail. The ONLY broken propeller I've ever seen was on my "amateur-built, experimental" airplane when a windstorm overnight flipped the airplane onto its tail (it's a pusher airplane, not a tractor like most Cessnas or Pipers), breaking the wooden prop. But that wasn't an in-flight failure; it happened at night, while the aircraft was unattended and *definitely* not running.
*admittedly, in airplanes, not helicopters and most definitely not multicopters. I'd be surprised if that made any difference, however.
I almost expanded my argument, anticipating a counter-argument along these lines. However, since I have a tendency to wax pedantic, I thought I'd leave the argument where I did. Since you bit, though...:)
"Coercion" as I am using the term, and "coercion" as you are using the term aren't quite the same thing. Yes, where there is a monopoly on a product or service, there is an element of coercion in that you can either do business with the monopoly or go without. In some cases, "going without" may not be much of a choice. For example, at my old house, there was exactly one electric utility to choose from. Can you live without electricity? Well...people did so for thousands of years. Can you live without electricity in Anchorage, Alaska, in a residential neighborhood on a lot so small that you can't store enough firewood to last all winter? Not so much. Nevertheless, there is still a choice: you can do business with the electric utility or not. The government will not come arrest you if you refuse to buy the electric utility's services. However, if I decide not to pay my taxes (i.e., "buy" the government's "services"), I will be arrested, and my possessions will be auctioned off to pay my back taxes. Clearly, one of these scenarios involves a much greater degree of coercion than the other. You could argue that, as long as I am a citizen of the United States, I am partaking of the government's services, and therefore, failure to pay taxes would be rather like getting an account with the electric utility, but then refusing to pay the electric bill when it came due. That's a valid point, but even that would be a civil matter rather than a criminal one, whereas failing to pay your taxes is, in fact, a crime.
Other than that, yes, I pretty much agree with you, and I have to admit, I'm a little surprised that you felt the need to describe industry and government in so much detail, since basically my point above was that *every* organization made up of people will tend to display the same patterns of greed, selfishness and short-shortsightedness GGP was identifying in the free market. I was merely pointing out that those problems are not unique to corporations; I wasn't saying that they *only* exist in government.
Agreed, and that's why I'm religious with whitespace whether I'm writing Perl, Python, HTML, JavaScript, Bash or any other scripting/programming/formatting language. However, I've seen Python break when a programmer pulls it into an editor that automatically converts tabs to spaces (or vice versa) while trying to maintain code that someone (else?) originally wrote in a different editor because now your script is no longer properly indented...even though it looks identical to the human eye (because most editors that I've used don't visually differentiate between tabs and spaces).
Ummm...I've been using Perl for close to ten years now in production environments and I both call functions with an ampersand (to clearly delineate that this a function defined with the program itself, as opposed to a built-in Perl function) and use C-style loops. While calling functions with an ampersand may not have any obvious advantages -- it's just the way I learned the language, and I've never had a compelling reason to stop -- I'd argue that C-style loops are a good idea. They are clear and obvious to programmers with a background in C/C++, Java, JavaScript and probably many other languages. for($a...$b)...not so much.
Comments are supposed to tell you what's going on. In fact, Perl has a built-in self-documentation system that makes it a breeze to document and find the documentation you want.
Very true.
You don't maintain perl code by trying to understand it and tweak it. You maintain it by replacing lines or blocks of code with better written code. And if you're not man enough to write better code, wtf are you doing trying to maintain it in the first place?
But this...Yeah, I think you may have been smoking those "roll-your-own" cigarettes again. That's either some pretty potent chemicals you've been ingesting there, or you don't really have any experience maintaining code in a production environment.
First, if you don't understand the code you are working on, how , exactly, are you supposed to know what blocks or lines of code you need to replace? Second, if the software requirements have changed (IME, the most common reason to rewrite working code), then it's not a matter of replacing the other guy's code with "better written code". It's a matter of updating the software to reflect current needs. The old code may have been *perfect* but if it no longer meets the customers' requirements, it needs to be rewritten. Third, "...if you're not man enough to write better code..." -- WTF is that?!?! Did you not know that the person widely credited with being the first programmer was a woman, as was the inventor of the compiler? What chauvinistic B.S.! If it weren't for your low/. ID, I'd guess you were a 13 year-old programmer wannabee full of piss and wind, but obviously you've been hanging out on-line long enough that you should have *some* experience in the real world. I'm just surprised that in that time, you don't have a better grasp on how the IT world really operates <shrug>
And yes, its true that reading someone else's code is usually a bad experience and you probably end up writing the program yourself from scratch
Yep, Perl's "forgiving syntax" is a double-edged sword. It allows you to generate a script very quickly to solve the problem you are currently working on, but it also makes it very difficult to maintain someone else's code. Because there are frequently many ways to accomplish the same task in Perl, the subset of Perl syntax and commands that *you* know and use on a daily basis may be quite different than the subset of Perl that *I* know and use on a daily basis. That means when I try to maintain your code, I will spend an inordinate amount of time trying to figure out just exactly what you are doing because your code looks like an entirely different language to me, and vice versa (BTDT, more than once).
I still think that Perl is not an inherently difficult language in which to program, but the very flexibility that draws people to the language does present some barriers to writing maintainable code. Fortunately, those working together for long enough in a Perl shop will learn the way their coworkers do things, which leads to an expanded understanding of the language, and consequently, less trouble understanding and maintaining other people's code.
Hey, hey, hey...that's not fair. Just because some people can't write a readable programs in Perl doesn't mean it can't be done. I mean seriously, what part of...:
#!/usr/bin/perl
not exp log srand xor s qq qx xor
s x x length uc ord and print chr
ord for qw q join use sub tied qx
xor eval xor print qq q q xor int
eval lc q m cos and print chr ord
for qw y abs ne open tied hex exp
ref y m xor scalar srand print qq
q q xor int eval lc qq y sqrt cos
and print chr ord for qw x printf
each return local x y or print qq
s s and eval q s undef or oct xor
time xor ref print chr int ord lc
foreach qw y hex alarm chdir kill
exec return y s gt sin sort split
...do you NOT understand?!?!
FWIW, and all joking aside, I frequently modify Perl scripts that I've written before -- sometimes including scripts that I hadn't touched in years. Even though Perl has a reputation for being difficult to read, I honestly believe that has more to do with programmer style than the language itself. You certainly can write programs that are difficult to maintain, but I'd argue that's not inherent in the language. Perl just allows you to write some rather obfuscated code if you (for some reason) choose to do so. Properly commenting your code will go a long ways towards ensuring readability in Perl...or any other language.
Cool, but I'd be curious how the languages fared in other metrics as well. For example:
Errors per line of code at initial run/compile, as appropriate;
Time to debug;
Number of times run/compiled until the program has been debugged;
Time to modify when the software requirements change; and
Number of new errors introduced when the software requirements changed.
I've used Python, and Perl is my "goto" language (sorry, bad pun) so I tend to suspect they would do better than C/C++ in these areas too, but it would be nice to have a study supporting or even refuting that theory.
Among the major commercial TV news channels, only CBS is privately held by the Redstones. ABC, NBC, Fox, and CNN are all publicly traded on NYSE or NASDAQ.
Okay, there was some ambiguity in the terms I used. I meant "private" as contrasted against "government", which is a terminology the government itself uses. For example, the Federal Aviation Administration contrasts private aircraft (aircraft owned by individuals or corporations) with public aircraft (aircraft owned by the government). By this definition, even "publicly traded" companies would still be "private".
Exclusive rights in radio spectrum are government interference.
Point taken. However CNN, for example, is a cable/satellite *only* channel. Does the principle still apply?
After five blogs are available to a city, would the federal government step in and say "nope, spectrum is too crowded, no new blogs"? If not, bad analogy.
See the preceding comment. Nevertheless, I will concede that when government allocates radio spectrum, you cannot completely eliminate government interference. Ideally, however, I would like to see that interference limited as much as possible.
Believe it or not, I ended up working on exactly such a computer for someone recently.
We used to have a saying at my previous job: "Perception IS reality." Whether or not people *need* to upgrade so as to fix security vulnerabilities, people *perceive* that their computer/phone/electronic gizmos are working as-is, and therefore they don't "need" to upgrade, so they don't. You and I might know better, but 99%* of consumers don't, especially when upgrading entails the risk of loss of data...and I *did* lose data when I updated my Hero from 2.0 to 2.1, despite backing everything up with My Backup Pro (IIRC). Apparently, the database that apps use isn't included in the backup, sigh.
*Disclaimer: Yes, I pulled that number out of thin air; I did not actually conduct a survey to get the exact number. You get my point, anyway.
Slashdot Mirror
Yeah, I started to argue that point as well, but my reply was already getting long enough without chasing down that rabbit trail. FWIW, I'm not especially good at programming in C, although the C-like language that the Arduino uses is pretty brain-dead simple.
Ummm...your example isn't exactly far fetched. Most places I've worked would not allow employees to use POVs to drive on company business. It wasn't a Lincoln Town Car, it was a Dodge pickup in one case and whatever fleet minivan was available in another, but the principle applies: you're on company time, you're driving a company owned, company insured vehicle.
Yes, I have to deal with other human beings. Most of the time, that is not only not a problem, it's actually enjoyable. However, the rest of the time...
Let me tell you a story. Once upon a time, an IT department had surplus equipment that they were disposing of. An RF tech working for the company asked if he could take one of the surplus laptops home, and IT told him yes, so long as he understood that the hard drive had been removed and destroyed (per company policy), and IT would provide absolutely no support for this laptop, since it was well out of warranty and would become his personal -- rather than work -- device. The RF tech acknowledged that he understood and was agreeable to these conditions...until he got the laptop home. Then he began pestering IT for a hard drive, just to verify that it was working. After that had been refused (numerous times), he began pestering IT for a memory upgrade for the laptop, which was also refused, also numerous times. In fact, at one point, the RF tech followed the desktop support guy down to the lunch room during the IT guy's lunch break, repeating his request for memory over and over and over like a spoiled two year old in the candy aisle at WallMart, until, fed up, the IT guy finally got HR involved. True story, I kid you not, and no, I was not the desktop support guy.
You may think you're being clever by sarcastically commenting how IT might actually have to learn to deal with human beings. However, I maintain that rather than being whiny, outcasts devoid of social skills, actually IT often displays exceptional restraint, WELL beyond the call of duty, by simply not smacking the snot out of an ignoramus who sincerely deserves it.
Just so long as the CxO's provide IT with the budget and staff to implement the application and network changes to support all the latest toys, that's fine. In my world, however, that's typically not the case.
For some reason IT folks think that all us iPhone toting folks are demanding that they support my iPhone. I don't expect you to support it, and most others don't either...It'd be nice if you could spend a few minutes helping me to figure out how to make my email work on the thing...
Ummm...make up your mind. Do you expect me to support your device, or can you figure it out yourself?
I don't expect you do this for every crazy piece of hardware out there...
So if someone has a different brand, screw them, but for you, on your chosen platform, I should be able to help you set up the services you need? You do realize that this attitude is common to every other user on the network, right? Which means, yeah, actually I do have to do this for every crazy piece of hardware out there.
Look, here's the deal...even if I never, ever have to touch your iPhone because you really CAN set up every configuration option blindfolded, in the dark, with one hand tied behind your back, I'm still responsible for keeping corporate data secure. That means, it's my butt on the line when you leave your iPhone at the bar and the confidential data you weren't supposed to have on there in the first place is now unaccounted for. It's my butt on the line when your Windows XP Home laptop -- which is still running the stock anti-virus and a/v database that Best Buy installed when you bought it four years ago -- introduces a virus into the network, infecting 37% of the other "Bring-Your-Own" devices (although, thank God, the servers are all patched and running current A/V, so they are safe).
Personally, I'd like to see the bring-your-own-device movement take off, and I can see several ways in which it can SANELY be implemented. In fact, we are starting to move in that direction where I work. But sorry, until I can honestly say that I'm reasonably certain that I have identified the likely risks of allowing users to bring their own devices, and I have taken all of the reasonable precautions to bring those risks to acceptable levels, the policy is "not on my network". I understand that may piss off some users. I can live with that. I can't, however, live with implementing a half-4$$ed BYOD policy, thus knowingly, willfully and intentionally putting my company's data at unnecessary risk.
I've had good luck with the Samsung drives as well. While OP is catching a lot of flack for his claim of a 95% failure rate, I have to say, I recently had a rather large (~15-20TB) RAID array in a server that had an extremely high number of hard drive failures. It wasn't 95%, but I probably replaced at least a third of the drives in that array...maybe more. Fortunately, the server manufacturer replaced them under warranty, and when I finally asked if there were any known issues with that make and model of drive, they admitted that there was indeed a problem with the firmware. IIRC, they were Western Digital SATA drives, but it's been over a year now since I had the last failure so I could be mistaken.
Like I said, sign me up for one :)
Just to be clear, since after re-reading my earlier comment, I see how it could be misunderstood -- I think you guys can do it. I was responding to the naysayers' claims that a 1-month delay is proof you can't do it. The way I see it, your commitment to providing a great product at a phenomenal price might mean I have to have a little more patience before I get my hands on one. That's understandable, and IMHO, it will be totally worth the wait.
IMHO, yes, and you gave the use case yourself: "Arduinos are programmed in a scaled-down version of C. C is fine for simple things, but gets more difficult when dealing with complex algorithms." As I've said elsewhere, I've already got two Arduino Unos, but I'd still like a Raspberry Pi for a couple of more complex projects that would be difficult to implement on the Arduino. OTOH, a Raspberry Pi would be overkill for most of the things I've already done with an Arduino. Actually, I'm not even sure how you would connect a Raspberry Pi to something like an IR sensor, a BMP085 temperature/air pressure sensor, or a string of LEDs. Maybe I missed it, but are there even raw CMOS or TTL level outputs on the Raspberry Pi without having to break out USB or video outputs?
even with multiple arduinos, there's only so much you can do.
Yep. I've got one Arduino, with another currently en route, but I definitely want a Raspberry Pi as well. The Arduino is great for certain things -- for example, the one I have at home just became the beginnings of a home weather station this weekend -- and I plan to use the second one for miscellaneous hardware hacking and eventually for use on some model rocketry/RC experiments. However, the Pi seems to be better suited for some of the rocketry/RC experiments I would like to try, like running a USB web cam across a WiFi link in flight. That might be possible on an Arduino using an XBee and one of the various camera shields, but frankly, it sounds like a lot more work than it's worth on an Arduino.
/. car analogy, sure...it's possible to take a pile of raw materials *only* and build a custom car, but realistically, are you really going to turn raw rubber into your own tires, or are you just going to go to the local tire shop and buy a set of Goodyears (or Pirelli, or...)?
To put this in terms of the requisite
"You can have it now. You can have it cheap. You can have it good. Pick any two."
If the Raspberry Pi can actually meet the design specs at the target price (or even anywhere near the target price), waiting another month or two for them to become available will definitely be worth it. Best of luck to you guys (and gals) at the Foundation. I, for one, will be eagerly awaiting the announcement that they are available for sale.
Thanks a lot, Mr. Coward. I just laughed coffee all over my keyboard at work, and now I have to explain to my boss how that happened, and why I need a new keyboard! (Seriously, well played, sir. Well played, indeed!)
Ahh...I didn't watch the video since I'm at work ;)
I'd fly one in a heartbeat, assuming I had the skill, of course...I'm (so far) strictly a fixed-wing pilot :-)
First, I seriously doubt one of those blades would even remotely decapitate the pilot. As I've already discussed in the comments to this article, I think the likelihood of a blade breaking is very, very remote. Even if a blade were to fail, did you see the size of those blades? I doubt they would have the mass to penetrate deeply even if a blade broke and even if it were to fail in such a way as to fly towards the pilot. Second, yeah, an unbalanced rotor is a pretty big deal, but I think it would be trivial to design a circuit to detect excessive vibration in the motor and shut off power to that one motor if such a condition were to occur.
I'd be more concerned about a complete loss of power, for example, due to battery failure. I imagine this particular device doesn't do auto-rotation very well, and it's about as aerodynamic as a brick, so I suspect it doesn't glide any better. Consequently, I'd feel a lot better with a ballistic recovery chute on board, although that can be problematic to engineer on rotary-wing aircraft. Unfortunately, I didn't see one on TFA.
From TFA: "A better flight time from on average 20-30 minutes is something we wish to improve." [emphasis mine]
First, let me say that I agree that the pilot should probably be under the blades, although I'm more concerned about stability. Lots of people have commented on the possibility of broken propellers, and yes, that is something to consider. However, I'd say it's less of a factor than most people on /. seem to think. I've got somewhere between 900 and 1000 hours of pilot in command time* in about 20 years and guess how many in-flight propeller failures I've seen in that time?
None.
Zero.
Not. One. Single. Failure.
Even the propeller that a friend of mine dragged along the runway during a botched landing bent, but didn't break. For the record, she recognized that something was wrong, and added power to "go around", and flew another approach and landing after curling up the last four inches of the propeller blade, but it didn't fail. The ONLY broken propeller I've ever seen was on my "amateur-built, experimental" airplane when a windstorm overnight flipped the airplane onto its tail (it's a pusher airplane, not a tractor like most Cessnas or Pipers), breaking the wooden prop. But that wasn't an in-flight failure; it happened at night, while the aircraft was unattended and *definitely* not running.
*admittedly, in airplanes, not helicopters and most definitely not multicopters. I'd be surprised if that made any difference, however.
I almost expanded my argument, anticipating a counter-argument along these lines. However, since I have a tendency to wax pedantic, I thought I'd leave the argument where I did. Since you bit, though... :)
"Coercion" as I am using the term, and "coercion" as you are using the term aren't quite the same thing. Yes, where there is a monopoly on a product or service, there is an element of coercion in that you can either do business with the monopoly or go without. In some cases, "going without" may not be much of a choice. For example, at my old house, there was exactly one electric utility to choose from. Can you live without electricity? Well...people did so for thousands of years. Can you live without electricity in Anchorage, Alaska, in a residential neighborhood on a lot so small that you can't store enough firewood to last all winter? Not so much. Nevertheless, there is still a choice: you can do business with the electric utility or not. The government will not come arrest you if you refuse to buy the electric utility's services. However, if I decide not to pay my taxes (i.e., "buy" the government's "services"), I will be arrested, and my possessions will be auctioned off to pay my back taxes. Clearly, one of these scenarios involves a much greater degree of coercion than the other. You could argue that, as long as I am a citizen of the United States, I am partaking of the government's services, and therefore, failure to pay taxes would be rather like getting an account with the electric utility, but then refusing to pay the electric bill when it came due. That's a valid point, but even that would be a civil matter rather than a criminal one, whereas failing to pay your taxes is, in fact, a crime.
Other than that, yes, I pretty much agree with you, and I have to admit, I'm a little surprised that you felt the need to describe industry and government in so much detail, since basically my point above was that *every* organization made up of people will tend to display the same patterns of greed, selfishness and short-shortsightedness GGP was identifying in the free market. I was merely pointing out that those problems are not unique to corporations; I wasn't saying that they *only* exist in government.
Agreed, and that's why I'm religious with whitespace whether I'm writing Perl, Python, HTML, JavaScript, Bash or any other scripting/programming/formatting language. However, I've seen Python break when a programmer pulls it into an editor that automatically converts tabs to spaces (or vice versa) while trying to maintain code that someone (else?) originally wrote in a different editor because now your script is no longer properly indented...even though it looks identical to the human eye (because most editors that I've used don't visually differentiate between tabs and spaces).
Ummm...I've been using Perl for close to ten years now in production environments and I both call functions with an ampersand (to clearly delineate that this a function defined with the program itself, as opposed to a built-in Perl function) and use C-style loops. While calling functions with an ampersand may not have any obvious advantages -- it's just the way I learned the language, and I've never had a compelling reason to stop -- I'd argue that C-style loops are a good idea. They are clear and obvious to programmers with a background in C/C++, Java, JavaScript and probably many other languages. for($a...$b)...not so much.
Comments are supposed to tell you what's going on. In fact, Perl has a built-in self-documentation system that makes it a breeze to document and find the documentation you want.
Very true.
You don't maintain perl code by trying to understand it and tweak it. You maintain it by replacing lines or blocks of code with better written code. And if you're not man enough to write better code, wtf are you doing trying to maintain it in the first place?
But this...Yeah, I think you may have been smoking those "roll-your-own" cigarettes again. That's either some pretty potent chemicals you've been ingesting there, or you don't really have any experience maintaining code in a production environment.
/. ID, I'd guess you were a 13 year-old programmer wannabee full of piss and wind, but obviously you've been hanging out on-line long enough that you should have *some* experience in the real world. I'm just surprised that in that time, you don't have a better grasp on how the IT world really operates <shrug>
First, if you don't understand the code you are working on, how , exactly, are you supposed to know what blocks or lines of code you need to replace? Second, if the software requirements have changed (IME, the most common reason to rewrite working code), then it's not a matter of replacing the other guy's code with "better written code". It's a matter of updating the software to reflect current needs. The old code may have been *perfect* but if it no longer meets the customers' requirements, it needs to be rewritten. Third, "...if you're not man enough to write better code..." -- WTF is that?!?! Did you not know that the person widely credited with being the first programmer was a woman, as was the inventor of the compiler? What chauvinistic B.S.! If it weren't for your low
And yes, its true that reading someone else's code is usually a bad experience and you probably end up writing the program yourself from scratch
Yep, Perl's "forgiving syntax" is a double-edged sword. It allows you to generate a script very quickly to solve the problem you are currently working on, but it also makes it very difficult to maintain someone else's code. Because there are frequently many ways to accomplish the same task in Perl, the subset of Perl syntax and commands that *you* know and use on a daily basis may be quite different than the subset of Perl that *I* know and use on a daily basis. That means when I try to maintain your code, I will spend an inordinate amount of time trying to figure out just exactly what you are doing because your code looks like an entirely different language to me, and vice versa (BTDT, more than once).
I still think that Perl is not an inherently difficult language in which to program, but the very flexibility that draws people to the language does present some barriers to writing maintainable code. Fortunately, those working together for long enough in a Perl shop will learn the way their coworkers do things, which leads to an expanded understanding of the language, and consequently, less trouble understanding and maintaining other people's code.
Hey, hey, hey...that's not fair. Just because some people can't write a readable programs in Perl doesn't mean it can't be done. I mean seriously, what part of...:
...do you NOT understand?!?!
#!/usr/bin/perl
not exp log srand xor s qq qx xor
s x x length uc ord and print chr
ord for qw q join use sub tied qx
xor eval xor print qq q q xor int
eval lc q m cos and print chr ord
for qw y abs ne open tied hex exp
ref y m xor scalar srand print qq
q q xor int eval lc qq y sqrt cos
and print chr ord for qw x printf
each return local x y or print qq
s s and eval q s undef or oct xor
time xor ref print chr int ord lc
foreach qw y hex alarm chdir kill
exec return y s gt sin sort split
FWIW, and all joking aside, I frequently modify Perl scripts that I've written before -- sometimes including scripts that I hadn't touched in years. Even though Perl has a reputation for being difficult to read, I honestly believe that has more to do with programmer style than the language itself. You certainly can write programs that are difficult to maintain, but I'd argue that's not inherent in the language. Perl just allows you to write some rather obfuscated code if you (for some reason) choose to do so. Properly commenting your code will go a long ways towards ensuring readability in Perl...or any other language.
I've used Python, and Perl is my "goto" language (sorry, bad pun) so I tend to suspect they would do better than C/C++ in these areas too, but it would be nice to have a study supporting or even refuting that theory.
Among the major commercial TV news channels, only CBS is privately held by the Redstones. ABC, NBC, Fox, and CNN are all publicly traded on NYSE or NASDAQ.
Okay, there was some ambiguity in the terms I used. I meant "private" as contrasted against "government", which is a terminology the government itself uses. For example, the Federal Aviation Administration contrasts private aircraft (aircraft owned by individuals or corporations) with public aircraft (aircraft owned by the government). By this definition, even "publicly traded" companies would still be "private".
Exclusive rights in radio spectrum are government interference.
Point taken. However CNN, for example, is a cable/satellite *only* channel. Does the principle still apply?
After five blogs are available to a city, would the federal government step in and say "nope, spectrum is too crowded, no new blogs"? If not, bad analogy.
See the preceding comment. Nevertheless, I will concede that when government allocates radio spectrum, you cannot completely eliminate government interference. Ideally, however, I would like to see that interference limited as much as possible.
These guys might take exception to Gandalf's advice :)
(completely disregarding the fact that the guy in TFA did, in fact, know what the thing was; he just wanted to find out what made it tick)
Believe it or not, I ended up working on exactly such a computer for someone recently.
We used to have a saying at my previous job: "Perception IS reality." Whether or not people *need* to upgrade so as to fix security vulnerabilities, people *perceive* that their computer/phone/electronic gizmos are working as-is, and therefore they don't "need" to upgrade, so they don't. You and I might know better, but 99%* of consumers don't, especially when upgrading entails the risk of loss of data...and I *did* lose data when I updated my Hero from 2.0 to 2.1, despite backing everything up with My Backup Pro (IIRC). Apparently, the database that apps use isn't included in the backup, sigh.
*Disclaimer: Yes, I pulled that number out of thin air; I did not actually conduct a survey to get the exact number. You get my point, anyway.