nupark2

Slap a case on it and a copy of Ubuntu, double (or triple) that price, and you still have a cheaper option than this USB solution.

When mixing OAuth and native applications written by non-nefarious parties, the only entity you're preventing from reading the user's password is the user themselves.

However, if a nefarious party writes a native app, they can easily acquire the password even if you do use OAuth.

It's a case of bad UX being pushed on users due to fundamental cultural misunderstandings between the web teams declaring authentication requirements, and the native developers who want to provide the best UI.

Twitter is absolutely doing this correctly by providing xAuth for use by native applications.

I think it's a response to the relatively recent over-abundance of attention and coverage given to wheel re-invention and uninformed opinion. I personally tie it to a particular subset of startup culture that relies heavily on convincing young developers to serve as grist for the startup mill by appealing to their ego.

This is why "forking" an open-source project was considered a nuclear option prior to the emergence of github.

I rarely even get pull requests from people forking my code on github, and when I do, they almost never have bothered to discuss with me prior to implementation. It's a relatively recent phenomena that is largely encouraged by the tools.

Forking a project is a huge deal. Forking a git repository is no big deal.

Github does the former, and it encourages too-broad forks, and at the same time, discourages coordination and contribution with the original project. Nearly all forks should be short-lived and completely subsidiary to the main project.

Create a clean, easy-to-use, app-store-enabled experience, without lots of cables, multiple boxes, and ugly UIs.

That is a bit unfair, but unsurprising. People choose to work where they want to live, and they'll work with the people they're most familiar with and understand, in the environment around them.

This is the classic response. It's also ridiculous. It's not just a matter of "passing the wrong type", it's a matter of using the type system to express higher-level constraints that make it impossible to introduce bugs in a complex system -- bugs more fancy than "I passed a string when I should have passed an int".

Of course, passing a string when you should have passed an int happens with regularity, too, and claims otherwise are a lie, especially if you don't spend a ridiculous amount of time pretending to be a compiler by writing extensive unit tests that would be totally unnecessary if you had one.

> And I never claimed that LINQ or C# lambdas were derived from Ruby, just that they were Ruby-ish. Clearly someone in Redmond is watching Ruby and Rails.

What? I ... no. I point out a 1965 paper on lambdas and you claim MS R&D is watching Ruby? You're comparing LINQ -- which implements a coherent model of relational algebra and set theory -- to Rails?

Ruby didn't pioneer these things, didn't add anything novel to them, implemented inconsistent models of them, and can't take any credit for them.

You mention LINQ as somehow deriving from Ruby -- it doesn't, it derives from set theory, relational algebra, and some very careful consideration of how to model those in a typesafe environment. You fail to mention that LINQ is type-safe, which is an enormous advantage to its use compared to traditional approaches of modeling set theory / relational data problems, and has value for things well beyond databases or querying simple data structures, eg: http://msdn.microsoft.com/en-us/data/gg577609

You claim lambdas as Ruby-ish idioms, and yet totally ignore where "lambda" derives from: lambda calculus. This is not a Ruby-ism, and Ruby discards much of what is of value in lambda calculus: http://en.wikipedia.org/wiki/Lambda_calculus#Lambda_calculus...

Ruby is a "me too" on those fronts, and not a particularly novel one.

And unsurprisingly, Linux is a terrible overall example of quality kernel development and design.

> If the Ruby community had a general atmosphere or a policy of encouraging sexist or unprofessional behavior, I'd let these remarks slide. But it doesn't.

Except that the only times I've ever had to deal with (or hear of, third-hand) a general atmosphere of sexist, unprofessional behavior in technology has been in relation to the startup community in general, and the Ruby community in particular.

Its driven from the top, largely because most mature programmers that would provide a counter to community immaturity have no reason or need to use Ruby.

> Nevertheless, it seems to me you've become the thing you claim to despise: insular and closed off to experiences that would contradict your dogmas.

That would be the opposite of "polyglot". I can find value in Clojure's concurrency design, Python's scientific community, Scala's marriage of OO and functional, F#'s modernization of ML environments, C#'s language design, ObjC's UIKit/AppKit libraries, C's propensity for close-to-the-metal optimization without dropping to assembly, Haskell's lazy evaluation and functional purity, OCaml's mixture of pure functional with mutable state, Erlang's micro-thread actors, Java's virtual machine, Smalltalk's REPL-on-steroids, lua's JIT.

However, almost nothing from Ruby. The technology there is almost totally uninteresting -- it's just yet another imperative scripting language with a poorly designed runtime -- and the community, unlike Python's, doesn't make up for it. In fact, that Ruby community is one of the primary things that seems to give technologists a bad name outside the technology industry. When I hear tales of sexist conference behavior, inappropriate language in presentations, and outright bad wheel-reinventing technology, the tales are almost always tied to either Ruby, youthful startups, or both.

