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]<javascript:_e({}, 'cvml', '[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]<javascript:_e({}, > 'cvml', > 'augmented-programming%[email protected]');>. > To post to this group, send email to > [email protected] <javascript:_e({}, 'cvml', > '[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
