metaclass: (Default)
metaclass ([personal profile] metaclass) wrote2009-01-26 09:42 am

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

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

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

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

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

[identity profile] g-rub.livejournal.com 2009-01-26 10:30 am (UTC)(link)
Неужели поддержка и развитие кривой наколенной реализации перла (или хотя бы регекспов) на сях будет много осмысленней и беззаботней, чем грамотное использование надежных инструментов?

[identity profile] metaclass.livejournal.com 2009-01-26 10:55 am (UTC)(link)
Судя по количеству различных библиотек для регэкспов на разных языках - так оно и есть. Видимо, таки лучше использовать либу на родном языке.

[identity profile] kiryl.livejournal.com 2009-01-26 10:59 am (UTC)(link)
С другой стороны сейчас появилась куча domain-specific language, которые очень удобны для решения узкого круга задач.

[identity profile] g-rub.livejournal.com 2009-01-26 11:09 am (UTC)(link)
Э, нет. Предыдущая реплика была о проекте для конечного заказчика а не о языке высокого уровня. Для такого проекта своя библиотека регекспов -- бешеный оверкилл.

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

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

[identity profile] metaclass.livejournal.com 2009-01-26 11:19 am (UTC)(link)
Почему библиотека регэкспов для ЯП это нормально, а библиотека GUI - нет? Я подозреваю, потому что авторы языков любят писать алгоритмы, но не любят рисовать картинки для пользователей. :)

[identity profile] g-rub.livejournal.com 2009-01-26 11:31 am (UTC)(link)
Возможно и поэтому.
А возможно -- потому что качественной реализации регекспов на С нету, а качественная реализация в перле встроена в ядро интерпретатора, а не вынесена в отдельную либу.

Для графических библиотек дела обстоят ровно наоборот.