"I've written plenty of lisp (Clojure and non-Clojure) and I haven't observed it to be significantly shorter than Scala/Haskell."
Same here. Although I've found Haskell to be noticeably shorter than Scala. But there are trade-offs. Java reads sequentially, top-to-bottom, so when you are new to a piece of code, you trace through it in this linear fashion. And as Paul Graham says in On Lisp (p30), such code 'looks solid and blockish'. But it's approachable, if somewhat long and cluttered. On the other end of the scale is Haskell, which is anything but linear. And with a healthy dose of library-specific operators, it can be quite alien looking. Until you are accustomed to the syntactic patterns, it's pretty hard going. But after that point, it is considerably faster to grok the meaning of the program, as it is entirely clutter free. Clojure (and Lisps in general) is closer to Haskell in its non-linear nature, but without more syntactic help (eg infix operators), it never gets to the compactness of Haskell. And the indentation gets a bit heavier.
The increased LOC in Java is the price you pay for this linearity. But with program complexity and scale, this price can get to be pretty heavy. The same can be said for indiscriminate mutability and side-effects.
The increased LOC in Java is the price you pay for this linearity. But with program complexity and scale, this price can get to be pretty heavy.
It's not just that as the program gets larger, you have more of that linear code. It's that the program necessarily stops being linear. There's no linear way to lay out the logic of a sufficiently complex system. The pieces may be linear in the small, but the way they interact is not. The same is true of spaghetti.
For some reason when people talk about readable code they tend to consider just the pieces and not the interactions between them. But you can't understand a system without the latter and it's the latter where most complexity lurks (in any language; function calls are also a kind of goto).
With or without side effects, a function call says "go to this other place and do this other thing and bring back the result". That's a kind of goto – a structured kind that's always paired with a return. This is higher level than the old-fashioned GOTO but that doesn't make it complexity-free. It's still possible to create spaghetti with it.
Maybe that sounds pedantic, but I don't think it is, because interaction complexity needs to be minimized just like other kinds of complexity do. When you call a function you are implicitly drawing a line between the caller and the callee. Imagine a picture of your program with all those lines drawn at once. That picture ought to have some order to it.
Side effects are a different kind of complexity. If pure function calls are like going camping and leaving nothing behind, then function calls with side effects are like going camping and burning a fire or littering or what have you.
Same here. Although I've found Haskell to be noticeably shorter than Scala. But there are trade-offs. Java reads sequentially, top-to-bottom, so when you are new to a piece of code, you trace through it in this linear fashion. And as Paul Graham says in On Lisp (p30), such code 'looks solid and blockish'. But it's approachable, if somewhat long and cluttered. On the other end of the scale is Haskell, which is anything but linear. And with a healthy dose of library-specific operators, it can be quite alien looking. Until you are accustomed to the syntactic patterns, it's pretty hard going. But after that point, it is considerably faster to grok the meaning of the program, as it is entirely clutter free. Clojure (and Lisps in general) is closer to Haskell in its non-linear nature, but without more syntactic help (eg infix operators), it never gets to the compactness of Haskell. And the indentation gets a bit heavier.
The increased LOC in Java is the price you pay for this linearity. But with program complexity and scale, this price can get to be pretty heavy. The same can be said for indiscriminate mutability and side-effects.