From: John S. Gage <[EMAIL PROTECTED]>
>Adrian Midgley wrote:
>>
>> There are a few of us, ranging from very good to people like me who
>> can write a filter but prefer easier languages for most things.
>
>I take it you're agreeing with me?
You shouldn't, because I am not.
>Which
>programmers do you want contributing to medical open source? The
one's
>who wrote Perl and Python or the one's who use them?
I want at least some of the people contributing to be physicians, who
understand what the data means, and have a feel for the interface from
the other side.
I have some experience of interface development with professionals
programming actually in LotusScript as it happens, and at least some
of the usefulness I have there is because I can see the objects behind
the interface, having written some equivalent ones - one of which is
better <smug> and found some others too difficult which they have
implemented at an impressive pace. Nevertheless, my code gives fewer
keystrokes when the consultation is busiest.
>The only reasons
>to go to higher level languages is to 1) involve domain experts in
>coding, which as we have seen will never happen
Not shown.
>if there were a very large group of C programmers devoted to
>medical open source
This would be a useful corpus...
>So far there are no horses with the open source colors.
Foals at least.
>> But on the other end of a telnet connection, or an HTTP/HTTPS
>> connection, or over VNC or X-Windows, it doesn't show and doesn't
>> mater what it was written in.
>
>This is the canard.
Hmm. I see a big difference between an X-terminal on 100MBit/s
network and a browser without addons over a 64k terminal.
One of our UK developers lectured last year on the topic of putting
all functions through the browser, and having seen some of his stuff I
am less unconvinced than I was...
Functonality on the dektop need not be monolithic.
I run a free text database, a medical record system, an email client,
more than one browser window with medical reference stuff, Letters
Outward which is a browser for the letters we have written and has
grown a few other functions around that in presenting patient info,
and a couple of other things, and I don't feel they all have to be
brought into one whole.
It is easier to teach people to write medical logic modules in an easy
language than a hard one. If speed turns out to be a problem, then
code that is running can be reimplemented in assembler or C or
whatever.
But there is a lot to be said for making doctors aware of the
possibility of directly handling their own data, and a C course is not
the way to start that.
--
Midgley
