使用 Tcl/Tk 制作桌面应用程序原型的优缺点
我已经开始使用 Tcl 制作桌面应用程序原型，并打算向一些风险投资家展示这个想法。 桌面应用程序和 Tcl 都不流行，因此我想准备好应对对此技术的任何反对意见。 以下是我所看到的优点，我确信我期待着充实大量缺点，但希望还有更多优点。
- 我最初开始在去年的一份雇佣合同上使用 Java 编写一些类似的代码，并且出于法律原因希望使用一种完全不同的语言来区分我的工作
- 虽然目前的代码作为命令行脚本运行，但需要应用一个 UI，Tk 对于原型来说就足够了，而且 Tk 与 Tcl 紧密集成。
- 由于我总体上远离 Java，因此我预见到“生产”（而不是原型）、UI 是用 C++ 编写的。 Tcl 很容易嵌入到 C++ 应用程序中，因此在将性能关键部分移植到 C++ 之前，底层的 TCL 引擎最初能够嵌入，
我知道潜在的缺点是“Tk UI 很丑陋”，但是如上所述，Tk UI 将是一个原型，无论如何，Tk 是丑陋的问题已经由你真正提出了： 为什么 Tk GUI 被认为丑陋？
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.
- 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
- 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.
- 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: Why are Tk GUI's considered ugly?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Tcl/Tk 在很多方面都表现出色。 第一，在很短的时间内开发工作原型非常容易。 第二，Tcl 社区比任何其他语言都更好地解决了分发问题。 如果这对您很重要，请阅读 starkits 和 starpacks。 Tcl 对虚拟文件系统的内置支持以及将所有内容打包到单个可执行文件（或单独的应用程序和平台相关的运行时）中的能力是首屈一指的。
Tcl 也将 unicode 嵌入到核心中（并且已经存在相当长一段时间了），这与某些脚本语言不同，在某些脚本语言中，unicode 似乎是事后添加的。 再加上良好的消息目录支持，使得国际化和本地化变得相当容易（从右到左的语言除外）。
如果没有有关程序确切性质的更多详细信息，很难说为什么 Tcl/Tk 可能是适合您的解决方案。 它并不适合所有产品，但许多人会对 Tcl 擅长的事情之多感到惊讶。
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.
我准备的风险投资问题是：
“你将如何为此招聘人员？”
我个人的经验是，一种语言的招聘情况（数量和质量）往往比语言特性本身更重要。
还要小心地使用需要更多技能的解决方案来捍卫自己的立场，例如嵌入解释器、多语言项目、运行时的更改等。这又是因为技术人员是瓶颈。
PS 我个人拒绝所有非本机 GUI。 所以我也有一段时间讨厌Java。 但我想这在用于原型设计时并不适用。
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.
Tk 拥有主题 GUI，并且已经拥有它们很长一段时间了。 让 TK GUI 看起来接近原生非常容易。 TK 对系统资源的占用也相当小（当然比 Winforms 更快、更小）。
Tcl 的关键论点是将其用作应用程序的脚本和扩展机制。 如果您使用内置 Tcl 解释器用 C++ 编写应用程序，并且可以从 Tk 获得您想要的内容，那么您很可能能够使用其自己的脚本语言编写应用程序的重要部分。 这将比编写本机 C++ GUI 更快、更容易。 然而，Tk 的功能并不是特别丰富，因此在投入使用之前，您希望能够放心地做您想做的事情。
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.
不要将“丑陋”的原型骗局视为只有一个骗局。 与非程序员交谈时，它算作 5 或 6 个缺点： 通读一遍，我的观点在那里
如果不知道程序的性质，就很难更具体。
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.