[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Opportunity costs in language design (was Re: What is a lightweight language)
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