On C# and .NET

At my current job I've been using C# and VB.NET for development, which are two technologies that I had never used and really shied away from as they are "corporate" technologies. I always figured that C# was just like Java and since I hated Java when I was in university I would have the same reaction when trying out C# for the first time.

Turns out I was wrong. In a nutshell, I would describe C# as "Java done right". The extra features that come with C# are little things that make the language as a whole more pleasant to use, and doesn't make me want to cry when it takes forever to do something simple - as I usually felt when working with Java.

Here's a few of the things I like:
Type Inference - some people will probably hate my code. I use var everywhere. My code looks like Javascript! It's especially useful in foreach loops over dictionaries (aka hashes, I'm so used to using Ruby that I tend to overuse this class):

foreach (var pair in myHash){
  ...
}

This way if my hash has some complicated type I don't need to put KeyValuePair whenever I want to iterate over the collection.

Functional Abstraction - this one is also known as anonymous functions. Check this one out:

CSV.Open("mycsv.csv", "r", row => {
  .. do something to row
});

This is valid C# code! And it works great! It isn't exactly the same as blocks in Ruby (break/next/redo/return don't work the same) but it accomplishes a lot of what I use blocks for.

Events - this is the observer pattern built into the language. I won't go too much into this as you can just learn about it from the Wikipedia page. This is actually something that would be useful in Ruby (probably not that hard to implement as a gem) and is implement in Rails.

There are a number of things that I don't really like - the system is closed and very much owned by Microsoft. While they have their community promise thing going that means they say they won't sue the Mono guys for reimplementing their platform, you never know when they might try to exercise their muscle.

A quick note on Mono: it's great. The executables it produces are binary compatible with Windows, so you can pull the Java-style compile-once-run-everywhere thing - build an executable with Mono in Ubuntu, and it will execute under Windows - provided you're not using any specific libraries. Compile a .dll on Windows with Visual Studio and you can use it just fine in Mono under Ubuntu. I'm impressed.

Whiny Programmers

This post is in response to this rant here. If you don't feel like reading it that's ok, it is about a programmer who is annoyed about the following scenario:
1) Business Guy (BG) has an idea (I say Guy here because I've only ever been approached by guys with business pitches, but you can easily replace the G with Girl if that's the case).
2) BG finds Programmer (P), offers no pay but 50% equity.
3) P does all the coding, late nights, etc.
4) BG makes all the decisions, takes all the glory, no mention of P in press releases, etc.
5) P gets annoyed.

This is a common scenario, and a lot of programmers have seen it (I was lucky, when I went along with this scenario I was actually getting paid, although the equity part was lower).

My problem with this type of rant is this: what is stopping P and BG from being the same person? Why can't programmers come up with business ideas, and do all the marketing/PR/etc. as this rant describes as "the easy part"? This guy seems to come to the false dichotomy of "programmer in startup" vs. "programmer in big company", when there are plenty of other options available.

Now of course the obvious answer is this: there is not enough time for P and BG to be the same person. It's time-consuming enough to do all the coding, you want to do all the marketing and product pitches and all that too? On top of that, BG often has this thing called "charisma" (known to geeks as CHA) which is a thing that geeks often neglect or marginalize but is quite important when it comes to making people want to give you money for stuff (whether it's VC funding or selling your product).

Not only that but there is all this other business stuff that needs to be done like:
Market research: does anybody actually want your product? How often do us geeks embark on an awesome project only to find out that nobody actually wants it? /me raises both hands and would raise more if had more hands
Sales: how do you make more demand for what you're selling? People might not care at the moment, but could be convinced to care. How do you do that?
Financing: how are you going to pay the bills before the company turns a profit? Unemployment benefits? Not likely. Often you might have to get a loan or sell some equity to a VC/angel so that you can eat while you get the ball rolling.
Etc.: there are a lot of other things that come into play here, but I won't bore you with all those details since I think the three above are enough to make the point.
In short, my point here is that business is not as easy as this guy makes it sound.

What do you do when a business guy comes to you with a pitch? You might as well hear his idea out, it might actually be worth something - although if you're young like me your sense of what is worth something might not be fully developed yet, so keep that in mind as well. Sign the NDA if you need to, but don't make any commitment until you know what you're getting into. However the most important thing is to set a precedent: be assertive at the beginning. Say that if you're getting 50% of the equity then you're actually getting 50% of the company which includes 50% of the decision making, 50% of the exposure, etc.

Keep in mind though that this requires 50% of the responsibility - if the business fails, it's 50% your fault. If the business guy is doing something obviously stupid, it is your responsibility to let him know and work with him to make a better decision (or realize that maybe what he is doing isn't so stupid). You can't expect to be treated like a partner if you don't act like a partner.

