3 ms·

You comment is interesting. In the first sentence Lisp is a good solution against complexity. In the second one it is not. A good litmus test for complexity is

You comment is interesting. In the first sentence Lisp is a good solution against complexity. In the second one it is not. A good litmus test for complexity is the following: as a developer analysing software in order to understand & modify it, how many lines of code do I have to read in order to grasp what is going on and what can I do to solve my problem? In my opinion this is the main goal of a good software architecture. The advantage of lisp is that I can create a DSL like library that precisely describe my domain. The issue is that because macros can have dramatic effects on the final program, I have to check carefully all of them in order to understand a piece of code. This and the inability to look up quickly what fields are inside an object or the exact api of a function. A common base language and static types are the best tools I know to create useful boundaries. Another way is to split the software but this comes with other issues. The use of the term "powerful" might be a bit misleading. Powerful is good. Here powerful refers to "easy metaprogramming". Metaprogramming is something you need in an ecosystem, but you need to hide it a bit so that you only use it when you really need it. I find the lisp community a little bit too proud of their metaprogramming capabilities.

evdubs 6y ago
> The issue is that because macros can have dramatic effects on the final program, I have to check carefully all of them in order to understand a piece of code. Do you have an example where you had to carefully check a macro when writing your Lisp code? I have never looked into macro code more closely than function code when writing Racket programs, and mostly I don't know or care if whatever I am calling is a macro or a function. > This and the inability to look up quickly what fields are inside an object or the exact api of a function. At least within Clojure and Racket, you have IDEs like Cursive and DrRacket that will show you function documentation and do code completion. Or are you saying that the presence of macros alters this somehow?
pmoriarty 6y ago
"how many lines of code do I have to read in order to grasp what is going on and what can I do to solve my problem?" I'm not sure that lines of code alone are that useful here, or APL would be everyone's idea of a perfect language, since it can express so much in so few lines. The Lisp community in particular seems to value verbosity over terseness, preferring long, descriptive function names and variable names, which make for more lines of code, but arguably greater readability. I personally value clear code far higher than terse or clever code. I'd much rather read over a page of easily understandable code in 5 minutes than puzzle over a single line that does the same exact thing for an hour.
- tincholio 6y ago
  Even with the long names, Lisp code can be very compact, because the language is very expressive. In my experience, You can implement the same functionality in Clojure or in Java, with the Clojure version being 3x to 5x smaller than the Java one. This does not necessarily hold for all domains and all code, but it is often the case.

evdubs 6y ago

> The issue is that because macros can have dramatic effects on the final program, I have to check carefully all of them in order to understand a piece of code. Do you have an example where you had to carefully check a macro when writing your Lisp code? I have never looked into macro code more closely than function code when writing Racket programs, and mostly I don't know or care if whatever I am calling is a macro or a function. > This and the inability to look up quickly what fields are inside an object or the exact api of a function. At least within Clojure and Racket, you have IDEs like Cursive and DrRacket that will show you function documentation and do code completion. Or are you saying that the presence of macros alters this somehow?

pmoriarty 6y ago

"how many lines of code do I have to read in order to grasp what is going on and what can I do to solve my problem?" I'm not sure that lines of code alone are that useful here, or APL would be everyone's idea of a perfect language, since it can express so much in so few lines. The Lisp community in particular seems to value verbosity over terseness, preferring long, descriptive function names and variable names, which make for more lines of code, but arguably greater readability. I personally value clear code far higher than terse or clever code. I'd much rather read over a page of easily understandable code in 5 minutes than puzzle over a single line that does the same exact thing for an hour.

tincholio 6y ago
Even with the long names, Lisp code can be very compact, because the language is very expressive. In my experience, You can implement the same functionality in Clojure or in Java, with the Clojure version being 3x to 5x smaller than the Java one. This does not necessarily hold for all domains and all code, but it is often the case.