Pro und Kontra zum Prototyping einer Desktop-App mit Tcl/Tk

Question

Ich habe mit dem Prototyping einer Desktop-App mit Tcl begonnen und beabsichtige, die Idee einigen Risikokapitalgebern vorzustellen. Weder Desktop-Apps noch Tcl sind in Mode und deshalb möchte ich bereit sein, Einwänden gegen diese Technologie entgegenzuwirken. Unten sind die Profis, wie ich sie sehe, ich freue mich darauf, jede Menge Nachteile zu entdecken, ich bin mir sicher, aber hoffentlich auch ein paar mehr Profis.

1. Ich begann ursprünglich auf einen Vertrag im vergangenen Jahr zu mieten einige Code auf der gleichen Linie zu schreiben, mit Hilfe von Java und wollen eine ganz andere Sprache verwenden, meine Bemühungen zu unterscheiden, aus rechtlichen Gründen
2. Während der Code an present läuft als ein Befehlszeilenskript, es wird notwendig sein, eine UI anzuwenden, für die Tk für einen Prototyp ausreicht, und Tk ist eng in Tcl integriert.
3. Da ich im Allgemeinen von Java weg bin, sehe ich die "Produktion", im Gegensatz zu Prototyp, UI in C++ geschrieben. Tcl ist einfach in C++ Anwendungen eingebettet, so dass der zugrunde liegende TCL-Motor wird zunächst in der Lage sein, eingebettet werden, bevor die Leistung der Portierung kritische Abschnitte zu C++

Ich verstehe ein Potential con ist „Tk UI ist hässlich“, aber wie gesagt oben, wird die Tk UI für einen Prototyp sein, und wie auch immer, die Tk ist hässlich Problem wurde auf SO bereits von mir erhoben: Why are Tk GUI's considered ugly?

Answer 1

Tk hat thematische GUIs und hat sie schon eine ganze Weile. Es ist ziemlich einfach, ein TK-GUI so aussehen zu lassen, als wäre es nativ. TK ist auch ziemlich einfach auf Systemressourcen (sicherlich schneller und kleiner als Winforms).

Das Schlüsselargument für Tcl ist, es als Scripting- und Extension-Mechanismus für Ihre Anwendung zu verwenden. Wenn Sie die Anwendung in C++ mit einem eingebauten Tcl-Interpreter schreiben und von Tk bekommen können, was Sie wollen, können Sie vielleicht auch wichtige Teile der Anwendung in einer eigenen Skriptsprache schreiben. Dies wird schneller und einfacher als das Codieren einer nativen C++ - GUI. Tk ist jedoch nicht besonders funktionsreich, deshalb möchten Sie sich wohl fühlen, dass Sie das tun können, was Sie wollen, bevor Sie sich dazu verpflichten.

Answer 2

Tcl/Tk zeichnet sich bei mehreren Dingen. Erstens, es ist ziemlich einfach, funktionierende Prototypen in sehr kurzer Zeit zu entwickeln. Zweitens hat die Tcl-Community das Verteilungsproblem besser als jede andere Sprache gelöst. Informieren Sie sich über Starkits und Starpacks, wenn Ihnen das wichtig ist. Die integrierte Unterstützung von Tcl für virtuelle Dateisysteme und die Möglichkeit, alles in eine einzelne ausführbare Datei (oder eine separate App und plattformabhängige Laufzeit) zu paketieren, ist unübertroffen.

Tcl hat auch Unicode in den Kern gebacken (und hat seit geraumer Zeit), im Gegensatz zu einigen Skriptsprachen, in denen Unicode scheint, ein angehefteter nachträglicher Einfall zu sein. In Kombination mit einer anständigen Unterstützung von Nachrichtenkatalogen wird die Internationalisierung und Lokalisierung dadurch erleichtert (außer für Sprachen, die von rechts nach links laufen).

Ohne weitere Details über die genaue Art Ihres Programms ist es schwer zu sagen, warum Tcl/Tk die richtige Lösung für Sie sein könnte. Es ist nicht perfekt für jedes Produkt, aber viele Menschen wären überrascht, wie viele Dinge Tcl gut macht.

Answer 3

Nehmen Sie nicht den "hässlichen" Prototyp con als nur 1 con. Es zählt als 5 oder 6 Nachteile im Gespräch mit Nicht-Programmierer: read all the way through, my point is in there

Ohne zu wissen, die Art Ihres Programms ist es schwer, genauer zu sein.

Answer 4

Die VC Frage, die ich bereiten würde für ist:

„wie wollen Sie Personal dafür einstellen?“

Meine persönliche Erfahrung, dass die Einstellung Situation (sowohl Quantität und Qualität) für eine Sprache ist oft wichtiger als die Sprachfunktionen selbst.

Achten Sie auch darauf, Ihre Position mit Lösungen zu verteidigen, die noch mehr Geschick erfordern, wie Einbettung von Dolmetschern, mehrsprachige Projekte, Änderungen der Laufzeiten usw. Dies, weil wieder qualifiziertes Personal der Flaschenhals ist.

Ps.s. persönlich lehne ich alle nicht-nativen GUIs ab. Also hasste ich Java auch eine ganze Weile. Aber ich denke, das gilt nicht, wenn es für das Prototyping verwendet wird.