6 ms·

> I cannot think of anything people do in C++ that I am unable to do in Lisp The biggest technical advantage I've noticed C++ having over other languages is t

by bcoates 14y ago

> I cannot think of anything people do in C++ that I am unable to do in Lisp The biggest technical advantage I've noticed C++ having over other languages is that library performance characteristics are documented as part of the portable language spec. I really miss that when I switch to other languages and have no idea if the builtin list class acts like a linked list or a vector or a deque or what. Knowing that the algorithm you just built out of library components doesn't have a n^3 blowup on some platform is a correctness issue, not a premature optimization. I'm more comfortable that's not going to happen working in C++, and the culture and libraries around it than anywhere else. Does CL specify that, as part of the specification and not just by convention? I'm having a hard time finding docs to that effect but I don't use Lisp enough to know where to look.

flyinRyan 14y ago
Actually, in CL a list is always a linked list. It's made of a "cons" which is a two celled part of memory for holding the head (usually data but can be anything) and the tail. A hash is also known to have hash behavior as opposed to, say, an rb tree. A vector is always what C++ would call an array though what CL calls an array might depend on convention (afaik it's often just a normal vector with the access calls changed to go to the correct location).
- betterunix 14y ago
  That does not really answer the question. Consider, for example, this question: how efficient is append i.e. for two lists of N elements, how much work will append do? It is easy to assume this will be linear work in N since append will make a copy; but does CLTL2 actually say that append cannot do work in quadratic time, or cubic time, or even exponential time? It's a valid complaint, in my opinion, and I say this as the person who promotes Lisp as an alternative to C++. I would put it in the category of "things missing from the Common Lisp standard," lumping it together with undefined behavior. In practice, this issue rarely comes up; it is generally safe to assume that no Lisp implementation will have an asymptotically worse version of a standard function than the simplest version of that function. So, for example, although the standard is silent on the matter you can safely assume that no Lisp implementation would have an nconc that is asymptotically worse than the simple linear time implementation, and you should not rely on an implementation giving you something better than that. In the C++ standard, there are definitions of running times. So, for example, the stable_sort function is guaranteed to be no worse than O(N log(n) log(n)), and no better than O(n log(n)). That is one thing that is nice about C++, so I can concede that point, though with the note that the C++ standard has its own glaring omissions that are much more disturbing than the running times of algorithms.
  - flyinRyan 14y ago
    Fair point, conceded.
MichaelSalib 14y ago
When I was doing heavy common lisp work, this was just a non-issue. If I wanted to understand how a library call would perform, I'd just press the magic button in SLIME to jump to the source code of the library routine and look. This was much easier than manually tracing through the layers of template and preprocessor indirection underlying even simple STL constructs. It is possible that this sort of standardization was vitally important given the incredibly poor quality of C++ implementations traditionally available, but in languages with better communities with higher standards for implementations and documentation, this really seems like a solution in search of a problem.
- Someone 14y ago
  "If I wanted to understand how a library call would perform, I'd just press the magic button in SLIME to jump to the source code of the library routine and look." That tells you how your implementation works. It tells you nothing about how other implementations (or the next version of your compiler) do things. The point is that, with C++, the standard proscribes the O(...) of algorithms. Yes, implementations can and will be broken, but given that writing a C++ compiler requires planning, I think it is unlikely that 'wrong choice of algorithm' will make it into any deliverable (counterexamples welcome)

by bcoates 14y ago

flyinRyan 14y ago

Actually, in CL a list is always a linked list. It's made of a "cons" which is a two celled part of memory for holding the head (usually data but can be anything) and the tail. A hash is also known to have hash behavior as opposed to, say, an rb tree. A vector is always what C++ would call an array though what CL calls an array might depend on convention (afaik it's often just a normal vector with the access calls changed to go to the correct location).

betterunix 14y ago
That does not really answer the question. Consider, for example, this question: how efficient is append i.e. for two lists of N elements, how much work will append do? It is easy to assume this will be linear work in N since append will make a copy; but does CLTL2 actually say that append cannot do work in quadratic time, or cubic time, or even exponential time? It's a valid complaint, in my opinion, and I say this as the person who promotes Lisp as an alternative to C++. I would put it in the category of "things missing from the Common Lisp standard," lumping it together with undefined behavior. In practice, this issue rarely comes up; it is generally safe to assume that no Lisp implementation will have an asymptotically worse version of a standard function than the simplest version of that function. So, for example, although the standard is silent on the matter you can safely assume that no Lisp implementation would have an nconc that is asymptotically worse than the simple linear time implementation, and you should not rely on an implementation giving you something better than that. In the C++ standard, there are definitions of running times. So, for example, the stable_sort function is guaranteed to be no worse than O(N log(n) log(n)), and no better than O(n log(n)). That is one thing that is nice about C++, so I can concede that point, though with the note that the C++ standard has its own glaring omissions that are much more disturbing than the running times of algorithms.
- flyinRyan 14y ago
  Fair point, conceded.

MichaelSalib 14y ago

When I was doing heavy common lisp work, this was just a non-issue. If I wanted to understand how a library call would perform, I'd just press the magic button in SLIME to jump to the source code of the library routine and look. This was much easier than manually tracing through the layers of template and preprocessor indirection underlying even simple STL constructs. It is possible that this sort of standardization was vitally important given the incredibly poor quality of C++ implementations traditionally available, but in languages with better communities with higher standards for implementations and documentation, this really seems like a solution in search of a problem.

Someone 14y ago
"If I wanted to understand how a library call would perform, I'd just press the magic button in SLIME to jump to the source code of the library routine and look." That tells you how your implementation works. It tells you nothing about how other implementations (or the next version of your compiler) do things. The point is that, with C++, the standard proscribes the O(...) of algorithms. Yes, implementations can and will be broken, but given that writing a C++ compiler requires planning, I think it is unlikely that 'wrong choice of algorithm' will make it into any deliverable (counterexamples welcome)