tpz

The distinction is simply (but critically!) this: the standard operating procedure (and, in fact, the only available way!) to shut down a piece of crash-only software is to crash it forcibly. There is no quit button, no shutdown command, no remote API, there is just kill. Sounds simple enough, but where it really gets interesting is in how this mindset affects your design and implementation decisions.

Imagaine for a moment what it would be like if during every second of work during every day of the week each and every thing you did was accompanied by a corresponding design exercise along the lines of "okay, but what if it crashes right then." Now that would sure produce some "software with good error handling", now wouldn't it. That is crash-only software.

Unless I am missing something, the only way the whole world can be a net saver would be for for all of us to start exporting goods and services off-planet. Anything else is simply a mirage that obscures currency inflation. :) Which, on a related note, goes eleventy-fold for anything remotely related to derivative instruments.

  A great engineer is not expected to know how their impact 
  on a 25 person company will be different than a 200
  person company. Moreover a great engineer may not yet
  know that not having that impact may be a really
  important loss to them.

A great engineer had bloody well know how their impact will be different, and they'd damn well know how that difference will affect them. Whatever kind of engineer you are referring to is most certainly not great and, worse, they are the kind you should strive to weed out of your hiring process before they end up getting hired and creating a lot of grief for both themselves and the company. Among other things, they have a strong tendency to bring to the table solutions that are mismatched in scale, complexity, delivery style, etc. relative to what would serve the company best.

(your 10k point is entirely valid, of course.)

The absurd claim about the "iPad only home", given that the iPad requires a computer to activate and manage.

Apple has gone out of its way to make sure the iPad is treated as an additional device, not a sole device for a user. This is important because it allows (or at least helps to allow) the iPad to be judged on its own merit for its own uses, not as if it were the general-purpose computer that some (critically: not Apple) like to claim that it is, much to the iPad's detriment.

  I was surprised to see that the default mode for development is unmanaged.

I find myself wondering what you mean by "default mode", as during the last 9 solid years of .net development work I have found it to very much be the case that managed is the default.

Can you clarify your statement?

But then it would have to swap, the user experience would suffer unpredictably, Steve Jobs would strangle the engineer responsible and the feature would never see the light of day.

All true, but worth a brief addition: these viewing distance / screen size / resolution models all assume average adult vision, so if you are one of the folks both lucky and unlucky enough to have above-average vision (or below, for that matter) you should take that into account.

As but one example, the parent's example transition at 7 to 8 feet would occur around 10 feet for me. Above-average vision is great on paper but translates into more expensive displays positioned farther away. :(

And not just that. A pattern I've been more consciously noticing recently (I'm sure it has been there the whole time but that I've just been noticing it more often for some reason) is the huge tendency for people to not just attribute success to luck but to attribute success to luck and failure to error/inherent crappiness, and to do so much more often than they are willing to attribute success to avoidance of error and an inherent goodness and attribute failure to bad luck.

I suspect this stems from some kind of ego factor in that when others succeed one wants it to be due to luck and not some factor that makes the other person "better" than they are, and that when others fail one wants it to be due to the other person being "worse" than they are.

Edit: I must admit that I've seen more and more of this on HN as its audience grows and changes, which is rather unfortunate. :(

Which is like saying "why not just use V8?" when talking about Node.js. IronJS, once it is ready, will likely be the best JS implementation (and its certainly the one I have my sights on!) through which to build and run a Node-like JS server on .NET but you'll still need to build the Node-like implementation itself (hopefully mostly if not entirely in JS.)

Within the Framework's Base Class Libraries themselves, the documentation is pretty good about stating what is and is not thread-safe and the implementations are generally quite good in that regard. Outside of the Base Class Libraries there is a lot of variability in thread safety, of course, so YMMV depending on what you're working with.

That said, the thread safety isn't as critical in something like Node, at least not in the sense you'd usually be worried about, as the execution model is explicitly single-threaded. What you'd be more interested in finding (and pushing to improve) would be libraries that are externally bound but fail to provide an async option using the recommended async patterns for .NET. To be clear, these recommended async patterns and a good number of their proper implementations do not require hidden threads for their async behaviour, as when built correctly they are layered upon lower-level async operations that themselves do not require threads.

