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

Question

Допустим, я пишу приложение на Haskell или Erlang (или любом другом, неважно), и я хочу, чтобы оно работало с моим графическим интерфейсом на более дружественном для меня языке (на мой взгляд), скажем, Python. Как склеить эти два? Как бы вы общались между этими двумя частями приложения? Делать какой-то сервер или что-то? Это решение популярно? Я видел такие вещи, как SMplayer, который является графическим интерфейсом для mplayer, и он работает довольно хорошо. Что вы думаете об этом дизайне?

Answer 1

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

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

1. Веб-приложения, использующие Haskell в качестве бэкэнда и Javascript / HTML для веб-интерфейса. Связь была сделана исключительно с использованием JSON. На сервере не было сгенерировано HTML или Javascript.
2. Собственно в чистом 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, которые могут автоматизировать это [1].
• Большинство хостов не поддерживают приложения на Haskell.

Преимущества второго подхода:

• все ваши разработки написаны на одном языке, поэтому их проще тестировать.
• Glade отлично подходит для визуального построения графического интерфейса, а интеграция с Haskell чрезвычайно хороша.
• Развертывание в Windows и Linux легко.
• GTK2HS очень хорош, полон и хорошо документирован.
• Привязки также пытаются отразить структуру ОО самой 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/

Answer 2

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

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

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

Answer 3

Комиссионные поддерживает Haskell, Erlang и Python:

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

Answer 4

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

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

Answer 5

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

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

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

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

Answer 6

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

1. Поместите все приложение в один процесс. Обычно это может быть что-то вроде Windows DLL (нативная, COM, управляемые сборки и т. Д.) Или общие объекты Unix.
2. Связь между двумя частями приложения с использованием механизмов IPC.

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