Of course, in many ways, code size is not at all related to performance, and you might have discovered the smallest code size to model a problem, but that code size has a "bug" in that its performance is mostly a function of evaluation strategy (e.g., call-by-need performance model is not even compositional with respect to the lexicographic syntax!). If we separate meaning from specification, then this is no longer true, but we've increased complexity in the meta-interpreter. It is not "the muck of the human political process" we are trying to get out of. Instead, it is the Turing tarpit we are trying to step out of. Already, many of our systems are like fossils.
For example, traditional measures of software complexity, such as Cyclomatic Complexity, are basically metrics on parse trees. You simply count the appearance of a set of static productions, and you get the rough idea for the complexity of the software. But these metrics don't apply well to languages that have cores that make heavy use of partial application. Can you spot the bug in [1]. Another measure of complexity is the Dependency Structure Matrix (DSM), which measures dependencies. But these "dependencies" are based on linking and loading dependencies -- again, evaluation strategy -- and not problem domain abstraction issues. Actually, a DSM in a way does show problem domain abstraction issues, but it looks at them in terms of dependencies. Likewise, Cyclomatic Complexity does show problem domain abstraction issues, but it looks at them in terms of the degree to which you are not explicitly modeling the context in which messages pass to and from objects. Neither is the true thing: The real measure is simply how well your problem domain is abstracted, which is subjective and based on requirements in most problems and cannot be summarized with algebraic equations -- math is only ONE problem domain, and if we base our non-math systems entirely on functional decomposition then we will get spaghetti code as a result, since modeling non-math systems as math systems is a problem domain abstraction error. [1] http://www.cs.stir.ac.uk/~kjt/techreps/pdf/TR141.pdf FOR FUN: Where is the bug here? The authors claim they are measuring the *economic* expressiveness of languages. Show me at least one counter-example and explain why your counter-example shows this is a cargo cult science (there are many famous programming language papers about this, and you can feel free to just point to one of those). On Sun, Jul 11, 2010 at 10:20 PM, Max OrHai <[email protected]> wrote: > > > On Sat, Jul 10, 2010 at 3:22 AM, Steve Dekorte <[email protected]> wrote: > >> It seems as if each computing culture fails to establish a measure for >> it's own goals which leaves it with no means of critically analyzing it's >> assumptions resulting in the technical equivalent of religious dogma. From >> this perspective, new technical cultures are more like religious reform >> movements than new scientific theories which are measured by agreement with >> experiment. e.g. had the Smalltalk community said "if it can reduce the >> overall code >X without a performance cost >Y" it's better, perhaps >> prototypes would have been adopted long ago. > > > But code size versus performance is only one of many concurrent trade-offs, > when it comes to defining 'better'. Different individuals or groups can have > legitimately different needs. The more people are involved (and the more > invested they are), the more difficult the consensus-building process. > Measurements can help, but they are human artifacts as well, in their own > way. They don't necessarily pull you up out of the muck of the human > political process. > > I'd say the issue isn't with computing culture per se, but with culture in > general. There's a big gap between Science as the rational, disinterested > pursuit of knowledge and *any* engaged "technical culture", even of people > as enlightened (and as few) as Smalltalkers. > > -- Max > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
