The trick here is to make the zippers at the meta or schema level. John On Sep 9, 2013 6:03 PM, "John Carlson" <[email protected]> wrote:
> Also, you could have an input zipper, a flippable conversion area, an > output zipper, and a history of conversion stack. > On Sep 9, 2013 5:11 PM, "David Barbour" <[email protected]> wrote: > >> I like Paul's idea here - form a "pit of success" even for people who >> tend to copy-paste. >> >> I'm very interested in unifying PL with HCI/UI such that actions like >> copy-paste actually have formal meaning. If you copy a time-varying field >> from a UI form, maybe you can paste it as a signal into a software agent. >> Similarly with buttons becoming capabilities. (Really, if we can use a >> form, it should be easy to program something to use it for us. And vice >> versa.) All UI actions can be 'acts of programming', if we find the right >> way to formalize it. I think the trick, then, is to turn the UI into a good >> PL. >> >> To make copy-and-paste code more robust, what can we do? >> >> Can we make our code more adaptive? Able to introspect its environment? >> >> Can we reduce the number of environmental dependencies? Control namespace >> entanglement? Could we make it easier to grab all the dependencies for code >> when we copy it? >> >> Can we make it more provable? >> >> And conversely, can we provide IDEs that can help the "kids" understand >> the code they take - visualize and graph its behavior, see how it >> integrates with its environment, etc? I think there's a lot we can do. Most >> of my thoughts center on language design and IDE design, but there may also >> be social avenues - perhaps wiki-based IDEs, or Gist-like repositories that >> also make it easy to interactively explore and understand code before using >> it. >> >> >> On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <[email protected]> wrote: >> >>> >>> These days, the "kids" do a quick google, then just copy&paste the >>> results into the code base, mostly unaware of what the underlying 'magic' >>> instructions actually do. So example code is possibly a bad thing? >>> >>> But even if that's true, we've let the genie out of the bottle and he >>> is't going back in. To fix the quality of software, for example, we can't >>> just ban all cut&paste-able web pages. >>> >>> The alternate route out of the problem is to exploit these types of >>> human deficiencies. If some programmers just want to cut&paste, then >>> perhaps all we can do is too just make sure that what they are using is >>> high enough quality. If someday they want more depth, then it should be >>> available in easily digestible forms, even if few will ever travel that >>> route. >>> >>> If most people really don't want to think deeply about about their >>> problems, then I think that the best we can do is ensure that their hasty >>> decisions are based on as accurate knowledge as possible. It's far better >>> than them just flipping a coin. In a sense it moves up our decision making >>> to a higher level of abstraction. Some people lose the 'why' of the >>> decision, but their underlying choice ultimately is superior, and the 'why' >>> can still be found by doing digging into the data. In a way, isn't that >>> what we've already done with micro-code, chips and assembler? Or machinery? >>> Gradually we move up towards broader problems... >>> >>>> >>>> >> _______________________________________________ >> fonc mailing list >> [email protected] >> http://vpri.org/mailman/listinfo/fonc >> >>
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