Anyway, the two points I have are:
1) When you're in that situation where you're the developer of a 2-guy startup, assert your position as a partner or you won't be treated like one.
2) Remember that there are more options than "work as programmer for startup" or "work for big co" - namely, the "start your own startup" is a viable option. I think a lot of people forget about this when thinking about finding jobs.

I Have Sold My Soul

I feel I must publicly admit this here to you all. I have purchase some Apple products. I have an interest in making apps for the iPad, so I went out and bought one. However it turned out to be fairly useless for development on its own, an actual Mac is necessary. So I picked up a Mac Mini off eBay for dirt cheap and have started working with that.

So what are my thoughts on it? Well, my first thoughts are that it is a pain in the ass. It isn't the interface really (learning a new OS is always tricky, so I'm not really factoring that into my considerations). What I'm talking about is Apple itself. The system is not that old, it is running Tiger, but it is a bit annoying to get things from Apple for it. They seem adamant on trying to get you to purchase Snow Leopard at every turn (which I ended up having to do anyway, since XCode with the correct iOS SDK does not work with Tiger). At least with Windows stuff still works on XP (I can't believe I'm sticking up for Microsoft) without having Windows 7 being stuffed down your throat. However to even things out, Mac software upgrades are far cheaper than Windows ones, so it doesn't hurt that much paying for it if I am considering it as a potential business investment.

Anyway, it might be that I am just not used to the system yet, but I still haven't seen what all the Mac fanboys are raving about. The only thing that I do know at this point is that Apple has bothered me enough that I have absolutely zero desire to purchase any more of their products - although I may end up doing it anyway, depending on how well this whole iPad app thing goes.

What about my Touch Book? Well, I wasn't especially enamoured with it. It was a bit too sluggish for the things I wanted to do and since I bought the iPad I really had no more use for it. I hope the new owner is happy and may it serve him well.

Anyway you can expect a few Objective-C related posts coming up here in the near future.

Introducing L-Systems

My apologies, I haven't been writing as much these days; I've been having a bit of a blogger's block as to what to write about. I've got a few other statistics articles in mind, however since I enjoy variety I don't really want to write about the same thing all the time. So I'll reach out to the readers, is there any topic in particular you'd like me to write about?

Now that that is taken care of, we can get down to business. I've been doing a lot of reading these days, and one thing that I've stumbled upon are a nifty little computer science topic called L-systems. These things are quite simple to describe, yet are able to produce all sorts of interesting results (have you noticed a common theme to some of my blog posts these days?).

You need 3 things to describe an L-system. The first is an alphabet. An alphabet is very simple, it is just a set of characters that you will use within your alphabet - nothing more, nothing less. This is similar to a programming language where your alphabet is some subset of the ASCII character set unless you're using something more esoteric like APL (which is actually pretty neat, I've been looking at it a bit recently and I might put up a post about it soon - I guess I don't have blogger's block after all! You're still welcome to give requests though :) ).
The next thing you need for an L-system is an axiom. An axiom is simply a finite, non-empty string from your alphabet. You can also call it a seed if you like. The axiom (or seed) serves as the basis for the growth of the system.
The third thing is the most important - the production rules. What these do is map a character in the alphabet to some string. You apply the production rules on the axiom by converting each character in the axiom to whatever the rules say it maps to.

Let's consider an example L-system:

Alphabet: F, +, -
Axiom: F++F++F
Rules:
F -> F-F++F-F
+ -> +
- -> -

It is not necessary to specify the rules for + and -, since if you don't include them it is assumed that they just map to themselves (the identity function).

Let's run this L-system through one iteration. Begin with the axiom:

F++F++F

Then apply the rules:

F-F++F-F++F-F++F-F++F-F++F-F

I'd go for another iteration or two, but as you can see this thing will grow quickly and the text would probably run outside of this div. I'll just let you use your imagination as to what the next iteration would look like.

You may wonder why I picked this specific alphabet, as it looks rather peculiar. It turns out that this alphabet is directions for a turtle. The F means go forward, the + means turn left, and the - means turn right, all the while drawing a line.

Suppose we make the angle that the turtle turns equal to 60 degrees and iterate 4 times, you'll end up with a picture like this:

If you iterated this L-system an infinite number of times and at each iteration divide the distance that the turtle moves on each F by 3, you would end up with a fractal called the Koch snowflake (I made the mistake of saying that name out loud to my girlfriend, which caused her to giggle uncontrollably - perhaps I pronounced it wrong).

The next thing we can do is give our turtle an upgrade. In the current state, the turtle is limited to only drawing convoluted lines. While this is good, there are a great many interesting things to draw that aren't lines. We can change this by adding a powerful new feature to the turtle with these two symbols: [ and ]. The [ will push the current state of the turtle onto a stack (there is only one stack, so I should call it the stack), and ] will pop that state off of the stack and restore the turtle to that state.

