![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Кстати, насчет "биндингов"
В дискуссиях о GUI для всяких эзотерических и не очень языков постоянно всплывает тема "биндингов" к ним для QT, GTK и прочего.
Так вот, мое имхо состоит в том, что язык, у которого нет собственной GUI библиотеки - неполноцен в принципе. Вот, к примеру, захочу я расширить функциональность некоего GUIшного контрола или написать свой. Или просто разобраться в тонкостях его работы, типа "когда вызывается такое-то событие". Если GUIшная либа писана на том же языке на котором я работаю, мне не нужно переключать мозг на чужеродный язык и его стиль, чтобы работать с ней. А если нет - начинается всякая хрень, типа самого это биндинга, единственное назначение которого - гонять туда-сюда вызовы между одним и вторым языком.
Оно конечно полезно, знать несколько языков. Но вот для работы эти переключения между языками не сильно полезны.
PS: Вообще эта идея меня посетила, когда я думал насчет того, как наиболее естественным образом выглядел бы GUI для Хаскеля. Вообще, проблема сама по себе более общая, чем GUI - я ее для себя сформулировал так "Как хранить/обрабатывать в языке общего назначения некую структуру данных, если этот язык для нее плохо подходит". Обычно делают отдельные структуры/языки для разных предметных областей - SQL для баз, декларативные иерархические описания для всяких GUI-шных и прочих форм, для них отдельные редакторы-дизайнеры.
Вот именно "отдельность" мне и не нравится - что-то раздражает переключать контекст мышления, когда надо к программе приделать GUI, взаимодействие с БД, или печатную форму.
Да и вообще работа с GUI может выражаться в языке каким-нибудь другим, гораздо более естественным для него способом, нежели последовательное создание контролов и чтение/запись их свойств. Тот же Хаскель, по моему мнению, вообще GUI должен генерировать автоматически при компиляции, исходя из информации о типах.
Так вот, мое имхо состоит в том, что язык, у которого нет собственной GUI библиотеки - неполноцен в принципе. Вот, к примеру, захочу я расширить функциональность некоего GUIшного контрола или написать свой. Или просто разобраться в тонкостях его работы, типа "когда вызывается такое-то событие". Если GUIшная либа писана на том же языке на котором я работаю, мне не нужно переключать мозг на чужеродный язык и его стиль, чтобы работать с ней. А если нет - начинается всякая хрень, типа самого это биндинга, единственное назначение которого - гонять туда-сюда вызовы между одним и вторым языком.
Оно конечно полезно, знать несколько языков. Но вот для работы эти переключения между языками не сильно полезны.
PS: Вообще эта идея меня посетила, когда я думал насчет того, как наиболее естественным образом выглядел бы GUI для Хаскеля. Вообще, проблема сама по себе более общая, чем GUI - я ее для себя сформулировал так "Как хранить/обрабатывать в языке общего назначения некую структуру данных, если этот язык для нее плохо подходит". Обычно делают отдельные структуры/языки для разных предметных областей - SQL для баз, декларативные иерархические описания для всяких GUI-шных и прочих форм, для них отдельные редакторы-дизайнеры.
Вот именно "отдельность" мне и не нравится - что-то раздражает переключать контекст мышления, когда надо к программе приделать GUI, взаимодействие с БД, или печатную форму.
Да и вообще работа с GUI может выражаться в языке каким-нибудь другим, гораздо более естественным для него способом, нежели последовательное создание контролов и чтение/запись их свойств. Тот же Хаскель, по моему мнению, вообще GUI должен генерировать автоматически при компиляции, исходя из информации о типах.
no subject
Это значит, что для GUI-ни лучше/проще/быстрее использовать специализированные тулзы, типа дизайнера в Delphi или Qt, в которых можно добавить свои специализированные виджеты/контроли.
Собственно дизайнер - это и есть язык программирования GUI.
Т.е. язык разработки здесь должен давать возможность переопределять стандартное поведение в нужных местах и дописывать свои виджеты с минимальными напрягами.
Из этих соображений язык реализации самой GUI либы - это уже низкий уровень. Он безусловно важен, но уже не настолько.
Он важен, когда либо библиотека криво сдизайнена/документирована и понять что происходит в сложных случаях без отладки потрохов трудно, либо когда натыкаешься на баг.
С моей точки зрения, обе ситуации достаточно редки, поэтому вполне оправдано выбирать для разработки более высокоуровневый язык с наличием хорошего биндинга к GUI или базам.
Я довольно долго (~10 лет) плотно сидел на делфи + билдер, сейчас перешёл на Python + Qt (~3х лет).
Биндинг очень качественный, с моей точки зрения.
И хотя несколько глюков я таки поймал, большинство было при использовании новых возможностей после перехода на новые версии - т.е. в ещё не достаточно оттестированном коде.
Насчёт сложности интерфейсов.
Первая программа на Python + Qt появилась несколько неожиданно:
Был заказ на разработку небольшой среды в помощь переводчикам специализированных иерархических данных (~100-200мб. в dbf-ах)
Нужно было отобразить исходное дерево, дерево перевода, возможные варианты, специализированная навигация. Деревья должны быть по возможности синхронны при любых манипуляциях.
Был написан прототип на Python + Qt чтобы проще было обсуждать с заказчиком вид и поведение GUI. С прицелом переписать на С++ после утрясения всех деталей для скорости.
Переписывать не понадобилось. Скорость работы прототипа вполне удовлетворила заказчика. :)
Сейчас разрабатывается большая система документооборота - начинали на Delphi, а потом перетащили на Python + Qt - скорость разработки поднялась больше чем в 2 раза. :)