5 ms·

I'm both a Lisp and a C++ fan and I really like the idea, but I'd like to make a couple of suggestions. - Use the STL algorithms more. There are way too many "

I'm both a Lisp and a C++ fan and I really like the idea, but I'd like to make a couple of suggestions. - Use the STL algorithms more. There are way too many "for" loops in this code which are trivial std::accumulate or std::transform calls. - When I see the eval and tokenize functions I ask myself, why not use Boost.Spirit.Qi? - I'm not sure working on a list of strings is efficient, why not work on a list of pairs of pointers instead? - Use smart pointers to avoid leaks. Just a small contribution, I really like the idea.

paufernandez 16y ago
"When I see the eval and tokenize functions I ask myself, why not use Qi?" You mean to use Qi's eval? I don't know Qi, so I don't understand what that would entail.
mahmud 16y ago
Note to confused Lispers: When I see the eval and tokenize functions I ask myself, why not use Qi? Pull down your eye-brows folks, he means boost::spirit::qi, not http://en.wikipedia.org/wiki/Qi_(programming_language) http://en.wikipedia.org/wiki/Qi_(programming_language) I had a whole minute of flabbergasted awe, then decided to double check with the Google :-)
- shin_lao 16y ago
  You're right, I edited my remark.
scott_s 16y ago
- Use the STL algorithms more. There are way too many "for" loops in this code which are trivial std::accumulate or std::transform calls. Pre-C++0x, that's not a clear tradeoff. Since pre-C++0x does not have lambdas, you would have to write one-off functions or function objects. In this case, I think that would increase the number of lines of code. I do a lot of work in C++, and I prefer using the STL algorithms to explicit for loops. But I have often written code that uses the STL algorithms, then reverted it back to a for loop because I had to introduce more code at another level of scope for a marginal gain in clarity - a voice in the back of my head tells me I'm being too cute. Now that C++0x has lambdas, this should cease to become an issue as I can assume compilers support them.
- shin_lao 16y ago
  I think a lot can be rewritten with boost::lambda or boost::proto without being too obscure.
  - scott_s 16y ago
    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.)
  - lutorm 16y ago
    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.
nocman 16y ago
"I'm both a Lisp and a C++ fan..." I find that to be very interesting. I spent far too many years working with C++, trying to master all of its nooks and crannies. It was my frustration with the limits of the language that drove me to finally learn Lisp. The fact that for loops always ended up appearing clearer than using STL was extremely frustrating. I'm not 100% sure that the introduction of lambdas in the newer versions of the C++ standard will not fix the problem (or at least help some), but I sincerely doubt that they will be enough. I truly wanted to use STL and the the standard containers, but it always ended up feeling like I was working extra hard to try and "get it right". In the end it was faster just to grumble, write another for loop with an explicit iterator, and move on. And yes, I'm aware of Boost and the like. I have all the template metaprogramming books you are likely to name. It all still feels terribly unnatural and forced compared to, say, composing a chain of function calls against a list of data in Lisp or Scheme.
- shin_lao 16y ago
  I really like playing with Racket. It's very powerful and simple. Mathematical. I concede that. But it's not "natural". I can guarantee you that Lisp showed to a novice isn't "natural". C++ is different. It's not unnatural. There's no "natural" programming language. C++ is explicit. You need to manage your memory. You need to tell how the return value will be handled. You need to work with the compiler, the linker. You have more control. More power. It gets in the way for some tasks, but it is mandatory for others. I find the lack of STL to be frustrating, because I'm used to it. To me it feels "natural". There's no problem with not being proficient with C++ or the STL. It's just not your thing!
  - ohyes 16y ago
    >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).
  - nocman 16y ago

paufernandez 16y ago

"When I see the eval and tokenize functions I ask myself, why not use Qi?" You mean to use Qi's eval? I don't know Qi, so I don't understand what that would entail.

mahmud 16y ago

Note to confused Lispers: When I see the eval and tokenize functions I ask myself, why not use Qi? Pull down your eye-brows folks, he means boost::spirit::qi, not http://en.wikipedia.org/wiki/Qi_(programming_language) http://en.wikipedia.org/wiki/Qi_(programming_language) I had a whole minute of flabbergasted awe, then decided to double check with the Google :-)

shin_lao 16y ago
You're right, I edited my remark.

scott_s 16y ago

- Use the STL algorithms more. There are way too many "for" loops in this code which are trivial std::accumulate or std::transform calls. Pre-C++0x, that's not a clear tradeoff. Since pre-C++0x does not have lambdas, you would have to write one-off functions or function objects. In this case, I think that would increase the number of lines of code. I do a lot of work in C++, and I prefer using the STL algorithms to explicit for loops. But I have often written code that uses the STL algorithms, then reverted it back to a for loop because I had to introduce more code at another level of scope for a marginal gain in clarity - a voice in the back of my head tells me I'm being too cute. Now that C++0x has lambdas, this should cease to become an issue as I can assume compilers support them.

shin_lao 16y ago
I think a lot can be rewritten with boost::lambda or boost::proto without being too obscure.
- scott_s 16y ago
  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.)
- lutorm 16y ago
  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.

nocman 16y ago

"I'm both a Lisp and a C++ fan..." I find that to be very interesting. I spent far too many years working with C++, trying to master all of its nooks and crannies. It was my frustration with the limits of the language that drove me to finally learn Lisp. The fact that for loops always ended up appearing clearer than using STL was extremely frustrating. I'm not 100% sure that the introduction of lambdas in the newer versions of the C++ standard will not fix the problem (or at least help some), but I sincerely doubt that they will be enough. I truly wanted to use STL and the the standard containers, but it always ended up feeling like I was working extra hard to try and "get it right". In the end it was faster just to grumble, write another for loop with an explicit iterator, and move on. And yes, I'm aware of Boost and the like. I have all the template metaprogramming books you are likely to name. It all still feels terribly unnatural and forced compared to, say, composing a chain of function calls against a list of data in Lisp or Scheme.

shin_lao 16y ago
I really like playing with Racket. It's very powerful and simple. Mathematical. I concede that. But it's not "natural". I can guarantee you that Lisp showed to a novice isn't "natural". C++ is different. It's not unnatural. There's no "natural" programming language. C++ is explicit. You need to manage your memory. You need to tell how the return value will be handled. You need to work with the compiler, the linker. You have more control. More power. It gets in the way for some tasks, but it is mandatory for others. I find the lack of STL to be frustrating, because I'm used to it. To me it feels "natural". There's no problem with not being proficient with C++ or the STL. It's just not your thing!
- ohyes 16y ago
  >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).
- nocman 16y ago