One would hope to work towards a "turtles all the way down" kind of scenario where eventually nothing you are using blocks on anything external and instead uses the async primitives and layers them up such that no threads are needed for any async operations. Admittedly, as .NET goes there would be areas you can't achieve that goal, however, as some framework bits are secretly backed by threads (e.g. some serial port handling, when last I checked), but this is also true in the case of Node.js which itself maintains threads behind the scenes for use with otherwise-unavoidable blocking code. In either Node-style case the end goal is the same: to minimize if not eliminate the need for such threads, and in the .NET-specific case it should be largely achievable (to the degree that it matters) as there are plenty of building blocks with proper async options.

It is interesting to me, at least, for the same reasons that made Node.js interesting in the first place: as a statement/experiment in seeing how far the async model can be pushed.

I'm a .NET dev by trade but became immediately interested in Node.js for that very reason.

In the .NET case, a Node-like project is in an interesting position: lots of long-running/externally-bound third-party (and even a few first-party) APIs are blocking in nature, except that if they were following the design guidelines they would all provide non-blocking alternatives based on a set of implementation patterns provided by and followed in the .NET base class library itself. Those implementation patterns would be relatively easy to generically wrap into the kind of callback pattern used by Node.js.

At the very least, a project like this has a possibility of highlighting some of the places where only blocking APIs have been provided but non-blocking ones should have also been provided. On a slightly more optimistic note, a project like this has a chance of allowing more solutions to be built in the Node.js events-instead-of-threads style without having to jump ship to an entirely different runtime.

No, but in the real world of deadlines, collaboration with teams that have their own different schedules, priorities, etc., they very often need a one week window not constrained but instead opened such that they can actually get something done about items in the important but not urgent quadrant.

For the record, I'm not unhappy at all, and if you'll look back at my original reply I was very up front about being just one data point.

You can get lucky. Or you can leverage insider knowledge. Or you can do some personal learning and invest wisely. All of these are equally applicable to investing in real estate or to investing in other things while being a renter. For some reason, however, those who profit from real estate are chalked up as lucky and those who profit from other things while renting seem to get to talk as if their success involved any less luck or any more informed investing. Why is this? In my case, I invested in a physical market in a particular region I had been watching for many years and which has generally steady indicators. I exited for entirely personal reasons (to live with my girlfriend, just to put it out there), not to "time" the market as claimed by one commenter who also claimed I got lucky. I was subsequently called out as unhappy by another - you. Again, why is this?

Any argument that can be made for or against success by an owner can be made equally well for or against success by a renter investing elsewhere, yet luck only gets cast towards the former, wisdom only towards the latter, and all the while the latter never seem to publish any of their investment success numbers to match their claims of benefit down the road. Again, why the disparity?

Whether in real estate or elsewhere, it's the same $500 per month during the same five years. Whether sourced from luck and/or expertise, why are one class of returns immediately disparaged while another goes entirely unstated yet entirely uncontested? I've never taken it as an offense personally, but do admit that it does seem to be a common pattern and not a particularly fair pattern, at that.

