mail got sent too fast...from "Watch What I Do": http://acypher.com/wwid/Chapters/05SmallStar.html
On Tue, Sep 10, 2013 at 11:36 AM, John Carlson <[email protected]> wrote: > 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 <[email protected]> wrote: > >> Check out "Smallstar" by Dan Halbert at Xerox PARC (written up in a PARC >> "bluebook") >> >> Cheers, >> >> Alan >> >> ------------------------------ >> *From:* John Carlson <[email protected]> >> *To:* Fundamentals of New Computing <[email protected]> >> *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" <[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 >> >> >> >> _______________________________________________ >> fonc mailing list >> [email protected] >> http://vpri.org/mailman/listinfo/fonc >> >> >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
