Sounds like a common objection to C++, where the language is so large that every team chooses its own subset of features they'll use, and ignore the rest :)

That's much less of a problem, because if you know the whole thing, then any subset of it is also known. It only becomes a problem if you need to change the code, because then you have to be aware of the subset to restrict yourself to.

C++ actually has a similar problem with developing idiosyncratic in-house solutions to common problems - it's not uncommon to find hand-rolled collections, reference-counting pointers etc, especially in older codebases from before STL and Boost became more widely accepted. But because the language doesn't offer anything close to the flexibility of Lisp macros, those idiosyncrasies are also much easier to parse.

I don't know anyone who claims to know the whole of C++.

Knowing the language itself is not that hard. It's big, but manageable. Obviously there will always be corner cases where you need your language lawyer hat (and the copy of the Standard), but those exist for pretty much any language.

The library is more complicated, especially once you get to iostreams and locales. But also less of an issue in this scenario.

> It is as if every project in lisp somehow magically develops its own DSL. That's a high hurdle for newbies to clear.

I'm not sure it is, most Lisp code I've seen is very readable, and you don't need to understand the internal most of the time.

Like in Scheme, if the function name isn't followed by a !, then you can assume that it is functional, so you don't need to worry about anything other than input and output.

So you end up with DSLs like:

    > (read-html (string-as-port "<h1>Hello, World!</h1>"))
    = '(h1 ("Hello, World!"))

It's a DSL, it's created a non-standard list at the end, an X-Expr, but it's readable, and predictable, without me trying to work out the internals of how a string-port functions, or how read-html works beyond it reads from a port.

Does the other way really scale though?

I mean, the "state of the art" is to have readable code everywhere. What readable really means is "have each component defined in terms of the standard library". This involves a lot of repetition and a lot more code, with the advantage that any part of the program can be understood by a new programmer.

The Lispy/Bottom Up way is to write a language, then solve your problem in terms of the language you just wrote. Only at the very low levels are you really dealing with standard library stuff. The advantages are obvious, but the disadvantage of this is you have to learn the DSL as well.

Have you experienced both approaches?

Fortunately, JEE & Spring are MUCH easier to get started with :-)

Let them eat COBOL...

Cobol, that's where you get your CICS! The original heavyweight framework, callbacks and all. Loads of fun.