If I were lucky or if I had made any effort whatsoever to time the market, you might be right. On the other hand, I know of lots of data points like mine, even with the crapfest of the last couple of years. (Sensationalist news articles and statistics about idiots lending too much money to other idiots really shouldn't hold much water to the HN audience, if you think about it.) Regardless, find me that renter and I'll buy them a nice lunch. If I could have made $125,000 during those years then by their own arguments all of these "smart" renters should have been able to do the same through some alternate portfolio of their choice.

As an aside, am I the only person to notice that every time a renter posts these kinds of articles they always talk about how down the road they'll have enough money to buy a mortgage-payer's home but they never actually bother to mention how their investments have been doing for them in the meantime? I suspect there's an obvious reason for the omission.

Agreed.

re: "It always seems to me that the author is simply trying to justify the fact that they rent." - this always seems to be the case. The few renters who seem to do well financially would also do well financially as homeowners but for some reason have convinced themselves that the numbers work out better for renting. Maybe it does for those people, maybe it doesn't. I'll come back to that point in the next paragraph. In the meantime, however, the vast majority of renters one might speak to are just pissing away money, are no further in terms of savings than those with mortgages, and have none of the equity built up that those with mortgages have, even those who are pretty new to their mortgages.

Now, back to whether or not those "smart" renters are any better off. First off, I'll readily admit that my single data point is just that, but it bears consideration nonetheless. I bought property in 2005. In a neighbourhood with some growth potential, in an overall market with generally upward movement. Nothing bullish, just generally upward movement. In fact, that movement had been slowing a bit at that point, and continued to slow somewhat more afterwards. We all know what happened next. I sold early this year. I wonder how many smart renters could have done this _well_, even given the shitty few years I happened to own before selling: I paid $500 more per month than what I would have paid to rent the same space (in other words, put me up against a smart renter with $500 to invest each month), for a total of $30,000 "invested" progressively over those five years. I sold for a net profit of $125,000 after all fees, commissions, etc. In a hesitant market still recovering from the nasty troubles we all know too well.

Find me a renter with that kind of ROI on their investments over the last 5 years and I'll congratulate them over a nice lunch which I'll be happy to buy for them.

(crickets)

Yeah, I thought so.

For what it is worth, if your builds are more CPU-bound than you thought then either your solution is very small overall (which I somewhat doubt) or you have it broken up across too many projects. For a good nine years now almost all .net and vs.net -related build slowness has been due primarily to high project count. A bit of solution restructuring should do the trick nicely for you. Merge some projects and/or shift off some less-frequently-modified projects into separate solutions, cook up some official builds of them, and then bring them back in as binary dependencies.

I have not yet seen any even remotely official information source associating language/compiler/etc. restrictions with background processing, just a growing number of comments like yours claiming that there is multi-tasking magic (for which there is no available evidence or technical reason) and that said magic would fail in the face of alternate languages, compilers, etc.

Can you cite any references for your claims?

For what it's worth, I have had my Android phone for ~17 months and to this date Locale is _still_ its killer app. I simply refuse to own any other phone until it can do the same.

I will certainly understand if iPhone/iPad multitasking arrives with some fairly severe limitations placed on the developers of background apps. Right now there's zero ability in that area so anything, even if severely limited, will still be an infinite improvement (depending on how you like to imagine your divide by zero operations playing out. ;)

Ambiguous? JavaScript Object Notation should probably use JavaScript's camelCasing, no? ;)

Android support was confirmed by Wakemate before they started collecting pre-orders, otherwise I would not have been one of them.

I may have accidentally implied the semi-retirement angle more strongly than my point regarding tending to the first business as if a garden instead of trying to scale it, which was more what I wanted to focus on. Apologies if that wasn't as clear as it could be.

Perhaps I should also have mentioned that he is diversifying, where diversifying is certainly distinct from scaling the first business up.

As far as his first business goes, I still think it is worthwhile questioning the common automatic assumption that the next goal should be to scale it.

re: "The next big question is: Can you scale it ?"

I would like to suggest a potentially more interesting question (or set of questions) :

_Should_ he scale it? If so, why? Why would so many HNers assume the next step to be scaling it? Might he not instead tend to his business like a garden, to ensure that it continues to be healthy, and use his remaining time to enjoy semi-retirement?

I think a lot of HNers could do with considering the above kinds of questions a bit more often. Why are you _really_ doing your start-ups? What are you _really_ looking to get out of them? Is it just to hear the 'ding!' of the cash register more frequently? I hope you're looking for more/different than that.

The editorialized title of the submission may have its problems, but "Correlation != Causation" and equivalent statements need to be consistently downvoted because they, as on every other site where they have for a while now been equally if not even more overused, have become the lazy man's catch-all content-free retort.

Much of what we take as certain once started with observed correlation. This trend of immediately and automatically discounting observed correlations will likely do more harm than good over time, as one would be hard-pressed to hypothesize and later prove (or at least fail to disprove, in the scientific sense) causation if one's habit were to always blurt "correlation != causation" in the face of new information.

On the other hand, many people also drive vehicles with manual transmission because doing so yields measurable improvements in both power output and fuel economy. Vehicles with manual transmissions also tend to be more predictably controlled in adverse weather conditions. Interestingly, but not necessarily surprisingly, these points translate quite directly into the NOSQL argument.

The downside to the manual transmission is simply that when you don't care to exert more driving effort in a given situation that doesn't benefit enough from the increase in enjoyment, power, economy, and control, you're better off with an automatic in that situation. As before, this aspect also translates rather nicely. :)

Someone surely did read the comments: the recruiter and/or one or more members of the HR department.

In all of the companies I have worked in as an employee or with as a consultant, the HR department always has by far the weakest staff. I have also observed that the number and degree of problematic staff in non-HR departments is largely correlated with just how weak the HR department is. This makes complete sense, of course, since it is the HR department that is supposed to address such problems and it is the HR department which usually plays the largest role in disciplinary decisions and firing decisions. The department holding onto firing decisions will always have the weakest staff, and for the simple reason that they aren't exactly going to fire themselves, now are they? :) The rest of the company's staff problems simply fall out from that. Not that I am suggesting that Google has notable staffing problems, rather simply that no matter where you go, even Google, the HR department (or whichever department in reality owns hire/fire, usually HR) will necessarily be the weakest in the organization.

"Who will pay 5 millions $ each year to use H264 on Firefox ?"

I've already paid for my H.264 licenses. Now I just want to use them. The PC to my left has a video card with licensed H.264 that I paid for and free software that harnesses it, the Mac in front of me has both a video card with licensed H.264 and a licensed software decoder and I paid for both, the Windows 7 VM running in the Mac even has a licensed H.264 decoder that I paid for, the phone to my right has licensed H.264 that I paid for, heck the linux-based set-top box in the living room has hardware in it with licensed H.264 decoding and as I'm sure you can guess I'll point out that I paid for that license too. :)

"If H264 become standard, every browser will have to pay the license fee."

Why? I just want Firefox to let me use the licenses I have already paid for.

All they have to do is defer to the appropriate operating system -level decoding support as many have suggested. That they are refusing to do so suggests to me that this has nothing to do with licensing fees and has everything to do with something else we've not quite uncovered yet.

At the end of the day, though, unless the Mozilla folks change their course I can easily see techies supporting family and/or business by saying "just install Chrome" the same way they used to (and to an extent still do, I suppose) say "just install Firefox" when their supported userbase complained about IE. The real risk now is that even if in the end Mozilla's issue is purely one of ideology it won't stop them from having become irrelevant in the process.

bugs' repeated comments being a perfect case in point. I know this entire subject is hardly HN material, but both myself and the vet sitting beside me would like you all to know that:

bugs repeated advice on exercise would, if applied, make sure that Joel's dog leads a short, uncomfortable life due to the kind of overexercise that compounds the kinds of hip problems that already lead to shortened lives in large breed dogs even when exercised properly. Do NOT overexercise a puppy. Especially a large breed puppy.

That said, don't take advise from the internet. Not even mine. Not even if it is from the vet sitting next to me since, while she may be a vet, this is still the internet. Talk to your own vet about what is right for your dog.

Which, in case you didn't know, the MSFT build stack was able to do with C++ projects long before it could with C# projects. I wonder if wglb's referenced company would have liked to know that. ;)

