Exactly. Alejandro, as a peice of style advice: To really blow people's minds, then put a picture of System A next to a system C that looks *exactly* like system A. Then ask which system is simpler. THEN explain side effects.
On Wed, Mar 3, 2010 at 4:14 PM, Alejandro Garcia <[email protected]> wrote: > I think this is a common difference on the meaning of complexity. > Let me try to exemplify: > > Which one of the following systems is more complex? (look at the attached > image) > > [image: > ?ui=2&view=att&th=12725d882a505c0c&attid=0.1&disp=attd&realattid=ii_12725d882a505c0c&zw] > > > Most peoplo would say that System A is more complex than system B. > > Mostly because in order to describe the system A we just need to describe > the nodes (circles). > Whereas in Sytem B we need to describe circles (nodes) and arrows > (interactions) > > > But other people would say that System B is simplier. > How could this be? > > Well they are viewing it from the point of view that system B has less > degrees of freedom. > > Ie just by changing on node (the bottom one) we can change the whole > system. > > And here is where side effects come along if each one the nodes doesn't > have any side effects. > Ie the output for each node is always the same given the same input. > > Then system B is much "simplier" ie easier to know how it will behave given > an input. > > > So although I agree that a system with less words to describe it, tend to > *look* simplier > It is far more important that the nodes inside the system don't have side > effects. > In order for the whole system to be truly simplier. > > > > > > > > > > On Wed, Mar 3, 2010 at 2:46 PM, Josh Gargus <[email protected]> wrote: > >> >> 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 >> >> > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
<<SystemComplexity.JPG>>
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
