Language Comparison Series
I needed something to do at the last SuperHappyDevHouse event, so I decided to start learning Python. I need something to use for some projects outside of work, and I've wanted to check it out for a while since so many people seem so committed to it, so it seems like as good a time as any. I've read through the pickaxe book and done a few small projects in Ruby at work, but it was a while back and I've not forgotten it all, so I figured it was worth trying something different. So I've been working through Dive Into Python, installed andLinux so I have a better dev environment locally (though we'll see how that goes; I may try VMWare, create a real Linux partition, or just switch back to using the Windows toolchain, as painful as it is), and now I'm working through the Django tutorial.
Of course, part of my motivation is also that we have our own programming language, currently called GScript, and it's good to learn about other languages so you can see how yours compares and so you can borrow the best ideas that are out there. The same applies to frameworks too, which is one reason I'm going to try out Django; we have our own ORM layer and web layer, so it's good to see what cool directions other people have gone with those.
Honestly, it's not worth it to me to check out any Java frameworks in those regards: everyone uses Hibernate, so I really should learn more about it, but Java just doesn't lend itself to great frameworks due to its lack of metaprogramming. No matter how clever you are, it's really a pretty fatal flaw in my opinion; the gscript interface to our ORM layer is all dynamic even though GScript is strongly-typed, thanks to the magic of our open type system, but on the Java side we have to do massive amounts of code generation that should be totally unnecessary. Thankfully pretty much our entire interface to the web layer is through gscript, so we don't have to do any Java code generation there. There are a lot of reasons why I think our web framework is better than anything else out there for the sort of work that we do, but the open typesystem in gscript really makes it untouchable. I think that it would take people some time to understand what we've done with our latest "smoke tests," but I think that if people really understand what we were doing it would blow their minds a bit, since it really is a total game-changer as far as our ability to reliably test our entire application from the UI on down.
But I digress . . . my point here is that I've started putting up a series of articles on the Guidewire Development Blog comparing GScript with Java, Ruby, and Python. I chose those because they're the languages I know best (or at least are freshest in my head) and because those are, for a lot of people, the main choices for a modern web development platform. I didn't include PHP because . . . well, because PHP code is always eye-bleedingly ugly. I'd certainly consider it for web development due to its sheer practicality, scapability, and rapid development model, but as a language designer it should really serve as a cautionary tale of how not to do things.
So if you want to see how GScript stacks up, head on over the dev blog and check it out. The first two are up, and I'll probably be adding one or two comparisons a week.
Of course, part of my motivation is also that we have our own programming language, currently called GScript, and it's good to learn about other languages so you can see how yours compares and so you can borrow the best ideas that are out there. The same applies to frameworks too, which is one reason I'm going to try out Django; we have our own ORM layer and web layer, so it's good to see what cool directions other people have gone with those.
Honestly, it's not worth it to me to check out any Java frameworks in those regards: everyone uses Hibernate, so I really should learn more about it, but Java just doesn't lend itself to great frameworks due to its lack of metaprogramming. No matter how clever you are, it's really a pretty fatal flaw in my opinion; the gscript interface to our ORM layer is all dynamic even though GScript is strongly-typed, thanks to the magic of our open type system, but on the Java side we have to do massive amounts of code generation that should be totally unnecessary. Thankfully pretty much our entire interface to the web layer is through gscript, so we don't have to do any Java code generation there. There are a lot of reasons why I think our web framework is better than anything else out there for the sort of work that we do, but the open typesystem in gscript really makes it untouchable. I think that it would take people some time to understand what we've done with our latest "smoke tests," but I think that if people really understand what we were doing it would blow their minds a bit, since it really is a total game-changer as far as our ability to reliably test our entire application from the UI on down.
But I digress . . . my point here is that I've started putting up a series of articles on the Guidewire Development Blog comparing GScript with Java, Ruby, and Python. I chose those because they're the languages I know best (or at least are freshest in my head) and because those are, for a lot of people, the main choices for a modern web development platform. I didn't include PHP because . . . well, because PHP code is always eye-bleedingly ugly. I'd certainly consider it for web development due to its sheer practicality, scapability, and rapid development model, but as a language designer it should really serve as a cautionary tale of how not to do things.
So if you want to see how GScript stacks up, head on over the dev blog and check it out. The first two are up, and I'll probably be adding one or two comparisons a week.
posted by Alan Keefer at 12:53 PM
2 Comments:
" Java just doesn't lend itself to great frameworks due to its lack of metaprogramming. No matter how clever you are, it's really a pretty fatal flaw in my opinion; the gscript interface to our ORM layer is all dynamic even though GScript is strongly-typed, thanks to the magic of our open type system, but on the Java side we have to do massive amounts of code generation that should be totally unnecessary. "
In regular Java projects, very few people use code generation. It was true maybe in 2003 but we are in 2008 :)
Java frameworks now (whether i be web, application, ORM etc) eliminate the need for code generation.
Perhaps, but it's only avoidable because of what you don't get. You can use runtime code generation to generate on-the-fly classes for various bits of the application, but they do very different things than what you get in a more dynamic language.
For example, ActiveRecord magically creates all sorts of classes, methods, and properties based on your database schema. In Java, there's no possible way to do that: sure, you could generate the classes at runtime, but how would you use them?
Similarly, the ORM part of Django takes a bunch of classes that describe your model and then lets you use that to create your database and provides a bunch of magic properties and methods for doing queries based on those properties. Again, there's no decent want to do that in Java without code generation.
You can do all that stuff reflectively in Java, but then you're just passing around bags of strings, which quickly gives you all the disadvantages of not having static types with none of the advantages of having dynamic types.
For what it's worth we do code generation to transform XML metadata about the DB schema into Java classes we can then work with in the application. There's really no way to avoid that unless we invert things by hand-coding the Java classes and deriving the metadata off of them via annotations, which has its own set of disadvantages (not configurable by customers, not easy to manage with tools, etc.). So you can't really win either way, and the end result is just way less usable than the frameworks you'll find in dynamic languages.
Post a Comment
<< Home