John N....Never mind. It was someone else and I tried to contact you at gmail. Oops On Apr 20, 2013 9:51 AM, "John Carlson" <yottz...@gmail.com> wrote:
> John Nilsson: Your message about an international group crashed my mail > client and attempts to contact you privately have failed. Could you try > resending the message? It has disappeared from my email. Thanks. John > On Apr 20, 2013 9:32 AM, "John Nilsson" <j...@milsson.nu> wrote: > >> One approach I've been thinking about is to invert the "information >> hiding" principle. >> >> The problem with information hiding is that the interface and properties >> exposed by a module is determined by the module: "I am a..." And some line >> is drawn between which properties are implementation details, and which are >> the contract. >> >> So I was thinking, what if the roles were swapped. What if modules could >> not declare a public contract but instead just had to conform to any type, >> interface or property that a client depending on it would care to declare >> as a requirement. In effect changing the module description into a >> collection of "You are a..." statements. Kind of similar to how a >> structural type allow any module conforming to the interface without the >> module having to implement a particular nominal type. >> >> For one, declaring a contract for a dependency is rather easy as it is >> based on local reasoning: "What do I do, what do I need?" as compared to >> "What do I do, what do others need?" >> >> Another benefit would be that there is no arbitrary reduction of the >> modules full capabilities. For example a Java List only implementing >> Iterable couldn't be used by clients requiring an ordered and finite >> sequence. >> >> I would expect this to encourage module writers to declare the smallest >> set of properties possible to depend on so that there would be more focus >> on "information shielding", what information to expose one self to, rather >> than what information not to expose to others. >> >> >> The problem with this approach is that the proof of conformance can't >> come from the module, and it's hardly productive to require each client to >> provide one. I guess in some sense this is partly solved by a mechanism >> such as type classes as done in Scala or Haskell. One problem with this >> scheme though is that they do this by means of a static dispatch, making it >> impossible to specialize implementations by runtime polymorphism. While I >> haven't played with it, I do believe that Clojure has solved it while >> preserving runtime polymorphism. >> >> >> BR, >> John >> >> >> On Thu, Apr 18, 2013 at 3:13 AM, David Barbour <dmbarb...@gmail.com>wrote: >> >>> Sounds like you want stone soup >>> programming<http://awelonblue.wordpress.com/2012/09/12/stone-soup-programming/>. >>> :D >>> >>> In retrospect, I've been disappointed with most techniques that involve >>> providing "information about module capabilities" to some external >>> "configurator" (e.g. linkers as constraint solvers). Developers are asked >>> to grok at least two very different programming models. Hand annotations or >>> hints become common practice because many properties cannot be inferred. >>> The resulting system isn't elegantly metacircular, i.e. you need that >>> 'configurator' in the loop and the metada with the inputs. >>> >>> An alternative I've been thinking about recently is to shift the link >>> logic to the modules themselves. Instead of being passive bearers of >>> information that some external linker glues together, the modules become >>> active agents in a link environment that collaboratively construct the >>> runtime behavior (which may afterwards be extracted). Developers would have >>> some freedom to abstract and separate problem-specific link logic >>> (including decision-making) rather than having a one-size-fits-all solution. >>> >>> Re: In my mind "powerful languages" thus means 98% requirements >>> >>> To me, "power" means something much more graduated: that I can get as >>> much power as I need, that I can do so late in development without >>> rewriting everything, that my language will grow with me and my projects. >>> >>> >>> On Wed, Apr 17, 2013 at 2:04 PM, John Nilsson <j...@milsson.nu> wrote: >>> >>>> Maybe not. If there is enough information about different modules' >>>> capabilities, suitability for solving various problems and requirements, >>>> such that the required "glue" can be generated or configured automatically >>>> at run time. Then what is left is the input to such a generator or >>>> configurator. At some level of abstraction the input should transition from >>>> being glue and better be described as design. >>>> Design could be seen as kind of a gray area if thought of mainly as >>>> picking what to glue together as it still involves a significant amount of >>>> gluing ;) >>>> But even design should be possible to formalize enough to minimize the >>>> amount of actual design decisions required to encode in the source and what >>>> decisions to leave to algorithms though. So what's left is to encode the >>>> requirements as input to the designer. >>>> In my mind "powerful languages" thus means 98% requirements, 2% design >>>> and 0% glue. >>>> BR >>>> John >>>> Den 17 apr 2013 05:04 skrev "Miles Fidelman" < >>>> mfidel...@meetinghouse.net>: >>>> >>>> So let's ask the obvious question, if we have powerful languages, >>>>> and/or powerful libraries, is not an application comprised primarily of >>>>> glue code that ties all the "piece parts" together in an >>>>> application-specific way? >>>>> >>>>> David Barbour wrote: >>>>> >>>>>> >>>>>> On Tue, Apr 16, 2013 at 2:25 PM, Steve Wart <st...@wart.ca <mailto: >>>>>> st...@wart.ca>> wrote: >>>>>> >>>>>> > On Sun, Apr 14, 2013 at 1:44 PM, Gath-Gealaich >>>>>> > In real systems, 90% of code (conservatively) is glue code. >>>>>> >>>>>> What is the origin of this claim? >>>>>> >>>>>> >>>>>> I claimed it from observation and experience. But I'm sure there are >>>>>> other people who have claimed it, too. Do you doubt its veracity? >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Apr 15, 2013 at 12:15 PM, David Barbour >>>>>> <dmbarb...@gmail.com <mailto:dmbarb...@gmail.com>> wrote: >>>>>> >>>>>> >>>>>> On Mon, Apr 15, 2013 at 11:57 AM, David Barbour >>>>>> <dmbarb...@gmail.com <mailto:dmbarb...@gmail.com>> wrote: >>>>>> >>>>>> >>>>>> On Mon, Apr 15, 2013 at 10:40 AM, Loup Vaillant-David >>>>>> <l...@loup-vaillant.fr <mailto:l...@loup-vaillant.fr>> wrote: >>>>>> >>>>>> On Sun, Apr 14, 2013 at 04:17:48PM -0700, David >>>>>> Barbour wrote: >>>>>> > On Sun, Apr 14, 2013 at 1:44 PM, Gath-Gealaich >>>>>> > In real systems, 90% of code (conservatively) is >>>>>> glue code. >>>>>> >>>>>> Does this *have* to be the case? Real systems also >>>>>> use C++ (or >>>>>> Java). Better languages may require less glue, (even >>>>>> if they require >>>>>> just as much core logic). >>>>>> >>>>>> >>>>>> Yes. >>>>>> >>>>>> The prevalence of glue code is a natural consequence of >>>>>> combinatorial effects. E.g. there are many ways to >>>>>> partition and summarize properties into data-structures. >>>>>> Unless we uniformly make the same decisions - and we won't >>>>>> (due to context-dependent variations in convenience or >>>>>> performance) - then we will eventually have many >>>>>> heterogeneous data models. Similarly can be said of event >>>>>> models. >>>>>> >>>>>> We can't avoid this problem. At best, we can delay it a >>>>>> little. >>>>>> >>>>>> >>>>>> I should clarify: a potential answer to the glue-code issue is >>>>>> to *infer* much more of it, i.e. auto-wiring, constraint >>>>>> models, searches. We could automatically build pipelines that >>>>>> convert one type to another, given smaller steps (though this >>>>>> does risk aggregate lossiness due to intermediate summaries or >>>>>> subtle incompatibilities). Machine-learning could be >>>>>> leveraged to find correspondences between structures, perhaps >>>>>> aiding humans. 90% or more of code will be glue-code, but it >>>>>> doesn't all need to be hand-written. I am certainly pursuing >>>>>> such techniques in my current language development. >>>>>> >>>>>> >>>>>> ______________________________**_________________ >>>>>> fonc mailing list >>>>>> fonc@vpri.org <mailto:fonc@vpri.org> >>>>>> >>>>>> http://vpri.org/mailman/**listinfo/fonc<http://vpri.org/mailman/listinfo/fonc> >>>>>> >>>>>> >>>>>> >>>>>> ______________________________**_________________ >>>>>> fonc mailing list >>>>>> fonc@vpri.org <mailto:fonc@vpri.org> >>>>>> >>>>>> http://vpri.org/mailman/**listinfo/fonc<http://vpri.org/mailman/listinfo/fonc> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ______________________________**_________________ >>>>>> fonc mailing list >>>>>> fonc@vpri.org >>>>>> http://vpri.org/mailman/**listinfo/fonc<http://vpri.org/mailman/listinfo/fonc> >>>>>> >>>>> >>>>> >>>>> -- >>>>> In theory, there is no difference between theory and practice. >>>>> In practice, there is. .... Yogi Berra >>>>> >>>>> ______________________________**_________________ >>>>> fonc mailing list >>>>> fonc@vpri.org >>>>> http://vpri.org/mailman/**listinfo/fonc<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
