Subject: Re: what we're up against
From: Todd D Millstein (todd@cs.washington.edu)
Date: Fri Mar 09 2001 - 11:33:58 PST
Thanks for the comments Matthai. I agree that there is a lot of
incremental work in the field. I guess my question is, is this more than
in other fields? Take a look at the proceedings from the next theory
conference. How many algorithms are incremental improvements off of old
algorithms, that make practically no difference? Look at the proceedings
from the next systems conference. How much new is there?
Maybe the problem is less the quality of our solutions than the quality of
our problems. In other words, we're essentially trying to solve the same
old problem we've always been trying to solve -- increasing program
expressiveness, while increasing programmer understanding, while
increasing program speed. There are clear conflicts among these goals,
and there is surely no general solution. As a result, everyone chips away
at the problem with their own small hammers, creating partial solutions
that are hard to validate.
People in our community seem to have better success and PR tackling other
problems that can use language solutions, security (Necula, Morrisett,
Mitchell) and XML stuff (Pierce, Wadler) to name two recent areas. Maybe
that's the right direction to go, rather than focusing on the same old
hard problem.
Todd
On Fri, 9 Mar 2001, Matthai Philipose wrote:
> I've heard similar stuff from other grad students in CS (though the vast
> majority are fine).
>
> I think the complaint has a tiny bit of truth in it. There is a lot of work in
> static analysis that is extremely incremental, and the results of which are
> used for optimizing programs, with very marginal gains. Another field with a
> similar "reputation" for the same reasons is computer architecture,
> microprocessor design in particular. The same is true of many kinds of
> analyses that make unsound conclusions via "dynamic analyses"... people have
> been doing it for a while, both informally and formally, but the insights
> added have been (in the overwhelming majority of cases) interesting heuristics
> at best.
>
> One way to tell if there is any truth in the matter is to make a list of
> programming systems advancements in the last 15 years that have/have some
> chance of making a impact discernible to other computer scientists and the
> rest of the world. Some examples off the top of my head:
> 1. Stuff exemplified by Java:
> -- well-defined semantics and static typing, including e.g. parametric
> polymorphism, of OO langs
> -- implementation (both static whole program analysis & dynamic
> compilation and JIT) that support large programs with decent performance
> -- reflection (interface to and implementation of Meta-level capabilities
> in a practical language)
> -- componentization and dynamic update
>
> 2. The ability to analyze Word (scalable analyses Henglein, Steensgaard, Das,
> etc):
> -- Non-standard typing/constraint-based analyses
> -- The use of these analyses for finding program errors a la Dan Weise's
> toolkits
>
> 3. Typed IRs, proof-carrying code, language-based security
> -- Precise definition and fast checking of important program properties
> -- Increased confidence in compiler correctness
>
> Some of the technical work underlying these things, was of course done long
> ago. But even in these cases, reducing the work to mainstream practice was I
> think a good achievement. I'm sure others can add more. But I think just this
> short list says that there is work that is both technically challenging and
> practically important going on.
>
> How to do something to get the word out is more difficult. I think stuff like
> Java helps tremendously. One thing I feel is that people don't have an idea of
> the breadth of applicabilty of program analysis/understanding. Most people
> thing that program analysis = program optimization = C program optimization =
> 5% speedup with a whole lot of effort, beyond the long-known optimizations.
> One way to counter this might be lessen the focus of compiler classes on
> program optimization, and use non-standard analyses for many different classes
> of clients (perhaps difficult to do in a 1 qtr class); stuff like program
> understanding and verification, database query compilation/optimization, OS
> security, etc comes to mind. Students should understand that any time they're
> dealing with stuff that looks like a programming language (i.e. some syntax
> and associated semantics), they can bring about a whole range of techniques
> from programming systems to abstract, build, optimize, verify and understand
> the stuff.
> Matthai
>
>
>
> _______________________________________________
> Cecil mailing list
> Cecil@cs.washington.edu
> http://majordomo.cs.washington.edu/mailman/listinfo/cecil
>
_______________________________________________
Cecil mailing list
Cecil@cs.washington.edu
http://majordomo.cs.washington.edu/mailman/listinfo/cecil
This archive was generated by hypermail 2b25 : Fri Mar 09 2001 - 11:34:04 PST