3 ms·

I agree with your first point. However, I'll have to very strongly disagree with "C++ has damn powerful meta-language facilities no other language of any level

I agree with your first point. However, I'll have to very strongly disagree with "C++ has damn powerful meta-language facilities no other language of any level has". C++ actually has terrible support for meta-language facilities. It is inconceivable in my mind that C++'s support for that is anywhere near something like Common Lisp, so forget about it being the best in that respect. I'd love to know what parts of C++ are great meta-language facilities. If you say C++ macros I'll have to laugh. Hard. </smuglispweenie>

william-newman 17y ago
Stepanov (i.e., Mr. C++ Standard Template Library) has said some comparably strong things about the expressiveness of C++ templates for the kinds of things expressed in STL, and he doesn't seem to be guilty of not investigating Lispy alternatives. e.g., http://www.antiquark.com/escape/public_html/stepanovusa.html http://www.antiquark.com/escape/public_html/stepanovusa.html There are various gnarly problems with C++'s model, some of which show up as gnarly problems in STL, even in fundamental stuff like implementing collections of refcounting pointers last time I looked. But as far as I can tell, every language which tries to get this correct within the language has some serious limitations or issues, arguably at least as bad, especially if like Stepanov one of your top priorities is eliminating every last bit of runtime overhead in the generated code. (E.g., implementing arrays of objects only as arrays of fixed-size pointers into variable-sized objects on the heap, as in typical CL and Java, is a no-go given STL priorities, and thus STL constantly wrestles with a bunch of problems that lots of other implementors have dodged by giving up on them.) As far as I know, no one has a comprehensively satisfactory solution for metalanguage facilities within the language. Getting metalanguage correct by stepping outside the language and upstream from the compiler, writing a separate program to generate the target program, has been a solved problem as long as we've known how to write compilers in Turing-complete languages. That approach is sometimes used for app code in conventional languages, as in FFTW, and to some extent it's what Lispy macros do. But for some applications, including STL as I understand it, stepping upstream is unsatisfactory. Sometimes what you'd really like to do is have your code generator query the compiler about what the compiler knows. STL in particular, IIRC, wants to have its code generation depend on what the compiler knows about types and typedefs and so forth. In an ideal world it would be routine for code generators to be able to ask the compiler about other things, too, like dead code, namespaces, and safety and other pragmas.
mojuba 17y ago
Templates, the implicit ctor/dtor paradigm coupled with scoping, to name a few. I know Lisp has a unique feature - let's say, unity of code and data, but hey, there are plenty of languages with unique features not found in C++; nevertheless I think my statement still applies, that no language compares to C++ in terms of power of meta-language facilities. I think I understand Lisp and I'd be happy if we could avoid Lisp wars in this context.
- anamax 17y ago
  Templates, the implicit ctor/dtor paradigm coupled with scoping, to name a few. I know Lisp has a unique feature - let's say, unity of code and data, but hey, there are plenty of languages with unique features not found in C++; nevertheless I think my statement still applies, that no language compares to C++ in terms of power of meta-language facilities. Umm, lisp macros can implement all of C++ meta-language facilities and more, so how are said meta-language facilities more powerful? And then there's the meta-language protocol....
  - mojuba 17y ago
    { X x, y; if (x > y) return; // some code ... } where X has a destructor. I'm curious if you can do this in Lisp without explicitly calling the destructors (for x and y) in proper places - two places in this example.
    - anamax 17y ago
      unwind-protect handles this case. (Note that most lisps have GC so if freeing memory is the only reason you're calling the destructor, you don't need to do anything.) http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/speope_unwind-protect.html http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec... There's a reason why PG refers to non-lisps as "blub". http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html http://www.gigamonkeys.com/book/beyond-exception-handling-co... http://www.lisp.org/mop/index.html http://www.lisp.org/mop/index.html

william-newman 17y ago

Stepanov (i.e., Mr. C++ Standard Template Library) has said some comparably strong things about the expressiveness of C++ templates for the kinds of things expressed in STL, and he doesn't seem to be guilty of not investigating Lispy alternatives. e.g., http://www.antiquark.com/escape/public_html/stepanovusa.html http://www.antiquark.com/escape/public_html/stepanovusa.html There are various gnarly problems with C++'s model, some of which show up as gnarly problems in STL, even in fundamental stuff like implementing collections of refcounting pointers last time I looked. But as far as I can tell, every language which tries to get this correct within the language has some serious limitations or issues, arguably at least as bad, especially if like Stepanov one of your top priorities is eliminating every last bit of runtime overhead in the generated code. (E.g., implementing arrays of objects only as arrays of fixed-size pointers into variable-sized objects on the heap, as in typical CL and Java, is a no-go given STL priorities, and thus STL constantly wrestles with a bunch of problems that lots of other implementors have dodged by giving up on them.) As far as I know, no one has a comprehensively satisfactory solution for metalanguage facilities within the language. Getting metalanguage correct by stepping outside the language and upstream from the compiler, writing a separate program to generate the target program, has been a solved problem as long as we've known how to write compilers in Turing-complete languages. That approach is sometimes used for app code in conventional languages, as in FFTW, and to some extent it's what Lispy macros do. But for some applications, including STL as I understand it, stepping upstream is unsatisfactory. Sometimes what you'd really like to do is have your code generator query the compiler about what the compiler knows. STL in particular, IIRC, wants to have its code generation depend on what the compiler knows about types and typedefs and so forth. In an ideal world it would be routine for code generators to be able to ask the compiler about other things, too, like dead code, namespaces, and safety and other pragmas.

mojuba 17y ago

Templates, the implicit ctor/dtor paradigm coupled with scoping, to name a few. I know Lisp has a unique feature - let's say, unity of code and data, but hey, there are plenty of languages with unique features not found in C++; nevertheless I think my statement still applies, that no language compares to C++ in terms of power of meta-language facilities. I think I understand Lisp and I'd be happy if we could avoid Lisp wars in this context.

anamax 17y ago
Templates, the implicit ctor/dtor paradigm coupled with scoping, to name a few. I know Lisp has a unique feature - let's say, unity of code and data, but hey, there are plenty of languages with unique features not found in C++; nevertheless I think my statement still applies, that no language compares to C++ in terms of power of meta-language facilities. Umm, lisp macros can implement all of C++ meta-language facilities and more, so how are said meta-language facilities more powerful? And then there's the meta-language protocol....
- mojuba 17y ago
  { X x, y; if (x > y) return; // some code ... } where X has a destructor. I'm curious if you can do this in Lisp without explicitly calling the destructors (for x and y) in proper places - two places in this example.
  - anamax 17y ago
    unwind-protect handles this case. (Note that most lisps have GC so if freeing memory is the only reason you're calling the destructor, you don't need to do anything.) http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/speope_unwind-protect.html http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec... There's a reason why PG refers to non-lisps as "blub". http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html http://www.gigamonkeys.com/book/beyond-exception-handling-co... http://www.lisp.org/mop/index.html http://www.lisp.org/mop/index.html