Autocoding project proposal
This posting is to introduce or suggest an open source software project
to produce a core tool that will allow an autocoding environment to be
developed, allowed to evolve in the open source software community and
spirit of. I believe we can overcome many of the problems that proprietary
autocoding systems inherently have (not to mention that existing
autocoding systems appear to be field/domain specific limited and that
it may be possible to beat this too.)
First:
Ghostscript PDF viewers for the following PDF links (if you don't already
have a PDF viewer) http://www.cs.wisc.edu/%7Eghost/
The following information represents what is probably the best of what is
available thru the Web on the subject of autocoding. (via google)
HIRTS DARP Working Group on Autocoding, 18th, 19th April 2000
http://www.cs.york.ac.uk/hise/darp/pdf/autocoding.pdf
(Brings up various issues which will help you focus in on what
"autocoding" is and what some of the issues to solve, are.)
The follow up to the above is:
May 8th thru 10th, 2001 "DARP HIRTS Workshop" paper by Jakob Engblom:
http://www.artes.uu.se/mobility/reports/hirts_report1.0.pdf
(See pages 5-6 section 3.2.5 The Use of Tools in Aerospace)
In summary, Though autocoding is being used to some extent, it is a
future hope, since in general it has a bug density which is an order of
a magnititude lower than manual code. Point being is that this is
leading edge stuff, an opportunity for OSS to shine.
The above paper mentioned the SCADE autocoding product:
http://www.esterel-technologies.com/scade/
(See code generator part of Product overview, Benefits, Toolset Features)
Autocoding as it applies to the medical industry:
http://www.ahima.org/journal/coding/coding.0110.1.htm
(Since it was mentioned in a paper above, know it's a product of a
different nature.)
To help show why I believe OSS efforts can shine when it comes to such a
project as Autocoding:
QinetiQ - Analysis of the Impact of Open Source Software
http://www.govtalk.gov.uk/interoperability/egif_document.asp?docnum=430
and From the Conference on the Public Domain, Nov. 9-11. 2001 at Duke Law
School "Coase's Penguin, or, Linux and the Nature of the Firm" by Yochai
Benkler: http://www.law.duke.edu/pd/papers/Coase%27s_Penguin.pdf
It is also worth mentioning, to my undersandng, that the GNU efforts are
becomming more modular in nature and there is also the Hurd that is
modular or componet based from the ground up. This is a consistant and
fitting direction in accord with an open autocoding development and use
environment.
OK, so although this project is not AeroSpace "Mission Critical", it does
not hurt to make the quality target of the project to be of such high
standards. Actually, what I believe is that the core (as mentioned at the
beginning of this post) can be made to be of high quality itself, where
the rest, the coding knowledge base or what ever you want to call the
pre-autocode dictionary, will be of whatever quality it is created and
improved to be (as is the way and spirit of the OSS community.)
Where to start?
Automating what was done manually requires the identification of, and
ability to apply, the manual action set we use, but have the computer do
it. A USPTO Published comment introducing these identified actions and
suggestions of how they may be applied, including autocoding, is here:
http://www.mindspring.com/~timrue/KNMVIC.html
The bottom part of my home page regarding the
"Virtial Interaction Configuration":
http://www.mindspring.com/~timrue/
An older paper on the Virtual Interaction Configuration:
http://www.mindspring.com/~timrue/KC.html
Why don't I do this shell and/or library myself?
I don't consider myself a programmer having the experience and knowledge
of better ways of coding somethings and as such I'm sure this core of
functionality can be coded better and faster than what I could do, but
there is what I have done, and that includes some python programming that
can be used and run to show/communicate some of the concepts of the
Virtual Interaction Configuration. And I can provide insight as to how it
may be used for such things as autocoding. Until recently, this past
week, I wasn't aware "autocoding" was an actual goal and practice of
anyone, though I have used the term for sever years now, and apparently,
given the above HIRTS DARP papers, my perspectives and thoughts on the
matter have been along the lines of what's been going on. Though I do
believe The VIC as a core can solve some of the problems facing commercial
autocoding packages (but this is something to get into later, when I can
communicate but showing).
Besides the VIC core, there is the pre-automation code base(s) to create
for whatever programming language(s) people want to use. And that's
something clearly beyond my ability to directly do, at least in the
beginning. Besides, there are many other things the VIC can be used for
besides autocoding. Consider it a tool for general automation...
At any rate I do believe Autocoding is a worthwhile goal that the GNU
community can shine at. And I think some of you, in consideration of the
HIRTS DARP link contents and the USPTO comment, will too.
If interested in helping, email me at mailto:threeseas@earthlink.net
If interested in using such a tool, then say so here, let others know.
Reply to: