[vemv]

Would agree with your view, but Lisps are arbitrarily powerful by the means of macros and interop.

In my daily work (Clojure) I can use different concurrency and typing models than Clojure originally envisioned, via core.async, clojure.spec. This is not some fairy tale or toy/PLT project.

How many languages can fundamentally change themselves without breaking things or getting awkward?

[eropple]

Lisps are arbitrarily powerful, yes, sure. Once I too was a Lisp head, I am familiar with the advocacy.

They also read awfully even with an editor designed for them. They aren't human-first languages. S-expressions are easy for a computer, they are hard for a human. So, yeah, that can be improved, too. "But you can do it with macros"--other people won't, and so you are thus devolved to the minimum set everyone can agree upon, and it's gonna be awful.

And so there is room to grow outside of one's parentheses, too.

[flavio81]

>They aren't human-first languages. S-expressions are easy for a computer, they are hard for a human.

I've used Python, C, C++, C#, Java and Pascal extensively. I can safely say Common Lisp allows you to write the most readable code of all languages i've used, and i'd expect this to be the same for most other lisps.

Since they are hugely flexible, they allow you to write code in such a way that the problem and solution are expressed in the most explicit and straightforward way.

[vemv]

Threading macros (-> / ->>) can greatly improve readability, putting lisps on par with Ruby (which I appreciate much).

Best of all, emacs/Cursive lets you trivially transform a sexpr into a threading form, and back. So one doesn't even have to do much effort for refactoring nested (a(b(c(d calls.

[eropple]

I totally get that--what I'm saying is that, much like something like C++, you can only practically use the subset everybody you have to work with will agree is acceptable. Threading macros, IMO, help but don't really solve the readability problem, and it's still a far sight from Ruby, but it's a good step. But you have to get Bill the chin-stroking graybeard down the hall to use them when they're "not how he uses Lisp." Contrast this to a language with more guardrails--the equivalent of that threading macro in Ruby (or in Scala, or in F#) is just...The Way You Do It, it's the standard of the tools involved.

You're transforming a linguistic readability issue into a cultural problem of agreement and that's a waaaay harder problem to solve, IMO. Lisps are cool. But every problem raised to "cultural problem" is so much harder to solve. (When was the last time you saw an indent war in Ruby?)

[vemv]

Your observations are on point, and collaborating with lispers is not free of bitter moments.

At work we use cljfmt (similar to gofmt) plus a variety of hacky formatters and conventions. It works for us and I hope to open-source part of our stack at some point!

The experience is similar to that of Rubocop - which btw is the reason why there aren't indent wars (or similar) on Ruby.

Great to decomplect how code is written (however you please), from how it is committed (autoformatted).

[vemv]

By the way I agree with `There is a better thing, even if you must make it`!

But I make those 'things' within lisp rather than by exploring new languages. If done sensibly, colleagues will be able to use those custom abstractions too.

[flavio81]

>Lisps are arbitrarily powerful by the means of macros.

This is my experiencie too. S-expressions + macros is an amazingly powerful combination.