Opportunity costs in language design (was Re: What is a lightweight language)

[Dan Sugalski <address@hidden>]

At 01:29 PM 12/11/2001 -0500, Matthias Felleisen wrote:
>Dan -- the question is whether there is a performance cost for programs in
>L minus feature F. This is called F's opportunity cost. (Okay, I do have
>some funny business degree.) Closures have a cost, continuations do, set!
>has a huge cost, etc.

Yup, I know about opportunity costs, though generally economics and 
business terms get swapped out of my brain. (Hopefully you haven't stirred 
up the bits involving accounting, as then I'll start having flashbacks to 
US primary school accounting and budgeting methods, payroll tax 
calculations, and  leave accruals--while a few hours with Diablo II usually 
puts those back down I lack the time today... :)

Opportunity costs are definitely important, and they're one of the things I 
actually worry about. In addition to more mundane things, like what tasks 
need doing to implement a language system and who has the skills to do 
them, there's the issue of the costs required for the design itself and how 
do they get paid? (If anyone can pay them at all)

One of the things I've found in designing Parrot is that the more of the 
design I can keep in mind at once the tighter and clearer it tends to be, 
and that leads to better execution speed. Unfortunately I'm often a 
Designer Of Very Little Brain, and the design needs to be broken into 
pieces small enough for me to cope with in one go. Even when the breaks are 
at conceptually clean spots (I try for that one--seems better than assuming 
I can manage it all at once, which is demonstrably not true) there's a cost 
paid in crossing the boundaries.

The downside to that is that, even if I manage a sweet design, I run the 
risk of having a sweet design that my successor can't manage the way I can. 
Which means that not only do I have to keep my own limits in mind (which is 
tough enough as it is) I have to keep the likely limits of other people in 
mind. Which adds cost to the design, as well as limiting the things that 
can be done. (The talk on REBOL at LL1 was a good example of this--a cool 
design's no good if only a handful of people can maintain it and none of 
them are the design's actual maintainer...)

The alternative to optimizing the design in the large is to go with a 
simple and tight design, but it's been my experience with those that the 
more conceptually simple and clean a design is, the slower it runs. And in 
those cases where it really runs fast, it's because things *aren't* clean 
somewhere. A clean design for the language might end up with The Compiler 
 From Hell, which ultimately makes the overall system less clean, since a 
bit more complex initial design would reduce the complexity of the back 
end. But, then again, you get to trade off the time and effort involved, as 
well as how many people pay which cost. (Is a design that's simple for a 
thousand users but a pain for three implementers better than one a bit 
tricky for that thousand but easy for the implementers?)

Bah. Engineering economics is a pain.

					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk