If the images of System A and System C are not showing the paths for side effects, then the images are lying to us.
No conclusions are valid when what we are shown is lying to us. We have this problem with government and finance and religion as well. Some even say that language was invented so we could better lie to each other. Such pessimists may be more accurate, but the optimists have more fun. Richard On Wed, Mar 3, 2010 at 1:25 PM, John Zabroski <[email protected]>wrote: > 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 >> >> > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > > -- Richard Karpinski, Nitpicker extraordinaire 148 Sequoia Circle, Santa Rosa, CA 95401 Home: 707-546-6760 http://nitpicker.pbwiki.com/
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
