I have nothing against name resolution at edit-time. My concern is that giving the user a list of 108 subtly different definitions of 'OOP' and saying "I can't resolve this in context. Which one do you mean here?" every single time would be insufferable, even if the benefit is that everyone 'sees' the same code.
On Sep 24, 2013 7:15 AM, "Matt M" <[email protected]> wrote: > > Person.draw(object) <-- What do I mean by this? Am I drawing a picture? > a gun? a curtain? > > And the way this works in conversation is that your partner stops you and > says "wait, what do you mean by 'draw'"? Similarly an IDE can underline > the ambiguity and leave it to the user to resolve, either explicitly or > implicitly by continuing to write more (often ambiguity is removed with > further context). > > I completely agree with Sean's quote (of Johnathan Edwards?) that names > are for people, and that name resolution should almost never be part of the > dynamics of a language. Names should be resolved statically (preferably at > edit time). > > Matt > > > On Monday, September 23, 2013 9:24:52 PM UTC-5, dmbarbour wrote: >> >> 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:* augmented-...@**googlegroups.com [mailto:augmented-...@** >>> googlegroups.com] *On Behalf Of *David Barbour >>> *Sent:* Tuesday, September 24, 2013 9:11 AM >>> *To:* augmented-...@**googlegroups.com; reactiv...@googlegroups.**com; >>> 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**** >>> >>> ** >>> >>
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
