I don't really have a big concern. If you just support numbers, people will find clever, but potentially incompatible ways of doing strings. I recall in the pre-STL days supporting 6 different string classes. I understand that a name is different than a string, but I come from a perl background. People don't reinvent strings in perl to my knowledge. On Sep 23, 2013 11:15 PM, "David Barbour" <[email protected]> wrote:
> 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 > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
