We developed an s-expression-like client-server based UI protocol. We used class ids and object ids. It was very difficult to debug. So much so that I developed a non distributed version (well it used X11). Note that we used string length for our strings. It was more of an issue of numbers everywhere that caused the confusion. When HTML came out, we abandoned our protocol. Learn from the past. HTML also knocked out other distributed options like NeWS and Display PostScript. These were lower level than HTML for a long time. I encourage you to leverage HTML and JavaScript to the extent you need to, but beware of more understandable protocols happening at the same level or above. Sometimes giving up expressive power can be better in the short run to gain market share. That is, the best product doesn't always win.
John On Sep 24, 2013 10:54 AM, "David Barbour" <[email protected]> wrote: > Even Lisp isn't parentheses balanced by definition, because you can do > this: > > '(")") > > In that same sense my bytecode is block balanced, except in text. > > [ [ [] [] ] [] ] > > { ] } > > The idea of using number of chars is possible, something like: > > {42|forty two characters here................. > > But that would also be very difficult to use in a streaming bytecode. It's > also difficult to read. I've always felt that bytecode should at least be > slightly legible, so I can easily get a sense of what's happening just by > looking at the raw streams, even though I don't expect people to program in > bytecode directly (nor read it that way often). > > On Tue, Sep 24, 2013 at 12:49 AM, Pavel Bažant <[email protected]> wrote: > >> I don't know the details of your language, but I see two possibilities: >> 1) If the textual representation of your language is parenthesis-balanced >> by definition, just do what Lisp does. >> 2) If not, format quoted text like quote number_of_chars char char char >> .... >> Yes I know 2) is fragile, but so is escaping. >> >> >> On Tue, Sep 24, 2013 at 7:24 AM, David Barbour <[email protected]>wrote: >> >>> 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 <[email protected]>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" <[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 >>>> >>>> >>> >>> _______________________________________________ >>> 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