So -- no, I don't look forward to them joining the rest of us in the iOS space.

- Despite the opinion clearly being unpopular here, I stand by it: the ruby community is toxic-at-best, and totally technogically uninteresting.

Individual Ruby developers may be very nice people, but that doesn't make the technology any more notable or novel, and doesn't change the general tenor of the Ruby community, which seems to be driven by larger than life personalities and a general lack of solid applied computer science.

Culture aside, simply technologically, Ruby has nothing significant to offer as compared to the many existing languages and technology stacks, especially those pushing forward language and runtime research. The only argument for Ruby here seems to be opening the market to developers unwilling to move beyond it.

We already have -- and without great fanfare -- Lua, JavaScript, C# (MonoTouch), et al. This seems somehow different.

Yes. If the choice is between UX and cost, I'll almost always pay more.

Not everyone will, but the people that don't are less profitable customers, as Apple is demonstrating.

If Apple wasn't forcing the larger industry to learn how to turn a profit by putting users first, the market would simply saturate the app store with whatever existent concepts are popular today.

Remember, prior to iOS, the Mac OS X market was both cry user friendly and very insular. Now, iOS has gone mainstream, but Apple's user-friendly focus hasn't (yet?).

Of course, your open market does still exist -- users can choose Android, which thrives on the notion of 'user choice'.

As for the payment question, simply in terms of UX and as a consumer, I want only one payment provider and account on the device. I hate pulling my credit card out and remembering my password for the nth account.

Consumers are happy with the platform. Look at the sales numbers and earnings reports. Obviously companies like Dropbox see the value in the platform too -- I just wish they'd take the time to understand why it has that value, and why Apple has huge profits and very happy users.

That's simply a tremendous percentage of your staff dedicated to putting out fires.

37Signals would see significant savings in development and maintenance costs -- and increased customer satisfaction -- if they approached this staffing requirement as a band-aid, not as a final solution, and took a long, considered look at the root cause of this systemic failure.

Which only goes to support the notion that much of Ruby's community has issues from the top down. We're speaking of computer science, in which objective, rational analysis leads to correct answers -- not appeals to emotion and an almost religious acceptance of poor solutions.

For every serious Ruby contributor and leader like Charles Nutter (JRuby), there are 5 DHHs or DDH adherents shouting down professionalism as if it was an anathema to logical expression.

Specifically, this comes to mind:

http://lifehacker.com/5859392/swearing-to-make-your-point-a-...

As well as this:

http://www.zedshaw.com.sharedcopy.com/rants/51489cec9386f7c1...

And this:

http://david.heinemeierhansson.com/posts/15-potty-mouths

There are more, but I don't think I need to internet-sleuth the entire set of well-known Ruby / Web personalities to demonstrate the point: a base lack of professionalism abounds.

You're just hand-waving away the issue. "Yes, you have to keep far more in your head at once to make sure you don't step on a PHP landmine, but that's why we're paid the big bucks!"

I'm sorry, but this is a false dichotomy and an inaccurate parallel with C. C's landmines are well-defined, understood, and derive from the target purpose (portable assembly). PHP's landmines are ambiguous, ill-defined, and just plain stupid, often caused by what amounts to a truly brain-dead lack of cognitive effort on behalf of the language authors. The language is poorly specified such that even if a developer should wish to invest sufficient effort, it's impossible to know where they all are.

Moreover, there are such ugly corner cases built into the language and common libraries that some landmines are entirely unavoidable. Whose brilliant plan was it to make fopen() accept URL parameters instead of defining a common stream API that arbitrary stream types could support?

Let's say I want to treat a byte array as a stream -- this is a pretty common thing to do in most languages:

  fopen('data:text/plain;base64,'.base64_encode($data), 'rb');

> And did that inertia spontaneously emerge from a vacuum? In the spirit of PHP's namesake you've devised a recursive argument to explain the only conceivable upside to using PHP.

PHP's inertia emerged out of ill-qualified individuals adopting the language as the most visible available option during a time when there was largely a dearth of options and limited understanding of the web as a platform and "what comes next" from CGI.

People -- collectively, as a group -- adopt poor solutions to their problems, simply as a matter of compounding gravitation and a lack of understanding of the long-term implications.

It's simple group decision making, and it's not reasoned, nor is it necessarily likely to produce the best possible answer, or even a good one -- especially when the group in question is ill-equipped to understand the problem space they're working in.