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:[EMAIL PROTECTED] If interested in using such a tool, then say so here, let others know.
