Updated 2011-07-04 22:08:51 by RLE

[...]

http://msdn.microsoft.com/vbasic/

A surprising number of people automate VB applications with Tcl.

TclBridge greatly eases work with VB.

TCLBRIDGE is pricey at $1825 for enterprise and $625 for 1 pro user

kennykb writes on comp.lang.tcl:

Perhaps the best head-to-head comparison of Tcl and VB in the context of adding GUI to a legacy engineering application was written by no less a light than Brian Kernighan (co-inventor of C, among his multitude accomplishments). You can find it at: http://www.usenix.org/publications/library/proceedings/tcl95/kernighan.html

And Marty Backe replies:

The postscript version [of the article above] is > 11 MB. I've created a pdf version of it (~200KB) that can be gotten from here: http://www.lucidway.org/Marty/Tcl/Docs/kernighan.pdf

HJG 2005-08-30 This page asks for username & password

AMG 2005-09-02 Mirror! http://andy.junkdrome.org/devel/tcl/kernighan.pdf . Thanks Marty for emailing me your copy; I will host it for you and everybody.

2007-10-23 - this link is now gone too ... has anyone got this paper?

AMG: I do. :^) I just updated the link.

A nice Cheat Sheet for moving from VB6 to Tcl here: http://sourceforge.net/docman/display_doc.php?docid=11951&group_id=10894 RS: Hm, interesting.. but even on A4-Landscape, I can't print it decently...

LES: if that is still useful to anyone (two years later!), here [1] is a remodeled page, and here [2] is this remodeled page in PDF.

[tgggg] 2010-01-07 Cheet Sheet link is on the web archive at http://web.archive.org/web/20080406073215/http://sourceforge.net/docman/display_doc.php?docid=11951&group_id=10894

WJP Also, butt-ugly. There's a very nice comparison of Tcl with VB in Brian Kernighan's paper Experience with Tcl/Tk for Scientific and Engineering Visualization [3] That's about as definitive as you can get. (In case you were wondering, Tcl wins.)

EKB I read Kernighan's paper with interest. It's really nice (although woefully out of date by now). It gives a balanced appraisal of several languages. But I don't think it's correct to say that "Tcl wins" out of the VB/Tcl comparison. Kernighan's own summary:
 As a rough summary, for the specific  purposes  I  have
 used  it  for,  Visual  Basic  is  significantly better than
 Tcl/Tk for the purely visual part (creating the interface on
 the  screen  and  having  it look somewhat like a commercial
 product), worse for programming, and  extremely  unsatisfac-
 tory  for  interprocess  communication.  Each is the easiest
 interface-building tool in its native environment.

peterc 2010-08-04: I would imagine the introduction of Tcl's Tile themed widgets since then would greatly swing the balance as far as the "visual part" goes.

Peter Newman 5 September 2005: I read Kernighan's comparison. And to me, he's bang on the money. Visual Basic really doesn't have anything over Tcl/Tk, except as regards the user interface builder - and the whole integrated development environment.

It's definitely quicker and easier to put a simple, primarily GUI, app. together with Visual Basic, than it is with Tcl/Tk.

But, it seems to me, that creating a Tk version of Visual Studio would be pretty trivial. Too much work for one person to do alone perhaps. But quite easy if broken down into nice easy little "fun weekend projects". If, say 10+ people were involved, and everyone documented their code properly, so others could easily upgrade and add to it, then it seems to me we could have something quite useful.

What's particularly nice about VB, is that you just write your code. And then press F5. At which points it create the executable, and runs it for you to test. Sweet as. Imagine if we could do that with Tcl/Tk. And end up with (say) a TclKit, Starpack, Freewrapped app., or even a Nullsoft installer type app., with no more than a button click/press.

Nothing too hard to do. All it requires is a few willing hands. And some clear top-down design, discussion and agreement on features, etc - before anyone starts coding.

EKB I'd be interested in this. There are a few tools like this listed on GUI Building Tools, but most of them are out of date, and although I've tried a few, none have really worked for me. The biggest block for me is that I want to be able to turn on and off different packages. Most of the GUI builders come with a particular set, so I can have BWidgets (which I like), but not BLT (which I absolutely require).

A place to start might be to look at existing tools for Tcl, as well as existing tools for other languages (e.g., Visual Studio, Borland's tools) to kick off a requirements spec.

Peter Newman 6 September 2005: Yeah, to me, specing it out properly, with lots of input from people as to what's needed, etc is the important thing. To come up with a good design, and one that breaks down into lots of small modules, each of which can be easily put together by one person, and then the whole lot combined. And also, lots of willing hands, of course.

And as you say, looking at the existing tools, to try and discover what's important. And what the best way of doing things is. To me, the thing that's interesting about Visual Basic (cf Tcl/Tk), is the Visual Studio development environment. That's also used for Visual C. I personally doubt that I would have designed an IDE this way. But it's not that bad to use. And it's popular; arguably the most popular development environment in the world. I suspect that both Visual Basic and Visual C would virtually disappear without it.

So, if you're going to design a development environment/IDE, then Visual Studio is probably a good model to base your design on. It's one of the few things that Microsoft seem to have got right.

EKB I think Tcl benefits from having a lot of different tools to do different tasks. Although in the long run it may be helpful to have one monolithic IDE, as a first step, I'd like an extensible GUI builder. Off the top of my head, I'd want:

  • Clean code generation, with a clear separation between automatically generated code & user code (so you can adapt the code and still reload it in the GUI builder, within reason)
  • Support for arbitrary widget collections
  • Use the ability of grid & pack to support easy resizing, while also allowing use of place
  • Support for Tile (which seems to be a different beast than other widget sets...?)

To support arbitrary widget collections, what I'm picturing is that the basic software wouldn't care what widget set you use at all. All it needs is a config file with metadata that describes a widget or widget set. Then the GUI builder uses the metadata. This should make it possible to continue using the GUI builder even if new widget sets appear.