[<<][staapl][>>][..]
Sun Sep 14 11:53:03 CEST 2008

Trench dwellers

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.

My reply:

    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..)

Hello folks,

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
Engineering background.

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..






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