On Sat, Jul 30, 2011 at 12:44 AM, BGB <[email protected]> wrote: > it is a generalized issue of API designs, or more correctly, > the common lack of good external APIs. >
Ah. I suppose, if someone manufactured a gun that shot both ways and a lot of people hurt themselves or their allies, you would call the problem "a generalized issue of aim and awareness, or more correctly, the common lack of careful aim by the users". Because blaming the tool would be ridiculous. I think the problem is: *too much power, with too little perspective. *An excess of power allows developers to ignore integration and composition concerns as they build their abstractions - i.e. because they can hide any abstraction inside a Turing-powerful calculation. The lack of perspective means they don't even know what integration and composition concerns they should be considering. That is *why* we have 'a common lack of good external APIs'. Asking people to design better is not a reasonable or realistic answer. > both heterogeneous address spaces, closures, etc..., work fine with a stack > model. > under what basis do you think they are problematic?... > Closures created in stacks only pass easily in one direction - i.e. you cannot easily 'return' them. Concurrency - stacks and interrupts don't mix in a very predictable way, and one cannot predict how long it will be before an asynchronous event is handled. Regarding heterogeneous address spaces: can you actually provide an example of a single stack crossing multiple address spaces that doesn't have a lot of 'complications' involved with references and such? or are you assuming that using something other than a stack machine abstraction somehow qualifies as a success for 'stack machine'? We've found adequate ways to hack around the stack machine abstraction. But the need to work around the too-simple abstraction, BGB, is the very nature of 'simplistic'. It is preferable that we work with our abstractions, not around them.
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