This gives us a lot more power to create interesting images. Consider this L-system:

Alphabet: F, [, ], +, -
Axiom: F
Rules:
F -> FF-[-F+F+F]+[+F-F-F]

If you iterate this system 4 times, use an angle of 22.5 degrees and a step size of 6 pixels for your turtle, you get something like this (grabbed from The Algorithmic Beauty of Plants (The Virtual Laboratory)):

That's a bit cooler! And that image is generated by a completely deterministic process (aka no randomness). Which means that unlike my fractal trees, you will get exactly the same picture if you follow the rules above.

You can take these L-system things much much further, however I can see your eyes beginning to glaze over, so I will save that discussion for another day. As for code, you can see the L-system parser here, and the turtle graphics renderer here.

Biasedness and Consistency

I remember back in those days when I was taking my first statistics class when this formula appeared (hotlinked from Wikipedia):

I thought to myself, "self, holy crap! That's nasty!" (there are actually a lot of nastier formulae, but I was young in my academic career and hadn't seen too many of them yet). At the time all I did was just memorize the formula and promptly forgot it after I had finished the course.

After I started taking economics and I had to take a lot more statistics, I started to wonder why this equation is the way it is. It turns out to be a bit interesting, and you can learn a bit about statistics when you answer this question.

The part that I thought was the weirdest is that when you take the standard deviation of the population you divide by n, however when you take it from a sample, you use n - 1. Why did the do this?

Let's go on an aside for a bit. When we are using a sample, these statistics that we are generating (the sample mean and the variance) are estimators of the actual parameters, based on the sample that we have taken. These two estimators are random variables, which means it is highly unlikely that they will be the same as the actual parameters. This is not a bad thing, however we would like to have some measures of "goodness" of the estimators that we have.

One measure of "goodness" is called unbiasedness. Intuitively we all know what a bias is, it is something that sorta skews the estimate away from the actual value that we are estimating. Formally you would call the estimator unbiased if:

E(estimator) = parameter

The E function there is the expected value of the random variable, which is essentially an average value that the random variable comes out to. If on average the estimator is not coming out to be our parameter, then we have some kind of bias going on.
Given the above definition, our variance estimator would be unbiased if:

E(s2) = σ2

It turns out that if you divide by n for the sample variance you end up with:

E(s2) = &sigma2 * (n - 1) / n

This is always smaller than the variance, so our estimate is biased downwards. Thus we must correct the bias by dividing by n - 1 instead of n.

So that's why you divide by n - 1 and not n. While that's almost enough statistics for you for one day, there is one last tidbit of information that can be taught here. If you look at the formula for the expected value of the biased estimator, you'll notice that the bias will shrink as n gets large. In fact in the limit, the bias will go to zero and you will have an unbiased estimator. The name for this type of estimator is a consistent estimator. While they are not as good as unbiased estimators (note that all unbiased estimators are consistent), it is often the case that you might want to use a biased yet consistent estimator instead of an unbiased one if perhaps there is something wrong with the variance of the unbiased estimator. Eventually in one of my statistics posts I will talk about some problems with real-world data that might cause this sort of thing to happen.

Science Vs. Faith

I saw this image the other day (via this post, which got it from here):

After reading the right-hand side I thought to myself, "hey, that's kinda like economics!" So I cried a little inside. And then I made my own version:

The Barnsley Fern

The guy who coined the name "fractal", Benoît Mandelbrot, really liked fractals because he believed - or I should say believes since he's still alive (UPDATE: I am extremely disappointed to say that as of Oct. 14, 2010 this is no longer true) - that nature is fractal in nature (no pun intended). He said that many things in the world do not fit into our standard notion of geometry with lines, spheres, cubes, etc. and instead take on a bit more sophisticated form - fractals.

One thing is for sure, many of the fractals that have been discovered are incredibly similar to real life. An example is Barnsley's Fern, a fractal generated from an iterated set of functions that looks an awful lot like ferns we see in nature. Here's a picture for you:

This image is generated using the following algorithm:

x, y = 0.0, 0.0

loop until satisfied:
  draw x, y
  x, y = random_func(x, y)

What random_func() does is applies a random linear transformation to the pair (x, y), chosen from a group of 4 possible transformations each with a specific probability. You can see the transformations on the Wikipedia page, or in my version of the code here. If you don't feel like going that far, a linear transformation is just where you take the vector (x, y) - let's call it v - multiply by a matrix and then add a constant vector:

v = A * v + a

In the fern drawing you would choose a random transformation, which is just a pair with a matrix and a vector to plug into the above formula. Different transformations will give you different shapes of the fern, feel free to play around and see what you get.

It's truly amazing how something so familiar can be generated using such a simple formula. I'm hoping to dig up some more things like this and hopefully post them here for all of you to see.