Haskell, Lambert, and the Clarke Ellipsoid

Math is best done in a functional language. I've browsed through the source of several map projection libraries, and none of them take a functional approach or use a functional language; some are simply imperative C, while others written in Java actually attempt to make map projections OO, and have super classes and inherited methods. Unnatural!! If math isn't functional, then nothing is. What I want to see in a projection library is the same thing I see in a map projection book: a clear, concise representation of the projection algorithm. Neither Proj4, nor its Java port, nor the Geotools library provides that clear representation. So I've started my own projection library, in Haskell.
Normally it's bad it start libraries that duplicate the functionality of other libraries; and in fact no one but myself is likely to ever use this Haskell port of Proj4, but I just can't help but thinking that map projection is a perfect application for Haskell. Everything is very mathy, which Haskell handles well, and 99% of everything is functional. Projection algorithms do not have side effects. Almost the entire library can be implemented in purely functional code. And no language is better, or more clear or more concise than Haskell for purely functional code. That's what Haskell is made for.
What will be interesting though, is after I have a few more projection algorithms implemented, seeing how I can hook up the library to the EPSG database, so I can pull projection parameters instead of having the user manually enter them all in. Proj4 has its own xml mapping from EPSG codes to projection parameters, and Geotools has its very own HSQL database of EPSG junk. I'll have to see what persistence options the oh so functional Haskell has to offer.

Library vs. Language

One never wants to write Java in Ruby. But sometimes, you don't have a choice. Libraries are typically not language agnostic. A library reflects the language it's written in. Write a library in A, try to use it in B, and you'll see an aesthetic clash resulting from a mismatch of idioms. This mismatch is why it can be so unpleasant to use languages other than Java on the JVM. Most of the libraries on the JVM were written in Java, and therefore expect to be interacted with in a Java way. So when you fire up your fancy new dynamic language, with literal maps and lists, and blocks and procs and yields and dynamic this and vararg that, you discover none of those fancy features are applicable to your libraries, because they weren't written with those things in mind. This isn't so much of a problem for JRuby, because they do go out of their way to make Java look more like Ruby, but I find it's a major problem in a language like Clojure; which to begin with, doesn't resemble Java at all (i.e. isn't OO) and has very few in the way of native libraries. When I compare the user experience of writing Common Lisp code with Common Lisp libraries, it looks and feels so much better than writing Clojure code with Java libraries. All the fancy lisp in the world can't save you from the evil Java library monster.
I think one of the things the Clojure community has to do, besides come up with their own libraries, is to start writing native Clojure wrappers around Java libraries. I'm not sure if such a project is feasible, but I know that I'd rather write separate bindings than pollute my Clojure code with Javaness. Honestly I wonder if issues like these will get more attention now that virtual machines are becoming this great big multi-language platforms. Maybe someone will find a magic solution. Skinnable language agnostic libraries! With Java, Clojure, Ruby, and Python stylesheets, get yours now!

GAE

Google App Engine is supposed to let you seamlessly scale your app on Google's hardware. But I'm afraid it isn't so. Not only does GAE not scale (they put caps on everything), but the non-relational backend they force you to use (for scalability) makes Django support horribly painful. It's a miracle that Django manages to work at all, and it's an even greater miracle how much of Django you can actually get working with something like app-engine-patch or appengine-helper. But though it works somewhat, it doesn't quite work enough.
ModelFormSets! I need them desparately, but for some reason they work not one bit. I try to use them and I get metaclass exceptions--presumably the result of messy leftovers from the app-engine-patch. So instead of using them I must not use them, and make do with regular FormSets, and the consequent data ingress/egress code which I must write manually. It is a recipe for spaghettization, which is what I'm experiencing. And however desparate I feel to stamp out this crufty code, without a fully operational Django it seems I cannot.
So that brings me to my point, which is that if GAE is to be useful at all, it can't be incompatible with the standard way of doing things. What's the point of hypothetically scaling, when none of the technology interoperates smoothly, and I (the humble developer) must spend ridiculous amounts of time puzzling out why some feature I desparately need simply won't work? And then after I'm done puzzling I have to out and spend more ridiculous amounts of time reimplementing the feature for myself; or worse, not implementing the feature and just letting my code overpopulate with redundant crud.
To hell with app engine. Give me back my relational database and real python.

Django Templates

Django templates really blow. It was my understanding the the Python philosophy was not to prevent the programmer from doing things; even if they were considered dangerous. But then the excuse for these hands-tied-behind-your-back templates is nullified -- the only possible reason to create them and have them be so limited and restricted is to prevent people from getting into trouble, as in by over-coding the View or something. Now, I understand how we don't want our pretty Python views to turn into PHP, but come on. If I need it, I should be able to get it. The only thing I can say is thank god for Mako; it was surprisingly easy to replace the native Django craplets with the far superior and flexible Mako, even on the unnatural and unforgiving GAE.
I thought I really liked Django, but having to work with these evil templates has turned me 180 degrees. Erb from Rails didn't have this evilness, not even JSF had this evilness -- with JSF you could either slip back into JSP, or write custom tags (with relatively little hastle). I don't even want to touch Django's "filter" bastardizations. Ick.
On the magicness scale, Django is certainly a step down from Rails, but until now I had thought that was a good step down, a step down that let the programmer more easily see behind the curtain (as it were). But having to work extensively with these Django templates has altered my opinion totally. When the framework stops working for me, and starts actively opposing my actions, it's time for a change.
Hurray Mako, boo Django. Maybe I ought to switch over to Pylons or Turbogears for a bit, see what those are like.

Python vs Ruby

I here it told that Ruby was, in part, an OO reaction to Python, i.e. that Matz didn't think Python was object oriented enough, and sought a better way. Python is certainly more functional (in the first class function sense) than Ruby -- indeed, methods just seem like syntacic sugar of functions over objects, with an implict self parameter instead of an explicit one. Objects themselves are little more than hashmaps.
But despite being a little hairier around the edges, I think Python's emphasis on first class functions over first class objects makes it more flexible. It's easier to manipulate methods in Python than it is in Ruby; in Ruby there's too much lambda/proc/block noise, and isn't so clear that methods on objects are simply functions with an implicit self parameter -- I'm not even sure that you can pull methods off objects in Ruby the way you can in Python, but then I haven't tried. Ruby encourages a more OOP perspective on things, which is not the case in Python.
It's also interesting to note that Django, perhaps in keeping with Python's relative hairyness, also doesn't bother with hiding too many nitty gritty details. In Django there just isn't as much magic. The request parameters get explicitly passed into the function, they don't magically appear. And it doesn't force you to do MVC. It's up to you. I heard one of the creators of Django say in a podcast, that he considers Django to be more like the factory for making the tools to make the product -- and a layer below Rails in abstraction.
Perhaps because I find it less magical and easier to understand, I prefer Django over Rails. It's not exactly a fair comparison, because my experience with Rails is limited to when I was young and foolish, but I would say that as a general principle, too much magic and you lose your way. I need to have my feet firmly on the ground; I want to know what's going on or else I feel out of control. I'm going to do another project in Rails; perhaps a website for my theorem prover, and in that sense I'll be giving it another chance -- but I think Django is the one for me.
It's also good to note that Python is considerably faster than Ruby.