Re: [fonc] Personal Programming Environment as Extension of Self
A thought about bytecode: One problem with distributing things in a
compiled version is that it doesnt really afford collaboration. If the
primary means of distribution instead would be the source as such it's much
easier to debug and fix issues discovered in imported modules. If something
like a github fork was the standard way of importing it would be even
better, then you are basically just a pull request away from contributing
tweaks too.
Things like minification as in the javascript world would have to be
discouraged though, so compilation and caching should be designers so
as not to be a performance problem.
But, like git, this should be easy if things are based on immutable content
adressable fragments. See f.ex. Datomic and/or camlistore as an approach to
this. ( and docker for that matter)
BR
John
Den söndagen den 22:e september 2013 skrev David Barbour:
Mark,
You ask some good questions! I've been taking some concrete actions to
realize my vision, but I haven't much considered how easily others might
get involved.
As I've written, I think a tactic concatenative (TC) language is the key
to making it all work great. A TC language can provide a uniformly safe and
simple foundation for understanding and manipulating streaming updates.
User actions must be formally translated to TC commands, though I can start
at a higher level and work my way down. However, the artifacts constructed
and operated upon by this language must be concretely visualizable,
composable, and manipulable - e.g. documents, diagrams, graphs, geometries.
Homoiconic this is not.
My own plan is to implement a streamable, strongly typed,
capability-secure TC bytecode (Awelon Bytecode, ABC) and build up from
there, perhaps targeting Unity and/or developing a web-app IDE for
visualization. (Unity is a tempting target for me due to my interest in AR
and VR environments, and Meta's support for Unity.)
I would very much favor a lightweight toolkit approach, similar to what
the REBOL/Red community has achieved -fitting entire desktops and
webservices as tiny apps built upon portable OS/runtime ( 1MB). BTW, if
you are a big believer in tools, I strongly recommend you look into what
the REBOL http://www.rebol.com/what-rebol.html community has achieved,
and its offshoot Red http://www.red-lang.org/p/about.html. These people
have already achieved and commercialized a fair portion of the FoNC ideals
through their use of dialects. They make emacs look like a bloated,
outdated, arcane behemoth.
(If REBOL/Red used capability-based security, pervasive reactivity, live
programming, strong types, substructural types, external state, and...
well, there are a lot of reasons I don't favor the languages. But what
they've accomplished is very impressive!)
I think the toolkit approach quite feasible. ABC is designed for
continuous reactive behaviors, but it turns out that it can be very
effectively used for one-off functions and imperative code, depending only
on how the capability invocations are interpreted. ABC can also be used for
efficient serialization, i.e. as the protocol to maintain values in a
reactive model. So it should be feasible to target Unity or build my own
visualization/UI toolkit. (ABC will be relatively inefficient until I have
a good compiler for it, but getting started should be easy once ABC is
fully defined and Agda-sanitized.)
Best,
Dave
On Sep 21, 2013 10:52 PM, Mark Haniford
markhanif...@gmail.comjavascript:_e({}, 'cvml', 'markhanif...@gmail.com');
wrote:
David,
Great Writeup. To get down to more practical terms for laymen software
engineers such as myself, what can we do in immediate terms to realize
your vision?
I'm a big believer in tools( even though I'm installing emacs 24 and
live-tool). Is there currently a rich IDE environment core in which we can
start exploring visualization tools?
Here's what I'm getting at. We have rich IDEs (in relative terms),
Intellij, Resharper, VS, Eclipse, whatever.. I think they are still very
archaic in programmer productivity. The problem I see is that we have a
dichotomy with scripting ennviroments (Emacs) as opposed to heavy IDEs.
e.g. we can't easily script these IDEs for expermination.
thought?
I find myself agreeing with most of your intermediate reasoning and
then failing to understand the jump to the conclusion of tactic
concatenative programming and the appeal of viewing user interfaces as
programs.
Tacit concatenative makes it all work smoothly.
TC is very effective for:
* automatic visualization and animation
* streaming programs
* pattern detection (simple matching)
* simple rewrite rules
* search-based code generation
* Markov model predictions (user anticipation)
* genetic programming and tuning
* typesafe dataflow for linear or modal
Individually, each of these may look like an incremental improvement
that could be achieved without TC.
But every little point, every
Re: [fonc] Personal Programming Environment as Extension of Self
David Barbour dmbarb...@gmail.com writes: My own plan is to implement a streamable, strongly typed, capability-secure TC bytecode (Awelon Bytecode, ABC) and build up from there, perhaps targeting Unity and/or developing a web-app IDE for visualization. (Unity is a tempting target for me due to my interest in AR and VR environments, and Meta's support for Unity.) When bootstrapping pervasive systems like this I think it's important to 'dog food' them as early as possible, since that makes it easier to work out which underlying feature should be added next (what would help the most common irritation?), and allows for large libraries of 'scratch an itch' scripts to build up. I would find out what worked (and what didn't) for other projects which required bootstrapping. Minimalist and low-level systems are probably good examples, since it's harder for them to fall back on existing software. I suppose I have to mention self-hosting languages like Smalltalk, Self and Factor. I'd also look at operating systems (MenuetOS, ReactOS, Haiku, etc.), desktop 'ecosystems' (suckless, ROX, GNUStep, etc.), as well as Not-Invented-Here systems like Unhosted. What was essential for those systems to be usable? Which areas were implemented prematurely and subsequently replaced? If it were me, I would probably bootstrap via a macro system (on Linux): * Log all X events, eg. with xbindkeys (togglable, for password entry) * Write these logs as concatenative programs, which just call out to xte over and over again * Write commands for quickly finding, editing and replaying these programs With this in place, I'd have full control of my machine, but in a very fragile, low-level way. However, this would be enough to start scratching itches. When controlling Ratpoison via simulated keystrokes becomes too tedious, I might write a few Awelon words to wrap Ratpoison's script API. I might hook into Selenium to make Web automation easier. As each layer starts to flake, I can go down a level and hook into GTK widgets, Imagemagick, etc. until some tasks can be achieved by composing purely 'native' Awelon components. It would be very hacky and non-ideological to begin with, but would be ever-present and useful enough to get some real usage. Cheers, Chris ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Personal Programming Environment as Extension of Self
Chris, You offer a lot of good advice. I agree that dog-fooding early would be ideal. Though for UI, I currently favor one of two directions: * web apps * OpenGL (perhaps just a subset, the WebGL API) I also want to address these in a manner more compatible with reactive programming. Fortunately, UI is a relatively good fit for both pipelining and reactive programming. I think I can make this work, but I might be using GPipe or LambdaCube as bases for the GL API. Best, Dave On Mon, Sep 23, 2013 at 2:59 AM, Chris Warburton chriswa...@googlemail.comwrote: David Barbour dmbarb...@gmail.com writes: My own plan is to implement a streamable, strongly typed, capability-secure TC bytecode (Awelon Bytecode, ABC) and build up from there, perhaps targeting Unity and/or developing a web-app IDE for visualization. (Unity is a tempting target for me due to my interest in AR and VR environments, and Meta's support for Unity.) When bootstrapping pervasive systems like this I think it's important to 'dog food' them as early as possible, since that makes it easier to work out which underlying feature should be added next (what would help the most common irritation?), and allows for large libraries of 'scratch an itch' scripts to build up. I would find out what worked (and what didn't) for other projects which required bootstrapping. Minimalist and low-level systems are probably good examples, since it's harder for them to fall back on existing software. I suppose I have to mention self-hosting languages like Smalltalk, Self and Factor. I'd also look at operating systems (MenuetOS, ReactOS, Haiku, etc.), desktop 'ecosystems' (suckless, ROX, GNUStep, etc.), as well as Not-Invented-Here systems like Unhosted. What was essential for those systems to be usable? Which areas were implemented prematurely and subsequently replaced? If it were me, I would probably bootstrap via a macro system (on Linux): * Log all X events, eg. with xbindkeys (togglable, for password entry) * Write these logs as concatenative programs, which just call out to xte over and over again * Write commands for quickly finding, editing and replaying these programs With this in place, I'd have full control of my machine, but in a very fragile, low-level way. However, this would be enough to start scratching itches. When controlling Ratpoison via simulated keystrokes becomes too tedious, I might write a few Awelon words to wrap Ratpoison's script API. I might hook into Selenium to make Web automation easier. As each layer starts to flake, I can go down a level and hook into GTK widgets, Imagemagick, etc. until some tasks can be achieved by composing purely 'native' Awelon components. It would be very hacky and non-ideological to begin with, but would be ever-present and useful enough to get some real usage. Cheers, Chris ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Personal Programming Environment as Extension of Self
Pavel, I'm interested in collaborators. But the very first help I'd need is administrative - figuring out how to effectively use collaborators. ;) Regarding names: I think it best if names have an explicit lookup mechanism. I.e. names aren't documentation, they're more like an index in a map. If we don't automate the use of names, they won't do us very much good. But by making the automation explicit, I think their fragility and the difficulties surrounding the names (e.g. with respect to closures, messaging, drag-and-drop, etc.) also becomes more obvious and easier to analyze. In Awelon at the moment, I use 'named stacks' that enable load/store/goto. But these are formally modeled within Awelon - i.e. as an association list. True external names and capabilities require more explicit lookups using capabilities or a powerblock. I agree with your point that many programmers probably aren't very motivated to eliminate the boundary. Fortunately, we don't need the aide of every programmer, just enough to get the project moving and past critical mass. :) Regards, Dave On Mon, Sep 23, 2013 at 3:21 AM, Pavel Bažant pbaz...@gmail.com wrote: Dear David, I am seriously interested in collaborating with you! I especially like the following points: 1) Programming by text manipulation is not the only way to do programming I actually tend to have the more iconoclastic view that text-based programming is harmful -- see my previous rant on FONC, but you mentioned what should be done, whereas I only managed to point out what should not be done. 2) I like the tacit idea. I always considered the omnipresent reliance on names as means of binding things together as extremely fragile. Do you think one could treat the names as annotations with documentation purpose, without them being the binding mechanism? 3) Last but not least: There is no fundamental difference between programmers and users. Both groups are just using computers to create some digital content. Any sharp boundary between the way the two groups work is maybe unnatural. I think psychology is an important factor here. I actually do think that many programmers actually like the existence of such boundary and are not motivated to make it disappear, but this is really just an opinion. On Fri, Sep 20, 2013 at 7:35 AM, David Barbour dmbarb...@gmail.comwrote: Over the last month, I feel like I stumbled into something very simple and profound: a new perspective on an old idea, with consequences deeper and more pervasive than I had imagined. The idea is simply this: every user action is an act of meta-programming. More precisely: (1) Each user event addends a tacit concatenative program. (2) The output of the tacit concatenative program is another program. (3) We can understand the former as rewriting parts of the latter. (4) These rewrites include the user-model - navigation, clipboard, etc. I will further explain this idea, why it is powerful, how it is different. To clarify, this isn't another hand-wavy 'shalt' and 'must' proposal with no idea of how to achieve it. Hammering at a huge list of requirements for eight years got me to RDP. At this point, I have concrete ideas on how to accomplish everything I'm about to describe. Users Are Programmers. The TUNES vision is revived, and better than ever. *WHY TACIT CONCATENATIVE?* Concatenative programming is perhaps best known through FORTH. Most concatenative languages have followed in Charles Moore's forthsteps, sticking with the basic stack concept but focusing on higher-order programming, types, and other features. A stack would be an extremely impoverished and cramped environment for a user; even many programmers would not tolerate it. Fortunately, we can move beyond the stack environment. And I insist that we do! Concatenative programming can also be based upon such structures as trees, Huet zippers, and graphs. This proposal is based primarily on tree-structured data and zippers, with just a little indirect graph modeling through shared state or explicit labels (details later). A 'tacit' programming language is one that does not mention names for parameters or local variables. Many concatenative programming languages are also tacit, though the concepts don't fully intersect. A weakness of tacit concatenative programming is that, in a traditional text-based programming environment, users must visualize the environment (stack or other structure) in their head, and that they must memorize a bunch of arcane 'stack shuffling' words. By comparison, variable names in text are easy to visualize and review. My answer: change programming environments! Powerful advantages of tacit concatenative programming include: 1. the environment has a precisely defined, visualizable value 2. short strings of tacit concatenative code are easy to generate 3. concatenative code is sequential, forming an implicit timeline 4. code also subject to learning,
Re: [fonc] Formation of Noctivagous, Inc.
When a font is hard to read, I use [Ctrl +]. So I did read the whole page. I didn't found it appealing, for one silly reason. Despite the pretty picture and the sales pitch… …I haven't the slightest idea _how_ this program is used. Loup. On Sun, Sep 22, 2013 at 10:05:58AM -0400, Tom Lieber wrote: Is this an anti-aliasing problem? I can read it fine on OS X, which it looks like John also uses. On Sun, Sep 22, 2013 at 6:24 AM, Josh Grams j...@qualdan.com wrote: On 2013-09-21 08:11PM, John Pratt wrote: Is it really hard to read? It's not. I found it pretty hard to read. I got through about two of the sections of text before I gave up. I could certainly fight my way through it if I had to, but...I'm sorry; your stuff may be great, but there's too much interesting stuff out there for me to have much incentive to spend effort on things with that painful of a presentation... ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] 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
On Mon, Sep 23, 2013 at 5:26 PM, Sean McDirmid smcd...@microsoft.comwrote:
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:* augmented-programm...@googlegroups.com [mailto:
augmented-programm...@googlegroups.com] *On Behalf Of *David Barbour
*Sent:* Tuesday, September 24, 2013 5:10 AM
*To:* augmented-programm...@googlegroups.com
*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 smcd...@microsoft.com
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 dmbarb...@gmail.com wrote:
Sean,
** **
I'm still interested
Re: [fonc] Personal Programming Environment as Extension of Self
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 smcd...@microsoft.comwrote: 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-programm...@googlegroups.com [mailto: augmented-programm...@googlegroups.com] *On Behalf Of *David Barbour *Sent:* Tuesday, September 24, 2013 9:11 AM *To:* augmented-programm...@googlegroups.com; reactive-dem...@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 ** ** ** ** On Mon, Sep 23, 2013 at 5:26 PM, Sean McDirmid smcd...@microsoft.com wrote: The names are for people, and should favor readability over uniqueness in the namespace; like ambiguous English words context should go a long
Re: [fonc] Personal Programming Environment as Extension of Self
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 dmbarb...@gmail.com 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 smcd...@microsoft.comwrote:
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:* augmented-programm...@googlegroups.com [mailto:
augmented-programm...@googlegroups.com] *On Behalf Of *David Barbour
*Sent:* Tuesday, September 24, 2013 5:10 AM
*To:* augmented-programm...@googlegroups.com
*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 smcd...@microsoft.com
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
Re: [fonc] Personal Programming Environment as Extension of Self
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 yottz...@gmail.com 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 dmbarb...@gmail.com 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 smcd...@microsoft.comwrote: 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:* augmented-programm...@googlegroups.com [mailto: augmented-programm...@googlegroups.com] *On Behalf Of *David Barbour *Sent:* Tuesday, September 24, 2013 5:10 AM *To:* augmented-programm...@googlegroups.com *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,
Re: [fonc] Personal Programming Environment as Extension of Self
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 dmbarb...@gmail.com 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 yottz...@gmail.com 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 dmbarb...@gmail.com 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 smcd...@microsoft.comwrote: 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:* augmented-programm...@googlegroups.com [mailto: augmented-programm...@googlegroups.com] *On Behalf Of *David Barbour *Sent:* Tuesday, September 24, 2013 5:10 AM *To:* augmented-programm...@googlegroups.com *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. *
Re: [fonc] Personal Programming Environment as Extension of Self
Oh, I see. As I mentioned in the first message, I plan on UTF-8 text being
one of the three basic types in ABC. There is text, rational numbers, and
blocks. Even if I'm not using names, I think text is very useful for tagged
values and such.
{Hello, World!}
Text is also one of the problems I've been banging my head against since
Friday. Thing is, I really hate escapes. They have this nasty geometric
progression when dealing with deeply quoted code:
{} - {{\}} - {{{\\\}\}} - \\\}\\\}\}} -
{\\\}\\\}\\\}\}}
I feel escapes are too easy to handle incorrectly, and too difficult to
inspect for correctness. I'm currently contemplating a potential solution:
require all literal text to use balanced `{` and `}` characters, and use
post-processing in ABC to introduce any imbalance. This could be performed
in a streaming manner. Inductively, all quoted code would be balanced.
Best,
Dave
On Mon, Sep 23, 2013 at 9:28 PM, John Carlson yottz...@gmail.com wrote:
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 dmbarb...@gmail.com 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 yottz...@gmail.com 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 dmbarb...@gmail.com 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
smcd...@microsoft.comwrote:
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:* augmented-programm...@googlegroups.com [mailto:
