3 ms·

Thanks for writing this followup, Ron. This paragraph really resonated with me: > All this is a reflection of the so-called Lisp curse, the fundamental proble

by eliben 4y ago

Thanks for writing this followup, Ron. This paragraph really resonated with me: > All this is a reflection of the so-called Lisp curse, the fundamental problem with Lisp -- its great strength is simultaneously its great weakness. It is super-simple to customize Lisp to suit your personal tastes, and so everyone does, and so you end up with a fragmented ecosystem of little sub-languages, not all of which (to put it mildly) are particularly well designed. I have a career-long love and admiration for Lisp, but I've never used it for "real" things because of this precise reason. I wanted my code to be understandable and modifiable by others who are already familiar with the programming language I'm using. With Lisp, it's almost guaranteed that any sufficiently large program will be written in its own dialect no one but the author knows.

vindarel 4y ago
nah, disagree, how do you come to the conclusion it is "almost guaranteed" without having tried it for "real" things? (no mean for ad-hominem, I'd like to read details) It's also a great language where you can adapt anything, any library, to your needs, bypass its shortcomings, etc. What is the ecosystem of fragmented sub-languages? I don't know any in CL. (ergolib isn't a crazy sub-language either, it's just a library with helper functions and macros). We have solid libraries like Serapeum, supporting all existing implementations. Not sub-languages. I agree in the weakness that it's too easy to fix a library and not contribute the fix back. Individuals and companies are guilty here. I wish I saw more companies contributing to the open-source libs they use. But other persons send great contributions. It's a small world, so we easily see the good and the ugly.
- eliben 4y ago
  I believe the OP's ergolib provides an example. From https://github.com/rongarret/ergolib/blob/master/core/binding-block.lisp https://github.com/rongarret/ergolib/blob/master/core/bindin..., the examples show code like: ;;; (bb ;;; x 1 ;;; :db (y z) (foo) ;;; :mv (a b c) (bar) ;;; (do-something) ;;; :with open-file f "foo" ;;; (do-something-else)) And the code this replaces. This seems to me hard to understand without first digging into ergolib and grokking what bb means. It's just one simple example. I forget now where it was, but there's a famous Lisp quote which goes something like (paraphrased from poor memory): in Lisp you don't just solve problem X, you first grow a new programming language designed for solving X-like problems and then simply solve X with that. This has its charms, for sure. But it makes the code harder to understand for folks not familiar with your "language designed for solving X-like problems"
  - vindarel 4y ago
    It's a little helper, so as in any language we have to check the doc and an example. Just like how to use a rest api, or a high level function that does a lot of stuff under the hood. Once you know it's a binding macro it's even easy to guess. I don't find it difficult, it is similar to many similar macros out there. so yeah, I don't find the example extraordinary enough to speak about sub-languages. Plus, as another comment said very well, the most important is domain knowledge to understand the code. And the quote is right but we can also use Lisp like a dumb language and get shit done!

by eliben 4y ago

vindarel 4y ago

nah, disagree, how do you come to the conclusion it is "almost guaranteed" without having tried it for "real" things? (no mean for ad-hominem, I'd like to read details) It's also a great language where you can adapt anything, any library, to your needs, bypass its shortcomings, etc. What is the ecosystem of fragmented sub-languages? I don't know any in CL. (ergolib isn't a crazy sub-language either, it's just a library with helper functions and macros). We have solid libraries like Serapeum, supporting all existing implementations. Not sub-languages. I agree in the weakness that it's too easy to fix a library and not contribute the fix back. Individuals and companies are guilty here. I wish I saw more companies contributing to the open-source libs they use. But other persons send great contributions. It's a small world, so we easily see the good and the ugly.

eliben 4y ago
I believe the OP's ergolib provides an example. From https://github.com/rongarret/ergolib/blob/master/core/binding-block.lisp https://github.com/rongarret/ergolib/blob/master/core/bindin..., the examples show code like: ;;; (bb ;;; x 1 ;;; :db (y z) (foo) ;;; :mv (a b c) (bar) ;;; (do-something) ;;; :with open-file f "foo" ;;; (do-something-else)) And the code this replaces. This seems to me hard to understand without first digging into ergolib and grokking what bb means. It's just one simple example. I forget now where it was, but there's a famous Lisp quote which goes something like (paraphrased from poor memory): in Lisp you don't just solve problem X, you first grow a new programming language designed for solving X-like problems and then simply solve X with that. This has its charms, for sure. But it makes the code harder to understand for folks not familiar with your "language designed for solving X-like problems"
- vindarel 4y ago
  It's a little helper, so as in any language we have to check the doc and an example. Just like how to use a rest api, or a high level function that does a lot of stuff under the hood. Once you know it's a binding macro it's even easy to guess. I don't find it difficult, it is similar to many similar macros out there. so yeah, I don't find the example extraordinary enough to speak about sub-languages. Plus, as another comment said very well, the most important is domain knowledge to understand the code. And the quote is right but we can also use Lisp like a dumb language and get shit done!