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

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

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

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

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

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

Flat | Top-Level Comments Only

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

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

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

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

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

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

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

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

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

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

2) Один из оптимальных путей в бизнесе -- производить много дешевого говна, которое юзеры будут часто и с охотой покупать. Тем не менее топик вроде технический. Так что давайте и рассматривать решения, хоть сколько-нибудь оптимальные не только с точки зрения бизнеса, но и с технической. С технической точки зрения решение, требующее написать все-на-одном языке (а единственное преимущество такого решения -- возможность отдать суппорт на откуп леммингам, неспособным удержать в голове более одного синтаксиса) -- неизменно ведет к гниению проекта в дальнейшей перспективе и необходимости периодического приглашения гуру для его оживления. И счастье, если язык, на который сделана ставка, к моменту очередного оживления будет достаточно популярен, чтобы пришедший гуру не сказал "не-не-не, надо ВСЕ переписать на ХХХ".

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

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

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

Почту, кстати он тоже будет сам пихать в 25-й порт, не передавая внешним подсистемам, написанным на "неродных" языках?

По первому абзацу все всегда так и делается. По поводу 25 порта тоже никаких проблем. Так все и пишется.

А вот по поводу кодогенераторов тут предубеждение на уровне постановки задачи. Я считаю, что это плохая архитектура, когда никак кроме как нагенерить налету кода и выполнить не получается. Кривовато это.

Нет ничего хуже многократно повторяющегося и чуть чуть меняющегося кода, сделанного вручную.

Привожу пример из практики - одна девочка (индия, компания CMMI-5) сделала copy-paste 32 раза. В исходном коде была ошибка. Стало 32 ошибки. Сидел и исправлял, нашёл не везде в первый день, во второй тоже не всё.

Что можно автоматизировать - надо автоматизировать. И кодогенерация - отличный метод исключить механические ошибки оператора/кодировщика на массово-однотипных задачах. Юнит-тесты, FSM для сетевых протоколов. К примеру, в samba4 огромное количество кода, отвечающего за протоколы - перенесли в кодогенерацию, чуть ли не до 50% всех исходных кодов.

http://www.nestor.minsk.by/sr/2008/08/sr80803.html - из той же поездки история. Решить задачу чем либо кроме кодогенерации в указанные сроки было невозможно (исполнители не увидели вариантов). Решение получилось прямое и конкретное. Как бы Вы решили эту проблему?

Пардон, я не про ту кодогенерацию подумал :)
Я подуал про "создать налету скрипт" и послать его на выполнение из системы рунтаймово. Типа такой полуинтерпретатор.

И второго типа мне попадались удачные системы.

Вида - "Тонкий клиент" - "Толстый сервер". Система - универсальный конфигуратор системы, с прицелом на фаервол.

Сервер генерирует код на TCL, передаёт его клиенту. Клиент код выполняет. Сервер на Ruby, клиент естественно на TCL. Ещё есть живые свидетели волшебства.

К сожалению проектировщик системы значительно опережал в развитии как специалист конечных исполнителей. Более того - он даже не предполагал, что его прототип-набросок начнут развёртывать в Production систему. Но работало в итоге неплохо, несмотря на студентов.

У меня такое делается. Себя оправдывает.

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

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

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

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

Направление -- регулярная обработка больших объемов данных по произвольным определяемым пользователем алгоритмам.

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

Когда пользователь -- аналитик, то хрен скроешься от определяемых им алгоритмов. :)

>> По поводу 25 порта тоже никаких проблем. Так все и пишется.

Т.е. самостоятельная наколенная реализация SMTP? Зачем?

Потому что дерево уже посадили, сына вырастили.

Только SMTP и священный грааль всех времён - HTTP и остаются. Жизнь так пуста ...

:)

А чем он страшен? :)

Он не страшен. Он уже реализован.

no subject

no subject

no subject

no subject

Пофлеймлю :)

Re: Пофлеймлю :)

Re: Пофлеймлю :)

Re: Пофлеймлю :)

Re: Пофлеймлю :)

Re: Пофлеймлю :)

Re: Пофлеймлю :)

Re: Пофлеймлю :)

Re: Пофлеймлю :)

Re: Пофлеймлю :)

Re: Пофлеймлю :)

Re: Пофлеймлю :)

Re: Пофлеймлю :)

Re: Пофлеймлю :)

Re: Пофлеймлю :)

Re: Пофлеймлю :)

Re: Пофлеймлю :)

Re: Пофлеймлю :)

no subject

no subject

no subject