Re: [RE: emc really needs ] Design and Tcl/Tk

[Ray <rehenry-at-up.net>]

Folk

I'm focusing on a small part of this -- hence the drift in subject line. 
I also don't find significant conflict between what I've said below and
the recent wish/design lists of others. 

On Sun, 19 Nov 2000, Paul wrote:
> As a front-end to write the UI in, Tcl/tk is probably the only real multi
> platform language. But it can be dreadfully slow when it comes to doing any
> maths intensive routines. The advantage of Tcl/tk is the ability to code new
> functions and rewrite old ones in another language.
> 
> For Graphical Interfaces and basic data processing - simple sort, string
> matching, integer maths - Use Tcl/tk.
> If it involves floating point maths or large data sets - Use something that
> avoids the tcl overheads.

I'm an amateur when it comes to Tcl/Tk but I am impressed with it's
ability to serve as a visual traffic cop.  The string handling commands
work very well to build or rip apart strings that can be passed to quicker
processing routines.  It is also very fast to write and try processes that
can be later written using a more appropriate language.

It is an easy language to read and begin to use.  It took me about two
weeks of hard study, long hours, and experiment to write the first
backplotter for the EMC.  I think that it took Paul two hours to extend it.
I know that my newbe status shows in my code but it was a brute-force
attempt and it worked. to show the tool path.  And it worked to spark
evolution.  These languages are relatively easy to get into and work with.

Paul and I have both found the language to be dreadfully slow, and a
processor and memory hog when you want it to compute and manipulate
vectors.  I'd avoid it like the plague for the math that is required to
generate visuals.  But three lines of code will build a variable menu
that can start up, source, or communicate with any one of an
entire directory full of routines  Two more lines of code and you can
automate and entire menu structure for an application or change it at the
whim of the user or programmer.  It takes one line of code to start
multiple language independent routines and pass data through them.  I think
it's in this arena that Tcl/Tk shines.  

But there is more because the common interfaces to Tcl/Tk, tclsh and wish,
can be customized one time, by someone who knows how, and they will
provide most any additional service that you need.  The emcsh and iosh in
the EMC are examples.  They provide connections to NML-- EMC's base
language.  Using these shells with our new CAD/CAM package and tcl, would
allow EMC functionality directly from the menu of the CAD/CAM screen. 
Similar connectors could be written for HPGL or any other system for which
we can find or intuit specs.  So if your system uses COM or CORBA or
PUTS/GETS or Afghan....

Tcl/Tk also provides for an easily functioning, automatically updating
library of it's own language extensions.  It can grow and manage that
growth with a single command.  Copying and building in additional
commands can be as easy as cut and paste.

There are a number of portability issues with Tcl/Tk code across OS's but
there are lots of folk working on lots of Tcl/Tk apps that need
portability.  Work arounds are well established and show up quickly for
the latest barriers set up by proprietary OS companies.  As Tcl/Tk
evolves, these issues get resolved within the language itself so that (/)
and (\) are interpreted correctly and (pwd) returns useful information
for the system that is being used.

Finally, It would be possible, soon, for us to begin to work on visual
aspects of the app.  Even before many of the features have been written or
designed. (This may bait some folk)  To use one of Matt's examples here.
It would be possible to make the snap_to menu and buttons before the
functionality was firmly in place.   Then some aspects of snap_to could be
enabled before "cen" on the command line had been coded.  I'm sure that
there will always be tension between the existing code base and the
evolving design document. <collective shrug - I hope> 

Since the above thoughts may go past some like sandpaper I'll refer to
earlier design comments.  As several have said, you can fall off that wagon
many different ways.  So I'd like to have the start of a visual screen,
and a comprehensive help file/directory/spec right from the get-go.  They
become a visual from which those of us that are word-impaired can watch the
project grow.  And they become a way for all to see what is done, what is
being done, and what needs to be done to move the project ahead.  It is my
opinion that Tcl/Tk would do such a job in a reasonably efficient,
flexible, and readable manner.  

So.  I'd like to see us start by accepting Tcl and perhaps iTcl as the core
Tool Command Language, accept TK and perhaps it's extensions as the core
gui language, and write some concise English on how we will write them
and use them within this project.  This will also determine some of the
file structure that we will use.

Just my 2 cents, and yes, you can respond that I ought to take a breath!

-- 

Ray