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

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

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

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

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

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

Flat | Top-Level Comments Only

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 и остаются. Жизнь так пуста ...

:)

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

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

Ну, дык и я про что. Он реализован 100 раз в 100 стандартных и нестандартных библиотеках языка, без каких-либо внешних средств. Чем плохо?

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

Кстати, в том же перле ЕМНИП большинство библиотек по отсылке почты используют в качестве backend-а утилиту mail, что абсолютно правильно.

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

no subject

no subject

Пофлеймлю :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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