[<<][staapl-blog][>>][..]
Tue Mar 29 00:51:25 EDT 2011

Right or Fast?

* The ``right'' way to build an application is to build a monolithic
  kernel.  This taps into the lexically sane hygienic macro magic of
  Racket.  A kernel (really a kernel generator) is a Racket module.

* The ``fast'' way to build an application is to incrementally add
  definitions on a live target, relative to a fixed kernel.

Both approaches are valid.  The monilithic kernel approach is very
close to ordinary Racket programming, and is a good approach for
developing large programs.  Read the Racket guide and manual for more
information.  The disadvantage is that the cycle is slower (compile,
upload).

The incremental approach is a ColorForth[1] style early binding
approach, and not a lisp style which would allow change of bindings in
existing code.  You can add new code on top of old code obscuring old
bindings for new code, but you can't modify existing bonds unless you
provide your own indirection mechanisms.  This seems overall a more
bullet-proof default.

The incremental approach has an `empty' and `load' cycle.  The `empty'
command will reset the code back to the initial kernel state, and
`load' can be used to add (non-modular) on top of this.  A workflow I
use is to develop code in a single file and use `empty' and `load' to
quickly change the code on a running target.  When done, move the code
to the kernel and recompile.

The incremental approach doesn't require a chip reset, and so works
better with applications that need to maintain state or run-time
behaviour inbetween code updates.  Overall I've found this to be the
case in deeply embedded programming.  You spend most of your time
setting up ad-hoc tests and measurements to see why things are not
working as expected.  A fast incremental state-change approach works
better here than a recompile-the-world functional approach.


[1] http://en.wikipedia.org/wiki/ColorForth



[Reply][About]
[<<][staapl-blog][>>][..]