5 ms·

I think I am willing to grant that "making the creation of programs easier" is probably closer to what language design should achieve than "make programs shorte

I think I am willing to grant that "making the creation of programs easier" is probably closer to what language design should achieve than "make programs shorter". However, the two are strongly correlated, so by selecting make programs shorter as the axiom you do end up using a less appealing objective, though not by much. However, Make Programs Shorter is vastly superior in another regard; it is explicitly measurable. When faced with a design choice, whether or not it Made Programming Easier might take lots of careful consideration on your part, and users of the language might have very strong opinions about whether Make Programming Easier was achieved. If you're counting characters and tokens, design changes instantly and verifiably achieve the objective or they don't. No fuss, no second guessing. Or, more crudely, selling your map to buy more decimals of latitude and longitude is not going to get you there.

david927 19y ago
I've worked a long time in a completely different vein, under the premise that language design should focus on making programs manageable. Making them shorter certainly promotes that in many respects, but destroys it in other respects. And the notion of "making the creation of programs easier" is to me, the completely wrong premise. That ends up being a wonderful derivative of making them manageable, but should never the goal. Programs are easy to create in BASIC, for example. They're just not scalable, which is another way of saying they lack manageability, which is something that only shows itself as the system's complexity expands. To paraphrase Alan Kay, you can build a doghouse with cardboard and plastic, but you couldn't build a house like that.