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. >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
