Ambiguity in English is often a problem. The Artist vs. Cowboy example shows that ambiguity is in some cases not a problem. I think it reasonable to argue that: when the context for two meanings of a word is obviously different, you can easily disambiguate using context. The same is true for types. But review my concern below: "when words have meanings that are * subtly* but significantly different". In many cases the difference is * subtle* but important. It is these cases where ambiguity can be troublesome.
Person.draw(object) <-- What do I mean by this? Am I drawing a picture? a gun? a curtain? Regarding conversations with coworkers: I think in the traditional KVM programming environment, the common view does seem important - e.g. for design discussions or over-the-shoulder debugging. At the moment, there is no easy way to use visual aides and demonstrations when communicating structure or meaning. In an AR or VR environment, I hypothesize this pressure would be alleviated a great deal, since the code could be shown to each participant in his or her own form and allow various meaning-by-demonstration/exploration forms of communication. I'm curious whether having different 'ways' of seeing the code might even help for debugging. Multiple views could also be juxtaposed if there are just a few people involved, enabling them to more quickly understand the other person's point of view. Best, Dave On Mon, Sep 23, 2013 at 6:21 PM, Sean McDirmid <[email protected]>wrote: > Ambiguity is common in English and it’s not a big problem: words have > many different definitions, but when read in context we can usually tell > what they mean. For “Cowboy.Draw(Gun)” and “Artist.Draw(Picture)”, we can > get a clue about what Draw means; ambiguity is natural! For my language, > choosing what Draw is meant drives type inference, so I can’t rely on types > driving name lookup. But really, the displayed annotation goes in the type > of the variables surrounding the Draw call (Cowboy, Gun) rather than the > Draw Call itself. **** > > ** ** > > Language is an important part of society. Though I can use translation to > talks to my Chinese speaking colleagues, that we all speak in English at > work and share the names for things is very important for collaboration > (and suffers when we don’t). For code, we might be taking about it even > when we are not reading it, so standardizing the universe of names is still > very important. **** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *David Barbour > *Sent:* Tuesday, September 24, 2013 9:11 AM > *To:* [email protected]; > [email protected]; Fundamentals of New Computing > > *Subject:* Re: Personal Programming Environment as Extension of Self**** > > ** ** > > Okay, so if I understand correctly you want everyone to see the same > thing, and just deal with the collisions when they occur. **** > > ** ** > > You also plan to mitigate this by using some visual indicators when "that > word doesn't mean what you think it means". This would require search > before rendering, but perhaps it could be a search of the user's personal > dictionary - i.e. ambiguity only within a learned set. I wonder if we could > use colors or icons to help disambiguate.**** > > ** ** > > A concern I have about this design is when words have meanings that are > subtly but significantly different. Selecting among these distinctions > takes extra labor compared to using different words or parameterizing the > distinctions. But perhaps this also could be mitigated, through automatic > refactoring of the personal dictionary (such that future exposure to a > given word will automatically translate it). **** > > ** ** > > I titled this "Personal Programming Environment as Extension of Self" > because I think it should reflect our own metaphors, our own thoughts, > while still being formally precise when we share values. Allowing me to use > your words, your meanings, your macros is one thing - a learning > experience. Asking me to stick with it, when I have different subtle > distinctions I favor, is something else. **** > > ** ** > > Personally, I think making the community "see" the same things is less > important so long as they can share and discover by *meaning* of content > rather than by the words used to describe it. Translator packages could be > partially automated and further maintained implicitly with permission from > the people who explore different projects and small communities. **** > > ** ** > > Can we create systems that enable people to use the same words and > metaphors with subtly different meanings, but still interact efficiently, > precisely, and unambiguously?**** > > ** ** > > Best,**** > > ** ** > > Dave**** > > ** ** > > ** ** > > On Mon, Sep 23, 2013 at 5:26 PM, Sean McDirmid <[email protected]> > wrote:**** > > The names are for people, and should favor readability over uniqueness > in the namespace; like ambiguous English words context should go a long way > in helping the reader understand on their own (if not, they can do some > mouse over). We can even do fancy things with the names when they are being > rendered, like, if they are ambiguous, underlay them with a dis-ambiguating > qualifier. The world is wide open once you’ve mastered how to build a code > editor! Other possibilities include custom names, or multi-lingual names, > but I’m worried about different developers “seeing” different things…we’d > like to develop a community that sees the same things.**** > > **** > > The trick is mastering search and coming up with an interface so that it > becomes as natural as identifier input. **** > > **** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *David Barbour > *Sent:* Tuesday, September 24, 2013 5:10 AM > *To:* [email protected]**** > > > *Subject:* Re: Personal Programming Environment as Extension of Self**** > > **** > > It isn't clear to me what you're suggesting. That module names be subject > to... edit-time lookups? Hyperlinks within the Wiki are effectively full > URLs? That could work pretty well, I think, though it definitely favors the > editor over the reader. **** > > **** > > Maybe what we need is a way for each user to have a personal set of > PetNames.**** > > **** > > http://www.skyhunter.com/marcs/petnames/IntroPetNames.html**** > > **** > > This way the reader sees xrefs in terms of her personal petname list, and > the writer writes xrefs in terms of his.**** > > **** > > I was actually contemplating this design at a more content-based layer:*** > * > > **** > > * a sequence of bytecode may be given a 'pet-name' by a user, i.e. as a > consequence of documenting or explaining their actions. **** > > * when an equivalent sequence of bytecode is seen, we name it by the > user's pet-name.**** > > * rewriting can help search for equivalencies.**** > > * unknown bytecode can be classifed by ML, animated, etc. to help > highlight how it is different. **** > > * we can potentially search in terms of code that 'does' X, Y, and Z at > various locations. **** > > * similarly, we can potentially search in terms of code that 'affords' > operations X, Y, and Z.**** > > **** > > I think both ideas could work pretty well together, especially since > '{xref goes here}{lookup}$' itself could given a pet name.**** > > **** > > **** > > On Mon, Sep 23, 2013 at 1:41 PM, Sean McDirmid <[email protected]> > wrote:**** > > Maybe think of it as a module rather than a namespace. I'm still quite > against namespaces or name based resolution in the language semantics; > names are for people, not compilers (subtext). Rather, search should be a > fundamental part of the IDE, which is responsible for resolving strings > into guids. **** > > **** > > It will just be like google mixed in with Wikipedia, not much to be afraid > of. **** > > > On Sep 24, 2013, at 4:32, "David Barbour" <[email protected]> wrote:**** > > Sean, **** > > **** > > I'm still interested in developing a code wiki! Had that idea in mind > since 2007-ish. **** > > **** > > But I might favor a more DVCS-style approach, where edits are > cherry-picked into each user's/group's private view of the wiki, and where > shared code is simply published to spaces where other people can find it > easily. (I'd really like some sort of content-based search, i.e. find me > functions relevant to this input that will produce outputs with a given > property.)**** > > **** > > I think forcing people to use a global Wikipedia repo will (reasonably) > scare too many people off. But I also think there should be one of them, as > a central collaboration point to help flatten the namespaces, and perhaps > another one for each large business, and another for each project, and > another for each user, with different groups finding niches for themselves. > **** > > **** > > The main thing is to avoid deep namespaces like Java. There are enough > words for everyone.**** > > **** > > (Hmm. I wonder if genetic programming with TC code might be an interesting > way to have little wiki-babies. ;)**** > > **** > > Best,**** > > **** > > Dave**** > > **** > > **** > > On Mon, Sep 23, 2013 at 2:04 AM, Sean McDirmid <[email protected]> > wrote:**** > > Imagine a language that comes with one shared namespace that all > language users can import from and export into, let’s call it the “code > wiki.” Search is built into the IDE so programmers can find things from > the code wiki easily. Only one branch of versioning is supported, and like > Wikipedia, vandalism is handled quickly via editors who care. At any rate, > programmers are expected to vet code that they are interested in reusing, > and ensure that changes to the code are reasonable (edit wars might result > in explicit forking), aided by very good diff tooling.**** > > **** > > **** > > -- **** > > You received this message because you are subscribed to the Google Groups > "Augmented Programming" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to > [email protected]. > Visit this group at http://groups.google.com/group/augmented-programming. > For more options, visit https://groups.google.com/groups/opt_out.**** > > -- > You received this message because you are subscribed to the Google Groups > "Augmented Programming" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to > [email protected]. > Visit this group at http://groups.google.com/group/augmented-programming. > For more options, visit https://groups.google.com/groups/opt_out.**** > > ** ** > > -- > You received this message because you are subscribed to the Google Groups > "Augmented Programming" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to > [email protected]. > Visit this group at http://groups.google.com/group/augmented-programming. > For more options, visit https://groups.google.com/groups/opt_out.**** > > -- > You received this message because you are subscribed to the Google Groups > "Augmented Programming" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to > [email protected]. > Visit this group at http://groups.google.com/group/augmented-programming. > For more options, visit https://groups.google.com/groups/opt_out. >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
