You are spot on. In their attempt to make the movie "broadly" acceptible, they turned what could have been the funniest damn movie on the planet into a mediocre sci-fi romantic commedy. Gag me.
That was probably the worst scene in the movie. And there were a lot of them in this movie. I don't care if it is human or not. It was boring, dull, predictable, poorly acted, and incredibly un-funny.
The books were awesome, but the movie sucked. They took the books and used it as a loose guide for various events in the movie. None of the dialog from the book survived. The acting was poor. The special effects were good. The pacing was rushed. Everything was glued together rather poorly.
You can tell that the people creating the movie had good intentions -- they wanted to cram many bits from the book into the movie. The problem is that they wanted to do it so badly that (due to time constraints) they condensed those scenes down to the point of being meaningless; they lost the funny. The whole point of including those bits is the funny!
Great stuff like the banter between Prosser and Author discussing where to find the notice for the demolition was reduced to "I eventually had to go to the cellar to find it". Ford 'saves' Author from the scene by rolling up with a shopping cart full of beer to distract the workers.
I could really go on, and on, and on... there is very little in this movie to truely enjoy.
The funniest bits of the movie were lines delivered during the narration. I believe these were the only bits in the movie where they left the original text (mostly) alone.
The only scene I felt was really true to the book was the bit about the whale and the bowl of petunias.
You forget the huge hoard of cash Microsoft has on hand. You don't keep that kind of cash in a savings account -- you invest it. While their sales may not have been hurt by a weak dollar, investment income can be.
I'm not asking you to prove motives. I'm asking you to prove that your hypothesis fits the available data better than any other hypothesis put forward.
We're talking about a ~7% variance from Google's results. Yahoo shows roughly a 5% variance from google's results. All 3 have different ranking systems. All 3 have existed for different periods of time. All 3 are working off of different data sets. All 3 have data sets of different sizes. All 3 have been collecting data for different lengths of time.
Can you really, honestly, say that the only reasonable explanation for the difference is that MS is gaming the results?
It is a reasonable basis (and I use that term loosely) for a hypothesis. However, your hypothesis can't be used to discredit or dismiss other explanations, because there is no evidence to support it.
Microsoft isn't talking about outsourcing here -- they can already do that if they want. They're talking about allowing people from foreign countries into the US to work in the US. Living expenses are the same as US workers. Salaries are the same as US workers.
Your model for labor assumes a pure supply/demand model. Your forget that what is actually being "bought" is work from a human. There are many other factors involved, money being only one of them.
At the end of the day, if there are 500 qualified people available to work and 1500 open positions, 1000 positions will remain unfilled - regardless of the demand.
Looking at it another way. If the supply of oranges so was so restricted that it cost $20 for a single orange, would you buy it or would you do without?
Nowhere does he mention wanting cheaper labor. H1B workers are not cheaper. He does mention that he wants qualified labor. Which would better allow his company to fix major security defects in their less-than-current products.
What part of "decades of well established behavior patterns" do you not understand? That's my evidence you fucking moron.
That isn't evidence. That is a pattern. Evidence would be "I have in my hands the source code, and I see a line that says if (site == IIS) rank += 500". Get back to me after you complete a remedial high school English course.
Properly commented/documented code is one of those things that is hard to describe, but you know it when you see it (or don't see it).
If I'm working on a routine complicated enough that it forces me to think about the problem in pseudo code before actually writing the code, the pseudo code ends up being left behind as comments in the code. This allows me to focus on mini-parts of the problem without losing focus, and also tends to appropriately describe what is going on at a high level (assuming of course your code does what you think it does;)).
If I'm trying to figure out what a piece of code does, and it takes awhile to dawn on me, I add a comment.
If I fix a wierd bug that doesn't look like a bug, in goes a comment to describe the buggy behavior so that someone else doesn't come in and make the same mistake a 2nd time. Sometimes I'll just comment out a line and add text above it which says "don't do this because of blah".
If I do something non-obvious/clever/evil, in goes a comment.
If time allows, I create "headers" for functions that describe what the function does, what the parameters are for, what all of the expected return values in various cases are, and what exceptions the code may throw (if any). I tend to do this more for core pieces of code than code that is rarely touched or considered throw-away.
No it's not, my opinion is based on decades of well established patterns of behavior by MS the corporation and top level MS executives.
So, with several logical explanations for a statistical difference, your preference is to form an illogical explanation with no evidence to back it up? I have no problem with you using an established pattern to cast doubt and as a basis for further research/investigation, but making baseless claims based on your colored perspective of Microsoft's history is absurd.
Exactly where have you had your buried for the last couple of decades anyway? Do you live in a world where MS has been kind, just, fair?
I live in a world where MS has made good decisions and bad decisions. I don't live in a world where I filter out everything that doesn't agree with my opinion.
To me, the conversion has been "you should use xyz instead of gotos", not that "xzy is also useful in this case." Perhaps I'm being overly defensive while reading...
That has got to be the best flame I've seen in a long time. It has all the classics -- a long history lesson, many implications about my lack of knowledge or how much of an idiot I must be, a you're wrong even though you agree with me statement, and even an attack on grammar.
Additionally, there are plenty of occasions where you don't have a choice allocating a resource on the heap or on the stack (because the resource may exist on neither the heap or the stack; ex: handles, critical sections, ref counted objects, and the like).
If you're like everyone else who has replied to me after I raise the above point, you'll mention that RAII solves all of those problems; to which I'll reply it doesn't when the order releasing resources is important, or when releasing a resource has an undesirable side effect.
Ugh, I swear I'm having the same conversation like 50 times.:p
RAII is great until you need to release resources in a deterministic order, or until the act of releasing a resource has a side effect.
In this particular usage example, it is very easy to reason where the code goes -- it always goes down, and it always hits a label at the end of the function that exists right before all of the method level cleanup occurs.
I typically see SEH used when asynchronous exception handling semantics are required or when lower-level access to exception information is required. I think that newer compilers support handling both synchronous and asychronous exceptions now, so that may no longer be as much of a concern.
I'm pretty hardcore in my use of exceptions; I generally only throw them when the app is in a state that can't be recovered from. A wide range of personal experience has directed me to that position (from bugs in compilers, bugs in designs, to bugs in people).
There are many forms of expected errors that can occur; I was listing some very obvious ones that anyone could relate to. An expected error is anything that "failed", but the failure was not entirely unexpected.
Putting resources in classes doesn't always work, especially when resources need to be released in a specific order or when the process used to destroy a resource has unavoidable side effects (the most common example I can think of here is where destruction of a resource overwrites some global data).
The way exceptions work under the hood is not well understood by most people. You don't incur any cost for checking the exception unless the exception is actually thrown. However, you do incur a cost in registering and unregistering exception handlers each time you enter/leave a try block. This is substaintially more costly than just an if statement, but it isn't horribly expensive in its own right. It does, however, add up. If you were to use exceptions the 'proper' way (ie: get rid of pass/fail return codes, and always throw on error), your code would be noticably slower.
The primary cost of using exceptions in C++ is the actual throw. This is why returning values indicating success or failure is still so popular in C++. It isn't nearly as big of a deal in other languages, but the implementation in C++ leaves a bit to be desired...
If you often have code that needs to do 'cleanups' _and_ needs to check many sequential possible error conditions, such that a couple of "if(!failed) {}" sets make your function unreadable, you should probably consider splitting your function and/or rethink your resource allocations.
If you ever do any programming using COM, you'd realize how impracticle that is. Every call you make has a success or failure result to it. Everyone one of those results must always be checked for failure. Following your logic would require a nested if statement for each function call made. Each time you make a call that returns an object, you have to make sure it gets released before returning (otherwise you leak a reference, and thus the object). Believe me when I say you do not want to manage that code with nested if statements.
Remember, the "nest" of gotos always goes down, and they all hit the same point. And the name of the label is (almost always) the same. It is incredibly easy to follow.
MFC doesn't use SEH (at least, it doesn't to my knowledge). SEH is a compiler extension that gives you lower-level access to the exception mechanism provided by Windows; something similar may exist for other platforms, but I haven't cared enough to find out.
SEH gives you a lot more flexability; the major things people use it for would include: 1) the ability to catch 'hardware' exceptions (divide by zero, access violation, etc) 2) the ability to have complicated logic in the 'catch' filter 3) access to the exception record (which contains details about the exception and any parameters for the exception that may be present) 4) access to the context record (which allows you to do things like saving a minidump and writing out a stacktrace for the exception) 5) do nifty things to the exception objects before passing them to handlers
Under the hood, the compiler translates the try/catch blocks into the same primitives you have access to via SEH.
There certainly isn't anything wrong with using exceptions. There are lots of ways to manage the sort of problem I originally described -- all of them work, and all of them have their various pros and cons. That being said, I've yet to see something that works as well as maintaining a single exit point paired with the use of a goto-on-error statement.
When I write code, one of my primary objectives is maintainability and obviousness. I hate having to fix bugs that other people introduce because they didn't realize the full implications of the change they had made. And I hate having to take lots of time bringing a new hire up to speed on how something works. Most other solutions cause either bugs due to un-realized complexity, or require lots of mentoring time to describe. If I can avoid all of that through the use of a goto, I'm all over it.
If you're programming using the Win32 API, it is a fact of life. It does, however, raise to light the broader issue of unexpected consequences and interactions that may occur through the use of such classes.
The conversaion is comparing and contrasting the use of "goto" and "exceptions". Java doesn't support the concept of a goto statement, so we can't be referring to Java. C doesn't support the concept of exceptions, so we can't be talking about C. Ergo, it is a given the conversation centers around C++.
I will conceed the contrived case is effecient where exceptions are always caught in the method that throws them.
This would require code to be structured as follows:
result = call(); if (result == failed)
throw some exception
You'll note that this isn't an example of the recommended use of exceptions. Proper design involving the use of exceptions demands that methods thrown them instead of returning error codes. The typical use would be as follows:
call();// can throw some exception
An error condition in this case incurs the full overhead of exception handling detailed in my previous posted.
Your suggested proposal for the use of exceptions in this manner is nothing more than an obscured goto.
Additionally, any non-stack based resources allocated during the try block will not be released after the exception is thrown, which is another strike against the use of exceptions in the manner you describe. This would be less of an issue if C++ provided for some sort of "finally" syntax, but it does not.
Slashdot Mirror
You are spot on. In their attempt to make the movie "broadly" acceptible, they turned what could have been the funniest damn movie on the planet into a mediocre sci-fi romantic commedy. Gag me.
That was probably the worst scene in the movie. And there were a lot of them in this movie. I don't care if it is human or not. It was boring, dull, predictable, poorly acted, and incredibly un-funny.
This movie is Jurrasic Park 2 for geeks.
... there is very little in this movie to truely enjoy.
The books were awesome, but the movie sucked. They took the books and used it as a loose guide for various events in the movie. None of the dialog from the book survived. The acting was poor. The special effects were good. The pacing was rushed. Everything was glued together rather poorly.
You can tell that the people creating the movie had good intentions -- they wanted to cram many bits from the book into the movie. The problem is that they wanted to do it so badly that (due to time constraints) they condensed those scenes down to the point of being meaningless; they lost the funny. The whole point of including those bits is the funny!
Great stuff like the banter between Prosser and Author discussing where to find the notice for the demolition was reduced to "I eventually had to go to the cellar to find it". Ford 'saves' Author from the scene by rolling up with a shopping cart full of beer to distract the workers.
I could really go on, and on, and on
The funniest bits of the movie were lines delivered during the narration. I believe these were the only bits in the movie where they left the original text (mostly) alone.
The only scene I felt was really true to the book was the bit about the whale and the bowl of petunias.
You forget the huge hoard of cash Microsoft has on hand. You don't keep that kind of cash in a savings account -- you invest it. While their sales may not have been hurt by a weak dollar, investment income can be.
I'm not asking you to prove motives. I'm asking you to prove that your hypothesis fits the available data better than any other hypothesis put forward.
We're talking about a ~7% variance from Google's results. Yahoo shows roughly a 5% variance from google's results. All 3 have different ranking systems. All 3 have existed for different periods of time. All 3 are working off of different data sets. All 3 have data sets of different sizes. All 3 have been collecting data for different lengths of time.
Can you really, honestly, say that the only reasonable explanation for the difference is that MS is gaming the results?
It is a reasonable basis (and I use that term loosely) for a hypothesis. However, your hypothesis can't be used to discredit or dismiss other explanations, because there is no evidence to support it.
Microsoft isn't talking about outsourcing here -- they can already do that if they want. They're talking about allowing people from foreign countries into the US to work in the US. Living expenses are the same as US workers. Salaries are the same as US workers.
Your model for labor assumes a pure supply/demand model. Your forget that what is actually being "bought" is work from a human. There are many other factors involved, money being only one of them.
At the end of the day, if there are 500 qualified people available to work and 1500 open positions, 1000 positions will remain unfilled - regardless of the demand.
Looking at it another way. If the supply of oranges so was so restricted that it cost $20 for a single orange, would you buy it or would you do without?
Nowhere does he mention wanting cheaper labor. H1B workers are not cheaper. He does mention that he wants qualified labor. Which would better allow his company to fix major security defects in their less-than-current products.
I think you just proved the previous poster's point. The people worth their salt already have jobs. :)
What part of "decades of well established behavior patterns" do you not understand? That's my evidence you fucking moron.
That isn't evidence. That is a pattern. Evidence would be "I have in my hands the source code, and I see a line that says if (site == IIS) rank += 500". Get back to me after you complete a remedial high school English course.
"No power in the 'verse can stop me."
Properly commented/documented code is one of those things that is hard to describe, but you know it when you see it (or don't see it).
;)).
If I'm working on a routine complicated enough that it forces me to think about the problem in pseudo code before actually writing the code, the pseudo code ends up being left behind as comments in the code. This allows me to focus on mini-parts of the problem without losing focus, and also tends to appropriately describe what is going on at a high level (assuming of course your code does what you think it does
If I'm trying to figure out what a piece of code does, and it takes awhile to dawn on me, I add a comment.
If I fix a wierd bug that doesn't look like a bug, in goes a comment to describe the buggy behavior so that someone else doesn't come in and make the same mistake a 2nd time. Sometimes I'll just comment out a line and add text above it which says "don't do this because of blah".
If I do something non-obvious/clever/evil, in goes a comment.
If time allows, I create "headers" for functions that describe what the function does, what the parameters are for, what all of the expected return values in various cases are, and what exceptions the code may throw (if any). I tend to do this more for core pieces of code than code that is rarely touched or considered throw-away.
No it's not, my opinion is based on decades of well established patterns of behavior by MS the corporation and top level MS executives.
So, with several logical explanations for a statistical difference, your preference is to form an illogical explanation with no evidence to back it up? I have no problem with you using an established pattern to cast doubt and as a basis for further research/investigation, but making baseless claims based on your colored perspective of Microsoft's history is absurd.
Exactly where have you had your buried for the last couple of decades anyway? Do you live in a world where MS has been kind, just, fair?
I live in a world where MS has made good decisions and bad decisions. I don't live in a world where I filter out everything that doesn't agree with my opinion.
To me, the conversion has been "you should use xyz instead of gotos", not that "xzy is also useful in this case." Perhaps I'm being overly defensive while reading ...
Because his theory makes logical sense, and yours is rooted in paranoia.
That has got to be the best flame I've seen in a long time. It has all the classics -- a long history lesson, many implications about my lack of knowledge or how much of an idiot I must be, a you're wrong even though you agree with me statement, and even an attack on grammar.
Bravo.
C++ doesn't have the concept of finally.
Additionally, there are plenty of occasions where you don't have a choice allocating a resource on the heap or on the stack (because the resource may exist on neither the heap or the stack; ex: handles, critical sections, ref counted objects, and the like).
If you're like everyone else who has replied to me after I raise the above point, you'll mention that RAII solves all of those problems; to which I'll reply it doesn't when the order releasing resources is important, or when releasing a resource has an undesirable side effect.
Ugh, I swear I'm having the same conversation like 50 times. :p
RAII is great until you need to release resources in a deterministic order, or until the act of releasing a resource has a side effect.
In this particular usage example, it is very easy to reason where the code goes -- it always goes down, and it always hits a label at the end of the function that exists right before all of the method level cleanup occurs.
I typically see SEH used when asynchronous exception handling semantics are required or when lower-level access to exception information is required. I think that newer compilers support handling both synchronous and asychronous exceptions now, so that may no longer be as much of a concern.
I'm pretty hardcore in my use of exceptions; I generally only throw them when the app is in a state that can't be recovered from. A wide range of personal experience has directed me to that position (from bugs in compilers, bugs in designs, to bugs in people).
There are many forms of expected errors that can occur; I was listing some very obvious ones that anyone could relate to. An expected error is anything that "failed", but the failure was not entirely unexpected.
Putting resources in classes doesn't always work, especially when resources need to be released in a specific order or when the process used to destroy a resource has unavoidable side effects (the most common example I can think of here is where destruction of a resource overwrites some global data).
The way exceptions work under the hood is not well understood by most people. You don't incur any cost for checking the exception unless the exception is actually thrown. However, you do incur a cost in registering and unregistering exception handlers each time you enter/leave a try block. This is substaintially more costly than just an if statement, but it isn't horribly expensive in its own right. It does, however, add up. If you were to use exceptions the 'proper' way (ie: get rid of pass/fail return codes, and always throw on error), your code would be noticably slower.
The primary cost of using exceptions in C++ is the actual throw. This is why returning values indicating success or failure is still so popular in C++. It isn't nearly as big of a deal in other languages, but the implementation in C++ leaves a bit to be desired...
If you often have code that needs to do 'cleanups' _and_ needs to check many sequential possible error conditions, such that a couple of "if(!failed) {}" sets make your function unreadable, you should probably consider splitting your function and/or rethink your resource allocations.
If you ever do any programming using COM, you'd realize how impracticle that is. Every call you make has a success or failure result to it. Everyone one of those results must always be checked for failure. Following your logic would require a nested if statement for each function call made. Each time you make a call that returns an object, you have to make sure it gets released before returning (otherwise you leak a reference, and thus the object). Believe me when I say you do not want to manage that code with nested if statements.
Remember, the "nest" of gotos always goes down, and they all hit the same point. And the name of the label is (almost always) the same. It is incredibly easy to follow.
MFC doesn't use SEH (at least, it doesn't to my knowledge). SEH is a compiler extension that gives you lower-level access to the exception mechanism provided by Windows; something similar may exist for other platforms, but I haven't cared enough to find out.
SEH gives you a lot more flexability; the major things people use it for would include:
1) the ability to catch 'hardware' exceptions (divide by zero, access violation, etc)
2) the ability to have complicated logic in the 'catch' filter
3) access to the exception record (which contains details about the exception and any parameters for the exception that may be present)
4) access to the context record (which allows you to do things like saving a minidump and writing out a stacktrace for the exception)
5) do nifty things to the exception objects before passing them to handlers
Under the hood, the compiler translates the try/catch blocks into the same primitives you have access to via SEH.
There certainly isn't anything wrong with using exceptions. There are lots of ways to manage the sort of problem I originally described -- all of them work, and all of them have their various pros and cons. That being said, I've yet to see something that works as well as maintaining a single exit point paired with the use of a goto-on-error statement.
When I write code, one of my primary objectives is maintainability and obviousness. I hate having to fix bugs that other people introduce because they didn't realize the full implications of the change they had made. And I hate having to take lots of time bringing a new hire up to speed on how something works. Most other solutions cause either bugs due to un-realized complexity, or require lots of mentoring time to describe. If I can avoid all of that through the use of a goto, I'm all over it.
If you're programming using the Win32 API, it is a fact of life. It does, however, raise to light the broader issue of unexpected consequences and interactions that may occur through the use of such classes.
The conversaion is comparing and contrasting the use of "goto" and "exceptions". Java doesn't support the concept of a goto statement, so we can't be referring to Java. C doesn't support the concept of exceptions, so we can't be talking about C. Ergo, it is a given the conversation centers around C++.
I will conceed the contrived case is effecient where exceptions are always caught in the method that throws them.
// can throw some exception
This would require code to be structured as follows:
result = call();
if (result == failed)
throw some exception
You'll note that this isn't an example of the recommended use of exceptions. Proper design involving the use of exceptions demands that methods thrown them instead of returning error codes. The typical use would be as follows:
call();
An error condition in this case incurs the full overhead of exception handling detailed in my previous posted.
Your suggested proposal for the use of exceptions in this manner is nothing more than an obscured goto.
Additionally, any non-stack based resources allocated during the try block will not be released after the exception is thrown, which is another strike against the use of exceptions in the manner you describe. This would be less of an issue if C++ provided for some sort of "finally" syntax, but it does not.
Actually, Apple coppied the "It just works" mantra from me; I've been using it to describe software I've worked on for the last 15 years ... :p