metaclass | Кстати, насчет "биндингов"

Кстати, насчет "биндингов"

В дискуссиях о GUI для всяких эзотерических и не очень языков постоянно всплывает тема "биндингов" к ним для QT, GTK и прочего.

Так вот, мое имхо состоит в том, что язык, у которого нет собственной GUI библиотеки - неполноцен в принципе. Вот, к примеру, захочу я расширить функциональность некоего GUIшного контрола или написать свой. Или просто разобраться в тонкостях его работы, типа "когда вызывается такое-то событие". Если GUIшная либа писана на том же языке на котором я работаю, мне не нужно переключать мозг на чужеродный язык и его стиль, чтобы работать с ней. А если нет - начинается всякая хрень, типа самого это биндинга, единственное назначение которого - гонять туда-сюда вызовы между одним и вторым языком.

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

PS: Вообще эта идея меня посетила, когда я думал насчет того, как наиболее естественным образом выглядел бы GUI для Хаскеля. Вообще, проблема сама по себе более общая, чем GUI - я ее для себя сформулировал так "Как хранить/обрабатывать в языке общего назначения некую структуру данных, если этот язык для нее плохо подходит". Обычно делают отдельные структуры/языки для разных предметных областей - SQL для баз, декларативные иерархические описания для всяких GUI-шных и прочих форм, для них отдельные редакторы-дизайнеры.
Вот именно "отдельность" мне и не нравится - что-то раздражает переключать контекст мышления, когда надо к программе приделать GUI, взаимодействие с БД, или печатную форму.
Да и вообще работа с GUI может выражаться в языке каким-нибудь другим, гораздо более естественным для него способом, нежели последовательное создание контролов и чтение/запись их свойств. Тот же Хаскель, по моему мнению, вообще GUI должен генерировать автоматически при компиляции, исходя из информации о типах.

Flat | Top-Level Comments Only

Что сложнее поддерживать взаимодействие с другим языком(инструментом) и код в 50-100 строк на этом языке или код в 1000+ строк на основном языке?

Если либа на другом языке строго изолирована за простым интерфейсом, качественно написана и не требует доработок - проще писать на разных языках, вернее один раз сбилдить на втором и забыть. Иначе - лучше использовать один язык.

>> вернее один раз сбилдить на втором и забыть

Что как бы и делается при реализации "биндингов" из других языков к Qt или GTK.

У меня еще ни в одном проекте не было, чтобы GUI-контролы не требовали переделок. Так что тут изолировать не получится.

(deleted comment)

Изначально речь шла не о "сложном UI" а о языках общего назначения и типовых задачах.

Определение "сложного UI" в студию -- тогда можно посмотреть и поискать. В целом моя область интересов с UI не пересекается.

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

В целом моя область интересов с UI не пересекается
Я подозреваю, что это точно так же для всех остальных комментаторов в этом посту. Хотел написать отдельный пост чтобы собрать статистику, кто сколько гуя нарисовал, но не могу сформулировать корректно вопрос.

Ха, так в этом и проблема.
Потому что попытка универсально оценить языки с позиции представлений о гуестроении некорректна по определению.

Области применения ЯП с точки зрения интерфейса -- это не только GUI, но и веб, и консольные, и серверные приложения. Качество внешнего интерфейса -- важно, но и оно далеко не всегда является первостепенной задачей (причем для упомянутых выше приложений критерии качества интерфейса будут кардинально разные).

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

Отсюда два логичных вывода
1) Разработчики ЯП не очень озабочены созданием уникального и сверхнавороченного GUI-инструментария, потому что спектр применений этого инструментария существенно уже спектра применения ЯП.
2) Обобщенная критика ЯП, основанная на точке зрения лишь одного сектора его применения, вызовет закономерный приток возражений со стороны разработчиков, использующих критикуемые ЯП в других целях. Причем оппонентов абсолютно закономерно будет больше чем сторонников.

(deleted comment)

Да, уже сталкивался, что приходилось править связь между проектом и либой после выхода новой версии.

Только в ОЧЕНЬ простых случаях, если не требуется одновременной отладки и т.п.

"GUI требующий отладки никто не пишет". :%)

В любом хорошо спроектированном случае, в т.ч. и сложном.

И вызовы между кодом на разных языках нормально понимаются отладчиками?

Проектировать надо так, чтобы была возможность изначально отладить все по частям, а затем протестировать и отладить сборный результат как "черный ящик" :)

В идеале, конечно да. А на практике бывает необходимость посмотреть отладчиком на работу контрола в уже собранной системе.

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

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

И в любом случае -- это скорей исключение, чем правило -- живьем на продакшне сквозную отладку делать. На продакшне вообще лучше не отлаживаться :)

Так что меня это ниразу не остановило бы при проектировании системы. Впрочем, дело вкуса и привычных методик работы.

(deleted comment)

Мой аргумент предельно конкретен.

Если у нас идет разговор о выборе языков и платформ, то мы подразумеваем что разработчик в рассматриваемом гипотетическом проекте волен их выбирать. То есть система пишется разработчиком "с нуля" или почти с нуля.

Если разработчик контролирует выбор языка и платформы, но не контролирует качество проектирования системы -- ему никакой язык не поможет.

Если же речь идет о "данной сверху" системе, написанной кем-то другим, которую теперь надо разгребать нам -- то не пофиг ли, какие языки, подходы и технологии мы предпочитаем?

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

Не спец в автоматизации оборудования для мясокомбинатов.
Но логика подсказывает, что

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

Если же речь не о дебаге в его классическом понимании, а о каком-то реалтаймовом отслеживании неконтролируемого потока данных, с диагностикой "на глаз" -- ну так это хоть и интересная, но весьма узкоспециализированная задача. Для нее действительно лучше сделать решение с учетом особенностей задачи (и наверное, сопряжение технологий на участке критических операций будет невозможным и бессмысленным изначально).

Только еще прицеплюсь к специфике задачи -- почему это некие хардварные адаптеры датчиков имеют отношение к ГУИ? Что это за система?
Речь идет о реалтаймовой системе наведения убойного молотка в лоб животного по мотивам обработки сигнала видеокамеры? Так это ниразу не задача для графических библиотек общего назначения.

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

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

Батенька, если бы предубеждение против многокомпонентных систем было объективно правильным подходом, мы бы до сих пор обрабатывали землю мотыгами и убивали мамонтов камнями. :)

Без тестового стенда в этой области никому не посоветую работать. В лепешку разбейся, увеличь планируемые сроки в 2 раза, но фундамент в виде эмуляторов/стендов подготовь.
Про многокомпонентные системы как я их вижу, я уже писал. Это, конечно, технология, которая позволит управляться с растущей сложностью. А предубеждение, вероятно, из-за молодости технологии и, соответственно, общим идиотизмом её апологетов.

(no subject)

vp.livejournal.com - 2009-01-26 18:46 (UTC) - Expand

(no subject)

blackyblack.livejournal.com - 2009-01-26 19:04 (UTC) - Expand

Я со всем согласен, но в реальности "оборудование существует в единственном экземпляре потому что стоит миллионы".
По поводу ГУИ :) Я думал мы плавно перешли к тому, насколько удобно-неудобно отлаживаться в ситуациях где системы разбиты на 1000 мелких кусков, которые невозможно отлаживать интегрально. В случае, когда система предоставляет целостную отладку ИМХО это много проще. чем если бы унас было взаимодействие между процессами на ровном месте и т.п. Добавило бы много веселых минут.

(no subject)

g-rub.livejournal.com - 2009-01-26 15:17 (UTC) - Expand

Flat | Top-Level Comments Only