Central Ohio Day of .NET and What I Wish I Said

First off, the Central Ohio Day of .NET last Saturday (better late than never, right) was a very well done conference as expected. Hats off to Mike Wood, Carey Payette and Jim Holmes (in reverse alphabetical order) for all the hard work they did. Events are NOT easy. For a recap - and a reason to attend/support next years event - check out this video by Andy Erickson. Nice work, Andy!

Once specific thing I'd like to point out about the sessions, was the relatively large number of talks on alternative languages (one session, Why Ruby? by Joe O'Brien, wasn't even specific to .NET). Though it's really refreshing to see sessions that aren't C# or VB.NET, I wonder what talks are going to look like in another 5 years. Will C# still be the default language for demonstrating new tools or will a DLR-based language (VB.NET, IronPython, IronRuby, etc) or F# be equally as dominant? Hmmmm...

I'm rambling.

After my introductory talk on IronPython, I started thinking about a lot of things I wish I had said or demonstrated. Of course, I don't know how I was going to cram more stuff into the allotted one hour and 10 minutes but nonetheless, here is the list of "Things I Wish I Said and Did":

• I didn't explore an IronPython executable or library with Reflector. When you do, the first thing you notice is that there is SIGNIFICANTLY more code with an IP app than with a similar C# app. This would have made for a nice discussion on choosing the right language for a given job.
• I didn't spend enough time on the functional portion of Python. I did gave an example using the map() function and I did a bit with reduce(), but I didn't have a lambda or filter() example prepared.
• Did I forget to mention that IronPython 2 is targeting .NET 2.0? Yup, I did. Kind of important if you were going to try to use Linq with IP.
• What about the standard libraries? Python is known as a "batteries included" language, but how would you understand that if I didn't show you the libraries?

I know there are a couple of more items that I'm just forgetting at the moment, but this list discusses some big ones. Hopefully, my next talk will give me some more time.

Project Euler Problem 2

Problem number 2 reads "Find the sum of all the even-valued terms in the Fibonacci sequence which do not exceed four million." The resolution to this problem is not quite as simple as the previous one, but it's not far off.

def fib(maxFibNumber):
    a, b = 0, 1
    while a < maxFibNumber:
        if (a % 2 == 0):
            yield a
        a, b = b, a + b

print sum([x for x in fib(4000000)])

This time we can't rely entirely on list comprehension for the answer. We have to define the fib(maxfibnumber) function that will calculate our Fibonacci sequence and return only even those that are even. I modified a Fibonacci function I found at literateprograms.org to do the job. I have to mention one of the little niceties that makes Python so useable: multiple assignment. Multiple assignment describes the technique of assigning - *binding* in Python - two variables simultaneously. We bind "a" and "b" as soon as we enter the "fib" function and then rebind them at the end of the while loop. This is just another way Python can help us with a simple programming idiom.

Taking on Project Euler with Python

Lately a number of posts on Project Euler, a series of predefined mathematical/computer science puzzles, have come to my attention. Bill Wagner has started a series of posts solving the Euler problems in C# and Dustin Campbell has posted one solution in F#. Several of my co-workers at SRT Solutions have been working through solutions in Ruby, Scala and Boo. My contribution will be in Python.

Project Euler problem 1 reads as follow: "Add all the natural numbers below 1000 that are multiples of 3 or 5." Python's list comprehension makes the solution to this problem trivial.

print sum([x for x in range(1,1000) if x%5==0 or x%3==0])

List comprehension is really just shorthand for a loop that sticks a variable into a sequence. In this solution, the loop is represented by the "for x in range(1,1000)" portion of the statement and a condition is added immediately following. The first "x" really just represents any value that is added to the sequence assuming it gets by our condition. Use the built-in "sum(list)" function and we have our answer. Simple, elegant and very readable.

Catching Up

I *want* to talk about Project Euler, but it's been a few weeks since I last blogged so I feel I obligated to mention a couple of things.

• Thing 1: I went to PyCon in Chicago. Good time, trip to Chicago aboard Amtrak was surprisingly pleasant, learned a lot, trip home aboard MegaBus was unpleasant (no need for a break 10 minutes from your destination, Ms. Bus Driver. Furthermore, it is important to train your drivers not punch cab drivers - it's apparently illegal).
• Thing 2: Disappointed in PyCon lightening talks since they were dominated by vendors. To all vendors out there: standing up and talking about the history of your company and how great you are does not get through to people who are expecting technical content. Instead, come prepared to talk about an interesting *technical* topic.
• Thing 3: If you are writing unit tests, but not doing Test Driven Development, then take a deep breath and just try to start writing your tests first. Yes, I have a lot more test code than production code, but debugging is so much easier and confidence in my code is so much higher. Do it and you'll never look back.
  
• Thing 4: The more I write Python, the more I love Python AND the more I appreciate C#. I've been doing a lot of Python posts lately, but I think I need to step back and do a bit of comparison between my two favorite languages.

That more or less covers the past few weeks. Now that I have that out of the way, my next post will not only cover the first Project Euler problem in Python.