but to say that they break more rules than anybody else is unfair because everybody breaks all those rules frequently
I never said that, and I don't believe it any more than you do. I'm not singling out hybrid drivers on their driving etiquette, merely on their car's exceptional stealth. Overall, I would still prefer existing rules be enforced more effectively before new rules get added.
The fact of the matter is that if you're looking where the fuck you're going and you check the street before you walk into it, it won't matter if a vehicle is making any sound.
Just as with security, a safety system (regulations in this case) must consider defense-in-depth. Car/pedestrian collisions are fatal or debilitating at relatively low speeds, so it seems to be reasonable from an engineering perspective to "design the system" to require multiple concurrent errors to lead to a collision. I'll accept that you consider the requirement onerous compared to possible safety gains, but the argument that sound is inconsequential for safety suggests that you actually want to punish pedestrian errors.
This wouldn't be a problem if people just paid a little attention before crossing the street
You are making the assumption that pedestrian collisions are caused by the inattention of pedestrians. Assholes in hybrids will continue to roll through right-turns-on-red, ignore (or race) pedestrians already crossing, dart around between lanes for a single-car "advantage", zip through small neighborhood streets at 50mph, etc. In all of those situations, there is a defensive advantage because of sound. If that advantage goes away, the assholes just get more dangerous.
Hmm.. Come to think of it, the police can solve most this by enforcing existing traffic laws. Once they start doing that, then I'll be in favor of reducing the noise pollution that cars make. In the meantime, they appear to split their time between catching speeders and only the grossest of safety violators, and I'll take the noise pollution over death.
And this f*** attitude is exactly why the economy is screwed. Give me a long term dividend producing stock over so-called "growth" any day.
Attitude? You mean like understanding the relevant terminology? The GP is right: dividend-bearing stocks with no expectation of future growth are typically classified as "income" stock. Dividend-free stocks with expectation of higher prices in the future is classified as a "growth" stock. There's no judgment in the GP's post about which is better (though now we know your opinion on the matter).
So what? The original point stands, which is that dividends matter when you are evaluating the performance of a stock.
Yes, and the GP's point appears to be that utilities serve the "income stock" role better than MSFT by providing higher dividends. And something like AAPL serves the "growth stock" role better than MSFT. Maybe MSFT fits in as a happy medium between the two broad classes of stocks, but if so its last 10 years have been underperforming expectations (low growth of a utility with a subpar dividend relative to a utility, or good dividend relative to other tech stocks with awful growth).
consider the limit case: a company buys out *all* of its shareholders.
There's no way that MSFT can buy all of their own shares without pressuring the price up on themselves. Those last few shareholders will get quite a good price! But seriously, what's wrong with buying back all of your shares? It seems to me that it's a natural mechanism by which a publicly-traded company can regain control at the cost of a capital investment—the reverse of an IPO.
They don't inline by default, unless you always code the implementations inline in the class declaration.
That's not true.
I did not mean to imply that inline guarantees that the function will be inlined. Sorry for the confusion, perhaps that was poorly worded. I meant the converse (not inverse): that omitting inline may prevent the compiler from performing an inlining optimization. If the function is out-of-line, then link-time optimization is required for inlining. If the function is out-of-line and linked into a shared library, then inlining outside of the shared library is impossible.
The presence of "inline" declarator, even implicit one from writing the bodies inside the class, generally doesn't affect the compiler these days.
Maybe not generally, but let me provide examples where it matters. 1) If you use GCC's -fvisibilty-inlines-hidden when compiling PIC, the compiler will bypass the PLT and therefore may inline code that it would otherwise assume may be redirected (e.g. by LD_PRELOAD). 2) If you define a member function as inline within an implementation, GCC will bypass the PLT in the same way, and it may or may not actually inline the code.
This is assuming that a given function even needs "this".
Aside from functors used in template functions, every member function should be using this or it should not be a member function. I think we both agree that the type of functors in "modern idiomatic C++" to which you refer should inline well. But I don't think these functions are representative of C++ OO code on the whole.
Basically, to defeat inlining and starve registers with "this", you need to do a lot of virtual calls.
Or build shared libraries, or lack access to a toolchain that performs link-time optimization, or use a toolchain that sucks at inlining non-leaf functions.
hot/cold separation is very important, true. however, hot/cold doesn't tend to get factored into the object model by designers, because refactoring is touted as an activity that doesn't change the program's behavior. In my experience with a variety of C++ developers, getting the benefits you speak of "for free" doesn't happen.
They don't inline by default, unless you always code the implementations inline in the class declaration. Plus, the extra register pressure from multiple thiss doesn't go away when you inline (admittedly, this doesn't matter as much on x86_64).
[C++] encourages a lot of inlining, which reduces branching but increases instruction cache usage.
C++ also encourages object-oriented programming techniques, which spreads functional responsibility across multiple classes. This naturally leads to more, smaller functions that may also mess with the instruction cache.
and why are you watching that part of him while he walks to begin with? [you kinda walked yourself into that one]
The GP's reason is probably something along the lines of this eyetracking study:
Although both men and women look at the image of George Brett when directed to find out information about his sport and position, men tend to focus on private anatomy as well as the face.
Why do men assess genitalia? I don't know, but it is a repeatable phenomenon, so you may as well accept it rather than castigating the GP for "looking".
I think you're focusing on the wrong part of the GP's post. Those sound like impressive improvements for synthetic benchmarks, but unless they translate into similarly impressive improvements for UI responsiveness for real sites, it doesn't matter to the average user.
It's interesting to consider that implementing video codecs in JavaScript may be practical sooner rather than later.
True, but that's not an argument for updating your web browser today.
Do you think you'll still be using Firefox 3.6 in 10 years?
No.
If not, then what's stopping you from upgrading now?
The tendency of the developers to mess with the UI means that I expect to weigh the value-add of the new features against learning whatever has changed in the new release. If nothing is bothering me now about the previous release, then I don't want to bother with this calculation. I have more important things to do with my life, like post on/. on threads bitching about web browsers.
Would it be easier to adapt going from XP to Vista to Win7 to Win8, or from XP straight to Win8?
I skipped Vista and had no problems with Win7. Back in the day, I wish I had skipped ME. I also skip non-LTS Ubuntu releases. Frankly, I hate OS upgrades on my personal machines.
"I refuse to adapt to change"
You're painting with broad, inaccurate, and needlessly offensive brush strokes there, buddy. Software exists to Get Shit Done, so change is not intrinsically good. If a new version of my web browser helps me to Get More Shit Done Faster, then I'll download it immediately. If a new version of my web browser instead destabilizes a tiny part of my life without improving my Get Shit Done Benchmark, then why should I adopt it at all?
Maybe you get more overhead than C++ by always using virtual calls but that is offset by not doing C++ magic like unnecessary constructor/destructor calls.
Bullshit. Constructors and destructors fall into several categories:
POD (initialized to garbage values): no cost for construction on the stack, and no code required for destruction at all. Cost for allocation via Foo() (whether on the heap or on the stack) is equivalent to calloc().
Trivial memberwise assignment (initialized to zero or other constant values): Equivalent to assignment from a constant—e.g. using PTHREAD_MUTEX_INITIALIZER—if inlined. C and C++ are identical, but note that the class/struct designer must "expose" the structure definition somehow for this to be inlined.
Necessary nontrivial initialization/finalization code (e.g. resource allocation): Equivalent to foo_create(&foo,...) and foo_destroy(&foo). C and C++ are identical, apart from the function name.
Virtual function calls, OTOH, (almost) always inhibit optimizations. The one exception I can think of is the case where the compiler sees a concrete class declared in main and it can theoretically bypass the vtable.
I like to use red ink on their resumes when I think a skill they claim is unjustified.
Hah, I have a similar approach. I'll point to the "grep list" on their resume and ask them, "Which of these tools are you really good with? I don't want to waste either of our time on the other stuff." Candidates are typically very quick to point out their own (perceived) weaknesses if they don't feel that they will be penalized for doing so, and it lets me know what they thought was worth bullshitting but not worth actually discussing.
Or maybe I offended them by offering up a better solution than they had imagined:P
I've had a few interviewees provide better answers than I had thought up. I don't understand why an interviewer would get offended by it, I think it's "friggin' awesome" when that happens!
Remembering finer points of an API is not an "ability".
I think people with very strong memories for details would disagree with you. It most definitely is an ability, and it should be weighed along with all of the other abilities the interviewee has.
Remembering API base is about as much a skill as spelling is a skill.
If your "whiteboard tests" are solvable with nothing more than a memory of APIs, then You Are Doing It Wrong. The problem should warrant discussion and pseudocode in order to be useful on a whiteboard.
...in an interview I conducted, I was able to recognize our candidate was both brilliant as hell and nervous to the point of babbling...
Well, it sounds like you are a good interviewer, and your strawman "whiteboard Nazi" is not. It seems that the underlying problem is not the practice of whiteboarding (which is a useful tool), but knee-jerk cuts from inattentive interviewers (who will make bad decisions with any tool).
But the guy who hacks together a quadratic time algorithm when Google can give him a perfectly good linear one certainly isn't.
This assumes that big-O complexity is the most important aspect of the job. Plenty of real-world problems involve small datasets or situations where "easy to implement correctly" trumps "performs optimally". But since everyone gets to use the Internet at work nowadays, I'd rather pick the guy who can derive an inefficient algorithm over the guy whose answer is, "The Google Knows."
Whiteboard tests do absolutely nothing to help you know if someone will be a good hire. All it does is test for good whiteboard skills.
In my experience, whiteboarding encourages the interviewee to talk about the problem and his/her approach in a fashion similar to rubber duck debugging. I don't want to share a repository with a developer who cannot get past this step. What whiteboarding should not be is a confrontation between interviewer and interviewee. Stage fright happens, people forget things on the spot, and a good interviewer should take action to help steer an interviewee out of the hole and back to solving the problem at hand.
One small "typo" on the whiteboad might mean the logic is completely wrong, but an IDE with online help and function/argument completion would allow you to make sure to use the right one in a real work situation.
That's why interviews are interactive events. If someone doesn't remember the order of parameters for strncpy, they negotiate some assumptions (or ask for reference assistance) and move on with the problem. It's not the end of the world, provided they know the important bits about the function and that they recognize the gap in their knowledge/memory.
OTOH, if someone says they are an experienced programmer in $language_or_library, then they had better know some of those APIs down cold. Programming is hard when you are constantly looking up reference material (thus getting pulled out of "the zone").
That doesn't give a consistent view. During your work, there are times when the file system isn't in a consistent state. Sure, you can tell it's not consistent because there are missing files, but it's still not consistent.
Yup, this is inconsistent from an external view during the transaction, which you need to solve with a lock. This, among other holes you have pointed out, make this ad-hoc transactional model much worse than a proper RDBMS. I guess you can think of it like a futex in linux: programming with futexes sucks, but it's the foundation of libpthread mutexes and condition variables (which are comparitively easy). So I guess back to your original point: a "transactional filesystem" abstraction layer sounds like an itch worth scratching, but it's not innovation by any means.
Using my DBMS example, how many DBMSs allow you to create hard links of records?
Not any RDBS that I know about, but hard links are not relational. I would expect this sort of behavior to be supported by any object or otherwise hierarchical database. In fact, it is directly supported in many modern programming languages via reference counting and objects.
Slashdot Mirror
I never said that, and I don't believe it any more than you do. I'm not singling out hybrid drivers on their driving etiquette, merely on their car's exceptional stealth. Overall, I would still prefer existing rules be enforced more effectively before new rules get added.
Just as with security, a safety system (regulations in this case) must consider defense-in-depth. Car/pedestrian collisions are fatal or debilitating at relatively low speeds, so it seems to be reasonable from an engineering perspective to "design the system" to require multiple concurrent errors to lead to a collision. I'll accept that you consider the requirement onerous compared to possible safety gains, but the argument that sound is inconsequential for safety suggests that you actually want to punish pedestrian errors.
You are making the assumption that pedestrian collisions are caused by the inattention of pedestrians. Assholes in hybrids will continue to roll through right-turns-on-red, ignore (or race) pedestrians already crossing, dart around between lanes for a single-car "advantage", zip through small neighborhood streets at 50mph, etc. In all of those situations, there is a defensive advantage because of sound. If that advantage goes away, the assholes just get more dangerous.
Hmm.. Come to think of it, the police can solve most this by enforcing existing traffic laws. Once they start doing that, then I'll be in favor of reducing the noise pollution that cars make. In the meantime, they appear to split their time between catching speeders and only the grossest of safety violators, and I'll take the noise pollution over death.
Gollum, is that you?
Attitude? You mean like understanding the relevant terminology? The GP is right: dividend-bearing stocks with no expectation of future growth are typically classified as "income" stock. Dividend-free stocks with expectation of higher prices in the future is classified as a "growth" stock. There's no judgment in the GP's post about which is better (though now we know your opinion on the matter).
Yes, and the GP's point appears to be that utilities serve the "income stock" role better than MSFT by providing higher dividends. And something like AAPL serves the "growth stock" role better than MSFT. Maybe MSFT fits in as a happy medium between the two broad classes of stocks, but if so its last 10 years have been underperforming expectations (low growth of a utility with a subpar dividend relative to a utility, or good dividend relative to other tech stocks with awful growth).
Dividends show up as regular taxable income, whereas a volatile "growth" stock such as AAPL will probably produce long-term capital gains. They're different, and it matters.
There's no way that MSFT can buy all of their own shares without pressuring the price up on themselves. Those last few shareholders will get quite a good price! But seriously, what's wrong with buying back all of your shares? It seems to me that it's a natural mechanism by which a publicly-traded company can regain control at the cost of a capital investment—the reverse of an IPO.
I did not mean to imply that inline guarantees that the function will be inlined. Sorry for the confusion, perhaps that was poorly worded. I meant the converse (not inverse): that omitting inline may prevent the compiler from performing an inlining optimization. If the function is out-of-line, then link-time optimization is required for inlining. If the function is out-of-line and linked into a shared library, then inlining outside of the shared library is impossible.
Maybe not generally, but let me provide examples where it matters. 1) If you use GCC's -fvisibilty-inlines-hidden when compiling PIC, the compiler will bypass the PLT and therefore may inline code that it would otherwise assume may be redirected (e.g. by LD_PRELOAD). 2) If you define a member function as inline within an implementation, GCC will bypass the PLT in the same way, and it may or may not actually inline the code.
Aside from functors used in template functions, every member function should be using this or it should not be a member function. I think we both agree that the type of functors in "modern idiomatic C++" to which you refer should inline well. But I don't think these functions are representative of C++ OO code on the whole.
Or build shared libraries, or lack access to a toolchain that performs link-time optimization, or use a toolchain that sucks at inlining non-leaf functions.
hot/cold separation is very important, true. however, hot/cold doesn't tend to get factored into the object model by designers, because refactoring is touted as an activity that doesn't change the program's behavior. In my experience with a variety of C++ developers, getting the benefits you speak of "for free" doesn't happen.
They don't inline by default, unless you always code the implementations inline in the class declaration. Plus, the extra register pressure from multiple thiss doesn't go away when you inline (admittedly, this doesn't matter as much on x86_64).
C++ also encourages object-oriented programming techniques, which spreads functional responsibility across multiple classes. This naturally leads to more, smaller functions that may also mess with the instruction cache.
Well, what else would you suggest for them to swim in?
The GP's reason is probably something along the lines of this eyetracking study:
Why do men assess genitalia? I don't know, but it is a repeatable phenomenon, so you may as well accept it rather than castigating the GP for "looking".
As a geek, you should recognize that (version) 1.8 is not a floating-point number, but a tuple of integers.
I think you're focusing on the wrong part of the GP's post. Those sound like impressive improvements for synthetic benchmarks, but unless they translate into similarly impressive improvements for UI responsiveness for real sites, it doesn't matter to the average user.
True, but that's not an argument for updating your web browser today.
No.
The tendency of the developers to mess with the UI means that I expect to weigh the value-add of the new features against learning whatever has changed in the new release. If nothing is bothering me now about the previous release, then I don't want to bother with this calculation. I have more important things to do with my life, like post on /. on threads bitching about web browsers.
I skipped Vista and had no problems with Win7. Back in the day, I wish I had skipped ME. I also skip non-LTS Ubuntu releases. Frankly, I hate OS upgrades on my personal machines.
You're painting with broad, inaccurate, and needlessly offensive brush strokes there, buddy. Software exists to Get Shit Done, so change is not intrinsically good. If a new version of my web browser helps me to Get More Shit Done Faster, then I'll download it immediately. If a new version of my web browser instead destabilizes a tiny part of my life without improving my Get Shit Done Benchmark, then why should I adopt it at all?
Bullshit. Constructors and destructors fall into several categories:
Virtual function calls, OTOH, (almost) always inhibit optimizations. The one exception I can think of is the case where the compiler sees a concrete class declared in main and it can theoretically bypass the vtable.
Hah, I have a similar approach. I'll point to the "grep list" on their resume and ask them, "Which of these tools are you really good with? I don't want to waste either of our time on the other stuff." Candidates are typically very quick to point out their own (perceived) weaknesses if they don't feel that they will be penalized for doing so, and it lets me know what they thought was worth bullshitting but not worth actually discussing.
I've had a few interviewees provide better answers than I had thought up. I don't understand why an interviewer would get offended by it, I think it's "friggin' awesome" when that happens!
I think people with very strong memories for details would disagree with you. It most definitely is an ability, and it should be weighed along with all of the other abilities the interviewee has.
If your "whiteboard tests" are solvable with nothing more than a memory of APIs, then You Are Doing It Wrong. The problem should warrant discussion and pseudocode in order to be useful on a whiteboard.
Well, it sounds like you are a good interviewer, and your strawman "whiteboard Nazi" is not. It seems that the underlying problem is not the practice of whiteboarding (which is a useful tool), but knee-jerk cuts from inattentive interviewers (who will make bad decisions with any tool).
This assumes that big-O complexity is the most important aspect of the job. Plenty of real-world problems involve small datasets or situations where "easy to implement correctly" trumps "performs optimally". But since everyone gets to use the Internet at work nowadays, I'd rather pick the guy who can derive an inefficient algorithm over the guy whose answer is, "The Google Knows."
In my experience, whiteboarding encourages the interviewee to talk about the problem and his/her approach in a fashion similar to rubber duck debugging. I don't want to share a repository with a developer who cannot get past this step. What whiteboarding should not be is a confrontation between interviewer and interviewee. Stage fright happens, people forget things on the spot, and a good interviewer should take action to help steer an interviewee out of the hole and back to solving the problem at hand.
That's why interviews are interactive events. If someone doesn't remember the order of parameters for strncpy, they negotiate some assumptions (or ask for reference assistance) and move on with the problem. It's not the end of the world, provided they know the important bits about the function and that they recognize the gap in their knowledge/memory.
OTOH, if someone says they are an experienced programmer in $language_or_library, then they had better know some of those APIs down cold. Programming is hard when you are constantly looking up reference material (thus getting pulled out of "the zone").
Yup, this is inconsistent from an external view during the transaction, which you need to solve with a lock. This, among other holes you have pointed out, make this ad-hoc transactional model much worse than a proper RDBMS. I guess you can think of it like a futex in linux: programming with futexes sucks, but it's the foundation of libpthread mutexes and condition variables (which are comparitively easy). So I guess back to your original point: a "transactional filesystem" abstraction layer sounds like an itch worth scratching, but it's not innovation by any means.
Not any RDBS that I know about, but hard links are not relational. I would expect this sort of behavior to be supported by any object or otherwise hierarchical database. In fact, it is directly supported in many modern programming languages via reference counting and objects.