![[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 должен генерировать автоматически при компиляции, исходя из информации о типах.
Re: Пофлеймлю :)
Привожу пример из практики - одна девочка (индия, компания CMMI-5) сделала copy-paste 32 раза. В исходном коде была ошибка. Стало 32 ошибки. Сидел и исправлял, нашёл не везде в первый день, во второй тоже не всё.
Что можно автоматизировать - надо автоматизировать. И кодогенерация - отличный метод исключить механические ошибки оператора/кодировщика на массово-однотипных задачах. Юнит-тесты, FSM для сетевых протоколов. К примеру, в samba4 огромное количество кода, отвечающего за протоколы - перенесли в кодогенерацию, чуть ли не до 50% всех исходных кодов.
http://www.nestor.minsk.by/sr/2008/08/sr80803.html - из той же поездки история. Решить задачу чем либо кроме кодогенерации в указанные сроки было невозможно (исполнители не увидели вариантов). Решение получилось прямое и конкретное. Как бы Вы решили эту проблему?
Re: Пофлеймлю :)
Я подуал про "создать налету скрипт" и послать его на выполнение из системы рунтаймово. Типа такой полуинтерпретатор.
Re: Пофлеймлю :)
Вида - "Тонкий клиент" - "Толстый сервер". Система - универсальный конфигуратор системы, с прицелом на фаервол.
Сервер генерирует код на TCL, передаёт его клиенту. Клиент код выполняет. Сервер на Ruby, клиент естественно на TCL. Ещё есть живые свидетели волшебства.
К сожалению проектировщик системы значительно опережал в развитии как специалист конечных исполнителей. Более того - он даже не предполагал, что его прототип-набросок начнут развёртывать в Production систему. Но работало в итоге неплохо, несмотря на студентов.
Re: Пофлеймлю :)
В особенности если скрипт состоит из 50-100 вызовов внешней утилиты, незначительно отличающихся лишь параметрами и порядком следования, а вся лаконичная логика, определяющая эти вызовы, задается юзером (т.е. заранее не предсказана) и анализируется двумя уровнями выше.
Re: Пофлеймлю :)