Sorry, let me translate it into non-nerd-speak for you: Your suggestion that this news is too old to be worthy of being published here implies that we all ("universal") should have read ("absorption") this news at the same time ("synchronous") months ago ("real-time") -- when, presumably, you did -- is unrealistic and naïve.
I don't think you read my response very closely, wherein I expect them to expose an API at a later date that does this in a safe manner. Nice straw-man, though.
I dunno bout that...I think expecting universal, real-time synchronous absorption of news is pretty unrealistic, and is grounds for handing in your own nerd card.
Be honest, the set of people who frequent slashdot is so large and diverse that you could re-skin your post to be about a myriad other issues and still manage to fool some mods out of some +1 Insightful points -- because, let's face it, the "slashdot community" still hasn't come to a universal conclusion that preventing unrestrained pointer-arithmetic is a good thing for a programming language to do. ("The nerve of a language designer to tie my skilled, pointer-manipulating hands!")
But let's put your fallacious overgeneralization about slashdot aside, and address why an accomplished, software-engineering denizen of this forum might come to the conclusion that a moratorium on unrestrained background activity might be a good idea on a portable, battery-driven embedded platform.
The previous sentence gave you all that you need to connect the dots for yourself, but I'll spell it out plainly: Imagine 15 developers, all of whom can responsibly write an application that only wakes up and polls something over the network every 5 minutes. Now imagine a user who has installed these apps. It could easily happen that -- by a uniform spreading of the moment that each app's background thread decides to wake & run -- that the clever power-management facilities in the device have now been trivially defeated: with the radio transmitter(s) now in almost constant operation. Furthermore, the resulting effect on battery life cannot easily be blamed on any of the 15 programmers, because each one of them in this hypothetical scenario was judicious in their use of resources in the background.
So where is the blame going to fall? On the creator of the platform, of course. This being the case, it would behoove Apple to take a step back, think about the problem, and -- after some thought -- offer a sensible API at a later date that can meet this need for developers while having as little impact on battery life as is needed. A queueing mechanism, perhaps.
And, speaking of amazement, I'm shocked that more programmers in various tech-related forums don't foresee the mess, let alone desire to forestall it.
FWIW, the parallel of the API feature with the clitoris was also a parallel of impatient programmers with the school boy's in this scene. I hope that clears that up.
This reminds me of the myth of the platonic dish, "milky weak coffee" versus the "rich, dark, hearty roast", and many other things from Malcolm Gladwell's famous TED Talk. There is no such thing as a perfect pepsi...
It can multitask. Several built-in applications do already. What you mean to point out is that the SDK does not currently expose an API for you to write an app that does things in the background.
Hard to believe Apple think limiting their iPhone in the same way is a good idea...
Agreed, but only if you imagine that they intend it to be this way for all time. It wasn't long ago that you would hear people say "it's hard to believe there's no SDK for the iPhone". Back then, I would reply "just you wait. Shipping a solid, documented, stable API is hard work. They'll give us one when they're ready. Before long, they announced it. Now it's here.
I think limiting the SDK in this way in the short term is a good idea. Although I'll agree that limiting it in this way in perpetuity does not. As embedded chipsets become more powerful, and their software becomes more refined, they'll do the right thing.
I think your use of the word "yet" is very important, and should not be understated. Let's face it, developers have a bad habit of always stampeding straight for the clitoris. If Apple first establishes a community of developers who have mastered the basics, and a stable of applications that behave well, then they can add some safe, well-thought-out background-processing API in a future version. The benefit of this is that soon the web is going to fill up with example code as people share tips with each other. As a second wave of iPhone developers emerges, they'll likely encounter safe example code in their searches.
You must be addressing the anonymous reader who submitted the writeup. I don't think it's at all reasonable for someone to expect that a Skype app should function over AT&T's cellular network. The SDK allows such an app to work over WiFi, and that's great. Expecting to circumvent AT&T's charges over their own network is absolutely ridiculous. What an idiotic writeup.
If he's saying that his multicore processors are going to be hard to program, then self-interest suggests he be very very quiet (;-))
This morning my son, already almost late for the bus to school, asked me to teach him how to make a cafe mocha (we lost an hour due to 'daylight savings time', and he wanted a jolt of caffeine). Teaching such a thing takes time. At best he had enough time to drink a shot of espresso. But what he really wanted was a cup of cocoa with caffeine in it. Could I get him to drink espresso?
"I'll pull you a shot if you're man enough to drink it," I said, applying gentle pressure to his ego.
"I am," he said weakly.
I looked him hard in the eye: "Are you!?"
He straightened his back, squared his shoulders, and solemly replied: "yes."
I turned my back to him so that he could not see my grin. I pulled him a double shot and handed it to him.
He drank it.
Hard to program, eh? Taunt enough geeks and someone will step up and solve the problem.
Really? Other companies have put 3G in a phone without making serious tradeoffs that make the resulting product very much unlike the iPhone? Do give an example.
And here I was thinking it had more to do with how much power the 3G chips consume, and how it would negatively effect how many hours you can get out of a fully charged battery. I'm shocked that Woz would be puzzled by this. He used to work with hardware, didn't he? Maybe he simply never did embedded hardware, and so it's out of the realm of his experience. But, shit, I'm just a programmer and I can understand that much.
Does anybody else out there remember the music video with Rob Malda and 5 or 6 other guys playing guitar accompaniment to something -- I forget what it was...perhaps Richard Stallman's classic tune "Come on people, Share the software"?
Well, that's the first thing that came to my mind in the Rehabilitation Night scenes that showed the Guitar Army.
On a different note, who did the voice of the monster-truck arena announcer? I swear it's the voice of Strongbad, but I can't find any credit.
No, but you did use the phrase "truly open mind", which is exactly what the Dawkins quotation is about -- not religion. Dawkins commonly uses this saying to encourage people to acknowledge that even something generally good, like "having an open mind", can be taken too far. Apparently, the person who responded to you thought that you were using the phrase "open mind" to discourage skepticism regarding something that warrants it.
Wow, that makes so much sense. I've never been able to explain why they would introduce something like XMLHttpRequest. I was unaware that its history was tied to outlook web access. I think you're right: they screwed up to our benefit, and now they're trying to put the genie back in the bottle. Thanks for that little history lesson!
Incidentally, you may want to investigate JSNI -- GWT's JavaScript Native Interface. It allows you to write incantations in your Java code that can call out to other JavaScript libraries -- if there's something you'd like to be able to exploit within the scope of a GWT project.
I'd like to see something like GWT where the source language is Javascript instead of Java - that is a Javascript to Javascript compiler where you could add whatever local features you need and have the compiler throw away the fluff and stick in cross-browser compatible shims.
You'll probably not get this wish any time soon. An essential design choice in GWT is that the source language uses static typing. This is what allows for the resulting "binary" (javascript) to be as small as possible (everything is monolithically compiled as one unit, and so the compiler can dead-strip any code that is provably never called -- and that "proof" hinges on static typing. Incidentally, the static typing is what makes fancy method/member completion in IDEs like Eclipse/Netbeans possible too. You'll not be seeing tools like that for JavaScript any time soon.
GWT is a brilliant design. I'm so happy someone thought to create it. I realize there are a couple of other things out there in a similar vein, but GWT is the only one that focused on building excellent web applications, rather than trying to make fat-client-apps-in-a-browser or X11 emulators.
I think a lot of facebook users do care that they also maintain duplicate profiles on myspace, etc... an open protocol for profile & network information would mean that a friend in my network wouldn't have to use the same social networking site that I do -- so long as they used one that supported the API.
I just had my "ah-ha" moment with social networking sites after experiencing the iPhone-optimized version of their interface (which is mercifully devoid of all of those horrible apps): it's not about making web pages about yourself...it's a communication medium. In particular, one geared towards expanding your network of social connections. All of those dumb things that people write on each other's walls are like little ICMP packets people send to each other in the process of maintaining those relationships.
Slashdot Mirror
Sorry, let me translate it into non-nerd-speak for you: Your suggestion that this news is too old to be worthy of being published here implies that we all ("universal") should have read ("absorption") this news at the same time ("synchronous") months ago ("real-time") -- when, presumably, you did -- is unrealistic and naïve.
I don't think you read my response very closely, wherein I expect them to expose an API at a later date that does this in a safe manner. Nice straw-man, though.
I dunno bout that...I think expecting universal, real-time synchronous absorption of news is pretty unrealistic, and is grounds for handing in your own nerd card.
Be honest, the set of people who frequent slashdot is so large and diverse that you could re-skin your post to be about a myriad other issues and still manage to fool some mods out of some +1 Insightful points -- because, let's face it, the "slashdot community" still hasn't come to a universal conclusion that preventing unrestrained pointer-arithmetic is a good thing for a programming language to do. ("The nerve of a language designer to tie my skilled, pointer-manipulating hands!")
But let's put your fallacious overgeneralization about slashdot aside, and address why an accomplished, software-engineering denizen of this forum might come to the conclusion that a moratorium on unrestrained background activity might be a good idea on a portable, battery-driven embedded platform.
The previous sentence gave you all that you need to connect the dots for yourself, but I'll spell it out plainly: Imagine 15 developers, all of whom can responsibly write an application that only wakes up and polls something over the network every 5 minutes. Now imagine a user who has installed these apps. It could easily happen that -- by a uniform spreading of the moment that each app's background thread decides to wake & run -- that the clever power-management facilities in the device have now been trivially defeated: with the radio transmitter(s) now in almost constant operation. Furthermore, the resulting effect on battery life cannot easily be blamed on any of the 15 programmers, because each one of them in this hypothetical scenario was judicious in their use of resources in the background.
So where is the blame going to fall? On the creator of the platform, of course. This being the case, it would behoove Apple to take a step back, think about the problem, and -- after some thought -- offer a sensible API at a later date that can meet this need for developers while having as little impact on battery life as is needed. A queueing mechanism, perhaps.
And, speaking of amazement, I'm shocked that more programmers in various tech-related forums don't foresee the mess, let alone desire to forestall it.
FWIW, the parallel of the API feature with the clitoris was also a parallel of impatient programmers with the school boy's in this scene. I hope that clears that up.
This reminds me of the myth of the platonic dish, "milky weak coffee" versus the "rich, dark, hearty roast", and many other things from Malcolm Gladwell's famous TED Talk. There is no such thing as a perfect pepsi...
It can multitask. Several built-in applications do already. What you mean to point out is that the SDK does not currently expose an API for you to write an app that does things in the background.
Rejoice: FF3 has some garbage collection improvements that should fix many leaks caused by browser add-ons.
Hard to believe Apple think limiting their iPhone in the same way is a good idea...
Agreed, but only if you imagine that they intend it to be this way for all time. It wasn't long ago that you would hear people say "it's hard to believe there's no SDK for the iPhone". Back then, I would reply "just you wait. Shipping a solid, documented, stable API is hard work. They'll give us one when they're ready. Before long, they announced it. Now it's here.
I think limiting the SDK in this way in the short term is a good idea. Although I'll agree that limiting it in this way in perpetuity does not. As embedded chipsets become more powerful, and their software becomes more refined, they'll do the right thing.
I think your use of the word "yet" is very important, and should not be understated. Let's face it, developers have a bad habit of always stampeding straight for the clitoris. If Apple first establishes a community of developers who have mastered the basics, and a stable of applications that behave well, then they can add some safe, well-thought-out background-processing API in a future version. The benefit of this is that soon the web is going to fill up with example code as people share tips with each other. As a second wave of iPhone developers emerges, they'll likely encounter safe example code in their searches.
The major difference is that Apple understands how to design products.
There, fixed that for ya.
Just think of it: 100 tonnes of USDA grade A beef grown in saline tanks!
"Good way to turn a positive thing negative"
You must be addressing the anonymous reader who submitted the writeup. I don't think it's at all reasonable for someone to expect that a Skype app should function over AT&T's cellular network. The SDK allows such an app to work over WiFi, and that's great. Expecting to circumvent AT&T's charges over their own network is absolutely ridiculous. What an idiotic writeup.
If he's saying that his multicore processors are going to be hard to program, then self-interest suggests he be very very quiet (;-))
This morning my son, already almost late for the bus to school, asked me to teach him how to make a cafe mocha (we lost an hour due to 'daylight savings time', and he wanted a jolt of caffeine). Teaching such a thing takes time. At best he had enough time to drink a shot of espresso. But what he really wanted was a cup of cocoa with caffeine in it. Could I get him to drink espresso?
"I'll pull you a shot if you're man enough to drink it," I said, applying gentle pressure to his ego.
"I am," he said weakly.
I looked him hard in the eye: "Are you!?"
He straightened his back, squared his shoulders, and solemly replied: "yes."
I turned my back to him so that he could not see my grin. I pulled him a double shot and handed it to him.
He drank it.
Hard to program, eh? Taunt enough geeks and someone will step up and solve the problem.
Other companies seem to be able to pull it off.
Really? Other companies have put 3G in a phone without making serious tradeoffs that make the resulting product very much unlike the iPhone? Do give an example.
And here I was thinking it had more to do with how much power the 3G chips consume, and how it would negatively effect how many hours you can get out of a fully charged battery. I'm shocked that Woz would be puzzled by this. He used to work with hardware, didn't he? Maybe he simply never did embedded hardware, and so it's out of the realm of his experience. But, shit, I'm just a programmer and I can understand that much.
To be a realistic parody, you'd have to name the act "RESTORE" and have it be an acronym that stands for reinvigorating intellectual property rights.
Thank you for posting here. I'm shocked that nobody has created a wikipedia article from your posts yet. :-)
NO WAI!
Does anybody else out there remember the music video with Rob Malda and 5 or 6 other guys playing guitar accompaniment to something -- I forget what it was...perhaps Richard Stallman's classic tune "Come on people, Share the software"?
Well, that's the first thing that came to my mind in the Rehabilitation Night scenes that showed the Guitar Army.
On a different note, who did the voice of the monster-truck arena announcer? I swear it's the voice of Strongbad, but I can't find any credit.
No, but you did use the phrase "truly open mind", which is exactly what the Dawkins quotation is about -- not religion. Dawkins commonly uses this saying to encourage people to acknowledge that even something generally good, like "having an open mind", can be taken too far. Apparently, the person who responded to you thought that you were using the phrase "open mind" to discourage skepticism regarding something that warrants it.
Wow, that makes so much sense. I've never been able to explain why they would introduce something like XMLHttpRequest. I was unaware that its history was tied to outlook web access. I think you're right: they screwed up to our benefit, and now they're trying to put the genie back in the bottle. Thanks for that little history lesson!
Incidentally, you may want to investigate JSNI -- GWT's JavaScript Native Interface. It allows you to write incantations in your Java code that can call out to other JavaScript libraries -- if there's something you'd like to be able to exploit within the scope of a GWT project.
I'd like to see something like GWT where the source language is Javascript instead of Java - that is a Javascript to Javascript compiler where you could add whatever local features you need and have the compiler throw away the fluff and stick in cross-browser compatible shims.
You'll probably not get this wish any time soon. An essential design choice in GWT is that the source language uses static typing. This is what allows for the resulting "binary" (javascript) to be as small as possible (everything is monolithically compiled as one unit, and so the compiler can dead-strip any code that is provably never called -- and that "proof" hinges on static typing. Incidentally, the static typing is what makes fancy method/member completion in IDEs like Eclipse/Netbeans possible too. You'll not be seeing tools like that for JavaScript any time soon.
GWT is a brilliant design. I'm so happy someone thought to create it. I realize there are a couple of other things out there in a similar vein, but GWT is the only one that focused on building excellent web applications, rather than trying to make fat-client-apps-in-a-browser or X11 emulators.
I think a lot of facebook users do care that they also maintain duplicate profiles on myspace, etc... an open protocol for profile & network information would mean that a friend in my network wouldn't have to use the same social networking site that I do -- so long as they used one that supported the API.
I just had my "ah-ha" moment with social networking sites after experiencing the iPhone-optimized version of their interface (which is mercifully devoid of all of those horrible apps): it's not about making web pages about yourself...it's a communication medium. In particular, one geared towards expanding your network of social connections. All of those dumb things that people write on each other's walls are like little ICMP packets people send to each other in the process of maintaining those relationships.