Most of programming is routine, and that's a problem.

While coding, I always have this nagging feeling that someone has already done what I'm doing, and done a lot better job of it than I. Heck, its more than a feeling, I just know it! It frustrates me, knowing there is this useful information that could save me time, just beyond my grasp.


At the end of the day I am interested in building programs with interesting functions, that I know about Java or SQL is purely a side effect of creating these interesting programs. If I could get away with knowing a lot less about Java and SQL, I would!


I'm not saying that aren't a lot of benefits from knowing low level systems, I think there is a huge advantage from knowing low level systems well. Just look at Skype, an application that is only so amazingly useful because the creators knew a lot about NAT traversal and P2P networking. But the creators of Skype also had to program a lot of routine things as well, things that ARE well understood, and that is where the wasted effort is.


If only we could spend a majority of our time working on the things that WEREN'T well understood, the interesting things. The mundane things, well, they are just as mundane to program as well.



This isn't a comment about OO in general, its more a comment about everything we do in software development in particular.


There are lots of things we (software developers) do, that are well understood:

1. If you need data for twelve rows of data, don't do twelve queries to get the data, do one.
2. When displaying read only data, no need to marshal all the objects, just load the relevant data.
3. In Swing programming don't do long running operations on the AWT-EventQueue thread.
4. Etc...


There are many rules that people apply for each situation that arises. The frustrating part is that when you encounter a new technology/framework you have to discover all of these rules of thumb, even though chances are that you are walking down well trodden path.


To me a great example is the email lists, where 90% of the time people are asking about the same 10 things. This is how the FAQ was born. But the FAQ has really gone no further, its not in an actionable form, we can't reason with it, we aren't able to programatically derive semantic meaning from it.

So? How do you design a system to have the smarts to know what to do?

Well I promise to post about it as soon as I figure that out :)

Project Euler

Grant has been trying to bully me into writing some Haskell code. The straw that broke the camel's back was the challenge to solve "Project Euler: Problem 1", well really the problem was not that interesting, but we had a good spread of languages in the office everyone wanted to solve the problem in, so this is a fun opportunity to compare writing the solution in our own pet languages. Grant used Scheme, Geoff: Ruby, Kartik: C++, Dan: Delphi, Chris was out sick, but I bet he'll do it in C#. Me, I'm going to use Haskell.

We had already discussed earlier in the day that there is an equation to give you the sum, but in the spirit of all following the same approach, I won't be using it.

The plan is for everyone to post the implementation in their blog, so without further delay, here is mine:

sum [n | n <- [1..999], mod n 3 == 0 || mod n 5 == 0 ]]