On Thu, Sep 26, 2013 at 5:21 AM, Eran Meir <eranm...@gmail.com> wrote:

> "This is my personal programming environment. There are many like it, but
> this one is mine."
>

Indeed. That's the same way I feel about my smart phone, and my Ubuntu
desktop. :)

Except those aren't nearly as casually personalizable as I want, due to the
coarse granularity for code distribution and maintenance. :(

Regarding the deep discussion of names seeming out of place for a tacit
model: yeah, I thought so too.  My own vision involves
programming-by-example extraction or workspace compilation into an
inventory of reusable AR/VR/GUI tools (mattock, wand, menus, etc.) or macro
assignments that will often be just as tacit and nameless as the objects
upon which they operate. Sharing values, even behaviors, should rarely
involve use of names.

But Sean and Matt are envisioning a very text-based programming
environment, due to their own experiences and their own development
efforts. I'm not going to take that away from them (it would be futile to
try). Also, text-based programming is undoubtedly more convenient for a
subset of  domains. I'm still interested in supporting it (perhaps via
pen-and-paper<http://awelonblue.wordpress.com/2012/10/26/ubiquitous-programming-with-pen-and-paper/>
and
AR), and text-based artifacts (documents, diagrams) are easily represented
in the model I propose. At least for these cases, I can usefully discuss
written names.

I agree with your position on pet names. But I can also understand Sean's
position; technology hasn't quite reached the point where we can easily
discuss code while pointing at it in a shared environment supporting
multiple views. I keep looking forward to Dennou Coil and other visions of
ubiquitous computing and an AR future. The technology is getting there very
quickly.

There will always be some common ground for people to meet, e.g. due to
formal structure, initial visualizers, and the sharing of values. But I'd
love to see different communities evolve, diverging and merging at
different points. I'd love to see children picking up metaphors, tools, and
macros from their parents . The formal structure can still support a lot of
integration and translation.

Warm Regards,

Dave


>

>
> With regard to naming (that's a lot of naming discussion for a 
> *tacit*programming environment - don't you think?), I like the idea of 
> personal
> sets of PetNames. After all, we're discussing *personal* programming
> environment as an extension of *self*. It should assist the person and
> extend their personal capabilities. I believe most users of such enhancing
> system will appreciate communicating with their personal assistant in their
> own language, even if it's just a slightly modified dialect of some common
> language.
>

> And when I re-read the original post, I wonder if debates of ambiguity are
> not going the wrong way. So I'd like to offer my own incomplete metaphor:
> Recall that "every user action is an act of meta-programming". And user
> actions are inherently unambiguous - at least in the personal frame of
> reference. Thus, the problem is actually a problem of change in coordinates
> systems. As an example, consider how one's notion of "naming" is another's
> shifted notion of "identity".
>
> This "relativity of semantics" can perhaps be practically reconciled using
> some rewriting protocols (transformations), helping communicating parties
> find common ground. On the other hand, a foundational problem with name
> reconciliation is that it's basically a unification problem -and this
> problem is undecidable for some logic theories/type systems.
>
> I'm not sure understand enough of David's idea (or substructural logic) to
> tell if this is a real problem or not, but I wanted to chime in, since I
> find the thread fascinating.
>
> Best regards,
> Eran.
>
>
> On Thu, Sep 26, 2013 at 2:23 AM, David Barbour <dmbarb...@gmail.com>wrote:
>
>
>> ...
>>
>  If I assume those responsibilities are handled, and also elimination of
>> local variable or parameter names because of tacit programming, the
>> remaining uses of 'names' I'm likely to encounter are:
>>
>> * names for dynamic scope, config, or implicit params
>> * names for associative lookup in shared spaces
>> * names as human short-hand for values or actions
>>
>> It is this last item that I think most directly corresponds to what Sean
>> and Matt call names, though there might also be a bit of 'independent
>> maintenance' (external state via the programming environment) mixed in.
>> Regarding shorthand, I'm quite interested in alternative designs, such as
>> binding human names to values based on pattern-matching (so when you write
>> 'foo' I might read 'bar'), but Sean's against this due to out-of-band
>> communication concerns. To address those concerns, use of an extended
>> dictionary that tracks different origins for words seems reasonable.
>>
>>  --
> 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 augmented-programming+unsubscr...@googlegroups.com.
> To post to this group, send email to
> augmented-programm...@googlegroups.com.
> 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
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Reply via email to