I'm firmly of the belief that you can never learn too many programming languages1. For one thing, each new language you learn teaches you more about the general principles of programming, which aren't specific to any one language, and makes you think about general problem-solving approaches. Also, no one language — even my beloved Perl — is perfect for every eventuality, and all have their strengths and weaknesses. So recently, I've been looking at Ruby. A comment by Nathan mentioned a review of TextMate, which in turn put me on to Rails — a web application framework for Ruby.
I haven't had time to look at the language in depth, but I like what I see so far. It's a neat language, with some of Perl's slightly terse syntax and flexibility, but with very solid object orientation. There's a package management system (RubyGems) which makes it really easy to install and package code. There's also a very neat self-documentation system
rdoc which produces command line and HTML documentation from well-commented code. What really knocked my socks off though was Rails. There's a movie here which shows David Heinemeier Hansson (the creator of Rails) using it to conjure up a working weblogging engine, seemingly out of thin air. The structure seems really easy to use, and suitable for everything from a simple application to access a database to a huge web application. This got me thinking. I've been giving serious consideration lately to building something web-based to administer Mr. Bsag's paintings. Every time he has an exhibition, we end up trying to generate a catalogue manually, matching up paintings, prices and titles. It's a real pain, and we inevitably make mistakes. I can imagine setting up a database record for each painting on MySQL with an ID number (which would be written on the back of the frame), a title, price, details of media and size and also a digital image of it. Then we could access and administer these records via a web interface, and generating a catalogue of a selection would be a piece of cake. It seemed to be a job that was too big for my limited PHP knowledge, but with Rails, I can imagine that I would fairly easily be able to put something together. Ruby doesn't have the user base of something like Perl or PHP yet, but I'm beginning to see that it has a lot of merits.
1 This is one half of my version of the saying, "You can never be too rich or too thin." The other half is, "You can never have too much music."