Don't forget that words can be images, vector graphics or 3D graphics. If you have an open system, then people will incorporate names/symbols. I'm not sure you want to avoid symbolic processing, but that's your choice.
I'm reminded of the omgcraft ad for cachefly. John On Sep 23, 2013 8:11 PM, "David Barbour" <[email protected]> wrote: > 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 > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
