21–30 of 86 posts
Seaside
using opencl isn't that much harder than c. obviously you need to understand a little about how gpus work, and there are all the same issues about allocating memory, segmentation faults, etc. but the compiler and runtime are quite solid, and the docs more than adequate. now that i am past the worst of the learning curve i'm looking around for more slow code, because it's an easy way to get more speed.
also, django, but others have mentioned that (it's such a breath of fresh air if you're used to using java...). next year, i hope to play with llvm some (although it will have to be on my own time - can't see how to do that at work...)
I love the way Apple doesn't care what anyone else thinks about their language and has ridiculously verbose 40 character long method names to make code clearer.
Love it!
I also find Clojure very cool :)
Easy to get started, fast, stable, the community is helpful and it is easy to read their source code if you get stuck somewhere.
Earlier this year I got tasked with implementing a system which involved multiple mobile clients talking to a rendering server. The mobile devices had a fairly beefy browser (Nokia N900), so the client was clearly suitable to be delivered as a web app. On the server side, we already had a realtime graphics system I had written earlier, to which the web clients would need to talk over a bidirectional connection with near-realtime responsiveness.
Being a C/desktop guy with little network experience, my first intuition was to do the simplest thing I knew how to handle: linking a small embeddable web server (e.g. libmicrohttpd) into the render server, and devising some cheesy custom application-specific protocol over HTTP.
Luckily, my work partner is not as stuck in the 1990s as I am, and he suggested we use XMPP. I was sceptical at first (XML? A server written in Erlang? Do we really need to go there? I just want to tinker with my pointers...)
He showed me some demos of realtime XMPP web apps built with Strophe.js, and I was rather impressed. Then we went over our system's client/server design and how it would map to XMPP, and I was sold.
We ended up using many more XMPP features than I had initially imagined, including publish/subscribe and multi-user chat rooms. Had we gone with my original approach, these concepts would have been implemented in some haphazard way in the render server itself. Now the rendering system just talks to the XMPP server like any other client. It's stable, scalable and fast.
Still, while BOSH in the browser is pretty amazing in practice, it does feel like a hack that's stretching the reasonable limits of what web apps should be doing over HTTP. Hopefully this time next year I'll be able to say that one of the best technologies I've worked with in 2010 was HTML 5 web sockets...
Tornado: If you are going to develop on GAE, Tornado is the way to go. It is fast, well written, and only includes the core features needed for a web app.
I can't highlight how much easier it has made things for me since switching from Django. Debugging Tornado's source code was a breath of fresh air compared to Django's monkey-patched bird's nest of dependencies.
This is in AS3, used in flex. It's a joy to process xml with it.