4 ms·

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

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.

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.