I think the problem here is how important physical retailers are as partners in actually selling the console. You don't want to piss off Walmart/Best Buy/Game Stop too much or they might not stock your device.
If (for whatever reason) you have to write code with support for exception handling compiled out, goto statements are incredibly useful. While not quite as syntactically nice as a try/catch/finally paradigm, the combined use of error checking macros and a "cleanup" label can rather elegantly emulate the control flow of exception handling where appropriate.
They're really a closer cousin to the RAII pattern common in C++ than exceptions. Exceptions usually imply action across functions, but here they're just trying to enforce end-of-scope invariants. So if you're writing C++ code with "exception handling compiled out" (such as with Embedded C++, if anyone still uses that) you can still leverage RAII to do a lot of that type of cleanup.
That said, "goto" gets a bad rap in my opinion. Anyone can parrot Dijkstra's "considered harmful" line, but few know the context that it came from. If you've seen large FORTRAN programs from that era, where "GO TO" was the main control flow choice and labels had to be integers you know how even simple algorithms could be made unreadable. Effectively Dijkstra was extolling ALGOL programers not to code as if they were writing FORTRTAN -- in a structured language "goto" is the control structure you need to use least.
Still, there are places where "goto" is the cleanest way to accomplish what you want to do, and you shouldn't fear using it. (Please pick a good name for the label though!) I've seen programmers write crazy twisty code with all sorts of strange temporary variables simply to avoid the use of the forbidden "goto" keyword. Clarity should be your aim, not religious purity.
Also remember that "break;" (except at the end of a switch case) "continue;" and even early "return;" are morally equivalent to the dreaded "goto;" when you think about it. They don't get the same bad press for some reason.
> Also remember that "break;" (except at the end of a switch case) "continue;" and even early "return;" are morally equivalent to the dreaded "goto;" when you think about it.
To a degree - they can't go backwards and what's more important they can't jump into the middle of other control structures. The second case was what's really made it hard to reason about code with gotos.
OK, I'll give you that. A goto into with a tricky destination is a particularly bad case, worse than most uses of "break;" I was just trying to point out that they're all violations of the LISPy ideal where all control flow forms a hierarchy.
OTOH, with nested loops its easy to misinterpret where a "break;" or "continue;" will actually go. This is something that's bitten me many times over the years, especially when reading code with poor or inconsistent indentation. At least a goto is visually unambiguous and maybe even has a helpfully descriptive label.
Also: "continue;" goes 'backwards' for a "while" or "for" loop but "forwards" in a do-while. It's probably the most confusing of the bunch.
I purchased a FitBit based on it's reputation without realizing that I would have to pay to access the data that I'm collecting... deal breaker! As others have said, I understand charging for an ongoing service like analyzing the data and using their site, but not for just accessing the raw data from the device.
For me, this is the first time that not owning my own data has really put me off. I'll be returning my FitBit.
This seems to me like it would be an interesting hypothesis for a an experiment, but a bad idea to suggest/encourage in any "real" (IRS) capacity. Academically the idea is interesting, but the thought of this being actually implemented is a little scary.
... but you could say the same thing about a lot of other areas of research, too. Face detection at Facebook's scale, for example: really cool academically and potentially really scary in application.
My work blocks the .xxx domain as well -- wish I'd looked at the domain before I clicked the link. What do you actually gain from the .xxx? Seems like it's just getting in the way of the discussion here.
Eventual payout from Google aside, I wonder if the team ever regretted the fact that taking funding "changed the yardstick" for success. I'd guess that going back to work for a big company (even with a big payout) wasn't really the original goal.
Remember. The "changed yardstick" is 100% conjecture. It's undeniable that taking outside investment increases the number of people who expect a return from your venture. However, we can't presume to know what the investors were really thinking. They may have known that a talented web and mobile email team will always be a talent buy irrespective of revenues and just sat back and waited to double or tripe their money in 12 - 24 months. Point is - we really don't know if that changed the game that much for them.
I think the sparrow team did what was best for them, and congratulations to them for a successful exit. Goodness knows I'd do the same if I were in there position.
I think what's most disheartening about these types of situations is that as a consumer they make me less and less likely to support startups. Sure, a team like this doesn't "owe" you anything -- you purchase their software and that's the end of the transaction... but if you're going to invest your time and energy into learning, adopting, and loving their product/ecosystem you want to believe that it's got a future. It's a shame that the frequency of these acquisitions (and subsequent shutdowns) erodes consumer confidence in small companies that make great products. Why bother getting yourself hooked on a new product if there's a decent chance it won't be around in another year?
To be fair, Google's current culling of its products shows that this isn't just a small company problem. But I have confidence that GMail will still be around for the foreseeable future. Same for Apple Mail. Same for Outlook. They might not be as good, but at least you can be confident that if you learn their ins and outs it they'll probably still be around in two years.
This looks fine if you're a single developer working on a (relatively) small project, but what happens when you grow to two developers? Or you hand off the project? At that point shouldn't the API registration be tied to the application and not the developer?
That said, it's probably more important to lower the initial barrier for entry to drive adoption.
