allertonm

Yielding inside a callback isn't a problem. I was actually thinking of the other yield you would need, the equivalent of suspending the continuation - but I later realize that this is no harder than the continuation case. So I was just being dense, my apologies.

And it appears that Ilya (the OP) has been looking at this approach using fibers too http://www.igvita.com/2010/03/22/untangling-evented-code-wit... - and the comment thread on the OP suggests that this is in use at Postrank.

Perhaps I'm being a bit dense, but it's hard to see how one could take an existing asynchronous API and adapt it to use co-routines, since the point where you'd ideally want to "yield" is behind the API - and it may not be desirable or even possible to change this (for example, changing a C-based driver to use Ruby-level co-routines would be a challenge.) OTOH it's fairly straightforward to store a continuation and resume it in a callback.

So while I think you're correct, pragmatically I suspect this approach has more chance of being implemented.

Good piece - having built a big Rails application, I love the speed of development but your comments about scaling totally resonate. Actually it was even worse in my case due to us using jruby (add VM overhead to the mix.) RAM is often the most expensive component of the cost to run an application and as things stand now Ruby/Rails makes it hard to keep those costs down.

I really like the idea of using Ruby's continuations to avoid the need to write all of your logic in CPS (ala node.js.)

From the memory standpoint, doesn't this just move your memory overhead from the machine stack to continuations on the heap? I do realize there are some advantages to heap over stack, especially on 32-bit architectures.

And in addition, what kind of overhead do you get when creating a continuation for the kind of deep call stacks you're dealing with?

I pointed to that image only in relation to the EXIF metadata, since the original article suggested that this problem was the "straw that broke the camel's back" - i.e even if you were prepared to live with the 2-application workflow, even that was not possible. This appears to be false.

Well, the point is that the photos didn't originally have geotag info, that came from the iPad - but the resulting photos have that and the original EXIF metadata.

Author of Windows app suggests customers choose a Windows netbook over an iPad - film at 11.

FWIW, I don't buy the claim that it's impossible for applications to get hold of photo metadata - I happen to know someone who is working on an iPad photo application and they don't seem to be having this problem (as evidenced by http://www.flickr.com/photos/carlitos/4669066513/ )

Same on Safari (4.0.5, Mac)

I'm sorry, but he's just not that into you.

