Yup. That one woke me out of a sound sleep all the way over in Tulsa. At first I though perhaps a refinery had exploded, but it just wouldn't stop. The larger aftershock the next week did too, but it wasn't nearly as scary.
The University of Oklahoma (home of one of the top Petroleum Engineering departments in the country, and recipient of much oil money), geology department has released statements disagreeing. Why aren't you reporting the "controversy" rather than the science? How incredibly biased!
In fact, just a few months ago, one their Geological researchers released a peer reviewed study that showed... let's see here... uh... that fracking is causing earthquakes.
Damn. Wait! I know there's a controversy to report here somewhere. Lemme look....ah, here it is:
Oklahoma’s official seismologist — the Geological Survey’s Austin Holland — is skeptical of the link between injection wells an earthquakes, a view shared by the Corporation Commission and the Oklahoma Independent Petroleum Association, a trade group that lobbies for the interests of oil and gas producers. More data is needed, Holland says.
See, this is actually a controversy! You just have to go to sources that aren't as familiar with the actual data, and/or are in the pockets of the folks doing the fracking. Why isn't this controversy being fairly reported?
That brings us to three now (ArcMap, Banyan, & NavInt) that are known to not be NSA code names. It would be funny if the entire list was in fact known commercial technical terms and/or government divisions.
BANYAN???
Isn't that the almost extinct government and defence email system, Banyan Vines??
I suspect that's exactly what it is referring to. I noticed at least one other word in that list, (NAVINT), that isn't really a program. NAVINT is just a nice short acronym for Naval Intelligence. It kind of makes me wonder if there isn't some other stuff in there that has nothing to do with classified programs.
Whoever got hold of this communication clearly wasn't really well-versed enough in that kind of work to tell what exactly is a technical term and what is is an actual NSA program.
In this modern era many people forget that typewriters had a *huge* security hole. The ink ribbons they used, in the right hands, were practically a "tape backup" of everything typed at that typewriter.
What this project clearly needs is a multi-million dollar effort to port all that COBOL code into today's hippest new language. That way any code in there that happens to actually work right through some fluke of fortune, will get new bugs inserted into it. Then we can do it all again when a new language becomes more fashionable next month.
I have to go now. They're totally rebuilding my building, now that there's been developed a snazzier way to weld joists. I'll get back to you in 9 months, if everything goes to schedule....
The big problem with C11 is that is it no longer "backwards"-compatible with C++, so many will ignore it. For a large number of people "C" is going to remain defined as "the subset of C++ that I can get a C-only compiler to compile".
All the programming languages that I know have their syntax based on C,
I'm hoping this was some kind of sheepish admission. Otherwise, you might as well walk into a car club and proclaim that you haven't the foggiest idea how to operate a stick shift.
Seriously, this is a hole in your understanding of programming that cannot help but limit your thinking in ways you probably don't even see. I highly suggest you take steps to correct this problem.
My oppinion is that Javascript is not bad as a scripting language, but we are abusing it and twisting it beyond its original purpose.
I actually agree with this statement whole-heartedly. However, I can't help but find it amusing that you immedately go on to propose using one or more of the modern updates to C, Ken Thompson's slightly higher-level replacement for PDP-7&11 Assembly language.
People who oppose interacial marriages are branded as bigots too. It doesn't exactly take a gift of prophecy to predict that someone who "regards or treats the members of a group with hatred and intolerance" will be branded as a bigot, since that is the English word for that exact activity.
Mentally ill is a bit of a stretch though. Perhaps there's someone out there who feels that all people who nurse unreasonable hatreds are metally ill, but the sad truth is that this is a common human behavior.
All this is true. But for those of us who don't possess unlimited money and time, why on earth would we waste some of it watching content we find abhorrent, when there's other good stuff out there? I don't think people who find anti-gay media disgusting should bother to sit through Card's work any more than I think people who find guys kissing abhorrent should pay to sit through Brokeback Mountain for 2 hours. This isn't about any fancy "boycott", its just common sense.
You might as well start complaining about young single males "boycotting" the Sex in the City movie.
Personally I agree with some of those positions, disagree with others, but IMHO all of them are debatable. People who disagree with me have a point, and a mostly sensible place they are coming from.
That differs from the GP list, mostly in that the vast majority of the entire society I've grown up with finds all of those practices abhorrent, and there is really no good justification for any of them that isn't based in superstition or fear.
The stuff in your list is political disagreements that our society is split on. To take one example, I personally agree that it is unjust for one part of the electorate to gang up on another and take away their drinking rights just out of sheer force of numbers. However, there are logical reasons to want to prohibit mentally-imparing substances to people whose decision making capabilities already aren't yet fully developed (according to many studies). That isn't an argument I agree with (nor do you I take it), but it at least has some good logic behind it.
One of my former employers (I won't say their name, but their initials are LMCO), solved this problem by using badge-operated turnstyles, like in the subways but enclosed in plexiglass so you can't jump them. An effective solution, but I lived in fear of getting stuck halfway through one in the middle of the night.
Awesomely informative post. One thing you did fail to mention though is that the pilot, while quite experienced overall, only had something like 45 hours experience flying this plane. Given the length of trans-pacific flights, that means he'd only flown this plane a bare handful of times at most. Add to that the fact (you mentioned) that he was attempting an unusual manual landing. Almost certianly he'd never done this before, outside of a simulator. Hopefully he'd done it a few times in a simulator at least, but the reported rediculouly low airspeed (a bit more than half the miniumum required), makes one wonder.
We don't know the ultimate cause yet, but whatever it ends up being, it certianly looks like that pilot could have done with a lot more training on that plane. And I'm not just saying this because my employer makes most of its money selling flight training to commercial pilots. Nope, not at all...
the actual affect is to reduce their hours from 40 hrs a week + overtime to a strict less than 30 hours
Cheapskate companies like Wal-Mart were already doing this. Have been for decades. Once you hit the magic number of 40 hours, they were already required to provide health care (and pay into unemployment, etc).
The difference here is that they were given a new "magic number" of 30, so the cheapskates who had all their employees working 39 hours a week (on the books), now move it down to 30. I suspect the only reason you are hearing complaints about it now is that the cheapskate companies are worried that the extra off-the-books hours they have been routinely demanding from their employees will have to be cut back now too, or they will become much harder to extract and hide.
How about this for an idea: Instead of complaining about the labor laws, why don't we instead try to do something about the labor scofflaws? Even pre-Obamacare, they were sticking the rest of us with all their employees heal care costs, unemployment costs when they "fired" them without paying anything into the insurance fund, etc. Why not attack the real problem here?
Still, given all the families I've seen destroyed by excessive software development overtime (and not a few people's health) , one has to start to wonder if it wouldn't be socially valuable to extend this protection to computer workers.
Lets not even get into the fact that some software bugs can ruin lives, or even kill people. You wouldn't be comfortable taking a flight flown by a pilot who has been working 12+ hour shifts 7 days a week for the last 2 months would you? Well, in a modern fly-by-wire aircraft, the computers are doing most of the work, and guess what hours those engineers who designed a built it were working.
They basically do not have the analytical or even basic math skills required to be writing the requirements they are in charge of
This is common, in fact, typical. If writing software were easy, they could do it themselves. Typically, it is far easier for you (the designer) to become proficient (at least to the novice level) in what the customer does than it is for them to become proficient enough in software development to make sensible design decisions themselves.
Where projects become total disasters is when neither happens. Following a "process" cannot substitute for actually knowing what you are doing.
There is one other thing in there that bugs me: the phrase "Design Requirements". Requirements should not be specifying how things get done, only what it is that will get done. If design is laid out in your requirements, you are definitely doing it wrong.
If it were me, I'd try to claim that I was actually truthfully reporting my accounting numbers, and it is the software (and by extension the authors thereof) who are guilty of trying to falsely report accounting numbers.
How about C) They somehow managed to steal the plans/desgin specs for the facility. D) They (more likely Mossad) have someone on the inside. E) All sorts of other scenarios we haven't thought of.
The really impressive part of the attack to me was the physical intelligence involved. Whoever did this knew the entire architecture of the Iranian nuclear facility; not just what was connected to what, but down to the model numbers of all the equipement used.
And note that breaking the method into separate sub-methods doesn't necessarily solve the problem of changes near the beginning breaking things later on.
That's a very good point. A lot of times these mongo routines really must be refactored to clean them up, and breaking them into sub-methods is really only the first step. If there's all sorts of exteranious interactions between blocks of code, and all you do is arbitrarially split the routine into multiple paremeterless routines operating on the same global data, you haven't really accomplished much. This is where the "coupling" I mentioned comes in. If you address the cohesion, but leave your routines with really crappy global coupling, I still have to read and understand the code in both routines fully to make sure routine A doesn't muck with globals in a way that subtly affects routine B.
However, that's just a detail. It doesn't change the fact that any routine larger than about 300 text lines or so (1,000 is right out), with a few notable exceptions, has too much in it for a limited human such as myself to reliably keep track of, and needs to be broken up. Yes, there are some tasks that are inherently expressed as large routines (state-machines, command dispatchers) and thus can't be reasonablely split up. Its a rule-of-thumb, not religous dogma. That doesn't change the fact that large routines are hard to understand, and should be justified or refactored.
Do you re-use your functions, or do they only exist to break apart a single operation into smaller blocks? If it's the latter, then he may have a good point
I disagree, strongly. Breaking a large routine into smaller ones abstracts away what those smaller routines are doing. It puts a boundry around their interaction with the rest of the code, and puts their code away somewhere that I don't have to worry about, unless there's some reason I want/need to know the details of how that routine accomplishes what it does.
If you put it all flat into one big routine, I have to read and grok everything in that routine, if only to reassure myself that none of it has interactions with the one area I care about.
We actually have terms for this stuff: Cohesion and Coupling. Cohesion in particular is an important concept here.
I find it amusing that the author's big example is Aho's parsers. Parsers are one of those special cases, as lexical analysis is a problem that is generally best solved by state-machines. I've tried for years, and really there aren't a lot of good ways to code lexer state machines that aren't either way slower than the typcial implementations, or a web of control flow that looks like a huge mess to those of us reared on structured programming. It isn't talked about much, but lexers (and some parsers) unashamedly make use of goto statements as their core braching mechanisim. Using Aho's awk parsing code as an example of why "clean" code isn't always desirable is like using the US Marines as an example of why killing people is often a good option for solving disputes. Perhaps its true in a technical sense, but its really crappy advice to be giving the general public.
Slashdot Mirror
there's still plenty of guys who believe in the Biblical definition of marriage.
That's true. We call them "polygamists".
Yup. That one woke me out of a sound sleep all the way over in Tulsa. At first I though perhaps a refinery had exploded, but it just wouldn't stop. The larger aftershock the next week did too, but it wasn't nearly as scary.
The University of Oklahoma (home of one of the top Petroleum Engineering departments in the country, and recipient of much oil money), geology department has released statements disagreeing. Why aren't you reporting the "controversy" rather than the science? How incredibly biased!
In fact, just a few months ago, one their Geological researchers released a peer reviewed study that showed ... let's see here ... uh... that fracking is causing earthquakes.
Damn. Wait! I know there's a controversy to report here somewhere. Lemme look....ah, here it is:
Oklahoma’s official seismologist — the Geological Survey’s Austin Holland — is skeptical of the link between injection wells an earthquakes, a view shared by the Corporation Commission and the Oklahoma Independent Petroleum Association, a trade group that lobbies for the interests of oil and gas producers. More data is needed, Holland says.
See, this is actually a controversy! You just have to go to sources that aren't as familiar with the actual data, and/or are in the pockets of the folks doing the fracking. Why isn't this controversy being fairly reported?
That brings us to three now (ArcMap, Banyan, & NavInt) that are known to not be NSA code names. It would be funny if the entire list was in fact known commercial technical terms and/or government divisions.
BANYAN??? Isn't that the almost extinct government and defence email system, Banyan Vines??
I suspect that's exactly what it is referring to. I noticed at least one other word in that list, (NAVINT), that isn't really a program. NAVINT is just a nice short acronym for Naval Intelligence. It kind of makes me wonder if there isn't some other stuff in there that has nothing to do with classified programs.
Whoever got hold of this communication clearly wasn't really well-versed enough in that kind of work to tell what exactly is a technical term and what is is an actual NSA program.
In this modern era many people forget that typewriters had a *huge* security hole. The ink ribbons they used, in the right hands, were practically a "tape backup" of everything typed at that typewriter.
What this project clearly needs is a multi-million dollar effort to port all that COBOL code into today's hippest new language. That way any code in there that happens to actually work right through some fluke of fortune, will get new bugs inserted into it. Then we can do it all again when a new language becomes more fashionable next month.
I have to go now. They're totally rebuilding my building, now that there's been developed a snazzier way to weld joists. I'll get back to you in 9 months, if everything goes to schedule....
The big problem with C11 is that is it no longer "backwards"-compatible with C++, so many will ignore it. For a large number of people "C" is going to remain defined as "the subset of C++ that I can get a C-only compiler to compile".
All the programming languages that I know have their syntax based on C,
I'm hoping this was some kind of sheepish admission. Otherwise, you might as well walk into a car club and proclaim that you haven't the foggiest idea how to operate a stick shift.
Seriously, this is a hole in your understanding of programming that cannot help but limit your thinking in ways you probably don't even see. I highly suggest you take steps to correct this problem.
My oppinion is that Javascript is not bad as a scripting language, but we are abusing it and twisting it beyond its original purpose.
I actually agree with this statement whole-heartedly. However, I can't help but find it amusing that you immedately go on to propose using one or more of the modern updates to C, Ken Thompson's slightly higher-level replacement for PDP-7&11 Assembly language.
People who oppose interacial marriages are branded as bigots too. It doesn't exactly take a gift of prophecy to predict that someone who "regards or treats the members of a group with hatred and intolerance" will be branded as a bigot, since that is the English word for that exact activity.
Mentally ill is a bit of a stretch though. Perhaps there's someone out there who feels that all people who nurse unreasonable hatreds are metally ill, but the sad truth is that this is a common human behavior.
All this is true. But for those of us who don't possess unlimited money and time, why on earth would we waste some of it watching content we find abhorrent, when there's other good stuff out there? I don't think people who find anti-gay media disgusting should bother to sit through Card's work any more than I think people who find guys kissing abhorrent should pay to sit through Brokeback Mountain for 2 hours. This isn't about any fancy "boycott", its just common sense.
You might as well start complaining about young single males "boycotting" the Sex in the City movie.
Personally I agree with some of those positions, disagree with others, but IMHO all of them are debatable. People who disagree with me have a point, and a mostly sensible place they are coming from.
That differs from the GP list, mostly in that the vast majority of the entire society I've grown up with finds all of those practices abhorrent, and there is really no good justification for any of them that isn't based in superstition or fear.
The stuff in your list is political disagreements that our society is split on. To take one example, I personally agree that it is unjust for one part of the electorate to gang up on another and take away their drinking rights just out of sheer force of numbers. However, there are logical reasons to want to prohibit mentally-imparing substances to people whose decision making capabilities already aren't yet fully developed (according to many studies). That isn't an argument I agree with (nor do you I take it), but it at least has some good logic behind it.
One of my former employers (I won't say their name, but their initials are LMCO), solved this problem by using badge-operated turnstyles, like in the subways but enclosed in plexiglass so you can't jump them. An effective solution, but I lived in fear of getting stuck halfway through one in the middle of the night.
Awesomely informative post. One thing you did fail to mention though is that the pilot, while quite experienced overall, only had something like 45 hours experience flying this plane. Given the length of trans-pacific flights, that means he'd only flown this plane a bare handful of times at most. Add to that the fact (you mentioned) that he was attempting an unusual manual landing. Almost certianly he'd never done this before, outside of a simulator. Hopefully he'd done it a few times in a simulator at least, but the reported rediculouly low airspeed (a bit more than half the miniumum required), makes one wonder.
We don't know the ultimate cause yet, but whatever it ends up being, it certianly looks like that pilot could have done with a lot more training on that plane. And I'm not just saying this because my employer makes most of its money selling flight training to commercial pilots. Nope, not at all...
According to my Indian friends, when they go home to visit relatives the traffic drives on whatever side of the road they happen to feel like today.
Interesting. That's how they drive in Korea.
In Korea, the eldest gets right-of-way.
That explains their car designs.
If they have a big problem with copilots and navigators having too much respect for authority, I have three kids who'd be perfect for them...
the actual affect is to reduce their hours from 40 hrs a week + overtime to a strict less than 30 hours
Cheapskate companies like Wal-Mart were already doing this. Have been for decades. Once you hit the magic number of 40 hours, they were already required to provide health care (and pay into unemployment, etc).
The difference here is that they were given a new "magic number" of 30, so the cheapskates who had all their employees working 39 hours a week (on the books), now move it down to 30. I suspect the only reason you are hearing complaints about it now is that the cheapskate companies are worried that the extra off-the-books hours they have been routinely demanding from their employees will have to be cut back now too, or they will become much harder to extract and hide.
How about this for an idea: Instead of complaining about the labor laws, why don't we instead try to do something about the labor scofflaws? Even pre-Obamacare, they were sticking the rest of us with all their employees heal care costs, unemployment costs when they "fired" them without paying anything into the insurance fund, etc. Why not attack the real problem here?
Still, given all the families I've seen destroyed by excessive software development overtime (and not a few people's health) , one has to start to wonder if it wouldn't be socially valuable to extend this protection to computer workers.
Lets not even get into the fact that some software bugs can ruin lives, or even kill people. You wouldn't be comfortable taking a flight flown by a pilot who has been working 12+ hour shifts 7 days a week for the last 2 months would you? Well, in a modern fly-by-wire aircraft, the computers are doing most of the work, and guess what hours those engineers who designed a built it were working.
They basically do not have the analytical or even basic math skills required to be writing the requirements they are in charge of
This is common, in fact, typical. If writing software were easy, they could do it themselves. Typically, it is far easier for you (the designer) to become proficient (at least to the novice level) in what the customer does than it is for them to become proficient enough in software development to make sensible design decisions themselves.
Where projects become total disasters is when neither happens. Following a "process" cannot substitute for actually knowing what you are doing.
There is one other thing in there that bugs me: the phrase "Design Requirements". Requirements should not be specifying how things get done, only what it is that will get done. If design is laid out in your requirements, you are definitely doing it wrong.
If it were me, I'd try to claim that I was actually truthfully reporting my accounting numbers, and it is the software (and by extension the authors thereof) who are guilty of trying to falsely report accounting numbers.
Two options, it is fair to assume they used both:
How about C) They somehow managed to steal the plans/desgin specs for the facility. D) They (more likely Mossad) have someone on the inside. E) All sorts of other scenarios we haven't thought of.
The really impressive part of the attack to me was the physical intelligence involved. Whoever did this knew the entire architecture of the Iranian nuclear facility; not just what was connected to what, but down to the model numbers of all the equipement used.
And note that breaking the method into separate sub-methods doesn't necessarily solve the problem of changes near the beginning breaking things later on.
That's a very good point. A lot of times these mongo routines really must be refactored to clean them up, and breaking them into sub-methods is really only the first step. If there's all sorts of exteranious interactions between blocks of code, and all you do is arbitrarially split the routine into multiple paremeterless routines operating on the same global data, you haven't really accomplished much. This is where the "coupling" I mentioned comes in. If you address the cohesion, but leave your routines with really crappy global coupling, I still have to read and understand the code in both routines fully to make sure routine A doesn't muck with globals in a way that subtly affects routine B.
However, that's just a detail. It doesn't change the fact that any routine larger than about 300 text lines or so (1,000 is right out), with a few notable exceptions, has too much in it for a limited human such as myself to reliably keep track of, and needs to be broken up. Yes, there are some tasks that are inherently expressed as large routines (state-machines, command dispatchers) and thus can't be reasonablely split up. Its a rule-of-thumb, not religous dogma. That doesn't change the fact that large routines are hard to understand, and should be justified or refactored.
Do you re-use your functions, or do they only exist to break apart a single operation into smaller blocks? If it's the latter, then he may have a good point
I disagree, strongly. Breaking a large routine into smaller ones abstracts away what those smaller routines are doing. It puts a boundry around their interaction with the rest of the code, and puts their code away somewhere that I don't have to worry about, unless there's some reason I want/need to know the details of how that routine accomplishes what it does.
If you put it all flat into one big routine, I have to read and grok everything in that routine, if only to reassure myself that none of it has interactions with the one area I care about.
We actually have terms for this stuff: Cohesion and Coupling. Cohesion in particular is an important concept here.
I find it amusing that the author's big example is Aho's parsers. Parsers are one of those special cases, as lexical analysis is a problem that is generally best solved by state-machines. I've tried for years, and really there aren't a lot of good ways to code lexer state machines that aren't either way slower than the typcial implementations, or a web of control flow that looks like a huge mess to those of us reared on structured programming. It isn't talked about much, but lexers (and some parsers) unashamedly make use of goto statements as their core braching mechanisim. Using Aho's awk parsing code as an example of why "clean" code isn't always desirable is like using the US Marines as an example of why killing people is often a good option for solving disputes. Perhaps its true in a technical sense, but its really crappy advice to be giving the general public.