Hi,
But other people would say that System B is simplier.
How could this be?
Simple, there are diferent people.
Complexity is not measurable in the objects (nor figures),
because it emerges from information process.
if we are the kind of people that consider information
as an object, we are happy when we can encapsulate bits
of information and sum the units...
If we consider information (in-formation) as the process
of formation (of a model) we can start to consider
the limitations of The Method and consider
people and what they are doing when they try to
apply/instantiate our universal formulas and idea(l)s
on their targets (real and virtual worlds).
Why we want to measure complexity?
Why we still insist in reinforcement of computing utopy?
It make us try to understand before acting and that way
we are undertrained/naïve when we need to
act before understanding (before we can write a few
lines of text about what we are sensing).
There is not enough documentation today on how to
act in a sustainable system and a lot of effort
put in defining "future" systems from the outside.
There is no publications about the failures to advance
in Object Technology surpasing its limits from research
in languages design.
A small number of papers comes from chemistry experts
We, chemist was always working with real objects :) and
spending a lot of money changing real world... with current
objects environments we have a good support to extend our
techniques and do... informatics; if people related with informatics
are constrained to computation and explanation of algorithms
(constrained by math) instead of considering evidence of
sustainable systems software development.
Why it is important to surpass the limits of OO ?
It is evident if we consider the results of application
of The Method (all reduced to aProblem... encapsulated
e.g. Problem inherit from Object).
And also important because most people today can act
and most of the times can´t understand what they are
doing.
cheers,
Ale.
----- Original Message -----
From: Alejandro Garcia
To: Fundamentals of New Computing
Sent: Wednesday, March 03, 2010 6:14 PM
Subject: Re: [fonc] my two cents
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)
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
