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

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

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

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

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

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

Flat | Top-Level Comments Only

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

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

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

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

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

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

Благо, нужда такая крайне редко возникает. Как правило, репозиториев хватает.

Хех, в "стандартные компоненты" в 2003 винде еще и IIS с ASP.NET входить, так что проблем их удалением можно создать.

Но вообще идея "официальных репозиториев" меня пугает. Это означает, что разработчиками постулируется "пользователям ничего кроме того, что мы посчитали кошерным не нужно".

Ну учитывая количество пакетов допустим в репозитории debian (~25000 наименований, но это за счет того что многие либы являются отдельными пакетами, прикладного софта меньше, общий размер порядка 20G) -- где-то так и есть.

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

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

Так ставятся тот же скайп и FBReader.

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

ну и что? И чем в этом случае внешняя утилита mail будет себя вести кошернее, чем мой вкомпилированный код? :) Поменялось что-то - поменялась библиотека - новый билд. Остается целостное монолитное решение с гарантированным номером версий, никакого ада библиотек и потом мучений, что "вдруг админ восстановил из загашников старую версию mail которая ему досталась от деда". А админ обязательно так сделает, им скажет, что ваша хреновая система не работает и не шлет почту.

Ребе, в данном случае утилита mail, принимающая стандартные параметры -- ссылка на системный MTA по умолчанию (которым может быть sendmail, postfix, exim -- не наше дело).

Мы занимаемся генерацией писем. Их транспортировкой, как и всех остальных, занимается MTA, настроенный админом. Все что нашему софту надо знать о хосте, где он крутится -- это поле From, которое мы вставим в свои письма (и то необязательно).

А уж админ отвечает за настройку маршрутов почты, mx-ресолвинг и прочие прелести. Нам до этого нет дела. А ему нет дела до деталей нашей реализации.

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

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

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

Ну тогда да... другого выхода особо и нет.

Хотя мы бы в этом случае сделали загрузочный самонастраивающийся дистрибутив OS.
Но об этом как-то давно уже был похожий спор :)))

Подобную проблему решали несколько по-другому.

Выделенная машина, OEM-инсталяция с диска, куда входит и ОС со всем окружением.

Руки за попытки влезть внутрь - отрубаются на уровне плечевого сустава. Всё контроллирует жестянной интеллект.

Аудитория - They are Smart Hardworking Peoples, but not technical (дословная цитата из письма заказчика). Филипины или Индонезия, уже не помню.

где-то я эту цитату уже видел… доклад на LVEE про использование d-i? :-)

That's it, exactly.

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

Ну а на серверной винде что? Там приложения тоже лупят производимую ими почту в 25 порт адресатам?

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

Но если и так -- это ж "аварийное" решение а не основное. И стремление "сделать SMTP нативно" стоит тут на последнем месте в списке мотиваторов.

Каким адресатам? В проге прописан адрес SMTP сервера, и на его 25 порт оно и щемится.

В общем, стремление "сделать нативно" следует из того, что на винде может вообще ничего не быть. Скачивает юзер инсталлятор, ставит, запускает - у него ничего не работает. Если ему показать список пререквизитов (СУБД отдельно, мыл трансфер отдельно, всякая другая трасца отдельно) - он сразу же стирает нашу прогу и идет покупает софт у конкурентов, больно надо ему в этой ИТ-хрени разбираться. Можно включить в инсталлятор все пререквизиты и потом пользователи будут нам капать на бошку "вот ваш инсталлятор снес нам нашу любимую допотопную версию того, сего, третьего". Сделать проверку всего, что нужно и ставить/обновлять автоматически - тоже нельзя. Возьмет юзер, удалит чужой софт, использующий такую же либу - и кранты нашему софту, садись на машину, езжай обслуживать.
А когда все нативно - зависимостей минимум, полвинды вирусами сожрано, черти пляшут в MTV, а нашему софту - пофиг, как работал так и работает. И под разными виндами, и от идиотизма админов не зависит.

> В проге прописан адрес SMTP сервера, и на его 25 порт оно и щемится.

Повезло с провайдером и с почтовым сервером. Beltelecom помнится отрубил 25 порт по диалапу, а кто-то ещё поставил SMTP 2525. Или классика жанра -- файрвол после переустановки.

И ваше поделие открывает порт всем вирусам-ботнетам. Вот кто спамит!

> А когда все нативно - зависимостей минимум, полвинды вирусами сожрано, черти пляшут в MTV, а нашему софту - пофиг

Ой вэй, у вас в экзешнике зашит движок БД? Даже в DLL не вынесено?

А причем тут порт для вирусов и ботнетом, у нас же исходящее соединение? Да и пофиг, какой там белтелеком, это дело внутри локалки работает обычно.

Ну вот из зависимостей - движок БД(который сам по себе минимально от всего зависит), пару либ для работы с графикой и GIS и в общем-то и все.

А чем плох вкомпилированный в основной проект движок БД, который поставляется на языке проекта? :) Некошерно? Мало файлов в итоге будет? Подумают, что раз мало ДЛЛ, то писали пионеры? :)

Ничем не плох, если задача существенно локальна. Изощрённые движки несколько Мб (2-10) потребляют, но и чёрт с ними. А неизощрённые (DBF) не очень надёжны.

Если все ради подсчета мегабайт. которые мы съекономим на ДЛЛ, то тогда понятно. Но вроде сегодня такими вещами не особенно кто мыслит

> И стандарта на то, "как посылать почту" в винде тоже нет, хотя вообще можно использовать MAPI

МАПИ и есть стандарт.

Flat | Top-Level Comments Only

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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