It's not in writing 40 lines that something like "blub" hurts, it's in reading it afterward. As long as you don't end up in Perl one liners, shorter code will tend to better highlight the relevant content (e.g., there are four keys that perform one of four things).

For me, I have found that a more concise language is easier to think in and write in. I recently worked on an application that was implemented both on the web using mostly javascript and as a desktop application in VB.Net.

One of the more complicated features I waited to implement in the web version, just because I found it rather difficult to think of the problem in VB. The javascript code was just easier to write and think in, and once implemented I could translate it to VB.

Although I do not know if there is a limit to the benefits of moving to a smaller language. Also, this is just my personal experience and I do not know how much it generalizes to other people.

I wonder. If it were only limited to the ratio of time required to type it, maybe.

But I think during the writing of the program, you type the code, review the code, look at some other code, come back to that code, so you are writing/editing/modifying a particular piece of code multiple times.

I have a superstition that there is an element of polynomial effect on the size of the resulting program on the time to get it working or to parse code written by another person.