I think you're taking the right approach with concatenation. Don't make the mistake people made with UIMS. On Sep 23, 2013 1:47 PM, "David Barbour" <[email protected]> wrote:
> John, I'll explain a few points that lead me to favor a bytecode: > > 1) I think distribution in an intermediate language is inevitable. As a > concrete example, if we distribute code in JavaScript, there will be people > who build CoffeeScript or Elm or Fay or GWT, using JavaScript as a target. > More broadly, I favor dialects, DSLs, user-defined syntax and notations for > different concepts - i.e. what I described in the first article: the > different documents, diagrams, graphs and geometries have different > interpreters. In general, I suppose it is feasible to distribute a > serialization of Elm/CoffeScript/DSL/etc. along with the interpreter for > it, but I think the overhead might not be acceptable. > > 2) I believe code distribution shouldn't be "shallow" like it currently is > between client and server. Sometimes we distribute code that distributes > code like a Matryoshka doll. Sometimes code is the output of collaboration > between services - e.g. a service that models the binding of multiple other > services together, or that interprets the result of querying a service. In > many cases, code will be specialized just for the recipient's current > queries. Optimization and typechecking are pervasive in the envisioned > system. In this context, it's unclear with whom we should collaborate. > > 3) Often, sources are hidden for security reasons. And I'm not just > talking about IP protection, but rather that sources may contain > capabilities regarding which we wish to control distribution. This is one > of the motivations for source code being the result of collaboration, or > specialized to a recipient. > > 4) I am interested in Augmented Reality and (to a lesser degree) VR > programming. In that such programming environments, the amount of metadata > tends to greatly outweigh the semantic content. We have visual > fingerprints, meshes, orientations. We have regions, rotation, navigation > in both large and small. In many cases, AR or VR itself might serve as a > partially shared space (formally, we might set our environment to observe > constructs exported by friends, businesses, public spaces). However, the > sheer amount of metadata involved suggests that distribution of source > shouldn't be the only basis for distribution of its behavior. The ability > to 'compile' a massive workspace into a small, reusable tool is quite > valuable. > > 5) I am interested in programming-by-example, extracting safe, reusable > code from user actions and toolsets. However, I think users creating this > code won't often have names even for their own actions, and automatically > creating names seems like nonsense. It seems wiser that code is > 'documented' by use of examples and animations, and named post-hoc for > patterns that come up again and again. > > 6) The vast majority of people, even programmers, will never look > under-the-hood at the source code for the applications they use. Looking at > a massive hairball of code that forms an application is perhaps not the > best basis for collaboration. As Sean McDirmid observes, use of a shared > space seems a better basis for collaborative efforts. > > ... > > But the idea of having a high-level distribution language is still > tempting. > > The 'Awelon' language is a simple expansion of the Awelon Bytecode. The > main difference is: Awelon has a simple module system, and Awelon has > defined words. A module for simple block-free data plumbing in Awelon's > standard environment might look like: > > import abc > assocr = swap assocl swap assocl swap % ((a*b)*c) -> (a*(b*c)) > rot2 = intro1 rot3 intro1 rot3 elim1 elim1 % (a*(b*c))->(b*(a*c)) > zip2 = assocr rot3 rot2 assocl % ((a*b)*(c*d)) -> ((a*c)*(b*d)) > roll2 = swap rot3 rot2 swap % rot2 on stack > take = zip2 rot2 % from stack to hand > put = rot2 zip2 % from hand to stack > jugl2 = rot2 roll2 rot2 % rot2 in hand > > One line of comma-separated imports is allowed. Any word not prefixed with > `_` is exported. Any word prefixed with `test` or `_test` is executed as an > application in a confined testing environment. In the context of a > wiki-like environment I support export of `this = ` such that I can treat > modules as having value as software components. > > Awelon's standard environment is essentially a structure designed for > capability-secure text-based programming: > > (stack * (hand * (powerblock * (stackName * namedStacks))))) > > All authority, even access to exclusive state, flows from the powerblock. > Controlling which powerblock reaches a subprogram provides a relatively > simple mechanism to extend, control, and audit the 'deep' behavior of > (potentially distrusted) subprograms. However, since the powerblock has a > standard location in the environment, programmers get all the syntactic > conveniences associated with ambient authority. > > The named stacks are actually modeled as an association list, so lookup is > with text. But one can goto a stack by name, swapping it with the current > one (keeping everything in the current hand). Or one may store/load from a > named stack (which is basically a goto take goback put). Named stacks thus > operate like a mix of locations, keyword inventory, and potential basis for > environment extensions. With an assumption that the content on a stack is > often a document-like structure (document, diagram, graph, geometry, etc.), > I can also build a library for zipper navigation of this document. In this > sense, each stack becomes a 'workspace' for artifact manipulation. > > Awelon is still designed under the paradigm of text programming in a > larger IDE, albeit potentially augmented with greater visualization of the > environment. But alternative environments could be developed, e.g, for > augmented reality. Software components built for one environment would > generally be compatible with others. > > To get this back on subject: Why not just distribute Awelon a lot like > JavaScript? > > It seems the higher level distribution language doesn't really gain me > much. It just becomes relatively complex, expensive bytecode. Every > intermediate processor would explicit code to deal with names. Rewrites > would result in code that doesn't have a clear name. Pattern matching and > machine-learning would need a bunch of extra logic to eliminate boundaries > between human names and build their own models of meaningful words. > > I've spent a lot of time pondering that question. Making Awelon the new > JavaScript appeals to me. But ultimately it seems a streaming bytecode has > better characteristics for my goals. > > In the programming environment I describe above, Awelon would be fully > subsumed, just one more artifact to be interpreted. Maybe that's how it > should be. > > > On Mon, Sep 23, 2013 at 1:54 AM, John Nilsson <[email protected]> wrote: > >> 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" <[email protected]> >>> 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 little bit of complexity, adds up, >>>>> pushing the system beyond viable accessibility and usability thresholds. >>>>> >>>>> Further, these aren't "little" points, and TC is not just "marginally" >>>>> more effective. Visualization and animation are extremely important. >>>>> Predicting and anticipating user actions is highly valuable. Code >>>>> extraction from history, programming by example, then tuning and >>>>> optimizing >>>>> this code from history are essential. Streaming commands is the very >>>>> foundation. >>>>> >>>>> -- >>> 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
