TheRevoltingX

Spare the rod, spoil the child I'm from El Salvador and beatings are a regular thing for us. It's normal for us to start working at 12.

Now that's the extreme, but this whole don't hit your kids movement is an epidemic.

Interesting, thanks so much for the response. I'll keep this in mind as I continue to develop my app. It's still between custom byte stream, json, thrift, etc.

But MsgPack looks interesting as well and, if anything, these blog posts have brought it into the light for me.

I looked at the java class and what might help is if you can set a buffer size and use that buffer to store the data in the buffer and expand it if necessary. But that seems like a lot of work. But yeah, not sure if you can optimize based on usage patterns due to the constraint you said. In any case, great stuff and thanks for the info.

Very interesting discussion. I work on a 2D MMORPG for Android. This is extremely relevant to me. I have a few questions though.

What if you take compression and deserialization out of the picture? For example, in my server I have a hash like data structure that gets turned into JSON for browsers and byte array for mobile clients.

For example, because the data has to be transferred at fast rates and will be going over mobile networks. The size of the packet matters because every millisecond counts.

Then to read the data, I simply read the stream of bytes and build the objects I need on the client. This has to happen mostly without allocations for example on Android to avoid the GC.

So a few questions: Does deserializing JSON cause any memory allocations? If you're not tokenizing the data and don't need to parse it, will it be a significant gain over s serialized byte protocol or JSON?

In any case, I'll experiment on my end and perhaps blog about my own findings.

You don't scale a language, you scale an architecture.

Hard to be depressed when Jesus got you....

Not yet, right now I have no need to learn yet another scripting language. I've been spending most of my language learning efforts on Erlang lately.

I've used Ruby, Java, and Perl professionally and my favorite by FAR is Perl.

This post makes way too many assumptions as to the causes of Jeff's post. Reminds of psychology, complete reach-around post.

I don't know, I'm pretty bothered by this. I checked Google Play the day I purchased it and it was only available w/ a contract. That's why when I saw it at Fry's I bought it because it was unlocked. Should have waited two more days and gotten it at half price. In any case, I'm going to go complain to them about this. I believe they offer price matching.

Ugh, you gotta be kidding me! I just bought this at Frys for full price (that's 799$)

I'm going to go see if they price match since I just bought it this weekend.

Indeed, it looks like they're even using requestAnimationFrame. It's still really slow on Firefox, which I've found to be one of the worst offenders when making canvas games. The problem here might be fixed by splitting the physics loop from the animation loop. I think it's doing all the calculations as fast as it draws.

Out of all the languages I've used (C/C++/Perl/Javascript/Erlang/Objective-C/Ruby)

I like Perl the best and javascript+ruby the least.

Freaking amazing, I've been utilizing MVC heavily to develop HTML5 games. Mainly borrowing ideas from Android and iPhone development with their layout engines and staying out of the way as much as possible.

I don't think it's coming full circle. They're just properly separating the project code, so that the time critical code is in C/C++ while the scale/fault-tolerant code will be in Erlang.

Nope sorry, I've only read pieces of his Art of CS book, but I'm also interested in reading 3:16 which I plan on ordering soon.

It's supposed just pick out the verse number 3:16 from every book and join it with any history or texts associated with it. Kinda like sampling.