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

[metaclass]

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

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

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

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

Comments

[vp.livejournal.com]

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

[g-rub.livejournal.com]

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

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

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

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

[metaclass.livejournal.com]

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

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

[g-rub.livejournal.com]

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

[blackyblack.livejournal.com]

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

[vp.livejournal.com]

Тестовый стенд всегда реализуется, да вот все особенности он учесть не может. Он эмулирует бизнеслогику, но, например, у меня тестовый стенд не смог мне подсказать что не так, пока я не увидел, что даун из обслуживающей фирмы в весах заменил полный кабель с полным квитированием на ТОЧНО ТАКОЙ ЖЕ по виду, но без квитирования. И в таком духе :)
Вообще это вечная проблема дорогих вещей. Штуку стоимостью выше 1000 баксов уже проблематично себе купить на работу на стол. Вот сейчас готовлю комнадировку завтра ехать на поклонение такой штуке :(

[blackyblack.livejournal.com]

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

[vp.livejournal.com]

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

[g-rub.livejournal.com]

1) Не 1000 а 2-5
2) Интегральная отладка -- зло, ее сложность растет быстрее сложности системы.