On Mar 3, 2010, at 8:48 AM, Andrey Fedorov wrote: > 2010/3/3 Reuben Thomas <[email protected]> wrote: > 2010/3/3 Wesley Smith <[email protected]>: > > On Tue, Mar 2, 2010 at 1:18 PM, Andrey Fedorov <[email protected]> wrote: > >> John Zabroski wrote: > >>> > >>> the three stumbling blocks are size, complexity and trustworthiness > >> > >> How are these different? > >> A small program is a simple program by definition, assuming it's expressed > >> in an intuitively comprehensible way. > > > > I disagree that a small program is by definition a simple program. > > Indeed, and it may help to lay a simple concrete example alongside > Wesley's theoretical approach: think of the difference between, say, a > short recursive function to traverse a tree and apply a callback. It > can even look quite simple on the page, but the chances are that there > are hidden depths. (This is certainly my experience with writing such > functions). Contrast with a long application initialisation routine, > of what I call "narrative" code, which is simply a list of "do this, > do that": initialise the windowing system, start the event loop, > register an event handler, open the main window, initialise the > menus...The code is long, but there are no loops, and it's completely > trivial to read (though how one knows when one has done everything one > needs to is another matter!). > > I think I understand exactly what you mean, so let me try to restate in > rigorously: you want to include attributes of a given programmer in our > definition of "complexity". If we do this, and we consider the "complexity of > code" and "size of code" in the eyes of today's "average software engineer", > I concede that recursion is more complex than iteration (and "narrative > code"). This is simply because of today's fashions. Those aside, I haven't > seen any evidence that our minds prefer one metaphor over another. > > But I'm not interested in the noise added by today's fashions, so I'm trying > to intentionally define an algorithm's "complexity" separately from any > single person's set of experience, however. So assuming a programmer's native > proficient in both a recursive and iterative implementation of a piece of > code, the complexity, in her mind, will be roughly equal to the size of the > code (and exactly equal to the number of "pieces of thought" that code > represents).
Wesley and Reuben weren't saying anything about recursive vs. iterative implementations of the same algorithm. They were simply saying that 100 lines of recursive code (or worse, self-modifying code) is more complex than 100 lines of eg: an app-initialization routine. The number of "pieces of thought" (whatever that means) in the app-initialization routine might even be greater (since it may talk about files, windows systems, audio devices, etc.), yet you can read through it and get the gist almost as fast as you read through a novel. On the other hand, you may have to stare for hours to figure out what the recursive or self-modifying code does. I think that this has very little to do with today's fashions. I agree with you that small programs tend to be simple, and large programs tend to be complex. However, it shouldn't be difficult to see that "small" and "simple" are not necessarily equivalent, because of the counter-example of self-modifying code. This is, I think, all that Wesley and Reuben are saying on this point. Cheers, Josh > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
