Кстати, насчет "биндингов"
Jan. 26th, 2009 09:42 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassВ дискуссиях о 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 должен генерировать автоматически при компиляции, исходя из информации о типах.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2009-01-26 08:04 am (UTC)no subject
Date: 2009-01-26 08:07 am (UTC)no subject
Date: 2009-01-26 09:15 am (UTC)Что касается возможности написать граф.библиотеку, непосредственно работающую с ОС, то
возможность
есть у всех. А вот
написанные
библиотеки - не у всех. Тем не менее, язык - полноценный, нет?
no subject
Date: 2009-01-26 09:16 am (UTC)no subject
Date: 2009-01-26 09:28 am (UTC)Толпы лінупсоідов по религиозным причинам стараются избавится от gtk или от qt или от обеих библиотек. И вообще не стоит их как важную часть ОС рассматривать.
no subject
Date: 2009-01-26 09:32 am (UTC)no subject
Date: 2009-01-26 09:39 am (UTC)no subject
Date: 2009-01-28 06:15 am (UTC)no subject
Date: 2009-01-26 10:21 am (UTC)Из чего это очевидно? Если только мы не пишем GUI с каким-то супер-адским откликом по времени?
И чем конкретно оправдана идея "каждому языку -- свой гуевый велосипед со своими багами и своим отдельным суппортом"?
no subject
Date: 2009-01-26 10:50 am (UTC)Я не уверен, что такой язык является хорошим выбором для писания программ со сложным GUI.
no subject
Date: 2009-01-26 11:02 am (UTC)б) нет, потому что грамотный биндинг подразумевает, что вся графическая сложность библиотеки доступна из рассматриваемого языка. Если не хватает сложности библиотеки -- тогда проблема не в языке а именно в либе.
в) исходно фраза про "сложность ГУИ" не звучала, и "проектами со сложным ГУИ" произвольный язык программирования мерять глупо (ибо ГУИ -- лишь одна из возможных областей задач, далеко не всегда обязательная). Но представим, что перед нами стоит такой проект, причем всю логику писать оптимально именно на языке который мы выбрали. Что ж, большинство языков поддерживают тот или иной механизм интеграции с С-шным кодом, поэтому в случаях тяжелого и сложного ГУИ ничто не запрещает напрямую слинковаться с Xlib и написать свою прослойку, делающую сложные и редкие трюки.
Отсутствие необходимых нам по проекту сложных трюков в типовой библиотеке говорит лишь об их слабой востребованности в соответствующей нише использования, и абсолютно ничего не говорит нам об абстрактном "качестве" библиотеки или тем более использующего ее языка программирования.
no subject
Date: 2009-01-26 10:44 am (UTC)xlib к ОС отношения не имеет ;)
// ща начнется холивар :)
no subject
Date: 2009-01-26 10:56 am (UTC)no subject
Date: 2009-01-26 11:06 am (UTC)no subject
Date: 2009-01-26 11:13 am (UTC)no subject
Date: 2009-01-26 01:01 pm (UTC)Unix-like ОС - это компилятор Си, ядро и libc. Всё остальное - сторонние компоненты.
Более того, не единственный способ отображения графики. Я бы ещё попытался согласится если бы помянули FrameBuffer как сервис ОС (благо что fb предоставляется ядром).
Упомянутые графические тулкиты (Qt, Gtk, WxWidgets) в качестве backend для отрисовки могут что угодно (Win32, Xlib, Framebuffer, Cocoa или даже друг друга - для WxWidgets/GTK).
> Очевидно, что нормальные языки, если на них писать GUI, должны обращаться напрямую к ней, а не через еще пару слоев библиотек на других языках.
Совершенно не очевидно, учитывая что Xlib - всего лишь just another one method of drawing primitives. Следовательно указанная "универсальная графическая библиотека языка X" должна быть портирована на как можно более низкоуровневые backends ВСЕХ ПОДДЕРЖИВАЕМЫХ ПЛАТФОРМ языка, следуя вашей логике.
Дальнейшее развитие выч. техники позволяет делать всё более сложные вещи, используя методы недавно казавшиеся слишком тяжёлыми и нерациональными.
It's evolution, baby.
Исправлено :)
Date: 2009-01-26 01:27 pm (UTC)Unix-like ОС - это компилятор Си, ядро и libc. Всё остальное - сторонние компоненты.
Более того, не единственный способ отображения графики. Я бы ещё попытался согласится если бы помянули FrameBuffer как сервис ОС (благо что fb предоставляется ядром).
Упомянутые графические тулкиты (Qt, Gtk, WxWidgets) в качестве backend для отрисовки могут что угодно (Win32, Xlib, Framebuffer, Cocoa или даже друг друга - для WxWidgets/GTK).
> Очевидно, что нормальные языки, если на них писать GUI, должны обращаться напрямую к ней, а не через еще пару слоев библиотек на других языках.
Совершенно не очевидно, учитывая что Xlib - всего лишь just another one method of drawing primitives. Следовательно указанная "универсальная графическая библиотека языка X" должна быть портирована на как можно более низкоуровневые backends ВСЕХ ПОДДЕРЖИВАЕМЫХ ПЛАТФОРМ языка, следуя вашей логике.
grub правильно отметил, что тут наблюдается дальнейшая компонентизация и растаскивание по отдельным квартирам отдельных задач.
Дальнейшее развитие выч. техники позволяет делать всё более сложные вещи, используя методы недавно казавшиеся слишком тяжёлыми и нерациональными.
It's evolution, baby.