Написание графического интерфейса на одном языке и основное приложение в другом

Ответ 1

Я написал приложения в Haskell, используя оба метода (клиент/сервер, native), и оба они приходят с их преимуществами. Я понимаю, что это больше, о чем вы просили, но я документировал проблемы и недостатки обоих подходов в надежде, что это поможет вам принять более обоснованное решение.

Более конкретно подходы, которые я использовал, были:

• Веб-приложения, которые используют Haskell в качестве бэкэнд и Javascript/HTML для интерфейса. Связь была выполнена исключительно с использованием JSON. На бэкэнд не было создано HTML или Javascript.
• Натурально в чистом Haskell с использованием GTK2HS

К первому подходу относятся:

• Мне пришлось отделить GUI-код от логики конца. Это определенно сделано для более чистого дизайна.
• Haskell теперь имеет высокопроизводительные веб-серверы [4,5]. Он также имеет отличную поддержку CGI/FastCGI и базы данных, если вы хотите писать скрипты в стиле PHP на сторонних веб-серверах. Я использовал последний подход, и он работал очень хорошо.
• Библиотеки пользовательского интерфейса теперь достаточно хороши, когда создание интерфейса в Javascript довольно приятное. Я очень доволен Qooxdoo [2], но есть несколько вариантов (jQuery, ExtJS...)
• Программная транзакционная память [3] делает тривиальным сохранение одновременно доступного состояния на стороне сервера. STM - единственная причина, по которой этот подход является жизнеспособным и забавным.
• Мне понравилось, что пользовательский интерфейс был совместим и легко развертывается на любых платформах, которые могут запускать веб-браузер. Если ваше приложение должно работать на Mac, а также в Windows и Linux, я все равно считаю, что это лучший способ пойти (подробнее см. Ниже).

Нижними признаками первого подхода являются:

• Мне приходилось разбираться с проверкой подлинности и сеансами, даже когда я знал, что это однопользовательское приложение. В настоящее время существуют рамки (Yesod, Happstack...), которые помогают в этом, но я думаю, что это случайная сложность, которую можно избежать, написав собственное приложение.
• Мне пришлось свернуть собственный клиентский протокол связи с сервером. Расширение протокола и обеспечение его правильности были болезненными на конце Javascript, но были абсолютной радостью на конце Haskell. Я подозреваю, что это будет применимо к любой комбинации GUI-friendly-language/Haskell, которую вы выберете.
• Хороший кусок моего кода закончил просто сортировку и разбор данных JSON. Это сейчас проблема, потому что я думаю, что есть несколько Haskell libs для этой заявки для автоматизации этого [1].
• Большинство хостов не поддерживают приложения Haskell.

Верхние стороны второго подхода:

• вся ваша разработка находится на одном языке и поэтому ее легче протестировать.
• Glade отлично подходит для визуального создания GUI, и интеграция Haskell очень хороша.
• Простое развертывание в Windows и Linux.
• GTK2HS очень хороший, полный и хорошо документированный.
• Связи также пытаются зеркально отразить структуру OO самого GTK. Для этого есть недостатки (см. Ниже), но большим преимуществом является то, что я смог использовать документацию для других языковых привязок, чтобы заполнить любые пробелы в документации. Когда я развился, я постоянно обращался к превосходным документам GTK от Python.

Нижними признаками второго подхода являются:

• развертывание приложения GTK2HS на Mac ужасно божественно и выглядит уродливо для загрузки.
• Установка GTK2HS на Windows является нетривиальной, на Mac это открытая исследовательская проблема.
• GTK2HS требует, чтобы вы писали очень унииоматичный Haskell. Там изменчивое состояние повсюду и отсутствие объектов означает, что вы в основном пишете процедурный код.

Надеюсь, это не было TMI.

-deech

[1] http://www.google.co.uk/search?hl=en&as_sitesearch=hackage.haskell.org%2Fpackage&as_q=json

[2] http://www.qooxdoo.org

[3] http://www.haskell.org/haskellwiki/Software_transactional_memory

[4] http://hackage.haskell.org/package/warp-0.3.2.3

[5] http://snapframework.com/

Ответ 2

Вы можете сделать это:

• основная программа в Haskell или Erlang может запускаться сама по себе в командной строке, с консольным приглашением и т.д.
• GUI на любом языке запускает основную программу и управляет ею через ядро ​​stdin и stdout.

Этот подход используется gdb (core)/ddd (GUI). Это позволяет легко отлаживать ядро ​​на командной строке. При таком подходе вы также можете легко выполнять пакетные скрипты с использованием ядра, модульных тестов и т.д.

Ответ 3

Если по дружественному языку вы имеете в виду Visual GUI Designer, то вы все равно можете сделать это в haskell. 2 основных графических интерфейса Linux, GTK и QT имеют визуальные дизайнеры, и вы можете использовать файлы GUI, которые они создают из haskell.

Проверьте библиотеки gtk2hs или qthaskell.

Ответ 4

Thrift поддерживает Haskell, Erlang и Python:

Thrift - это программная среда для масштабируемые межязыковые сервисы развитие. Он объединяет программное обеспечение стек с движком генерации кода для создавать службы, которые работают эффективно и плавно между С++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, С#, Cocoa, JavaScript, Node.js, Smalltalk и OCaml.

Ответ 5

У вас есть два очевидных варианта:

• Поместите все приложение в один процесс. Это обычно включает в себя что-то вроде Windows DLL (native, COM, управляемых сборок и т.д.) Или Unix-общих объектов.
• Общайтесь между двумя частями приложения с помощью механизмов IPC.

Обычно вариант 1 предпочтительнее, если соответствующие языки поддаются анамнезу.

Ответ 6

Он будет зависеть от точного языка, который вы хотите использовать как для графического интерфейса, так и для логики. Как ответил Дэвид, у вас в основном есть только эти два варианта, и у них обоих есть преимущества и недостатки:

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

Использование разных процессов может быть хорошим, если вы все время выполняете много вещей в логическом процессе, но хотите, чтобы gui все еще был отзывчивым. (хотя это может быть достигнуто и с помощью потоков в одном процессе). Кроме того, если вы не можете внедрять языки, это будет самым простым решением. (например, с использованием простых сокетов для IPC, которые существуют практически на всех языках и действительно портативны (что не так верно для таких вещей, как трубы или разделяемая память).

Так что это действительно зависит от языков, которые вы выберете.