![[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
no subject
no subject
no subject
no subject
Для языка программирования -- вероятно, другой расклад. ЯП уровня питона и руби проектировать не доводилось пока, поэтому ничего тут не скажу в пределах своей компетенции :)
А парсинг строк в С, выявляемый по переполнению буфера -- либо от неумения комбинировать инструменты, либо там где технически невозможны иные решения из-за ограничений требований к производительности либо платформе.
no subject
no subject
А возможно -- потому что качественной реализации регекспов на С нету, а качественная реализация в перле встроена в ядро интерпретатора, а не вынесена в отдельную либу.
Для графических библиотек дела обстоят ровно наоборот.
no subject
no subject
no subject
no subject
Что как бы и делается при реализации "биндингов" из других языков к Qt или GTK.
no subject
no subject
Определение "сложного UI" в студию -- тогда можно посмотреть и поискать. В целом моя область интересов с UI не пересекается.
Но из общей логики очевидно, что для сложных (=нетиповых) задач рассчитывать на функциональность типовых библиотек странно. Независимо от того, как эта функциональность реализована в конкретном случае -- через биндинг или через "родную" библиотеку.
no subject
Я подозреваю, что это точно так же для всех остальных комментаторов в этом посту. Хотел написать отдельный пост чтобы собрать статистику, кто сколько гуя нарисовал, но не могу сформулировать корректно вопрос.
no subject
Потому что попытка универсально оценить языки с позиции представлений о гуестроении некорректна по определению.
Области применения ЯП с точки зрения интерфейса -- это не только GUI, но и веб, и консольные, и серверные приложения. Качество внешнего интерфейса -- важно, но и оно далеко не всегда является первостепенной задачей (причем для упомянутых выше приложений критерии качества интерфейса будут кардинально разные).
Ну и наконец, интуиция подсказывает, что удельная проектов интересующего Вас типа (GUI со строгими требованиями к интерфейсу) еще более снизится, если мы будем рассматривать не валовое количество проектов в каждой области применения, а количество уникальных задач.
Отсюда два логичных вывода
1) Разработчики ЯП не очень озабочены созданием уникального и сверхнавороченного GUI-инструментария, потому что спектр применений этого инструментария существенно уже спектра применения ЯП.
2) Обобщенная критика ЯП, основанная на точке зрения лишь одного сектора его применения, вызовет закономерный приток возражений со стороны разработчиков, использующих критикуемые ЯП в других целях. Причем оппонентов абсолютно закономерно будет больше чем сторонников.
no subject
no subject
no subject
no subject
no subject
no subject
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)