Whoa, whoa, whoa. You're arguing with what you think I'm saying, not what I'm trying to say.
There are diminishing returns in focusing on extreme brevity. If I'm going to write a script, I just use Lua. (Other people like Python or Ruby. Sure.) Squeezing 10% more out of an already small program is well past the point of diminishing returns.
Depending on the problem, APL/J/K might make more sense. Or awk, make, SQL, etc. (My only experience with the APL family is playing around with J a bit, but they seem like awk in that they gain their conciseness in exchange for being focused on a certain problem domain. That's usually a good trade-off, though.)
I'd rather see more focus into techniques to make larger projects manageable, like module systems, type inference, declarative programming. As techniques, they're intrinsically harder to show off in this medium, though (except for small amounts of type inference, but its payoff increases with project size). That's all I'm saying.
I think I kind of agree with you, but kind of not.
Try looking at it from this perspective: There is really only one program. It is running on the internet and the disconnected nodes that only exchange data by sneakernet. It never stops running. Every bit of software that we think of as a separate program is really a part of this program. What are the techniques that make this program manageable (in the sense that it continues to perform useful functions and people continue to extend it)? I don't think they're module systems and type inference. I think REST, for example, plays a much bigger role. Full-text search of documentation plays a big role. NANOG plays a big role. Most of the things that really matter most in keeping it manageable are interpersonal and institutional rather than purely technical.
But this large program is made up largely of code, and nearly all of that code is made up of individual lines of code. Many of the technical things that help us most to keep it manageable are precisely the ones that allow us to write self-contained modifications more and more incrementally — a page, or a paragraph, or a line of code at a time.
So in that sense, things like type inference and programming higher on the declarativeness scale (e.g. DSLs, libraries) are important in managing the large project precisely because they can be compellingly demonstrated in "programs" of less than a page.
There are diminishing returns in focusing on extreme brevity. If I'm going to write a script, I just use Lua. (Other people like Python or Ruby. Sure.) Squeezing 10% more out of an already small program is well past the point of diminishing returns.
Depending on the problem, APL/J/K might make more sense. Or awk, make, SQL, etc. (My only experience with the APL family is playing around with J a bit, but they seem like awk in that they gain their conciseness in exchange for being focused on a certain problem domain. That's usually a good trade-off, though.)
I'd rather see more focus into techniques to make larger projects manageable, like module systems, type inference, declarative programming. As techniques, they're intrinsically harder to show off in this medium, though (except for small amounts of type inference, but its payoff increases with project size). That's all I'm saying.