Lisp interpreter in 90 lines of C++

Just to be clear, I didn't describe Lisp as "natural", I described using the STL (meaning, particularly, heavy use of STL algorithms, function objects, etc) as feeling terribly unnatural and forced. Judging by the reaction here, "unnatural" was perhaps not the best choice of words. What I meant was this: when trying to use the STL to get stuff done, I felt like I was always jumping through hoops to do things "the STL way", with the end result being more complicated and less clear than just doing it in a "C++ without the STL" way.

> I can guarantee you that Lisp showed to a novice isn't "natural".

Again, I never argued that Lisp was "natural". And secondly, if you are dealing with a true novice (as in, someone who has never programmed in any programming language), both C++ and Lisp are going to look decidedly "unnatural" to them. But I don't want to beat the natural/unnatural language dead horse any longer, since that was not what I was discussing. However, I will concede that Lisp looks decidedly foreign to people who have programmed before in languages with an Algol-like syntax (C, C++, Java, Javascript, Perl, etc).

And, for the record, I am very proficient in C++ (many years of work experience), and I understand how the STL works very well (I invested a lot of time in learning the STL). I invested that time because I wanted to make C++ do more than it had done for me in the past, and the STL seemed like the way to do that. However, in the end I decided that there really was no good way to make C++ do what I wanted, and the real answer was to go with something that was far better at handling higher level constructs. After trying out Lisp (and Scheme) for I while I realized that the primary things I was trying to do with the STL were no-brainers in Lisp. And with a decent FFI I can still use C or C++ when I need to do things at a lower level. I still use C++ libraries when it makes sense to do so, but I would not now start a new project with C++ as the primary language if given the choice to use something else (unless, of course, the only choices were something even worse than C++ :-D ).

>But it's not "natural". I can guarantee you that Lisp showed to a novice isn't "natural".

How do you define a language as "natural"?

I can't say I find any language to be 'natural', there are just some that I know the rules to more implicitly than others.

(Including natural languages like English or Spanish).

I played with boost::lambda, and I found the resulting code less clear than a simple for loop. I also had difficulty gaining an intuition for what I could and could not do with it. Rather than constantly asking myself "Can I use boost::lambda here...? Will it look better or worse than the alternative?" I just decided to never use it.

While I prefer a functional style of coding, I recognized that it was silly to adhere to it if doing so made my code worse - C++'s support for what I wanted to do just wasn't there. If what I wanted to accomplish was several lines of code, I wrote a separate function or function object. If it was brief and I could not express it with combinations of existing functions, then I just wrote a for loop.

I didn't play with boost::proto, so I can't comment on that. But! C++ has real lambdas now. So, problem solved. (Once the compilers catch up.)

Like the other post said, I really wanted boost::lambda to work. However, I found that anything more complicated than "_1 * 2.0" became write-only code, so in practice it was useless.

Graders at the University of Michigan are willfully unaware of it because we want students to have some coding style. You'd be surprised how many have to be repeatedly slapped around until they get a real programmer's editor instead of trying to use gedit without configuring it.