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
<[email protected]>wrote:

> David Barbour <[email protected]> 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
> [email protected]
> http://vpri.org/mailman/listinfo/fonc
>
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Reply via email to