Pros and cons for prototyping a desktop app with Tcl/Tk

Question

I've begun prototyping a desktop app with Tcl and intend to present the idea to some venture capitalists. Neither desktop apps nor Tcl are in vogue and so I want to be prepared to counter any objections to this technology. Below are the pros as I see them, am looking forward to fleshing out plenty of cons I'm sure, but hopefully some more pros as well.

1. I originally began writing some code along the same lines on a contract for hire last year, using Java, and want to use an entirely different language to differentiate my effort, for legal reasons
2. Whereas the code at present runs as a command line script, it will be necessary to apply a UI, for which Tk will suffice for a prototype, and Tk is tightly integrated with Tcl.
3. Since I'm staying away from Java in general, I foresee the "production", as opposed to prototype, UI being written in C++. Tcl is easily embedded into C++ apps, so the underlying TCL engine will initially be able to be embedded, before porting performance critical sections to C++

I understand a potential con is "Tk UI's are ugly", however as stated above, the Tk UI will be for a prototype, and anyway, the Tk is ugly issue has been raised on SO already by yours truly: http://stackoverflow.com/questions/349409/why-are-tk-guis-considered-ugly

Answer 1

Tcl/Tk excels at several things. One, it's pretty easy to develop working prototypes in very short order. Two, the Tcl community has solved the distribution problem better than just about any other language. Read up on starkits and starpacks if this is important to you. Tcl's built-in support for virtual file systems and the ability to package everything into a single executable (or separate app and platform-dependent runtime) is second to none.

Tcl also has unicode baked into the core (and has had for quite some time), unlike some scripting languages where unicode appears to be a tacked-on afterthought. That, combined with decent message catalog support makes internationalization and localization pretty easy (except for right-to-left languages).

Without more details about the exact nature of your program it's hard to say why Tcl/Tk might be the right solution for you. It's not perfect for every product but many people would be surprised at just how many things Tcl is good at.

Answer 2

Don't take the "ugly" prototype con as being only 1 con. It counts as 5 or 6 cons when talking to non-programmers: read all the way through, my point is in there

Without knowing the nature of your program it is hard to be more specific.

Answer 3

The VC question I'd prepare for is:

"how are you going to hire personnel for that?"

My personal experience that the hiring situation (both quantity and quality) for a language is often more important than the language features themselves.

Also be careful to defend your position with solutions that require even more skill, like embedding interpreters, multilingual projects, changes of runtimes etc. This because, again, skilled personnel is the bottleneck.

P.s. personally I reject all non native GUIs. So I hated Java for quite some time too. But I guess that doesn't apply when used for prototyping.

Answer 4

Tk has themed GUIs and has had them for quite a while now. It's quite easy to make a TK GUI look close to native. TK is also fairly easy on system resources (certainly faster and smaller than Winforms).

The key argument for Tcl is to use it as a scripting and extension mechanism for your application. If you write the application in C++ with a built-in Tcl interpreter and can get what you want from Tk you might well be able to write significant chunks of the application in its own scripting language. This will be quicker and easier than coding a native C++ GUI. However, Tk is not particularly feature-rich, so you want to be comfortable that you can do what you want before committing to it.