Плюсы и минусы создания прототипа настольного приложения с помощью Tcl / Tk

Question

Я начал создавать прототип настольного приложения с помощью Tcl и собираюсь представить эту идею некоторым венчурным капиталистам. Ни настольные приложения, ни Tcl не в моде, и поэтому я хочу быть готовым противостоять любым возражениям против этой технологии. Ниже приведены доводы "за", как я их вижу, я с нетерпением жду, когда увижу много минусов, я уверен, но, надеюсь, еще несколько за.

1. Первоначально я начал писать некоторый код в том же духе в договоре о найме в прошлом году, используя Java, и хочу использовать совершенно другой язык для дифференциации моих усилий по юридическим причинам
2. В то время как код в настоящее время выполняется как сценарий командной строки, необходимо будет применить пользовательский интерфейс, для которого Tk будет достаточно для прототипа, а Tk тесно интегрирован с Tcl.
3. Поскольку я вообще не использую Java, я предвижу «производство», а не создание прототипа, когда пользовательский интерфейс пишется на C ++. Tcl легко встраивается в приложения C ++, так что базовый движок TCL будет изначально встраиваться, прежде чем переносить критически важные для производительности разделы на C ++

Я понимаю, что потенциальный недостаток - это "Tk UI ужасны", однако, как было сказано выше, Tk UI будет для прототипа, и в любом случае, проблема Tk is udly была поднята на SO уже вашим по-настоящему: * Почему Tk GUI считается уродливым?

Answer 1

Tcl / Tk выделяется в нескольких вещах. Во-первых, довольно легко разработать рабочие прототипы в очень короткие сроки. Во-вторых, сообщество Tcl решило проблему распространения лучше, чем любой другой язык. Читайте о старкитах и ​​старпаках, если это важно для вас. Встроенная поддержка Tcl для виртуальных файловых систем и возможность упаковать все в один исполняемый файл (или отдельное приложение и зависящее от платформы время выполнения) не имеют аналогов.

В Tcl также есть юникод, запеченный в ядре (и уже довольно долго), в отличие от некоторых языков сценариев, где юникод, похоже, является задним числом. Это в сочетании с приличной поддержкой каталога сообщений делает интернационализацию и локализацию довольно легкой (за исключением языков с написанием справа налево).

Без подробной информации о точном характере вашей программы трудно сказать, почему Tcl / Tk может быть правильным решением для вас. Он не идеален для каждого продукта, но многие люди будут удивлены, насколько хорош Tcl.

Answer 2

Вопрос VC, к которому я бы готовился:

«Как вы собираетесь нанимать персонал для этого?»

Мой личный опыт показывает, что ситуация с наймом (как количеством, так и качеством) для языка часто важнее самих языков.

Также будьте осторожны, чтобы защищать свою позицию с помощью решений, которые требуют еще большего мастерства, таких как встраивание переводчиков, многоязычные проекты, изменения времени выполнения и т. Д. Это потому, что, опять же, узкое место - квалифицированный персонал.

P.s. лично я отвергаю все не родные GUI. Так что я тоже давно ненавижу Java. Но я думаю, что это не относится к прототипам.

Answer 3

Tk имеет тематические графические интерфейсы и уже довольно давно. Сделать графический интерфейс пользователя TK довольно просто. TK также довольно легко обрабатывает системные ресурсы (конечно, быстрее и меньше, чем Winforms).

Ключевым аргументом для Tcl является использование его в качестве механизма сценариев и расширения для вашего приложения. Если вы пишете приложение на C ++ со встроенным интерпретатором Tcl и можете получить то, что хотите от Tk, вы вполне можете написать значительную часть приложения на своем собственном языке сценариев. Это будет быстрее и проще, чем кодирование собственного C ++ GUI. Тем не менее, Tk не особенно многофункциональный, поэтому вы хотите, чтобы вы могли делать то, что вы хотите, прежде чем совершать это.

Answer 4

Не принимайте "уродливый" прототипный довод "против" за 1 кон. При разговоре с непрограммистами это считается 5 или 6 минусами: Прочитайте до конца, моя точка зрения там

Не зная природу вашей программы, трудно быть более конкретным.