Comment by ergo98 | Hacker News Reader

Comment by ergo98 | Hacker News Reader

Parent Full thread

Reading his comments, he sounds like many developers when faced with tools they aren't accustomed to using languages they aren't competent at: Instead of acknowledging confusion and ignorance (in the polite way of saying it), turn it into criticisms of the externals.

Look at virtually everyone new to JavaScript and web development as a great example of this. Even brilliant minds, when first introduced to the surprisingly powerful JavaScript, post diatribes of dislike for it.

For instance consider-

"A bit surprised how many hoops I have to jump through to do asynchronous HTTP on Android. NSURLConnection+delegate was so easy."

So how does one do asynchronous HTTP on Android?

http://stackoverflow.com/questions/828280/is-there-an-accept...

Is that hard? What hoops are there? It is extraordinarily straightforward, and is built such that you are essentially the commander and chief of a centralized asynchronous mechanism. But yes, if you look for it to be exactly like you've done it before, it might seem Byzantine.

Android has a tremendous number of quirks and imperfections, but I see no reason why Joe Hewitt's opinion is of any significance.

I never said it was "hard", just that I was surprised that the simple task of "get me this URL" required me to work with some abstract classes for "async tasks". Strikes me as overengineering. The networking classes could easily encapsulate the threading stuff and let me just stay on the UI thread, as every other networking library I've ever worked with has done.

I've found other places in the Android SDK when, rather than simply using callbacks to encapsulate asynchronous work, I'm required to deal with the threads myself (see GLSurfaceView). You can accuse me of being "confused and ignorant" but I feel I am making a valid critique of the API design.

AsyncTask does encapsulate the threading stuff though.

The HTTP APIs aren't Android specific - they're just the standard Java API and Apache's HttpClient. I suppose Google could create another API on top of these APIs (and all the other ancient and poorly designed Java APIs), but since Java's "callbacks" are objects with methods you override, you aren't really saving yourself much.

I love that here on HN you frequently get comments from the original author or subject of the article.

Completely agree. I'm faced with the relatively simple task of accepting a self-signed certificate. The things that HttpClient is making me do ...

>You can accuse me of being "confused and ignorant"

It isn't an accusation or an insult: Every developer on the planet has recurring periods where they are confused and ignorant. I can't make any such a claim in this case, but can only point out that such public displays often grow from such temporary roots.

However yes I cede a thousandfold that Android has an endless array of quirks and nuances that seem...non-optimal. Parts of the API show their Google lineage, while other parts draw from the Java norm. And on the "quirksmode" thing, couldn't agree more.

It was the "Android Tools Are Horrendous, OS Is Hideous" bit that caught my eye: I can't imagine someone seriously developing for something they consider hideous, with horrendous tools, especially when they have shown themselves to be principled.

I am obviously expecting that in a few years time Android will suck much less, or I wouldn't bother investing time in it.

I actually found reading through his tweets that a lot were valid criticisms. I'm disappointed that there is such a "fanboy" divide on Apple vs Android. Why can't we acknowledge there are pros and cons of both and accept that different things bother people differently?

Are you new to the Internet?

There are absolutely pros and cons of both. There is no question about it. However Joe is being used as a pawn with people quoting over his over-the-top hyperbole like "Android tools are horrendous, OS is hideous". That isn't a "pro and con" point.

I somewhat sense that Joe is perhaps still fighting his evangelical battle about the Apple thing (note that I'm not taking his Tweets as ultra serious, and I picture some jocular hyperbole, even if some net reporter takes it as statements of concrete truth), and it's like Android is his abused rebound mate, used as a prop to try to strike back. Like he's trying to aggrandize how extraordinary his suffering is to announce the depth of his principle.

That's how media works. I'd argue that some of the news stories that came out about him quitting over App Store policy were over-the-top hyperbole.

> Is that hard?

No, but he never said it was hard.

> What hoops are there?

it's not built into the HTTP request process, even though async HTTP is what you want... basically always. With the example, for every single type of request you have to create a new class. If you generalize the thing a bit, you only have to write an anonymous class every time.

He's comparing that to NSURLConnection where 3 out of the 4 constructors (well technically 1 constructor and 2 initializers) are asynchronous and simply take a request and a delegate (total: one line).

>it's not built into the HTTP request process, even though async HTTP is what you want... basically always

In the Android world that simply isn't the case, and thread-oriented (as opposed to evented) development is the most common strategy, which is why the calls are synchronous -- you toss off a thread to do some web service calls, processing the request and updating the UI.

Regardless, a universal HttpAsyncTask class, with an oncomplete delegate, is a trivial undertaking (there is no need to create one for every unique call). Should there be one in the stock library? Maybe. The lack of one by default is indicative of the fundamentally different general approaches however. Not better or worse, just different.

I've been writing code on android for almost a year now have even made modifications to some of the tools and android itself to meet our needs, and I totally agree with all of his complaints.

I agree that the way you show is easy. Could he have been doing it in some other fashion that is not that straightforward and assumed that it was the only way to do it? Probably. Was he jumping the gun by saying that there were too many hoops. Definitely.

Yes,

This is a common pattern. But it's a pattern that includes very good developers.

That's because just about all tools and environments today are "awful", are unintuitive and overly complex and it's actually useful to vent and then get your understanding of the situation under control. Then you can move on to producing something useful.

No one has yet produced tools and environments that seem in sane except to those who are used to them and adapted to their compromises. Good developers don't silently accept the excuses but stay frustrated on some level - it's an incentive to produce better stuff. Obviously, you still do want to channel this frustration into reasonably moderate and useful directions.

Reply on news.ycombinator.com