3 ms·

What you're saying is really that it's too powerful for it's own good. And I agree. But what's good for Lisp isn't necessarily good for me, I prefer more power

What you're saying is really that it's too powerful for it's own good. And I agree. But what's good for Lisp isn't necessarily good for me, I prefer more power to one size fits all libraries. I think it comes down to experience in the end; the more you have, the more unwilling you are to give it up.

reikonomusha 10y ago
I disagree about it being "too powerful for its own good". If it was, we would have a magnificently efficient and useful library come out of this that brings Go- or Erlang-style programming to Lisp. But alas, this code does not. A lot of hardcore Lisp aficionados do the equivalent of a mathematician writing a "sketch of a proof" and saying "left as an exercise", without ever writing the details of the proof. It's occasionally aggravating when you pull in a library and discover that this is the case. To be clear, there are many Lisp folks do not do this. Some go the full mile and implement something completely and robustly. Edi Weitz has been the canonical example in the community.
- codr4life 10y ago
  Completely, what is that? Doesn't that depend on context (as in problem being solved)? Simple is often faster, and these are pretty fast without even trying. There is plenty of room for simple, fast enough code. Owning code you understand is an advantage.
  - rtpg 10y ago
    Completeness means being as performant as possible on all the possible axes. You might want simplicity, but users also want performance. So a complete solution will be performant, but simple. You have one use case, but other users have others. A complete solution will work in as many use cases as possible given its constraints. Scala's parser combinators are a good example of a complete solution. It offers the "elegant" solution of parser combinators. But it also offers an implementation of this using things like Packrat parsing that are extremely efficient. The non-complete example of this is someone who writes a parser combinator library that is simple, but simply not performant for real world use. For example, you might write a simple version in Python, but not properly apply TCO and so your parser can't handle deeply nested structures because of a stack overflow. --- With regards to owning code, I remember hearing that it took 9 years of the initial publication of quicksort for there to be a bugfree implementation of it. Even easy things can be tricky.
  - jonathanstrange 10y ago
    Completely, what is that? Well, comprehensive unit tests for a start...
    - codr4life 10y ago
      What's comprehensive? Doesn't that too depend on context? I'm with Kent Beck on tests. I'll test as much as I have to too move forward with confidence. In the end, my goal is to write working code, not tests.
- TeMPOraL 10y ago
  > A lot of hardcore Lisp aficionados do the equivalent of a mathematician writing a "sketch of a proof" and saying "left as an exercise", without ever writing the details of the proof. It's occasionally aggravating when you pull in a library and discover that this is the case. That's exactly "too powerful for its own good". It's so easy to write a half-assed sketch of a library that nevertheless gives you some new powerful feature, that some people end there, and publish the sketch that was enough for their use case.
wtbob 10y ago
I guess I should have mentioned that Lisp is my language of choice. I like the ease with which I can implement anything. But it does have a cost: everyone else implements everything himself, too. I actually think Quicklisp has helped. It's even easier to do (ql:quickload "foo-lib") than it is to write my own foo library.
- nickik 10y ago
  Everybody can do that stuff in Clojure too, and it does not suffer from the same thing CL does. It seems to me that it is a culture/ecosystem problem more then anything else.

reikonomusha 10y ago

I disagree about it being "too powerful for its own good". If it was, we would have a magnificently efficient and useful library come out of this that brings Go- or Erlang-style programming to Lisp. But alas, this code does not. A lot of hardcore Lisp aficionados do the equivalent of a mathematician writing a "sketch of a proof" and saying "left as an exercise", without ever writing the details of the proof. It's occasionally aggravating when you pull in a library and discover that this is the case. To be clear, there are many Lisp folks do not do this. Some go the full mile and implement something completely and robustly. Edi Weitz has been the canonical example in the community.

codr4life 10y ago
Completely, what is that? Doesn't that depend on context (as in problem being solved)? Simple is often faster, and these are pretty fast without even trying. There is plenty of room for simple, fast enough code. Owning code you understand is an advantage.
- rtpg 10y ago
  Completeness means being as performant as possible on all the possible axes. You might want simplicity, but users also want performance. So a complete solution will be performant, but simple. You have one use case, but other users have others. A complete solution will work in as many use cases as possible given its constraints. Scala's parser combinators are a good example of a complete solution. It offers the "elegant" solution of parser combinators. But it also offers an implementation of this using things like Packrat parsing that are extremely efficient. The non-complete example of this is someone who writes a parser combinator library that is simple, but simply not performant for real world use. For example, you might write a simple version in Python, but not properly apply TCO and so your parser can't handle deeply nested structures because of a stack overflow. --- With regards to owning code, I remember hearing that it took 9 years of the initial publication of quicksort for there to be a bugfree implementation of it. Even easy things can be tricky.
- jonathanstrange 10y ago
  Completely, what is that? Well, comprehensive unit tests for a start...
  - codr4life 10y ago
    What's comprehensive? Doesn't that too depend on context? I'm with Kent Beck on tests. I'll test as much as I have to too move forward with confidence. In the end, my goal is to write working code, not tests.
TeMPOraL 10y ago
> A lot of hardcore Lisp aficionados do the equivalent of a mathematician writing a "sketch of a proof" and saying "left as an exercise", without ever writing the details of the proof. It's occasionally aggravating when you pull in a library and discover that this is the case. That's exactly "too powerful for its own good". It's so easy to write a half-assed sketch of a library that nevertheless gives you some new powerful feature, that some people end there, and publish the sketch that was enough for their use case.

wtbob 10y ago

I guess I should have mentioned that Lisp is my language of choice. I like the ease with which I can implement anything. But it does have a cost: everyone else implements everything himself, too. I actually think Quicklisp has helped. It's even easier to do (ql:quickload "foo-lib") than it is to write my own foo library.

nickik 10y ago
Everybody can do that stuff in Clojure too, and it does not suffer from the same thing CL does. It seems to me that it is a culture/ecosystem problem more then anything else.