Hum, I can't tell why coding is fun. I can however tell why I have so much fun developing my current project.
The project is a compiler to produce serialization and deserialization classes from a datatype description.
I have a lot of fun, because of the following things at the moment:
Sometimes, code approaches a level where the code itself is either clear beyond anything or where the code actually teaches you something about the problem you are solving. For example, in an abstraction of access paths through C datastructures (something like foo.bar->baz), my constructor calls for the various "steps" on the path look like: super(previousPath, "->", accessedMember). This makes me happy, because it is just so clear. You take the path until now, put a -> after it and put the accessed member after that to get the new path. Or, in other words: super(previousPath, "->", accessedMember).
In other parts, I put up some work to get fluent interfaces and internal domain dependant languages going. Parts of the code suddenly look like: BeginWithDerivingSerialiser().andThen(padToByteAligned).andThen(minimizeDuplication).andFinallyEmit(C89) or in another part: return CompositeHash().whichDependsOn(members).andOn(name).andNothingElse().
These little things, coupled with the knowledge what hassle this was before these little DSLs makes me smile everytime :)
Furthermore, my little compiler is growing in visible steps. I have adopted an iterative development style by now. That means, I know inputs for my compiler which are not handled properly yet, and I know what I need to solve to be able to handle this type. From this knowledge, I can pick certain inputs to solve which require a bit more infrastructure to work. On the other hand, once I implement the next input, it is really fun to do so, because I see: This works, that works, I dont need to care about that, because this abstraction does that for me and so on and so on. This is fun, because I can see how a previously large problem shrinks in simple 1-2 day steps until it it is easy to solve and then I solve it and my compiler is stronger now :)
Third, as you said, code is a fun puzzle. Solving the issues at hand is just the first step. Sometimes it is complicated and you need to think a day about the problem, sometimes an algorithm is just known. But after that, nudging and shifting the code until it looks and feels really lean and elegant is very, very interesting. Maybe extracting this into a method works? Maybe turning these loops the other way works? Maybe inverting that if makes it nicer? Who knows! Lets try! Maybe it will become one of thos masterpieces :)
The project is a compiler to produce serialization and deserialization classes from a datatype description.
I have a lot of fun, because of the following things at the moment:
Sometimes, code approaches a level where the code itself is either clear beyond anything or where the code actually teaches you something about the problem you are solving. For example, in an abstraction of access paths through C datastructures (something like foo.bar->baz), my constructor calls for the various "steps" on the path look like: super(previousPath, "->", accessedMember). This makes me happy, because it is just so clear. You take the path until now, put a -> after it and put the accessed member after that to get the new path. Or, in other words: super(previousPath, "->", accessedMember).
In other parts, I put up some work to get fluent interfaces and internal domain dependant languages going. Parts of the code suddenly look like: BeginWithDerivingSerialiser().andThen(padToByteAligned).andThen(minimizeDuplication).andFinallyEmit(C89) or in another part: return CompositeHash().whichDependsOn(members).andOn(name).andNothingElse().
These little things, coupled with the knowledge what hassle this was before these little DSLs makes me smile everytime :)
Furthermore, my little compiler is growing in visible steps. I have adopted an iterative development style by now. That means, I know inputs for my compiler which are not handled properly yet, and I know what I need to solve to be able to handle this type. From this knowledge, I can pick certain inputs to solve which require a bit more infrastructure to work. On the other hand, once I implement the next input, it is really fun to do so, because I see: This works, that works, I dont need to care about that, because this abstraction does that for me and so on and so on. This is fun, because I can see how a previously large problem shrinks in simple 1-2 day steps until it it is easy to solve and then I solve it and my compiler is stronger now :)
Third, as you said, code is a fun puzzle. Solving the issues at hand is just the first step. Sometimes it is complicated and you need to think a day about the problem, sometimes an algorithm is just known. But after that, nudging and shifting the code until it looks and feels really lean and elegant is very, very interesting. Maybe extracting this into a method works? Maybe turning these loops the other way works? Maybe inverting that if makes it nicer? Who knows! Lets try! Maybe it will become one of thos masterpieces :)