I worked with ANTLR, attempting to build a small code generator. ANTLR, along with TextTemplate includes a complete toolchain for building everything required for a code generator, ANTLR includes both a parser generator and a tree walker generator, and TextTemplate is a full templating solution.
However, working with the ANTLR suite turned out to be harder than I was expecting. Debugging the generated AST transformation code required a lot more spelunking through generated code than I was happy with. ANTLR has good support for debugging parsers over text, but I couldn't get debugging tree walkers in the ANTLR tools working to my satisfaction.
I can see two alternate paths going forward. Either I take the lisp approach and build out tree transformation code using something like clojure, and learn to love emacs and clojure's REPL. Or I take the path of writing code in a programming language written by compiler writers to write compilers in. Two obvious examples include Haskell and Scala.
The reason I am persisting with figuring this out is that we are on the cusp of one of those interesting times when we get to re-write the world again. We re-wrote everything when PCs appeared, then we re-wrote it again when Windows beat out MS-DOS, then we re-wrote everything again when the web first appeared.
And we are going to do it again to allow people to be able to use applications inside their web browsers, disconnected from the web. This is different from traditional desktop applications, even though from the users perspective they appear to be the same. The new functionality is that data is being kept both on the client, in a web browser hosted sql datastore, as well as on the server.
Which means we are about to re-write all of the applications that business users use. Oh goody =)
Friday, December 26, 2008
Saturday, December 13, 2008
Google's approaches to concurrency
I have a bit of a thing for concurrency. It is one of those challenges where in the answer actually lies in choosing the right collection of technologies such that programmers can achieve what they want to, safely and effectively.
The traditional approach, using locks et al, requires a level of mathematical proof that is infeasible. If we are going to use locks, we need to do it in a way that the compilers and run times will be able to verify that we aren't being stupid, otherwise it becomes too hard.
Google's various approaches to utilising concurrency safely are intriguing. The first, MapReduce, is beautiful in the way that it elides concurrency. Suddenly programmers can write programs that will be run across thousands of machines, in a way that is both safe and manageable.
Then there is the message passing paradigm that has surfaced in both Google Gears and in Android. This can be looked at as another implementation of the Actor model, but in both cases using languages that are mutable and in widespread use. It is the fact that messages are serialised across the communication boundary that gives safety, but the rest of the language environment isn't impacted. It only requires programmers to treat talking to another thread the same way that they talk to another process across the internet, a widely understood abstraction.
Where this gets interesting for me is the Chrome multi-process architecture. Here is an architecture that facilitates traditional programmers moving into concurrent code using message passing, but also in a way that is compatible with all the current libraries.
Actually, where it gets really interesting is Google's native x86 web plugin. This technique could be used to embed plugins as completely managed threads inside of an application. Near as I can tell this is bringing Chrome's multi-process architecture into other web browsers, by the back door.
What I want to know is what would happen if someone took Google's x86 plugin architecture and bolted it into something like Qt, where the thread responsible for the screen paint, the thread holding the application code, and various other threads (network io, database io, et al) were each one of these managed x86 processes? It would allow Qt applications to dynamically download code into a running application, and spin them up as additional sandboxed services.
The possibilities...
The traditional approach, using locks et al, requires a level of mathematical proof that is infeasible. If we are going to use locks, we need to do it in a way that the compilers and run times will be able to verify that we aren't being stupid, otherwise it becomes too hard.
Google's various approaches to utilising concurrency safely are intriguing. The first, MapReduce, is beautiful in the way that it elides concurrency. Suddenly programmers can write programs that will be run across thousands of machines, in a way that is both safe and manageable.
Then there is the message passing paradigm that has surfaced in both Google Gears and in Android. This can be looked at as another implementation of the Actor model, but in both cases using languages that are mutable and in widespread use. It is the fact that messages are serialised across the communication boundary that gives safety, but the rest of the language environment isn't impacted. It only requires programmers to treat talking to another thread the same way that they talk to another process across the internet, a widely understood abstraction.
Where this gets interesting for me is the Chrome multi-process architecture. Here is an architecture that facilitates traditional programmers moving into concurrent code using message passing, but also in a way that is compatible with all the current libraries.
Actually, where it gets really interesting is Google's native x86 web plugin. This technique could be used to embed plugins as completely managed threads inside of an application. Near as I can tell this is bringing Chrome's multi-process architecture into other web browsers, by the back door.
What I want to know is what would happen if someone took Google's x86 plugin architecture and bolted it into something like Qt, where the thread responsible for the screen paint, the thread holding the application code, and various other threads (network io, database io, et al) were each one of these managed x86 processes? It would allow Qt applications to dynamically download code into a running application, and spin them up as additional sandboxed services.
The possibilities...
Sunday, December 7, 2008
Saturday, December 6, 2008
48 hours
That was a rush. Intense. Insane. I want more. I want time to think. I want to understand. I want to just feel. Body longing, mind screaming. Sanity yet prevails, almost.
Where to from here? I know not. It is in the hands of the fates.
*wolfish grin*
Where to from here? I know not. It is in the hands of the fates.
*wolfish grin*
Wednesday, December 3, 2008
It's all about concurrency
Probably the most amusing, to me at least, comment after the AppEngine talks yesterday was "It's all about concurrency."
The thing with AppEngine is that it is factored in such a way as to allow insane amounts of concurrency in a way that doesn't break programmer's heads. The traditional programming by mutation based computation model is still present. There is no need for programmers to get side affect free religion to use AppEngine's massive scale out capacity.
The only downside of AppEngine is that it requires programmers to grok DataStore. DataStore is where the concurrency rubber hits the road, and it breaks programmers. Programmers are control freaks by nature, and being forced to give up control for MT safety is emotionally hard.
It's going to be an interesting decade. Just as the wide spread adoption of GUIs forced OOP on a generation of programmers, Multicores are going to force concurrency on this generation. I'm kinda expecting a lot of programmers not to make the transition...
The thing with AppEngine is that it is factored in such a way as to allow insane amounts of concurrency in a way that doesn't break programmer's heads. The traditional programming by mutation based computation model is still present. There is no need for programmers to get side affect free religion to use AppEngine's massive scale out capacity.
The only downside of AppEngine is that it requires programmers to grok DataStore. DataStore is where the concurrency rubber hits the road, and it breaks programmers. Programmers are control freaks by nature, and being forced to give up control for MT safety is emotionally hard.
It's going to be an interesting decade. Just as the wide spread adoption of GUIs forced OOP on a generation of programmers, Multicores are going to force concurrency on this generation. I'm kinda expecting a lot of programmers not to make the transition...
Monday, December 1, 2008
Brain full now, check back later
Possibly the most amusing part of playing with technology is how routinely I wind up feeling completely and utterly stupid.
Subscribe to:
Posts (Atom)