I'd recommend looking into quartz composer on mac os x. On Sep 9, 2013 5:11 PM, "David Barbour" <dmbarb...@gmail.com> 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 <paul_ho...@yahoo.ca> 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 > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
