It's not generating code that is costly, but reading it. Understanding 100 lines of code is usually easier than understanding 1000 lines of code, understanding 1000 lines of code is usually easier than understanding 10000 lines of code etc.
So generally it pays of to keep codebase small and simple.
That's not at all true. The costly part is the complexity. You could spend half a day puzzling over ten lines of cleverly written Lisp and just breeze through 100 lines of Java that do the same thing.
BTW author of article mentions also incidental complexity of Java classes. It's worth consider too and maybe it's more accurate picture of problems with Java (and many other languages, it's more like poor design and "cult of complexity" than technology problems).
There are too many abstractions, classes, interfaces, inheritance, needless design patterns... it kills productivity and maintainability and ability to understand such codebases.
If 90% of that java code was generated, then what exactly were they doing?
Also, there is such a thing as too much abstraction, but there is also such a thing as too little abstraction and refusal to use design pattern where it fits, because "it would be too complicated" alias someone was scared and lazy to learn. Neither is good. The projects I have seen that refused these "advanced" techniques all ended like hard to maintain and makes sense of mess of special exceptions to special situations - hard to reason about code.
Design patterns are not hard and abstract thinking is as useful as good memory. Refusal to learn either is not mark of good developer.
Basically, you read stuff it is generated from, and you dont read generated part unless you suspect bug in generator.
The other occasionally generated stuff is syntactic sugar - hashCode, equals or delegate methods. That is quick to read once you get used to how it looks. More importantly, if that sort of thing is 90% of the code, then there is something wrong.
In reality, it's more likely that those 100 lines of boring Java are easily written in 10 lines of just as boring Lisp, the only difference being the removal of 90 lines of boilerplate getters and setters, iteration logic, exception declarations, class definitions and instantiation, and so on.
You can explain to someone (or learn on your own) "fancy" functional constructs like map, fold, and select in about ten minutes. And then they can be part of your vocabulary for an entire career. It is absolutely unfathomable to me that this is not a complete no-brainer.
Imagine a novelist who replaced every instance of ten common English words with their literal dictionary definition every time they came up in a book. That's the level of incredulity I personally experience every time I see someone write the same implementation of `map` for the tenth time in a single source file.
I hear this sort of thing from Lisp advocates all the time, but have never seen it in practice. Understandable Lisp isn't that compact.
Thus it is more understandable and less understandable, both at the same time, but on different levels.
Much more understandable for the domain-level programmer.
Much less understandable for the low-level execution-level programmer.
Do you suspect that this might have something to do with it? Lisp has a very different syntax from C-style languages, and this seems to trip people up much much more than the functional components of it.
Not being familiar with the idioms of another language doesn't mean those idioms are hard. It just means you aren't familiar with them.
Also, you are literally replying to a comment chain provoked by a post that argues, with code, exactly this point. The Clojure (a Lisp dialect) version has the same core logic as the Java version. The core logic is virtually inarguably just as readable as the Java version. And it is just shy of an order of magnitude fewer lines of code than the Java version.
So here's an example from a real, live code base of understandable Lisp, in practice, that is 10x more compact than the Java version.