Hi David,
The often used quote by Einstein is:
"Make everything as simple as possible, but not simpler"
People interpret that in a lot of interesting ways, but it does point to a
'minimum simplicity'.
In software, you might build a system with 100,000 lines of code. Someone else
might come along and build it with 20,000 lines of code, but there is some
underlying complexity tied to the functionality that dictates that it could
never be any less the X lines of code. The system encapsulates a significant
amount of information, and stealing from Shannon slightly, it cannot be
represented in any less bits.
If you let your imagination go wild, you can envision a system with twice as
much functionality. Now it may be that it requires less than 2X lines of code,
but it still has a minimum.
All modern systems we have today exist in silos. Many interact with each other,
but for the most part we are forced to deal with them individually. If we
wanted to get closer to what Zed was describing, we'd have to integrate them
with each other. Given that there are probably huge redundancies it wouldn't
end up being N*X lines of code, but given the amount of information we've
encoded it our various systems it would still be stunningly large.
I think Windows is up around 50M. There may be systems out there that are
larger. I certainly can imagine a system that might contain 500M lines of code.
It would be a pretty nice piece of software, but I honestly doubt that we could
build such a thing (as a single thing*) given our current technologies.
*One could take the Internet as a whole with its 2.3 billion users and untold
number of machines as a 'single system'. I might accept that, but if it were so
I'd have to say that its overall quality is very low in the sense that as one
big piece it is a pretty messy piece. Parts of it work well, parts of it don't.
If things are expanding then they have to get more complex, they encompass
more. Our usage of computers is significant, but it isn't hard to imagine them
doing more for us. To get there, we have to expand our usage and thus be able
to handle more complexity. Big integrated systems that make life better by
keeping it more organized are probably things we absolutely need right now. Our
modern societies are outrageously complex and many suspect unsustainable. The
promise of computers has been that we could embed our intellect into them so
that we could use them as tools to tame that problem, but to get there we need
systems that dwarf our current ones.
Paul.
>________________________________
> From: David Leibs <david.le...@oracle.com>
>To: Fundamentals of New Computing <fonc@vpri.org>
>Sent: Friday, June 15, 2012 3:17:19 PM
>Subject: Re: [fonc] The Web Will Die When OOP Dies
>
>
>I have kinda lost track of this thread so forgive me if I wander off in a
>perpendicular direction.
>
>
>I believe that things do not have to continually get more and more complex.
>The way out for me is to go back to the beginning and start over (which is
>what this mailing list is all about).
>I constantly go back to the beginnings in math and/or physics and try to
>re-understand from first principles. Of course every time I do this I get
>less and less further along the material continuum because the beginnings are
>so darn interesting.
>
>
>Let me give an example from arithmetic which I learned from Ken Iverson's
>writings years ago.
>
>
>As children we spend a lot of time practicing adding up numbers. Humans are
>very bad at this if you measure making a silly error as bad. Take for example:
>
>
> 365
>+ 366
>------
>
>
>this requires you to add 5 & 6, write down 1 and carry 1 to the next column
>then add 6, 6, and that carried 1 and write down 2 and carry a 1 to the next
>column
>finally add 3, 3 and the carried 1 and write down 7
>this gives you 721, oops, the wrong answer. In step 2 I made a totally
>dyslexic mistake and should have written down a 3.
>
>
>Ken proposed learning to see things a bit differently and remember the digits
>are a vector times another vector of powers.
>Ken would have you see this as a two step problem with the digits spread out.
>
>
> 3 6 5
>+ 3 6 6
>------------
>
>
>Then you just add the digits. Don't think about the carries.
>
>
> 3 6 5
>+ 3 6 6
>------------
> 6 12 11
>
>
>
>
>Now we normalize the by dealing with the carry part moving from right to left
>in fine APL style. You can almost see the implied loop using residue and
>n-residue.
>6 12 11
>6 13 0
>7 3 0
>
>
>Ken believed that this two stage technique was much easier for people to get
>right. I adopted it for when I do addition by had and it works very well for
>me. What would it be like if we changed the education establishment and used
>this technique? One could argue that this sort of hand adding of columns of
>numbers is also dated. Let's don't go there I am just using this as an example
>of going back and looking at a beginning that is hard to see because it is
>"just too darn fundamental".
>
>
>We need to reduce complexity at all levels and that includes the culture we
>swim in.
>
>
>cheers,
>-David Leibs
>
>
>On Jun 15, 2012, at 10:58 AM, BGB wrote:
>
>On 6/15/2012 12:27 PM, Paul Homer wrote:
>>I wouldn't describe complexity as a problem, but rather an attribute of the
>>universe we exist in, effecting everything from how we organize our societies
>>to how the various solar systems interact with each other.
>>>
>>>
>>>Each time you conquer the current complexity, your approach adds to it.
>>>Eventually all that conquering needs to be conquered itself ...
>>>
>>yep.
>>
>>the world of software is layers upon layers of stuff.
>>one thing is made, and made easier, at the cost of adding a fair
amount of complexity somewhere else.
>>
>>this is generally considered a good tradeoff, because the reduction
of complexity in things that are seen is perceptually more important
than the increase in internal complexity in the things not seen.
>>
>>although it may be possible to reduce complexity, say by finding
ways to do the same things with less total complexity, this will not
actually change the underlying issue (or in other cases may come
with costs worse than internal complexity, such as poor performance
or drastically higher memory use, ...).
>>
>>
>>
>>
>>>Paul.
>>>
>>>
>>>
>>>
>>>>________________________________
>>>> From: Loup Vaillant <l...@loup-vaillant.fr>
>>>>To: fonc@vpri.org
>>>>Sent: Friday, June 15, 2012 1:54:04 PM
>>>>Subject: Re: [fonc] The Web Will Die When OOP Dies
>>>>
>>>>Paul Homer wrote:
>>>>> It is far more than obvious that OO opened the door
to allow massive
>>>>> systems. Theoretically they were possible before,
but it gave us a way
>>>>> to manage the complexity of these beasts. Still,
like all technologies,
>>>>> it comes with a built-in 'threshold' that imposes a
limit on what we can
>>>>> build. If we are too exceed that, then I think we
are in the hunt for
>>>>> the next philosophy and as Zed points out the
ramification of finding it
>>>>> will cause yet another technological wave to
overtake the last one.
>>>>
>>>>I find that a bit depressing: if each tool that tackle
complexity
>>>>better than the previous ones lead us to increase
complexity (just
>>>>because we can), we're kinda doomed.
>>>>
>>>>Can't we recognized complexity as a problem, instead of
an unavoidable
>>>>law of nature? Thank goodness we have STEPS project to
shed some light.
>>>>
>>>>Loup.
>>>>_______________________________________________
>>>>fonc mailing list
>>>>fonc@vpri.org
>>>>http://vpri.org/mailman/listinfo/fonc
>>>>
>>>>
>>>>
>>>
>>>
>>>_______________________________________________
fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
>>
_______________________________________________
>>fonc mailing list
>>fonc@vpri.org
>>http://vpri.org/mailman/listinfo/fonc
>>
>
>_______________________________________________
>fonc mailing list
>fonc@vpri.org
>http://vpri.org/mailman/listinfo/fonc
>
>
>_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
