Here's a short description, if you don't want to haul through the entire thesis:
On Mon, Sep 9, 2013 at 7:54 PM, Alan Kay <alan.n...@yahoo.com> wrote: > Check out "Smallstar" by Dan Halbert at Xerox PARC (written up in a PARC > "bluebook") > > Cheers, > > Alan > > ------------------------------ > *From:* John Carlson <yottz...@gmail.com> > *To:* Fundamentals of New Computing <fonc@vpri.org> > *Sent:* Monday, September 9, 2013 3:47 PM > *Subject:* Re: [fonc] Software Crisis (was Re: Final STEP progress report > abandoned?) > > One thing you can do is create a bunch of named widgets that work together > with copy and paste. As long as you can do type safety, and can > appropriately deal with variable explosion/collapsing. You'll probably > want to create very small functions, which can also be stored in widgets > (lambdas). Widgets will show up when their scope is entered, or you could > have an inspect mode. > 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 > > > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
