Honestly, I too worry that I have way too weird of a breadth of knowledge, albeit not much depth, and sometimes worry if that will actually ever really pay the bills (Luckily, I have very secret and cunning plans that I hide in the darkness of my laboratory, simply waiting for the right moment...). In part 2 of the saga, I have posted the mjbcalc simple (untyped) lambda calculus symbolic calculator. A small, almost worthless, user guide is included in Word format. Code isn't the greatest, but it should be readable. Like all my other code releases consider it licensed under the GPL/2.0. I'd love to hear if anybody actually finds this useful. People don't realize how easy it is to build such simple "real programming languages", and, I hate to sound too mean, but classes like the worthless CECS 530 Compilers here at the University of Louisville don't do much justice to the topic. Like I said, I wrote it to spite the Professor who passed out something (SymCalculator2 in this archive, don't even bother looking at the horrible code in the other half) with much uglier, less readable code, poor API, poor encapsulation/abstraction, etc... that had a fraction of the power of this toy I built from scratch in a weekend... A little bit of clean up work, decent documentation, and optimization work and this baby might actually be pretty useful, and is capable of "real" programming. Then we can start talking about fun things like additional types (strings, tuples, lists), continuations, ...
If anyone is curious about the interesting background of the Lambda Calculus, check out the readable wikipedia article of the previous link. You might also find this paper on Proofs as Programs (via Lambda the Ultimate, a language blog) interesting. I was reading/skimming it just tonight and it discusses an overview of Frege's modern logic, Lambda Calculus, then Typed Lambda Calculus. It then discusses how the Typed Lambda Calculus and Logic Proof have a near direct correspondence between each other (just about to the point of being alternative syntaxes for the same concepts, albeit having been individually derived in very different manners).
If anyone is curious in working with these concepts in more than just my toy implementation above, might I suggest checking out a ML-derived language like Haskell or F#.