Attacking CAP seems to be a recent theme - Stonebraker did this a few weeks back (http://cacm.acm.org/blogs/blog-cacm/83396-errors-in-database...)

Abadi's take seemed more interesting to me since it isn't rubbishing CAP as such, but noting that C, A & P are not symmetrical and also that there is a fourth consideration - latency - that most discussions of this topic do not take into account even though it is clearly a design factor in some existing NoSQL databases.

Unlike an iPhone, the iPad is not designed to be carried in a pants pocket.

We'll have to see how this pans out. The language in 3.3.1 puts Javascript and the Cs into two separate categories with regard to access to "the documented APIs" and taken at face value would appear to rule out Phonegap.

(and yes, I have looked at their source and know how it works.)

"providing in WebKit's javascript engine access to system services"

Yes, it's almost as if it were some kind of "intermediary" or "translation layer".

I've seen it stated a few times that "EA uses Lua on the iPhone" - but my googling hasn't revealed any evidence to support this. Does anyone have a cite for this?

Firstly, that's a call to authority argument, so automatically suspect. Secondly you don't present any evidence that EA uses Lua on the iPhone or that it receives an exemption from Apple to do so.

I'm pretty certain that ActionScript is not an example to the contrary, and I'm fairly fond of it as a programming language.

I'd go so far as to suggest that the majority of the non-Apple tools that people are proposing to use instead of Objective-C will produce an inferior result, and that's why Apple is clamping down on them.

(BTW, love the kneejerk downvoting in this subthread, keep em coming.)

Yes, just completely change the context from one where the code runs at the user's expense, to one where it runs at the developer's, and my comment sounds like nonsense. Aren't you the clever one.

If you are only able to make a profit by cutting corners on app development time, perhaps that means you aren't charging enough for your services.

At least one benefit of this change is that it levels the playing field for developers such as yourself - all of your competition is in the same position as you are, and you can't be undercut by someone who is building their apps using a Flash compiler or whatever.

This post from a former QNX marketing VP appears to disagree with you: http://saunderslog.com/2010/04/09/rim-didnt-buy-qnx-for-its-...

"QNX has long been looking for a partner with whom to enter the mobile space. For example, almost 10 years ago I was the marketing VP at QNX for a short period of time. Even then, QNX CEO Dan Dodge thought that the real prize in the embedded OS market was the mobile handset."

FWIW, despite being the author of a Clojure/Cocoa bridge, I was never under any illusion that this would ever be able to run on the iPhone.

(See "Why is this a terrible idea?" at http://github.com/allertonm/Couverjure)

I find it hard to believe this is just about automotive. QNX makes a very well regarded embedded OS, people I know who've worked with it rave about it.

So I can't help wondering if RIM has just bought their next-gen mobile OS, especially given the widely held view that RIM's current platform is ancient and creaky.

Hmmm. I assume you're referring to VisualAge. It's a bit of a stretch to call that "the original version of Eclipse". A predecessor, yes - but the only thing the two have in common is that they were both IDEs.

Of course, the language that is now called Javascript 2 is not the same language that Yegge was referring to.

He's had a bit of a change of heart about Cloud Computing since 2003, eh?

2003: "But the thing I'm most interested in is software as a service. That idea that every customer who wants to do accounting on computers, or every customer who wants to do inventory, or manufacturing, has to figure out what computer to buy, what operating system to buy, what Cisco router and switch to buy, what database to buy, is just nonsense.

Companies should be experts in their business, and computing should be available on the Net as a service. So more and more, our business is changing from selling our applications to our customers to: We buy the computers, we run the applications, and you use it. We'll be the experts. And you just pay us a monthly fee. That really is utility computing."

2009: "Cloud’s water vapor….Cloud computing is not only the future of computing, it is the present and the entire past of computing.

…Salesforce.com has been around for a decade. And so has NetSuite…and people are saying, “Well, that’s cloud computing.” Google is cloud computing. Everyone is cloud computing….Everything is in the cloud now….It’s this nonsense.

…But it’s not water vapor. All it is is a computer attached to a network. What are you talking about? I mean, what do you think Google runs on?…Water vapor? It’s databases and operating systems and memory and microprocessors and the Internet!

…And the VCs, I love the VCs. [They ask their start-ups] “Oh…is that cloud?” [And the start-ups go] “Oh! Oh! Microsoft Word! Change ‘Internet’ to ‘cloud’! Mass change. Give it back to these nitwits on Sand Hill Road.”

…What do you mean by “cloud computing”?…All the cloud is is computers on a network.

Our industry is so bizarre. They just change a term and they think they’ve invented technology….You can’t just come up with a [slogan] like “Let’s call that ‘cloud.” [But] it sure beats innovation.”

Everywhere but Goldman, it appears.

This idea has been bounced around by a few people interested in getting Clojure onto the iPhone/iPad platform too, since the JVM is unlikely to ever be there.

MacRuby suggests that it's not a complete pipedream, but the experience of the Unladen Swallow team indicates that it will not be all unicorns & rainbows. You'd also have to find an appropriate GC (I know some people are looking at using Boehm to get MacRuby on iPhone, but you have to wonder if you'll run afoul of the Appstore Police by incorporating a GC in your app.)

>transparent unless you have a side-effect

Only if you believe the side effect of using the CPU doesn't count.

This doesn't affect your point, since ObjC does still deal in raw memory addresses, but it has supported garbage-collection since Objective-C 2.0 (i.e since Leopard/10.5)

+1

I have a lot of time for Objective-C and Cocoa for desktop and mobile development. I'd go so far as to say it's a huge factor in the success of the Mac and iPhone platforms. It's pretty unique in supporting AOT, compiled-to-native executables while offering dynamic language and runtime features.

However the reasons it works so well for those purposes (low memory footprint, fast application startup time) don't seem very relevant for server development - and the downsides (#1 being the ability of coding mistakes to corrupt memory and/or abort the process) become huge liabilities for a server. So my guess is that this framework is going to come out on the wrong side of any cost/benefit analysis.

I consider myself a geek (and most of my friends would agree) but it's been 15 years since I last compiled the Linux kernel :)

That said, I wouldn't rule it out as a test because of that, but I do think that if you are going to compare 4 different RAM sizes of CS instances, and compare the costs of doing a job using those different sizes then you need to pick a job that is going to make use of the RAM. You can see from the results that there is a small (time) benefit moving from 256 to 512MB (but not enough to offset the increased costs) and virtually none above that.

Compiling the linux kernel seems like a poor choice of test, since it is not a pure CPU activity and will perform a significant amount of I/O.

In addition, it doesn't seem like compiling the linux kernel requires very much RAM, so you get the most bang for your buck using a CS VM with only 256MB and the cost only goes up from there as you add more RAM that the test cannot benefit from.

(Edit: I would love whoever downmodded me to explain why I am wrong.)