Archive for SQL

An eye-opener

I’ve long been a fan of Python and similar technical solutions which sit easily within an agile toolchain. I’ve always been in favour of Open Source solutions (not least because they’re generally gratis!). But my professional work is and always has been almost exclusively on Windows platforms. My laptop dual-boots WinXP/Kubuntu, but it’s the WinXP which gets most of the airplay. That’s basically because I’m pragmatic: I’m far more productive under Windows than I am under Linux, and part of the reason for that is Python. Having spent some 5 years earning my living as a C/C++ programmer, I haven’t written a serious line of either since I picked up Python some seven years ago.

The upshot of all this is that I tend to be something of a champion of Python running under Windows. I try to pick up Win-specific questions on the Python, Python-tutor and Python-win32 mailing lists. And I try to produce helpful web pages, modules and examples to show that you can get things done using Python under Win32, in spite of the *nix-oriented swerve of many of its developers and advocates.

But in spite of being a Python advocate, I’ve never really felt that strongly about the various Microsoft technologies and languages which people sometimes grumble about on mailing lists and blogs. Until the other day, when I attended a course concerning differences between SQL Server 2000 & 2005 (which I use professionally). I felt like I was wading through treacle. It was a real eye-opener for me, so used to the freedom which Python gives me.

There were two things which hit me the most: poorly-designed syntax; and the Visual Studio environment and languages. The SQL Server development team have added a few (not many in fact) new features to the core product, so naturally some new syntax has had to be devised to cope with this. Now I’ve seen many a hot-headed thread grow to a ripe old age on the Python mailing lists concerning proposed syntax changes. But at least people care, and there’s a sense that it *matters* what the language looks like at the end. In SQL Server they seem to have thrown around new and existing keywords, brackets, commas and other bits of punctuation with gay abandon and no consideration for the poor buggers who’ll have to use them later.

Try setting up an HTTP Endpoint around a stored procedure. And now close that session down and do it again without looking at the syntax. Impossible. And don’t get me started on the *ridiculous* Notification Services which require two new databases (yes, databases) and three XML files. (And that’s another thing: the plague of XML…)

But the thing which really made me miss Python was having to write extensions using C# within the Visual Whatever environment. So many lines and so much disk activity for so little result. I have never understood so well why people refer to Python and its neighbours as “agile”. It really seemed like being able to breathe again in comparison to being stifled by technology.

sqlalchemy & IronPython — two to watch

Michael Bayer, the indefatigable author of Myghty, sqlalchemy and Mako is moving sqlalchemy forward apace. He’s recently proposed what I see as a sensible simplification of the varied query/select methods which sqlalchemy offers. I’ve been following sqlalchemy for a while. The trouble is that I’m first and foremost a SQL developer and first and foremost a Python developer. Trying to marry the two is something I find difficult. If I were a SQL dev who dabbled in Python, I’d just throw SQL statements around and do things with the results. If I were a Pythonista who needed some data, I’d use sqlalchemy (or SQLObject, or whatever) and be happy. Because I’m both I want the best of both worlds. Maybe sqlalchemy’s about to offer it!

In other news, Michael Foord (aka Fuzzyman) has started a wiki for IronPython recipes. It even got a mention on O’Reilly’s Windows DevCenter. (It’s only a shame they can’t spell Centre correctly ;). I keep meaning to have a look at IronPython, not least because it’s obviously the way Python is going to go on Windows at some point in the future. Better be on the ball before the game starts. (If that’s the metaphor I want).