I'm not even so sure that they are unnecessarily complicated to scale, or that you should need or have to replace the features you list. I am sure, however, that everything you list ends up needing to happen if the solution chosen doesn't apply well to the problem at hand.

When you really dig deep down into each and every article on this subject, whether for or against NOSQL, the most important (and yet unstated) fact is this:

It isn't that RDBMS systems scale or don't scale, or that NOSQL systems scale or don't scale, it's that any solution which prioritizes (just for example) consistency and availability is not going to scale effectively for a problem that instead prioritizes availability and partition tolerance.

I am willing to bet that any time a problem and a given solution don't align on the two attributes they've respectively prioritized from CAP, there will be a claim that the solution "doesn't scale". The reality is just that the solution wasn't applicable to the problem at hand. If instead one evaluates solutions which match the problem's CAP priorities, the solutions will scale effectively (modulo their individual pros and cons relative to the other options within the evaluated CAP-priority-matching set of possible solutions, of course.)

re: "steeping time (not that long, else you'll get the bitter flavor bits that no one like)"

As a tip to those who might want to give tea a try, the pattern of increased bitterness with increased steeping time is highly dependent on tea quality. Not necessarily price, but quality.

Don't be afraid to do some research, talk to local tea lovers, etc. to find the best quality (not simply the most expensive, as that is a sure way to just get ripped off) loose tea in your area. You'll be rewarded for it in terms of the freedom you have in steeping time, as better tea can be steeped longer and to stronger flavour without developing bitterness. (Higher-quality tea can also be reused for another steeping or two (gasp!) and still deliver great flavour, making it an even better value.)

For those coming off of a strong coffee habit, you can have yourself a nice, strong (but almost never bitter!) replacement in no time.