Programming language comparison

As a close to the year a note on a recent comparison opportunity. I needed to do some calculations with too many variables so I wrote a program to do it. Emacs and Python are the first choice, gives me a chance to concentrate on the problem, not the language I'm using. I ran this through to completion with minimal testing. I was getting output that looked right, didn't bomb etc. Let's call it alpha code. Someone else had asked for it, so I re-wrote it in Java using netbeans. I pulled a class I have called test which formats output, increments test numbers and validates that no tests have failed. Makes testing easier by a mile. Simple methods for each variable type. No big deal, just nice to use. Ported it and in doing so realised a difference to the Python results. Guessing porting problems that goes on the to do list. I'd started to sigh having to re-write stuff that is (to me) quite natural in Python. 'for listitem in list: process listitem' - seems so natural it gets hard when I have to re-write it to suite the language. Last time I updated netbeans I noted some advertising about Ruby. I'd played with Ruby, but not having a project to do not really taken it seriously. With an IDE I thought it might be fun as well as instructive, so I ported it to Ruby. First thing to go over was the test class. TDD makes so much sense. Eventually got it all running and learned a good bit along the way. Main thing is that the Ruby syntax is awkward compared to Python. Camel case is frowned on by netbeans! The other one is the true false thing. Lisp ideas in Python and Ruby vs Java bools vs Python None etc. Eventually moved to defining true and false in Python to keep the functions common across the ports. Then I went back to Python, mainly to move the test class over. This was instructional (to me). I implemented it as a class for future reference. Having completed the circle I concluded that I still prefer Python. Even if Java does have it's javadoc (which I like). Ruby left me shrugging my shoulders; why bother changing from Python, I see no real advantage to using it. Biggest lesson is the confirmation of test first as a programming approach.

Photography

I now subscribe to three photography blogs, as well as listening to Norm and Tim with their breakaway photo enthusiasm. One thing I read recently had me thinking. Tims blog led me to this article which turned things around just a little. I'd always had it that the camera came first. Buy the best you can afford. This piece points out that fashion dictates body features, quality is the big variant with lenses. Canon and Nikon put effort in making the money spent on lenses last more than a couple of body changes, which often means that the body can be replaced whilst making good use of your stock of lenses. The feature list is quite often little more than bragging rights so it's often not much of a loss. The lesson? Invest in good lenses, pay less for the body and change it more often. The savings on a body can take you well into high quality lenses, especially if moving into the 'old fashioned' world of prime lenses.