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

[metaclass]

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

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

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

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

Comments

[perplexed-bear.livejournal.com]

И что у нас в итоге остаётся?
C
C++
C#
Java
Pascal (Delphi, Lazarus)
Visual Basic
Python
Perl
TCL/TK

И фффсё?

[tonal.myopenid.com (from livejournal.com)]

Lazarus отпадает, т.к. у него биндинг к GTK если я не ошибаюсь.
У Python и Perl нет своей библтотеки для GUI - только биндинги.
Хотя у всех 3х есть биндинги к виндовым User32 + GDI32 и к *nix-овым Х-ам.
Следует ли их этого заключить, что они являются/не являются полноценными языками?

А если ёрничать, то C++ в составе C++Builder-а не является полноценным языком, т.к. GUI там на delphi писано (VCL). Но если выкинуть на помойку VCL и IDE и добавить то же Qt, то язык становиться вполне полноценным! :)

Да, кстати забыли Oberon и SmallTalk - тама GUI не отделим от языка и IDE. :)

[perplexed-bear.livejournal.com]

Действительно, SmallTalk забыл. Оберон/Component Pascal - под вопросом. Т.е. я не сомневаюсь, что это полноценный язык, но не видно на нём разработок. А если уж так говорить, то и LispWorks сюда по той же причине включать.

[tonal.myopenid.com (from livejournal.com)]

Мне кажется, что всё таки специализация рулит.
Это значит, что для GUI-ни лучше/проще/быстрее использовать специализированные тулзы, типа дизайнера в Delphi или Qt, в которых можно добавить свои специализированные виджеты/контроли.
Собственно дизайнер - это и есть язык программирования GUI.
Т.е. язык разработки здесь должен давать возможность переопределять стандартное поведение в нужных местах и дописывать свои виджеты с минимальными напрягами.

Из этих соображений язык реализации самой GUI либы - это уже низкий уровень. Он безусловно важен, но уже не настолько.
Он важен, когда либо библиотека криво сдизайнена/документирована и понять что происходит в сложных случаях без отладки потрохов трудно, либо когда натыкаешься на баг.

С моей точки зрения, обе ситуации достаточно редки, поэтому вполне оправдано выбирать для разработки более высокоуровневый язык с наличием хорошего биндинга к GUI или базам.

Я довольно долго (~10 лет) плотно сидел на делфи + билдер, сейчас перешёл на Python + Qt (~3х лет).
Биндинг очень качественный, с моей точки зрения.
И хотя несколько глюков я таки поймал, большинство было при использовании новых возможностей после перехода на новые версии - т.е. в ещё не достаточно оттестированном коде.

Насчёт сложности интерфейсов.
Первая программа на Python + Qt появилась несколько неожиданно:
Был заказ на разработку небольшой среды в помощь переводчикам специализированных иерархических данных (~100-200мб. в dbf-ах)
Нужно было отобразить исходное дерево, дерево перевода, возможные варианты, специализированная навигация. Деревья должны быть по возможности синхронны при любых манипуляциях.
Был написан прототип на Python + Qt чтобы проще было обсуждать с заказчиком вид и поведение GUI. С прицелом переписать на С++ после утрясения всех деталей для скорости.
Переписывать не понадобилось. Скорость работы прототипа вполне удовлетворила заказчика. :)

Сейчас разрабатывается большая система документооборота - начинали на Delphi, а потом перетащили на Python + Qt - скорость разработки поднялась больше чем в 2 раза. :)

[potan.livejournal.com]

Lisp (CLIM), Haskell, Scala.

[familom.livejournal.com]

Если под "неполноценностью" понимать "не general-purpose", то да.

[metaclass.livejournal.com]

Языки, которые не предлагаются в качестве средств разработки GUI, не рассматриваются, так что речь идет именно о general-purpose языках.

[ugenk.livejournal.com]

А xlib - это собственная C'шная библиотека? :)

[metaclass.livejournal.com]

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

[raydac.livejournal.com]

человек вообще неполноценное существо, у него нет разъема для подключения монитора

[atzkey.livejournal.com]

Да! Надо больше gui-библиотек! Чтобы больше сумасшедших программистов рисовало сумасшедшие интерфейсы!
http://atzkey.livejournal.com/76372.html?thread=162132#t162132


Неполноценны языки, которые не способны взаимодействовать с другими языками. (Представилась библиотека для Piet, написанная на Brainfuck)

[metaclass.livejournal.com]

Взаимодействие с другими языками это способ бессмысленного усложения проектов. И так на простейших проектах - дикая смесь из обычных general-purpose языков, SQL, XML, и прочей хрени. Вот осталось только еще прикрутить интерпретатор хаскеля и питон для "скриптинга" и сидеть наслаждаться мыслями "как сдохнут те, кто это будет поддерживать в будущем".

[kiryl.livejournal.com]

Помимо гуйни есть масса других задач.

[metaclass.livejournal.com]

Это само собой. Особенно если стараться не связываться c GUI, потому что нет нормальных средств его делать.
Я, собственно говоря, GUI рисовать не люблю, даже когда его просто делать, а уж когда через какие-нибудь извраты - то и вообще стараюсь не связываться.

[volodymir-k.livejournal.com]

Неубедительный креотифф. Смешано требование по чтению старого кода, способы компоновки, наличие компонентов, какой-то "собственный", "биндинг". Чё вообще надо? В чём проблема-то?

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

[metaclass.livejournal.com]

Ну вот то, что вызывает winapi или там xlib - должно быть написано на самом же языке. Жаба и дельфи как раз в этом плане нормально сделаны вроде.

[gds.livejournal.com]

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

[mr-aleph.livejournal.com]

я не помню, когда я последний раз делал гуй.

[metaclass.livejournal.com]

Ничего, придет кризис, еще и юзеров саппортить будете :)

[zamotivator.livejournal.com]

Я так и не понял, какой категории относится С++ и Qt =)

[metaclass.livejournal.com]

К правильной. QT написан на С++? Написан :)

[mibori.livejournal.com]

русский не совершенный

[mibori.livejournal.com]

язык?

[metaclass.livejournal.com]

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

[divine-assass1n.livejournal.com]

От современной веб-разработки Вы бы сошли с ума с такой установкой :)

Между тем проблема не в количестве языков, а в предоставленном Application Programming Interface. Хороший продуманный API не усложнит проект и не создаст проблем с поддержкой, разве что если инженеры имбецилы.