3 ms·

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, t

by 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
    - mojuba 17y ago
      unwind-protect is not the same. Destructors in C++ are part of custom data types, and unlike unwind-protect, they are "implied", which makes your code safer and more succinct. And no, it's not necessarily memory clean-up, of course. C++ destructors are a powerful tool, you can create data types that otherwise would require support on the compiler's side.
      - anamax 17y ago
        > unwind-protect is not the same. You're right - they're more powerful, but bringing that up didn't seem necessary. > And no, it's not necessarily memory clean-up, of course. Never said that they were. However, C++ programmers spend a fair amount of time worrying about/writing code for memory cleanup and destructors is where a lot of that time/code goes. Folks using languages with GC don't do that nearly as much. Destructructors are only implied for scope-allocated variables. By tying value lifetime to variable scope, C++ gets to do certain things, but as a result, programmers have to do certain work. Lisp values are not tied to variable scope, so complaining that lisp doesn't have mechanisms for values that are tied to scope is sort of like complaining that a hovercraft doesn't have a parking brake. > C++ destructors are a powerful tool, you can create data types that otherwise would require support on the compiler's side. Actually, they're just a mechanism for calling code when a value "goes away". That's almost required for a language with manual memory management but unnecessary for languages with GC. However, destructors are also the only way that C++ has for automatically calling code. Other languages have other, more general, mechanisms.
        mojuba 17y ago
        I see what you are saying, but unfortunately garbage collectors in their present form are more evil than good. They are fine in some situations, but may turn to a problem in others. For example, you may get very undesirable effects if you are creating and destroying a large number of objects in a time-critical application (a game, etc). So, languages that provide no way of controlling allocation have relatively limited application compared to those that do provide full control over memory allocation. By "relatively limited" I mean just relatively, that is, the reason Python, Ruby, Perl, PHP, Java, C# and Lisp with their GC facility exist is that it works most of the time, but there are certain areas where you have no choice other than C/C++. Kernels, compilers (including Lisp compilers), game engines, everything that deals with hardware, image, audio and video processing, etc etc. This is an endless list where you really have no choice. Try to write a VST plug-in in Lisp, for example, that would add a reverb and will be able to do it on 8 audio channels in real-time on a 3GHz CPU.

by mojuba 17y ago

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
  - mojuba 17y ago
    unwind-protect is not the same. Destructors in C++ are part of custom data types, and unlike unwind-protect, they are "implied", which makes your code safer and more succinct. And no, it's not necessarily memory clean-up, of course. C++ destructors are a powerful tool, you can create data types that otherwise would require support on the compiler's side.
    - anamax 17y ago
      > unwind-protect is not the same. You're right - they're more powerful, but bringing that up didn't seem necessary. > And no, it's not necessarily memory clean-up, of course. Never said that they were. However, C++ programmers spend a fair amount of time worrying about/writing code for memory cleanup and destructors is where a lot of that time/code goes. Folks using languages with GC don't do that nearly as much. Destructructors are only implied for scope-allocated variables. By tying value lifetime to variable scope, C++ gets to do certain things, but as a result, programmers have to do certain work. Lisp values are not tied to variable scope, so complaining that lisp doesn't have mechanisms for values that are tied to scope is sort of like complaining that a hovercraft doesn't have a parking brake. > C++ destructors are a powerful tool, you can create data types that otherwise would require support on the compiler's side. Actually, they're just a mechanism for calling code when a value "goes away". That's almost required for a language with manual memory management but unnecessary for languages with GC. However, destructors are also the only way that C++ has for automatically calling code. Other languages have other, more general, mechanisms.
      - mojuba 17y ago
        I see what you are saying, but unfortunately garbage collectors in their present form are more evil than good. They are fine in some situations, but may turn to a problem in others. For example, you may get very undesirable effects if you are creating and destroying a large number of objects in a time-critical application (a game, etc). So, languages that provide no way of controlling allocation have relatively limited application compared to those that do provide full control over memory allocation. By "relatively limited" I mean just relatively, that is, the reason Python, Ruby, Perl, PHP, Java, C# and Lisp with their GC facility exist is that it works most of the time, but there are certain areas where you have no choice other than C/C++. Kernels, compilers (including Lisp compilers), game engines, everything that deals with hardware, image, audio and video processing, etc etc. This is an endless list where you really have no choice. Try to write a VST plug-in in Lisp, for example, that would add a reverb and will be able to do it on 8 audio channels in real-time on a 3GHz CPU.