TCL/TK vs VISUAL BASIC
Arnold deVos
Richard Brodie wrote:
>
> After writing 20,000 lines of TCL code in a factory test
> application setting, I am being asked to come up with an
> answer to the question: "Might it not have been better to
> have written all of this in Visual Basic?" Having never
Well, here's my 2cents worth on this (BTW I've dabbled in VB and written
maybe 20k lines of tcl over the years):
I like the Tcl language, especially its "reflexive" nature and its
simple, generalized structure. But these features can make for a
debugging nightmare. Sometimes it seems that every mistake I make is,
nevertheless, valid Tcl with a novel interpretation. I can live with
this but its not for everybody.
Here are some more points:
Pro Tcl:
- The full (non-beta) releases of Tcl are much more robust than VB.
(Perhaps because its a lighter weight system overall)
- Tcl is a much more powerful language than VB.
- Its hard to beat the functionality of Tk text and canvas widgets.
On the other hand:
- VB has a full blown development environment around it (with real
debugging!)
- VB as a language is easier to understand (there is no "quoting hell")
- The interfacing possiblilies available in the latest VB releases via
OLE seem to be extremely good.
- As a general statement, VB is faster. If you are dealing with a
thousand icons on a Tk canvas you have to be very careful how you handle
them. Less so with a similar situation involveing a TreeView in VB.
All of this is just IMHO.
--
Arnold deVos
Seattle
WA USA email: a...@seanet.com
Tony Lownds
Richard Brodie wrote:
...
> 2. Visual Basic is a "commercial" language, and therefore support
> for it (upgrades as well as technical help) is something one might
> expect to be able to bank on with greater certainty than would be
> the case with free- or share-ware.
My experiences with Microsoft's support indicates that this is not the
case... for instance, with MS's push for Win95, they just dropped VB3,
and now it costs $95 to report a bug for that platform. Also, you have
to deal with VBX and OCX vendors at the same time, most of them small
companies with poorly implemented support systems.
Even with these issues, Visual Basic is still a great RAD tool if you
can trade non-portability and ugly implementations for speed of
development. Consider putting a VB base underneath your project, and
then you can use the strengths of TCL/Tk and those of VB together. With
a VB base you can make a nice development and distribution system, and
let features be implemented in TCL/Tk or VB, whichever is easier for the
programmer on that job.
We added a basic scripting tool (BasicScript) to our main project, a GUI
client for a engineering information database at Unisys, and it was a
great design decision. Implementing features in a script is as
controlled (if not more) as in VB, and our power users add some of thier
own features, all distributed with no effort through a shared database.
Now that its in there, the next overhaul of our project (management
willing) will include a script development and distribution system from
the first release. The script code may be the only thing that will carry
over without an overhaul from the previous version...
-Tony Lownds
Eric Vought
> 2. Visual Basic is a "commercial" language, and therefore support
> for it (upgrades as well as technical help) is something one might
> expect to be able to bank on with greater certainty than would be
> the case with free- or share-ware.
>
> reliable and bug free.
These last two are very common misconceptions with commercial versus
free software.
First of all, with many free software packages, upgrades and bug fixes
are much more rapid. The main reason for this is that free software, by
its very nature is non-proprietary and can therefore be developed in a
much more open environment. These means more thorough testing in much
earlier stages of development. It also means that the end users are free
to look through the source code, find the problem, and submit patches,
something which significantly speeds up the bug fix process and which
just can't happen in a commercial environment. Of course, this also
means that the end user can always modify the code to meet their own
needs if the developers are not responsive to a particular problem. If
you have a problem with Visual Basic that Microsoft won't fix (or won't
fix until the next release...), you are stuck, but with Tcl, you have
the option of going to the code or of talking to other users who may
have gone through the code already and may have a workaround.
Technical support differences are complex. With popular and
well-maintained free software, like Tcl and Linux, the level of
technical knowledge available on the newsgroups are very high. Chances
are that the actual code writers are monitoring the newsgroup and may
answer questions if experienced users don't answer first. They will also
often correct or clarify answers from other users. However, the level of
sophistication of the user is expected to be higher, for the most part.
The newsgroup members will expect the end user to have read manuals and
release notes and will sometimes respond to a question simply by
refering to manual entries (e.g.: RTFM "grid"). This is good and bad. I
don't know how many times I've called up commercial tech support and had
someone on the other end that was hired just for technical support read
a paragraph to me verbatim from the manual I have in front of me, and,
when pressed, was able to offer no other information. That doesn't
happen on a newsgroup for the most part.
On the other hand, you won't be coddled on comp.lang.tcl, and if your
coworkers get offended by someone asking them to (shudder) read the
release notes, rather than looking the answer up for them and posting
it, you probably should go with Visual Basic. Anecdotally, a software
maintainer posted on some newsgroup a while or so back complaining about
an email message they had received asking for an answer to a programming
question--- they wanted the answer in a particular format, mailed to a
particular address with tested and debugged examples. The answer to the
question was covered in a FAQ listing. The maintainer deleted the
message and never responded. I've heard several anecdotes like this.
So, the bottom line is, tech support for free software works and works
well, but only if the end user is willing to excercise intelligence and
do a little work on their own.
Robin Becker
I've also written in both TCL/TK & VBA (visual basic for Apps) I come
out generally in favour of TCL/TK
TCL/TK
+ It's fairly light weight
+ You can add it to your own code
+ It has the concept of a path ie autoloading
+ You can widget twiddle ie get the desired functionality
+ There's lots of expertise around on the net
+ executing external apps is easy under unix systems
not so good yet under Win32
+ There's lots of documentation; in the worst case you can
check out the code.
- Version changes can be a nightmare
- installations are often quite gothic, each extension makes
different assumptions about where libraries etc should live.
- pure tcl is quite slow
- users are often unfamiliar with the widget functionality
I have difficulty in getting people to double click in
graphs or use button 2 (forget the middle button we're
in Gatesville).
- object programming is primitive. I've used itcl obTcl and looked
at stooop, but none are entirely acceptable. I think the main
problem is that tcl objects have to be procs, which presumably
have to be global in scope. Plea to Ousterhout et al what about
local procedures?
VBA
+ It has a rather poor debugging environment since windows
have to be on top before they get messages, communication
and debugging can be complicated.
+ users feel familiar with the widgets
+ In Gatesville there's only one way into GatesApps &
this is a GatesLang with GatesFunctionality. I don't
fancy my chances at programming a widget which will work
across all GatesPlatforms.
- The class heirarchy was invented by a programmer from hell
- You're limited to the builtin widgets + any arbitrary set
of conforming provided ones from dlls
- If you use dlls you take responsibility for locating these
which makes life difficult moving from PC to PC
- Win95 behaviour is different from Win31 is different from NT
- There's zero real expertise; since VB & VBA are so new and they
live in a continually changing environment dominated by
commercial considerations most programmers are always on the
wrong side of the learning curve cf ODBC OLE OLE2 etc etc
- Documentation is poor, since VB & VBA are designed to be for
everyone, real details are often hidden.
- I'm not sure about this one, but I think it would be very
difficult to add VB to an existing App as an extension language.
--
Robin Becker
Robert Heller
Richard Brodie <bro...@epg.sdd.hp.com>,
In a message on Fri, 02 Aug 1996 16:06:29 -0700, wrote :
RB> I suppose the main objections to TCL are the following:
RB>
RB> 1. Most other sites use Visual Basic. While this may be less
RB> a consequence of its functional superiority or greater natural
RB> appropriateness, and more just the result of being more widely
RB> known and used, nevertheless there are potential advantages to
RB> widespread use having to do with easier maintenance (support
RB> programmers could be transferred without having to learn a new
RB> language) and technological transportability.
RB>
RB> 2. Visual Basic is a "commercial" language, and therefore support
RB> for it (upgrades as well as technical help) is something one might
RB> expect to be able to bank on with greater certainty than would be
RB> the case with free- or share-ware.
*MY* Experience with "commercial" packages vs. "freeware/shareware"
packages has resulted in a some conclusions (not necessarily
universal).
One of the things I have noticed: sometimes you want to do something
with a software package that the people who wrote the software package
did not think of. With a commercial package you might be stuck. You
*might* be able to to talk the maker of the package into making the
changes needed, but you might have to wait for a new release. And maybe
the changes are not *exactly* what you would have wanted and might not
do things in the way you want. With a freeware package that comes with
source code, the sky's the limit. Actually, Tcl/Tk was in fact written
with the idea of extending it in many ways.
RB>
RB> 3. Visual Basic has been around longer and thus is probably more
RB> reliable and bug free.
RB>
I can toss out counter examples -- i.e. a commercial system that has
been out longer NOT being more reliable or bug free than a younger
freeware package. Software does not necessarily improve with age.
Sometimes it gets worse, usually because some "quirks" get hardened into
the package for "downward" compatibility. Or because some early design
"error" prevents certain kinds of fixes or functionality and this design
"error" can't be removed without causing a massive amount of code breakage,
which a commercial software house might want to avoid (being fearful of
losing customers).
RB>
RB> Some advantages of TCL are:
RB>
RB> 1. It is interpreted rather than compiled and can thus be modified
RB> very rapidly, thereby shortening development time.
RB>
Yes, this is a very big advantage.
RB> 2. Technical help is not only free, as is the software itself, but
RB> is available on-line, usually near instantaneously, from a vastly
RB> varied user community.
Something harder to get for a commercial package.
RB>
RB> 3. Programmatic control (as opposed to the compositional straight-
RB> jacket of a graphical interface) results in the ability to more easily
RB> modify layouts, as well as to generate some complex effects that might
RB> not otherwise be feasible or even possible.
Very definitely.
RB>
RB> I welcome any comments, extensions, or criticisms you may have on
RB> the above observations based upon your own experience.
I have recently been converting a large Quick BASIC program to Tcl/Tk
and noticed some things. Some of the Basic code was doing some "dumb"
things, mostly because there are things you just cannot do in BASIC, but
which are easy to do in Tcl/Tk. Things like sparse arrays and array
indexes that are not integers. To get around these things the BASIC
program ended up doing some less than optimal sorts of hacks. I don't
know if Visual BASIC is any better than Quick BASIC or not, but you
might find some things harder to do in BASIC that are easy to do in
Tcl/Tk. (The reverse might also be true.)
--
\/
Robert Heller ||InterNet: Hel...@CS.UMass.EDU
http://vis-www.cs.umass.edu/~heller ||FidoNet: 1:321/153
http://netmar.com/mall/shops/heller /\
Eric Johnson
Richard Brodie wrote:
> First, just a brief overview of what has given rise to this
> concern. We are dealing with a brand new factory, preparing
> to produce a brand new product. I began on a Windows 3.1
> platform, but had to convert to Windows 95 when it became
> apparent that TCL did not have the built in I/O to be able
> to communicate with serial test guages, and that I would have
> to extend TCL using references to 32-bit C I/O functions.
> (The documentation that came with these guages, gave examples
> of straightforward BASIC communication).
> ... a general concern began to
> grow that somewhere there was a "robustness" problem.
Richard,
Although this will increase your cost per station, I'd
suggest you migrate from Windows 95 to Windows NT, whether
you use Tcl or Visual Basic. I've seen too many problems
with Windows 95 in general to really trust it for a
factory automation system.
If you stick with Tcl, you'll find that it works better on
Windows NT, too--an added benefit. I know how much cost
is an issue (I spent 5 years working on factory automation
systems), but I've seen too many unexplained crashes of
Windows 95 to really trust it. NT is generally better on
these issues.
Good luck,
-Eric
--
Eric F. Johnson URL:
http://ourworld.compuserve.com/homepages/efjohnson/
CAMAX Manufacturing Tech., Inc.
7851 Metro Parkway phone: +1 612 854 5300 fax: +1 612 854
6644
Minneapolis, MN 55425 USA email: john...@camax.com
Bryan Oakley
Richard Brodie wrote:
>[snip]
> I suppose the main objections to TCL are the following:
>
Hmmm. What if you find a flaw in visual basic, and upon submitting the
flaw to Microsoft they say "yeah, we know but we won't come out with a
fix for that because it doesn't affect very many people" (or some other
lame excuse). Or, not much better, "that fix is scheduled for release N
in the second quarter of next year". You're stuck. OTOH, with Tcl you
have the option of patching the source code yourself.
>
> 3. Visual Basic has been around longer and thus is probably more
> reliable and bug free.
Hmm. I'm not so sure about that. That may be true or it may not -- tcl
and tk have been around for many years (though for most of it's life it
was a unix only product). In the preface to Dr. Ousterhout's book he
wrote "In the spring of 1988 I decided to implement such a language, and
the result was tcl". So, in one way, shape or form tcl has been around
for 8 years. Hasn't Visual Basic only been around since '92 or so?
Also, one might argue that visual basic was developed by a large
corporation with a history of buggy products, whereas tcl/tk was
developed by a few dedicated and highly talented individuals, so it is
bound to be more reliable and bug free. But that's just the Microsoft
basher in me talking.
--
Bryan Oakley, Software Engineer
Healthcare Communications, Inc.
oak...@healthcare.com
Peter da Silva
One comment: Tcl has been around longer than Visual Basic, and about as long
as the specific variant of Microsoft Basic that Visual Basic is derived from.
--
Peter da Silva (NIC: PJD2) `-_-' 1601 Industrial Boulevard
Bailey Network Management 'U` Sugar Land, TX 77487-5013
+1 713 274 5180 "Har du kramat din varg idag?" USA
Bailey pays for my technical expertise. My opinions probably scare them