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
