Out of the funk


I have not been feeling creative for a long time. I suppose this is something that happens from time to time for people. I can recall other times when it happened to me. This time was different. It lasted a long time. But enough with that.

One of the things that helped me get back on track was watching conference talk videos. I have been trying to exercise more for the last couple years with varying degrees of success. The one thing that consistently works for me is walking. The problem with walking is I live in Pittsburgh. Once September ends the sun becomes a rare thing until the following April.

So the solution is obvious. Go to the gym to walk or use the treadmill we bought eons ago. Even though my gym is very close to my house, it is amazing how easy it is to make excuses about not having enough time. The treadmill doesn’t take that excuse. The problem there is walking on a treadmill is SO BORING. Then a realization hit me. I have a tablet. It fits nicely on the magazine holder on the treadmill. And I had been collecting links to conference talks I never find time to watch.

In the past, the number of talks I wanted to watch would have probably only lasted me a week or two. Recently it seems that most of the major conferences (especially some that I would love to attend but are just too far away) have been posting videos of pretty much every talk. Now the solution to the treadmill problem was in focus: I would watch 30-60 minutes of video every morning while I walked on the treadmill.

I know a lot of you are asking why I didn’t do this sooner. I don’t have a good answer. But I wish I had. I started seeing inspiring talks about all sorts of subjects. And then just a few days ago I saw the one that launched me into action: MythBashers: Adventures in Overlooked Technologies by Avdi Grimm.

I have been trying to think up a meaningful side project to learn some new things and scratch a few itches. That word, meaningful, has been the killer. I build distributed systems to manage medications in my day job. If I want to do something meaningful, it should help me get better at that. I was trying to figure out ways to play with message queues and streaming systems and other crazy things. That would be meaningful.

But really what I needed was something I could work on that would be fun. If I managed to learn something along the way that was applicable to my day job, great. But I started programming as a hobby. I wasn’t doing it for the money or the fame. I was doing it because I enjoyed it.

I have been dabbling in “functional” languages because I find them intriguing. The reasons are the same as anybody else. I played with Erlang, tried (and hated) Scala, fell in love with Clojure. The learning curve on all of them is steeper for me than F#, though, since in my day job I use C#. So I decided to focus on F#. I’ll pick up Clojure again later and I’m sure I’ll check out Elixir. But for now I need to focus, so F# it is.

And so we come to the project. Back in college I ended up getting very poor grades one semester. I partly blame taking two 300-level econ classes at the same time. My parents blame beer. I know the real truth. It was MUDs. To those who weren’t alive in the early 90’s, a MUD is a Multi-User Domain (or Dungeon). Think World of Warcraft, but with nothing but text. I was obsessed. I spent a lot of time in the computer lab playing. And then it got worse – my roommate showed me how to connect from my dorm room. Yeah.

To this day I have resisted games like World of Warcraft because I know what will happen. But now it is time to put that misspent youth to use. I have started building a MUD in F#. I doubt it will ever be great. I may be the only person who ever plays it. That is not what matters. What matters is it is a real thing to build. A thing I can care about and enjoy. That is really what a hobby project should be. I may come up with a better idea someday, but in the meantime I should be using my hobby time to do something more useful than reading millions of words about software development. I should be writing software.

I plan to write about what I learn along the way. I actually have set up a micro-blog of sorts in the project where I am posting my “stories” and other notes along the way. I expect that as I start I will not be writing good F# code, but by writing the code I will learn more and eventually I will have written some good F# code. Probably just a couple methods across the project. 🙂

If you would like to follow along (and tell me what I am doing wrong – this is a learning experience, after all) you can find the project here.




I’ve been spending some time learning about different languages and paradigms, which introduces me to terminology I’ve never heard before. I am not a “classically trained” computer science major – my programming and design skills are mostly self-taught. When I was staying mostly in my own space (building line of business applications in .Net, and VB (and some dBase) before that) I did not get exposed to any of this crazy terminology.

So, mostly as notes to myself, I am writing down what these terms I keep hearing mean (in my own words), instead of just glossing over them in my head and hoping the rest of the context clues will keep me going. If you get any value from this, great! 🙂

Memoization is a term I keep hearing in the various functional programming/distributed systems videos I’ve been watching. I figured it has something to do with remembering things and not put too much more thought into it. And, indeed, it does have to do with “remembering”, but a fairly specific case of it.

Memoization is keeping the results of past computations so that you can refer to them again without having to take the time to do the computation. It shows up often in recursive solutions. Basically, if you have a deterministic (a word I do know, since I did study a good amount of statistics WAY back in college) function, you can store the result in a dictionary keyed with the input value(s) (or a hash of them), and just use it in the future instead of recalculating.