Refactoring in Tunes
Sun, 09 Jan 2000 05:42:38 +0100
> > From: Laurent Martelli [mailto:email@example.com]
> > Subject: Re: Refactoring in Tunes
> > >>>>> "bill" == btanksley <firstname.lastname@example.org> writes:
> > bill> you're asking for. "Refactoring" is generally used to
> > bill> indicate the process of changing the way code put together in
> > bill> order to produce a better fit to a better design. In other
> > bill> Refactoring in this sense cannot be helped by a runtime
> > bill> system ...
Why not, Bill? You cite meta-programs which does exactly this:
> > bill> ... and Smalltalk works well because there are automated tools
> > bill> to performs some of the most common refactorings.
> > think that refactoring does not only apply to OO languages. I see it
> > as finding patterns which are used more than once.
> [snipped: example of finding redundant patterns, making them into a
> function, and calling the function from both places]
> No, that's function factoring, not Refactoring. My "Refactoring" book calls
> that "Extract Method". Refactoring also includes the inverse of that --
> "Inline Method". A good coder should know how to do both refactorings;
> sometimes you need to inline a method in order to get special behavior (or
> because you made a poor choice of factoring earlier and now you have to
> redivide your functions' functionality).
What is the novelty? In the context of lambda-calculus "Extract Method"
is lambda-abstraction and "Inline Method" is beta-reduction, but with
high-order functions and others machineries you can really catch arbitrary
patterns of symbols in a clear manner (IMHO better than in mainstream so-called
However is known that lambda-unification (are there substitutions which
make equal 2, or N, lambda-terms? Eventually, which are these substitutions?
See the simple example of Laurent Martelli) is semi-decideable(?) (at the best,
you could construct a procedure that terminates if these substitutions exist;
otherwise the procedure won't terminate).
For each reader not familiar with the subject and that doesn't understand:
I'm sorry, but with my limited english, it is difficult to explain these terms.
> > When you're dealing with OOL, you introduce new base classes, but it's
> > the same mechanism.
> The full art of refactoring is about being able to change the design of a
> program, not simply make it take up less space.
".. simply make it take up less space" is not futile: this save valuable
resources both for machines and human beings. For example, a program of
100 lines is much more understandable and manegeable than an *equivalent* program
of 10.000 lines (settle 2 programs are equivalent it is not a so simple matter;
for example, see the preceding definition of lambda-unification).
However, the theory of data compression is well developed.
> You accomplish that change in two steps:
> first, you apply source changes which preserve the old behavior
> but provide a more suitable class or function layout (these are
> what Fowler calls "refactorings");
> and second, you change the arrangement of these new classes to provide
> your new behavior.
Well, if I am not wrong, Brian spoke just to **automatize** this process:
discover arbitrary structures (in general sense, not only computable functions),
abstract it from the relative context and riutilize it freely (in automatic or
Good question. Only some suggestions: deduction, induction, neural nets,
genetic programming (with induction, see ADATE to synthetize(?) programs
from input/ouput pairs: http://www-ia.hiof.no/~rolando/adate_intro.html),
and so on. Arrows, Brian?.
P.S.: (?) means: is it correct in english?