I think it's fine if people model names, text, documents, association lists, wikis, etc. -- and processing thereof.
And I do envision use of graphics as a common artifact structure, and just as easily leveraged for any explanation as text (though I imagine most such graphics will also have text associated). Can you explain your concern? On Sep 23, 2013 8:16 PM, "John Carlson" <[email protected]> wrote: > 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 > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
