Re: [fonc] Component-based software
I think BGB is exactly correct, I think the major failings of such
libraries is that they fail to address problems about how shared resources
are handled and how arbitrary component libraries interact.
I would argue that the solution is to write a language that can convey that
information, as well as support factoring out resource management
responsibilities (like memory management and collection library choice) and
design assumptions (reference/object management policies), from small well
defined pieces of code (components), each component can then focus on one
responsibility, and let the things it depends on handle their
responsibilities within the defined constraints of the dependency (This
would also allow for a marketplace of code design).
This would be different than now because all the typical assumptions
(including language semantics) of a C library or a JVM library are now part
of the dependency system, and hence can be manipulated (i.e. if a library
needs a form of garbage collector, it just marks it a dependency, that
garbage collector can now be shared between components (but it doesn't have
to be)) (for a language semantic dependency consider objects, a component
may use the object system, but how do we abstract away the design of the
object system? We make the semantics a dependency, and then any object
system which provides those semantics (or has an adapter component which
translates between the two) can be used to fulfill that dependency) .
Building such a system would require more complex dependency analysis than
we do today, the language would also need to be homoiconic, or at least,
provide such features, and it would need to involve some rather interesting
context manipulation constructs (how do you write code {for use by/using} a
component that depends on completely different semantics and dependencies
than the current section of code?).
This is part of what I am currently working on for my master's thesis.
On Wed, Jul 18, 2012 at 3:08 PM, BGB cr88...@gmail.com wrote:
On 7/18/2012 4:04 PM, Miles Fidelman wrote:
Tomasz Rola wrote:
On Sun, 15 Jul 2012, Ivan Zhao wrote:
By Victorian plumbing, I meant the standardization of the plumbing and
hardware components at the end of the 19th century. It greatly liberated
plumbers from fixing each broken toilet from scratch, to simply picking
and
assembling off the shelf pieces.
There was (or even still is) a proposition to make software from
prefabricated components. Not much different to another proposition about
using prefabricated libraries/dlls etc. Anyway, seems like there is a lot
of component schools nowadays, and I guess they are unable to work with
each other - unless you use a lot of chewing gum and duct tape.
It's really funny, isn't it - how badly software components have
failed. The world is littered with component libraries of various sorts,
that are unmitigated disasters.
Except. when it actually works. Consider:
- all the various c libraries
- all the various java libraries
- all the various SDKs floating around
- cpan (perl)
Whenever we use an include statement, or run a make, we're really
assembling from huge libraries of components. But we don't quite think of
it that way for some reason.
yeah.
a few factors I think:
how much is built on top of the language;
how much is mandatory when interacting with the system (basically, in
what ways does it impose itself on the way the program is structured or
works, what sorts of special treatment does it need when being used, ...).
libraries which tend to be more successful are those which operate at a
level much closer to that of the base language, and which avoid placing too
many special requirements on the code using the library (must always use
memory-allocator X, object system Y, must register global roots with the
GC, ...).
say, a person building a component library for C is like:
ok, I will build a GC and some OO facilities;
now I am going to build some generic containers on top of said OO
library;
now I am going to write a special preprocessor to make it easier to use;
...
while ignoring issues like:
what if the programmer still wants or needs to use something like malloc
or mmap?;
how casual may the programmer be regarding the treatment of object
references?;
what if the programmer wants to use the containers without using the OO
facilities?;
what if for some reason the programmer wants to write code which does not
use the preprocessor, and call into code which does?;
...
potentially, the library can build a large collection of components, but
they don't play well with others (say, due to large amounts of internal
dependencies and assumptions in the design). this means that, potentially,
interfacing a codebase built on the library with another codebase may
require an inordinate amount of additional pain.
in my case I have tried to, where possible, avoid these sorts of issues in
my own
Re: [fonc] Deployment by virus
John Nilsson j...@milsson.nu writes:
On Thu, Jul 19, 2012 at 3:55 AM, Pascal J. Bourguignon
p...@informatimago.com wrote:
Joke apart, people are still resiting a lot to stochastic software.
One problem with random spreading of updates is that its random.
Random as in where it's applied or random in what's applied?
Both.
The problem is that it would give more work to system administrators
everywhere trying to explain to users why this software on this computer
has this bug, while this same software on this other computer hasn't.
It would also complicate bug reporting.
I was thinking that the viral part was a means to counter the seeming
randomness in an otherwise chaotic system. Similar in spirit in how
gardening creates some amount of order and predictability, a gardener
who can apply DNA tweaks as well as pruning.
As I understand it CFEngine does something like this wile limited to
simple configuration.
BR,
John
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Deployment by virus
More work relative to an approach where full specification and controll is feasible. I was thinking that in a not to distant future we'll want to build systems of such complexity that we need to let go of such dreams. It could be enough with one system. How do you evolve a system that has emerged from som initial condition directed by user input. Even with only one instance of it running you might have no way to recreate it so you must patch it, and given sufficient complexity you might have no way to know how a binary diff should be created. BR, John Den 19 jul 2012 13:54 skrev Pascal J. Bourguignon p...@informatimago.com: ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Deployment by virus
On Thu, Jul 19, 2012 at 02:28:18PM +0200, John Nilsson wrote: More work relative to an approach where full specification and controll is feasible. I was thinking that in a not to distant future we'll want to build systems of such complexity that we need to let go of such dreams. It could be enough with one system. How do you evolve a system that has emerged from som initial condition directed by user input. Even with only one instance of it running you might have no way to recreate it so you must patch it, and given sufficient complexity you might have no way to know how a binary diff should be created. It seems a great idea for evolutionary computation (GA/GP) but an awful idea for human engineering. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Deployment by virus
Eugen Leitl eu...@leitl.org writes:
On Thu, Jul 19, 2012 at 02:28:18PM +0200, John Nilsson wrote:
More work relative to an approach where full specification and controll is
feasible. I was thinking that in a not to distant future we'll want to
build systems of such complexity that we need to let go of such dreams.
It could be enough with one system. How do you evolve a system that has
emerged from som initial condition directed by user input. Even with only
one instance of it running you might have no way to recreate it so you must
patch it, and given sufficient complexity you might have no way to know how
a binary diff should be created.
It seems a great idea for evolutionary computation (GA/GP) but an
awful idea for human engineering.
Perhaps not. The idea would be that we would design our systems not
with hard boundaries and functionalities, but like living organisms are
designed. Notice that all the program of an organism is contained in
each of its cells. Cells behave differently depending on the
environment (organ, tissue) there are in. If you migrate a cell to a
different organ, it may start behaving differently. It can because it
has all the programs.
On the other hand, if you move a library to another place, it will just
break because it doesn't have the programs needed in that other place.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Deployment by virus
On 7/19/2012 7:32 AM, Eugen Leitl wrote: On Thu, Jul 19, 2012 at 02:28:18PM +0200, John Nilsson wrote: More work relative to an approach where full specification and controll is feasible. I was thinking that in a not to distant future we'll want to build systems of such complexity that we need to let go of such dreams. It could be enough with one system. How do you evolve a system that has emerged from som initial condition directed by user input. Even with only one instance of it running you might have no way to recreate it so you must patch it, and given sufficient complexity you might have no way to know how a binary diff should be created. It seems a great idea for evolutionary computation (GA/GP) but an awful idea for human engineering. it comes back to the idea of total complexity vs perceived or external complexity: as the system gets larger and more complex, the level of abstraction tends to increase. the person can still design and engineer a system, just typically working at a higher level of abstraction (and a fair amount of conceptual layering). so, yeah, traditional engineering and development practices will probably continue on well into the foreseeable future. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alan Kay in the news [german]
On Wed, Jul 18, 2012 at 2:01 PM, Alan Kay alan.n...@yahoo.com wrote: Hi Long, I can keep my elbows into my body typing on a laptop. My problem is that I can't reach out further for more than a few seconds without a fair amount of pain from all the ligament tendon and rotator cuff damage along that axis. If I get that close to the keys on an organ I still have trouble reaching the other keyboards and my feet are too far forward to play the pedals. Similar geometry with the piano, plus the reaches on the much wider keyboard are too far on the right side. Also at my age there are some lower back problems from trying to lean in at a low angle -- this doesn't work. But, after a few months I realized I could go back to guitar playing (which I did a lot 50 years ago) because you can play guitar with your right elbow in. After a few years of getting some jazz technique back and playing in some groups in New England in the summers, I missed the polyphonic classical music and wound up starting to learn classical guitar a little over a year ago. This has proved to be quite a challenge -- much more difficult than I imagined it would be -- and there was much less transfer from jazz/steel string technique that I would have thought. It not only feels very different physically, but also mentally, and has many extra dimensions of nuance and color that is both its charm, and also makes it quite a separate learning experience. Cheers, Alan Hey Alan, That's awesome that you are learning classical guitar. Are you using Aaron Shearer's texts to teach yourself? One trick I have learned is to not support my left hand at all when playing. In this way, the dexterity in my fingers increases and when I press down on the fretboard I am using only my finger muscles. I've had bilateral ulnar nerve transposition, and for a whole year in college could not type at all due to muscle atrophy from nerve compression! I wrote all my computer assignments on paper, and paid a personal secretary to type them in for me. I thought about everything the program would do before I wrote anything on paper, since I hated crossing out code and writing editorial arrows. Dragon Naturally Speaking is really quite good, although not good for programming in most languages. I've found Microsoft Visual Basic is somewhat possible to speak. I also experimented with various exotic keyboards, like the DataHand keyboard in the movie The Fifth Element. It was easily my favorite keyboard, but the main problem and reason I don't use it after getting better is that going to somebody else's desk and typing becomes a lesson in learning how to type again. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alan Kay in the news [german]
Hi John Sorry to hear about your nerve problems. I got a variety of books to get started -- including Anton Shearer's and Christopher Parkening's. Then I started corresponding with a fabulous and wonderfully expressive player in the NetherlandsI found on YouTube-- Enno Voorhorst Check out: http://www.youtube.com/watch?v=viVl-G4lFQ4 I like his approach very much -- part of it is that he started out as a violin player, and still does a fair amount of playing in string quartets, etc. You can hear that his approach to tremolo playing is that of a solo timbre rather than an effect. And some of the violin ideas of little to no support for the left hand do work well on classical guitar.But many of the barres (especially the hinged ones) do require some thumb support. What has been interesting about this process is to find out how much of the basic classical guitar technique is quite different from steel string jazz chops -- it's taken a while to unlearn some spinal reflexes that were developed a lifetime ago. Cheers, Alan From: John Zabroski johnzabro...@gmail.com To: Alan Kay alan.n...@yahoo.com; Fundamentals of New Computing fonc@vpri.org Sent: Thursday, July 19, 2012 5:40 PM Subject: Re: [fonc] Alan Kay in the news [german] On Wed, Jul 18, 2012 at 2:01 PM, Alan Kay alan.n...@yahoo.com wrote: Hi Long, I can keep my elbows into my body typing on a laptop. My problem is that I can't reach out further for more than a few seconds without a fair amount of pain from all the ligament tendon and rotator cuff damage along that axis. If I get that close to the keys on an organ I still have trouble reaching the other keyboards and my feet are too far forward to play the pedals. Similar geometry with the piano, plus the reaches on the much wider keyboard are too far on the right side. Also at my age there are some lower back problems from trying to lean in at a low angle -- this doesn't work. But, after a few months I realized I could go back to guitar playing (which I did a lot 50 years ago) because you can play guitar with your right elbow in. After a few years of getting some jazz technique back and playing in some groups in New England in the summers, I missed the polyphonic classical music and wound up starting to learn classical guitar a little over a year ago. This has proved to be quite a challenge -- much more difficult than I imagined it would be -- and there was much less transfer from jazz/steel string technique that I would have thought. It not only feels very different physically, but also mentally, and has many extra dimensions of nuance and color that is both its charm, and also makes it quite a separate learning experience. Cheers, Alan Hey Alan, That's awesome that you are learning classical guitar. Are you using Aaron Shearer's texts to teach yourself? One trick I have learned is to not support my left hand at all when playing. In this way, the dexterity in my fingers increases and when I press down on the fretboard I am using only my finger muscles. I've had bilateral ulnar nerve transposition, and for a whole year in college could not type at all due to muscle atrophy from nerve compression! I wrote all my computer assignments on paper, and paid a personal secretary to type them in for me. I thought about everything the program would do before I wrote anything on paper, since I hated crossing out code and writing editorial arrows. Dragon Naturally Speaking is really quite good, although not good for programming in most languages. I've found Microsoft Visual Basic is somewhat possible to speak. I also experimented with various exotic keyboards, like the DataHand keyboard in the movie The Fifth Element. It was easily my favorite keyboard, but the main problem and reason I don't use it after getting better is that going to somebody else's desk and typing becomes a lesson in learning how to type again. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
