[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Autocoding >Re: Multiple Languages v. Multiple Paradigms

On 08-Mar-02 18:26:13 Michael Vanier <mvanier@cs.caltech.edu> wrote:

 MV> ...  To be
 MV> able to use libraries written in another language transparently
 MV> and with little or no additional cost relative to what the user
 MV> of the language it which the library was written would face would
 MV> be a huge win.  Being able to use a surface syntax that was
 MV> optimal for the task at hand would in many cases be a major win.
 MV> But the semantics are really the big issue.  Different languages
 MV> have different strengths and weaknesses, and I have long since
 MV> stopped believing in an uberlanguage that could do everything as
 MV> well or better than any other language.  To give one example:
 MV> garbage collection is incredibly useful in the sense of making a
 MV> programmer's life easier. Direct pointer manipulations (like in
 MV> C/C++) can be used effectively to make speed-critical code much
 MV> faster.  These two language-related features do not live well
 MV> together.  You can do GC in C/C++ with conservative garbage
 MV> collectors, but there are tradeoffs that you would not have to
 MV> deal with in a language that doesn't have pointers.  Similarly,
 MV> there appears to be some fundamental tensions between
 MV> statically-typed and dynamically-typed languages, between
 MV> statically-typed functional programming languages and
 MV> statically-typed object-oriented languages, and so on where there
 MV> is no one perfect way to do things.  This may be because we
 MV> haven't found the right approach yet, or because there are
 MV> fundamentally irreconcilable semantic differences between
 MV> programming languages.  I think the latter is more likely to be
 MV> the case.  If so, then it makes sense to be able to code
 MV> different parts of an application using the language with the
 MV> appropriate features for that part, which leads us to the issue
 MV> of inter-language unification.  To do this well, if it can be
 MV> done well, is a major challenge for the next generation of
 MV> programming systems.

 MV> Mike

You cannot solve a general language problem by creating another language.
It's the Turing Halting problem and Godel's Theorem

But there is another approach, not a language but action set for
automation of language use and translation. The gears and bearing of

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

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
(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:
(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:
(See code generator part of Product overview, Benefits, Toolset Features)

Autocoding as it applies to the medical industry:
(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

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

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:

The bottom part of my home page regarding the
"Virtial Interaction Configuration":

An older paper on the Virtual Interaction Configuration:

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.

There are nine action constants and by identifying them in what we do, by
super-imposing or overlaying these actions upon what we do, we can
identify the automation points. With this, we can automate what we do
thru computers, including programming. And what is programming but the
automation of complexity that is made up of simpler things, done so to
make the use and reuse of such complexity easy for the user.

What language you use is perhaps more a matter of interfacing to a process
that eventually is translated into machine readable form, binary machine
code. Mixing and matching languages for the best of effect shouldn't be a
problem as it eventually gets converted to the machine code common. But
understand that this is not a new language or a replacement of languages,
rather a tool set to allow the automation of language use. I.E. automating
the do's, don'ts and standards in any language as well as any dynamically
repeatable sequence of functionality.

Certainly everyone does understand in reading and responding to posts
here, they actually make use of all nine action (the crew of the
Nebachadnezzar [each persons ship]).

It's physics!

Lets see now (using the metaphors of the movie "The Matrix"):

Switch (AI - alternate/activate interface) - start and stop, change
interfaces - Uh, start up Web Browser/newsreader/email client and connect.
Go to group, thread....

Apoc (PK - Place Keeper) - keep track of where you are - Pick up where
you left off on the thread..

Tank (OI - Obtain Input - Output to-> Input) - get input - read with eyes.

Mouse (IP - InPut set) - input from - internet and monitor

Dozer (OP - OutPut set) - push output to - via keyboard/mouse to Mailing
list posting.

Neo (SF - Sequence stufF) - one step at a time - damn this non-polyphonic
qwerty keyboard and mouse...

Morpheus (IQ - Intelligence Quotient) - what's the meaning of the post
I'm reading, what the meaning I want to respond with - within the (KE'd)
constraints of ....

Trinity (ID - IDentify) - identify posters and forum - hey there is one
by ____ in ____ forum, now I know to be (KE'd) constrained as to how I

Cypher (KE - Knowledge Enable)- constraints to apply to Morpheus (IQ)
meanings and Trinity (ID) poster named _____ and _____ forum and ____

Of course the three agents represent the three fundamental concepts of
INPUT, PROCESSING, OUTPUT. The nine above are an expansion upon them. Just
as in physics, the more details you have the greater the control.

Maybe it'd be a worthwhile exercise to ask others to give an example of
their use of the nine, in using computer or other non-computer related
things done?

There is something else that makes such a configuration of functionality
even more useful, beyond just programming and that is to supply the user
with the three primary User Interfaces. The CommandLine Interface, The GUI
and the side door to application/functionality external control. And
example that may be seen as the Amiga Arexx "Ports" found pretty much
standard in amiga applications, libraries and devices. But lets just call
it the Automation Programming Interface (API), as the general concept of
this "side door" exist in many different flavors and limitations usually
unfriendly in standard an ease of use.

But with all three accessible in a user friendly way..... Well if you
eliminat one of the primary colors of light (RGB) then the remaining
combination is far more limiting than -1/3 due to synergy of the three.
The same door of possibilities exist with the three primary user

If interested in helping, it's an open project, let me know.
If interested in using such a tool, then say so here, let others know.

Timothy Rue
Email @ mailto:timrue@mindspring.com
Web @ http://www.mindspring.com/~timrue/