Hi Jochen, first of all, apologies for the delayed reply, I kinda got
knocked out by a nasty sinus infection right after I sent that e-mail. I
will admit to having copied and pasted in the past, and I probably will in
the future, but I'm not proud of it. I follow the Kent Beck rule on this,
which is basically, if you use the same code twice, it's no big deal, but if
you do it three times or more, you should refactor. I think I actually got
that from the Fowler book which as you say is very good.
In terms of a fractal dimension for code, here's an example:
for (var i = 0; i < foo; i++) {
console.log(bar);
for (var j = 0; j < bar; j++) {
console.log(baz);
console.log(quux);
}
}
So here you have a piece of code which contains another piece of code highly
similar to itself. The inner loop is like a version of the outer loop copied
and then slightly altered. You could imagine an infinite series of for
loops, each with a tiny tweak but otherwise highly similar to the containing
loop. Kind of like how the Koch curve contains an infinite number of nested
Koch curves, in a sense, but the difference is that the Koch curve is a
regular fractal, while this code, if it has fractal dimension, represents an
irregular fractal.
On Fri, Dec 10, 2010 at 11:14 PM, Jochen Fromm <[email protected]> wrote:
> Hi Giles,
>
> "Copy and Paste" is not something only unexperienced
> programmers do. Let us admit it, programmers do it all the time. It is a
> basic tool which is applied on many scales, from the highest level of the
> application
> to the lowest level of the individual function.
> Similar or duplicated code is not completely bad, it can even be faster
> than entirely unique
> code (for instance if you code a loop directly
> in Assembly language, the branching command can be eliminated). If
> repetitive code is good or bad depends on the judgement of the programmer -
> whether he wants performance or elegance.
>
> There is a Harvard Business Review article named "When Should a Process Be
> Art" which
> says that some creative processes naturally resist definition and
> standardization.
> Programming is such a creative process.
> The programmer adjusts the raw material until it matches the desired
> requiremewnts. It is an
> artistic process where the quality can not be measured by counting the
> lines of code, see
> http://4loc.wordpress.com/2010/11/22/progress-in-the-software-world/
>
> I doubt that refactoring can be automated.
> The book from Martin Fowler is useful:
> "Refactoring: Improving the Design of Existing Code"
> A list of patterns from this book can be found here
> http://www.refactoring.com/catalog/
>
> I am not sure if it makes sense to define a
> fractal dimension for text or code. The box counting method is a common
> method to
> determine the fractal dimension of images
> and graphics. We divide the space up into a grid of boxes of size x, and
> count the number of boxes of that scale that would contain a part of the
> attractor.
>
> If we divide the code into lines, and count the number of lines which
> repeat themselves, we would get
> a number between 0% and 100% (only repetition: 100%, no repetition: 0%).
> This is not a fractal dimension. And if we are honest, we must consider the
> whole stack, which begins on the deepest level of machine code. Ruby for
> example is written in C, and C in Assembly language. Many programs which
> look elegant just hide the messy part under the hood.
> They are based on large frameworks which contain all the messy and ugly
> code.
>
> -J.
>
>
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at cafe at St. John's College
> lectures, archives, unsubscribe, maps at http://www.friam.org
>
--
Giles Bowkett
http://gilesbowkett.com
============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at http://www.friam.org
