Sun Sep 14 11:53:03 CEST 2008
Got quite a to-the-point reply from DavidP5 on the microchip forum:
The people who inhabit these forums are probably "in the trenches"
as much as anyone. It is ironic that you seem to be having some
difficulty explaining what your tool actually does in a way that
is comprehensible to the people you are talking to (translating it
into trenchese?). Clearly you love the concepts that you work
with, and they sound so exotic (the lambda domain for example),
but they may be getting in the way of you showing the
trench-dwellers how you are proposing to make their lives
easier. I suspect that using it "just as a low-level machine
abstraction layer" is as much as you can hope for, but you will
have to stop talking like that if you want to get any traction
around here. I think you would be better to say that you have made
a Forth implementation for PIC18s, and ask people to test it and
suggest improvements. I have read your pic18-forth pdf. It is
interesting but way too abstract for "trenchers". A tutorial about
how to use your Forth for a variety of useful tasks (how to use a
timer, how to send and receive data over a USART, responding to an
external interrupt, writing to flash etc) would be better
received. Trench-dwellers are primarily practical people so you
must show them how to do stuff with your Forth if you want them to
be interested. It would also be worth demonstrating that your
compiled programs are at least as good as compiled C in terms of
efficiency and resource utilisation.
This puts the finger on the sour spot. Looks like there is only one
way around this: differentiate the documentation in a Scheme camp and
a machine code camp.
Thanks. Your suggestions are very helpful. It does look indeed
like a different approach to documentation is needed. I'm getting
more convinced that the real problem I'm trying to solve is not
really the technical one of building this system, but to write the
documentation, bridging two different engineering cultures that
generally just ignore each other..
A question to the PLT Scheme list:
(at least, something I want to ask but writing down the question makes
me think more.. this needs to ferment a bit more..)
This list being a lair of educators, I guess it is the right place to
get some inspiration. I'm looking for advice on writing documentation
which needs to use the concept of lexical scope and closures for
people that have spent already several years in an Electrical
I have an EE/DSP background myself, and after absorbing Scheme and a
bit of basic language theory over the last 3 years I think I finally
get it, in that this ``exotic lambda domain'' has become a natural way
of working. I recall that learning this was not an easy process, and
involved partially un-learning the use of real machines as my only
reference point. However, in the meanwhile I seem to have not made
any progress at all extracting knowledge from my own learning process
to better explain the basic ideas in simple terms to my former peer
group, or avoiding unnecessary lore.
So the question: Does anyone have ideas or experience to ``sell the
benefits of functional programming'' to an EE biased audience?
I need two chapters.
1. The Forth language.
2. Its compiler.
I'm taking the following post off the blog..