Comment by loewenskind | Hacker News Reader

Comment by loewenskind | Hacker News Reader

Parent Full thread

Do you like functional programming? One of the nice things about functional programming is that I can see right away what is being done with a collection. Map is applying or "mapping" some translation to the list to create a new one, filter is taking a subset of the collection that meets some criteria. In e.g. C you just have that big dumb for loop. You want to know what is being done to the the collection? Well, you're just going to have to read the whole thing. Every time.

The problem is that there are several different kinds of things you want to do to a collection, but in C you just have the for loop and have to keep writing e.g. filter every time you need one. Over and over.

Apple gives you the functional approach to multitasking: there are a handful of things you actually want to use multitasking for and they're all supported with the api. You're complaining that they didn't give you that dumb for loop so you could just do it all yourself by hand. Over and over.

To make your comparison more precise:

Apple gives you a fixed set of functions that you can pass to map(). Other OSes give you chance to write your own functions that you will be able to pass to built-in map.

That's simply not the case. My analogy is exactly how I wanted it. What things do you want to do with a service? Run a background thread to completion? You can do that. You want to play music when your app is in the foreground? Covered. Want to receive notifications from the network? Check. What to do certain tasks at scheduled times? Affirmative.

Further, if I'm reading your code I don't have to go "Oh God, they started a thread. What do they think they need it for...", I can just look at what API you used and I know exactly what the goal was. Exactly the same advantage that map/filter/reduce/etc. have over a for loop.

Sorry, but your argument just supports mine.

It is basically: what do you want? This or that supplied function covers your need, you can pass it. Sorry, you can't make yours, what would you possibly want?

Honestly? I don't know right now. Maybe I will have earth-shattering idea next week or month, but I don't know right now. The point is, the original authors of map didn't try to envision what you are going to use map for, and provide enum for choosing an appropriate action. They allowed you to pass any function you want, doing whatever you want.

For example, when speaking about Android, the framework contains class that handles things like managing threads for you. You just plug-in the required functionality, just like you pass your function to built-in map. The boilerplate that you are arguing against is simply not there. Just like with map you know, that "this function will be applied for every item in set" or with filter you know "you will get new set containing items from original set for which the supplied predicate is true", you know that "this functionality will run in background". The accidental complexity of managing it is hidden; the functionality allowed is not fixed.

No, I don't think you understand my argument.

>This or that supplied function covers your need, you can pass it. Sorry, you can't make yours, what would you possibly want?

We've had concurrency and services for decades, we already know every general action you can possibly do with a service. No one is going to come up with some totally new novel use for a background service anymore than anyone will come up with a new general action to apply to lists. Everything you would ever want to do with a background service can be divided into about 5 kinds of tasks and those are covered. Full stop.

If you disagree then please describe some act with a service and I'll explain to you how that already fits in one of the 4 or 5 kinds of things people do with services. Proposing that some day, some where someone may come up with something that doesn't fit this mold is just hand waving.

Everything you would ever want to do with a background service can be divided into about 5 kinds of tasks and those are covered.

AFAIK it's not possible to simply keep an SSH or IM connection open when you switch to another app.

You can have your app continue to run for up to 10 minutes after it's been closed, so it should be possible to use that time to keep your connection open. If no one has contacted you in 10 minutes then chances are they wont in the next 10 either so it would be better to switch to push notification and let the phone manage notifications.

Keeping SSH or IM connections open is an action of a well known use for servers; listening for updates. And that's covered in the API.

Write an IM app for the iPhone 4.

You're wrong. These are the same excuses that people always make for apple, that simplicity and functionality are mutually exclusive. This excuse seems to usually be made ONLY for Apple. Why can't they have their easy to use APIs but ALSO have the ability for real developers who want to write "that same for loop over and over", or who, you know, what to write something like an Instant Messaging application do so?

What are you talking about? What functionality does an instant message application need that isn't supported? It can get push notifications if someone sends you a message. You could even leave your app running for up to 10 minutes in the background waiting for updates if you wanted (which probably matches actual usage pretty well).

What you can't do is have your app sitting in the wait queue for data coming in over the wifi because that would mean the wifi card has to run constantly. Ask Android how quickly doing that can drain your battery.

You get AOL to add support for apple's push server into their Oscar protocol chain and I'll concede.

My battery lasts fine and I'm generally logged into IRC and/or meebo for most of the day in addition to the Google Talk that I leave signed in and my three email accounts that get updates. etc, etc. The battery woes are simply unjustified for the most part.

I couldn't find the article in 30 seconds, but I recall someone from Google, Android or one of the carriers (i.e. someone qualified to talk about it) who acknowledged the battery issue and pointed to exactly this as the culprit.

Reply on news.ycombinator.com