Refactoring in Tunes

[btanksley@hifn.com]

> From: Francois-Rene Rideau [mailto:fare@tunes.org]
> Subject: Re: Refactoring in Tunes

> I'd like to intervene in this thread about "Refactoring".
> As I understand it, refactoring is just a very particular case of
> metaprogramming, with lots of hype around, and meant to be 
> done manually only
> (because hypists follow the C++/Java/OO buzzwagon, where automated
> metaprogramming is rendered practically impossible in the presence
> of ugly misdesigned dominating languages). I don't mean that works on

No!  Emphatically and strongly NO.  Refactoring is indeed a subcase of
metaprogramming, but that says nothing about whether we should discuss it;
metaprogramming itself is a special case of computer science, and we
certainly discuss THAT.

Refactoring is a useful discussion as compared to metaprogramming, because
refactoring is about teaching people how to control their source code.
Automatic refactoring will only replace manual refactoring when computers
become as intelligent as humans.  Until then, all we'll have is _assisted_
refactorings.

> For any "refactoring" trick, you can find a decomposition of it into
> nice and general metaprogramming rules. Massimo already talked about
> lambda-abstraction and beta-expansion: concepts indeed difficult to
> express if at all in languages such as C, C++, Java, but trivial in
> functional programming languages such as LISP, FORTH, ML, 
> Haskell, etc.

...and irrelevant to computer science in general.  Lambda calculus has been
a huge drag on computer science (I assert), and the sooner we get rid of it,
the better.  I posted a link to the 'Joy' page a bit earlier; take a look
for a study of computation theory completely without lambda calculus.

> The fact that such operations be done before runtime leads us 
> in the realms
> of "partial-" or staged evaluation. Combining them leads us 
> to substitution,
> and finding the right substitution is unification (which can 
> get pretty
> difficult for higher-order terms).

And none of this is relevant without lambda calculus.  Pretty neat, huh?

> If you allow for more meta-level
> functionality (who talked about differentiating functions to compute
> normal vectors for 3D shapes?), then you can "refactor" the 
> code in even simpler ways; etc.

Could you clarify this?  I don't really see how differentiating a function
could result in a refactoring, much less a simpler one.

> About "refactoring", I'd like to stress out that what's 
> simple according
> to one's point of view isn't as simple according to another 
> one's. And the
> "one's" in question might be people trying to understand the program,
> people trying to prove it correct, people trying to execute 
> it efficiently
> on a given hardware, etc, etc.

Absolutely.  for example, consider a clear, parsable language definition
written in yacc.  To prove certain things about it you want to rewrite it
into one of the "normal forms", which in turn is entirely useless for real
parsing.

> In as much as "refactorers" 
> keep just one
> version of the code at a time, they are not being helpful in 
> having people
> with divergent point of views agree on a same program; for 
> that, you have
> to be able to manipulate not just the code, but the 
> meta-code, too, so as
> to be able to _consistently_ go back and forth between 
> different versions
> of your program. Etc, etc.

Interesting.  I think I see your point here -- each person can write their
own refactoring metacode which provides their facorite view of the program,
and the programming tools update every person's metacode to stay up to stay
up with all changes to the program itself.  So, for example, I have a
class-and-procedures based view, and I use it to modify the code; Brian logs
in tomorrow, and sees my changes in his types-and-arrows view.

> [ "Faré" | VN: Уng-Vû Bân | Join the TUNES project!   

-Billy