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

[metaclass]

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

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

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

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

Comments

[metaclass.livejournal.com]

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

[atzkey.livejournal.com]

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

[kiryl.livejournal.com]

Язык -- это инструмент. Для каждого инструмента есть область применения. Если проект не тривиален, использование нескольких языком может упростить проект и уменьшить объем работы. К примеру, обрабатывать строки на C -- дело неблагодарное, но для низкоуровневой работы и участков критичных к времени выполнения он подходит отлично. Так что не нужно фанатизма.

[g-rub.livejournal.com]

Неужели поддержка и развитие кривой наколенной реализации перла (или хотя бы регекспов) на сях будет много осмысленней и беззаботней, чем грамотное использование надежных инструментов?

[metaclass.livejournal.com]

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

[kiryl.livejournal.com]

С другой стороны сейчас появилась куча domain-specific language, которые очень удобны для решения узкого круга задач.

[g-rub.livejournal.com]

Э, нет. Предыдущая реплика была о проекте для конечного заказчика а не о языке высокого уровня. Для такого проекта своя библиотека регекспов -- бешеный оверкилл.

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

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

[metaclass.livejournal.com]

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

[kiryl.livejournal.com]

Если декомпозиция задачи проведена грамотно, а не серией костылей "чтоб работало", то поддержка тоже упростится.

[kiryl.livejournal.com]

Что сложнее поддерживать взаимодействие с другим языком(инструментом) и код в 50-100 строк на этом языке или код в 1000+ строк на основном языке?

[metaclass.livejournal.com]

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

[g-rub.livejournal.com]

>> Взаимодействие с другими языками это способ бессмысленного усложения проектов

Отнюдь не бессмысленного и не всегда усложнения.
Выше уже приводился пример парсинга строк на С. И на самом деле пример с GUI -- из той же области.

А то что хороший специалист должен владеть несколькими инструментами, а не тупо одним -- следует из общих законов развития человечества. :)

Ничего в этом дикого нет. В конце концов, выходя на улицу Вы, вероятно надеваете рубашку, ботинки, куртку. Сделанные из различных материалов и обладающие различными интерфейсами. И никто не называет это "бессмысленным усложнением" по сравнению с однородным гидрокостюмом. :)

[metaclass.livejournal.com]

Хм, тем не менее строки на С парсят до сих пор, судя по постоянным дырам с переполнением буфера в различных программах.
Насчет нескольких инструментов - это только в России так, а в развитых странах, по слухам, предпочитают узких спецов, а не многостаночников.
И гидрокостюм был бы реально удобнее :)

[g-rub.livejournal.com]

Предпочитают узких спецов где?
Чтобы один узкий спец писал весь проект на том языке, в котором он узкий спец?

Или же там предпочитают узких спецов, пишущих свою _часть_ проекта?

Развитость страны, кстати -- еще не показатель того, что в этой стране не умеют лепить говнопродукты с кривой архитектурой. :)

[kiryl.livejournal.com]

Мы эту проблему решили в узком кругу ограниченных людей. (C)

[metaclass.livejournal.com]

Я бы предпочел использовать в проекте один язык, или чтобы все участники знали все используемые языки. Чтобы не было проблемы "команда разработчиков БД в гробу видела проблемы разработчиков бизнес-логики, которые в гробу видели проблемы разработчиков GUI".

Для крупных проектов, само собой, приходится использовать много разных языков, но это не потому, что это хорошо, а потому что безальтернативно, как с этими биндингами. "По другому написать невозможно или черезчур затратно".
И ключевые части, то, для чего этот проект предназначен и за что его покупают, в любом проекте, я считаю, обязательно должны писаться самостоятельно и на языке, для которого есть и будет поддержка.

[g-rub.livejournal.com]

1) Один язык -- не всегда оптимально
2) Все знали все используемые языки -- вопрос квалификации. В юниксовых конторах так и есть, кстати :) Естественно, степень владения конкретным языком может варьироваться от разработчика к разработчику, но все должны быть в состоянии понять и поправить код друг друга на любом из используемых языков.
3) "в гробу видала" -- вопрос грамотного менеджмента и организации взаимодействия так, чтобы все подкоманды имели представление об общей цели и влиянии друг на друга и в то же время -- имели возможность организовывать внутрикомандную работу без тотального подчинения другим подкомандам.

>> Для крупных проектов, само собой, приходится использовать много разных языков, но это не потому, что это хорошо, а потому что безальтернативно, как с этими биндингами. "По другому написать невозможно или черезчур затратно".

Естественно. :) Оптимальный подход -- он потому и оптимальный, что по другому написать невозможно или чересчур затратно.

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

Если соль проекта -- в ГУИ, которого раньше никто не видел, а не во внутренней логике, то для такого проекта вообще нужен собственный domain-specific язык, предназначенный для описания высокосложных гуев, отнюдь не общего назначения :)

[vp.livejournal.com]

"Один язык -- не всегда оптимально"

В бизнесе для понятия "оптимальность" есть только два критерия - это трудозатраты и качество. Трудозатраты = текущие вложения, качество = дальнейшие вложение по причине возможного геморроя. Даже интуитивно понятно, что если бы был качественный тул "все-в-одном", то по определению он бы позволил трудозатраты свести до минимума. И понятно, что если бы мы использовали связки языков и т.п., это однозначно бы привело к росту трудозатрат.
Так что это не совсем то, что можно назвать оптимальным

На счет знания всех языков.. Я приводил причту во языцех, как я опрашивал ВСЕХ линуксоидов, на предмет IOCTRL управления портом. "На этот вопрос не ответил никто". Все, кто отвечал, считали себя мегагуру во всем.

[g-rub.livejournal.com]

Еще к слову об "узких специалистах" а не "многостаночниках".

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

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

Это не "узкий специалист", а электрик, который принципиально пользуется только кусачками или только отверткой для всех задач подряд -- от снятия изоляции до зачистки проводов и зажатия клемм.

[blackyblack.livejournal.com]

Согласен. Такие проекты очень тяжело читать.

[g-rub.livejournal.com]

Если технологии строго разграничены по соответствующим подзадачам, то в чем проблема-то?

В любом случае, код описывающий GUI, будет организован по другим принципам, чем код, реализующий алгоритмы бизнес-логики, и переключать контекст будет необходимо. Независимо от синтаксиса.

А умение читать различные синтаксисы -- это чисто вопрос опыта и общей подготовки.

[blackyblack.livejournal.com]

"Если технологии строго разграничены по соответствующим подзадачам, то в чем проблема-то?"
Сам не знаю. Теория теорией, а качественного разграничения так толком и не видно. То логика в SQL залезет, то графика в XML.

[metaclass.livejournal.com]

Хех, у меня даже подсветка записей в SQL описывается, потому что так проще всего :)