Re: [stack] function/object ambiguity + quotation alternative

Stevan Apter wrote:
> i don't want to spoil the party, but the fact is, i'm rarely in
> the position where i *want* to factor my code.

Yeah, well, you're a party-spoiler anyhow. :-)

>  my building blocks
> are not words or code-fragments, they're *functions*.

I do not understand this. "Word" is the Forth term for what other
languages call "functions". And most of what other languages call
"functions" are built of code-fragments.

Being able to put together and take apart functions/words is pretty
useful to programming. That's what the functional programming mavens
talk about with their "referential transparency"... and concatenative
languages are a bit better at that.

In brief, I don't understand why you'd "complain" about being _able_ to
refactor code more easily. I understand that you want to analyse
requirements, architect solutions, and detail-design perfectly the first
time... But since none of these are possible, it makes sense to write
code that's as mutable as possible.

> typically,
> a function evolves over time in response to demands from the
> environment by acquiring new arguments and/or producing results
> with new components.  the large-scale "topography" of the system
> is relatively stable.
> (come to think of it, this is a pretty 
> good metaphor for how systems grow in the real world.)

Good for you -- I'm not so lucky. For me there are two ways that a
system changes: either we fix problems in the code that implemented the
old requirements, or new requirements get added. In both cases the
architecture usually has to change at least a bit.

> if i have
> to dig into the functions and move snippets of code around into
> a new functional architecture, then my original design was pitched
> at the wrong "level."

It probably _was_ pitched at the wrong level. This happens all the time.

> the kind of refactoring i want to avoid
> (because it is the most painful kind) is *renaming*.  going from
> a set of several hundred functions a,b,c,... to a different set
> x,y,z,... .

I would classify renaming as the simplest kind of refactoring -- it can
usually be done with a simple search and replace, and then let the
compiler tell you if you missed anything. I wouldn't make a million name
changes at the same time, of course.

> code is committed to a function with a name when 
> a judgement is made that that functionality will endure for the
> lifetime of the system, and that changes will for the most part
> be extensions rather than revisions.

I expect that from code that's been in production use for 10 years.
Nothing younger.

-Wm