![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Кстати, насчет "биндингов"
В дискуссиях о GUI для всяких эзотерических и не очень языков постоянно всплывает тема "биндингов" к ним для QT, GTK и прочего.
Так вот, мое имхо состоит в том, что язык, у которого нет собственной GUI библиотеки - неполноцен в принципе. Вот, к примеру, захочу я расширить функциональность некоего GUIшного контрола или написать свой. Или просто разобраться в тонкостях его работы, типа "когда вызывается такое-то событие". Если GUIшная либа писана на том же языке на котором я работаю, мне не нужно переключать мозг на чужеродный язык и его стиль, чтобы работать с ней. А если нет - начинается всякая хрень, типа самого это биндинга, единственное назначение которого - гонять туда-сюда вызовы между одним и вторым языком.
Оно конечно полезно, знать несколько языков. Но вот для работы эти переключения между языками не сильно полезны.
PS: Вообще эта идея меня посетила, когда я думал насчет того, как наиболее естественным образом выглядел бы GUI для Хаскеля. Вообще, проблема сама по себе более общая, чем GUI - я ее для себя сформулировал так "Как хранить/обрабатывать в языке общего назначения некую структуру данных, если этот язык для нее плохо подходит". Обычно делают отдельные структуры/языки для разных предметных областей - SQL для баз, декларативные иерархические описания для всяких GUI-шных и прочих форм, для них отдельные редакторы-дизайнеры.
Вот именно "отдельность" мне и не нравится - что-то раздражает переключать контекст мышления, когда надо к программе приделать GUI, взаимодействие с БД, или печатную форму.
Да и вообще работа с GUI может выражаться в языке каким-нибудь другим, гораздо более естественным для него способом, нежели последовательное создание контролов и чтение/запись их свойств. Тот же Хаскель, по моему мнению, вообще GUI должен генерировать автоматически при компиляции, исходя из информации о типах.
Так вот, мое имхо состоит в том, что язык, у которого нет собственной GUI библиотеки - неполноцен в принципе. Вот, к примеру, захочу я расширить функциональность некоего GUIшного контрола или написать свой. Или просто разобраться в тонкостях его работы, типа "когда вызывается такое-то событие". Если GUIшная либа писана на том же языке на котором я работаю, мне не нужно переключать мозг на чужеродный язык и его стиль, чтобы работать с ней. А если нет - начинается всякая хрень, типа самого это биндинга, единственное назначение которого - гонять туда-сюда вызовы между одним и вторым языком.
Оно конечно полезно, знать несколько языков. Но вот для работы эти переключения между языками не сильно полезны.
PS: Вообще эта идея меня посетила, когда я думал насчет того, как наиболее естественным образом выглядел бы GUI для Хаскеля. Вообще, проблема сама по себе более общая, чем GUI - я ее для себя сформулировал так "Как хранить/обрабатывать в языке общего назначения некую структуру данных, если этот язык для нее плохо подходит". Обычно делают отдельные структуры/языки для разных предметных областей - SQL для баз, декларативные иерархические описания для всяких GUI-шных и прочих форм, для них отдельные редакторы-дизайнеры.
Вот именно "отдельность" мне и не нравится - что-то раздражает переключать контекст мышления, когда надо к программе приделать GUI, взаимодействие с БД, или печатную форму.
Да и вообще работа с GUI может выражаться в языке каким-нибудь другим, гораздо более естественным для него способом, нежели последовательное создание контролов и чтение/запись их свойств. Тот же Хаскель, по моему мнению, вообще GUI должен генерировать автоматически при компиляции, исходя из информации о типах.
Re: Пофлеймлю :)
А вот по поводу кодогенераторов тут предубеждение на уровне постановки задачи. Я считаю, что это плохая архитектура, когда никак кроме как нагенерить налету кода и выполнить не получается. Кривовато это.
Re: Пофлеймлю :)
Привожу пример из практики - одна девочка (индия, компания CMMI-5) сделала copy-paste 32 раза. В исходном коде была ошибка. Стало 32 ошибки. Сидел и исправлял, нашёл не везде в первый день, во второй тоже не всё.
Что можно автоматизировать - надо автоматизировать. И кодогенерация - отличный метод исключить механические ошибки оператора/кодировщика на массово-однотипных задачах. Юнит-тесты, FSM для сетевых протоколов. К примеру, в samba4 огромное количество кода, отвечающего за протоколы - перенесли в кодогенерацию, чуть ли не до 50% всех исходных кодов.
http://www.nestor.minsk.by/sr/2008/08/sr80803.html - из той же поездки история. Решить задачу чем либо кроме кодогенерации в указанные сроки было невозможно (исполнители не увидели вариантов). Решение получилось прямое и конкретное. Как бы Вы решили эту проблему?
Re: Пофлеймлю :)
Я подуал про "создать налету скрипт" и послать его на выполнение из системы рунтаймово. Типа такой полуинтерпретатор.
Re: Пофлеймлю :)
Вида - "Тонкий клиент" - "Толстый сервер". Система - универсальный конфигуратор системы, с прицелом на фаервол.
Сервер генерирует код на TCL, передаёт его клиенту. Клиент код выполняет. Сервер на Ruby, клиент естественно на TCL. Ещё есть живые свидетели волшебства.
К сожалению проектировщик системы значительно опережал в развитии как специалист конечных исполнителей. Более того - он даже не предполагал, что его прототип-набросок начнут развёртывать в Production систему. Но работало в итоге неплохо, несмотря на студентов.
Re: Пофлеймлю :)
В особенности если скрипт состоит из 50-100 вызовов внешней утилиты, незначительно отличающихся лишь параметрами и порядком следования, а вся лаконичная логика, определяющая эти вызовы, задается юзером (т.е. заранее не предсказана) и анализируется двумя уровнями выше.
Re: Пофлеймлю :)
Re: Пофлеймлю :)
Прошу поверить на слово, что мои текущие задачи без кодогенерации нерешаемы в принципе. А с кодогенерацией -- пишутся, отлаживаются, работают с приемлемым качеством.
Направление -- регулярная обработка больших объемов данных по произвольным определяемым пользователем алгоритмам.
Re: Пофлеймлю :)
Re: Пофлеймлю :)
Re: Пофлеймлю :)
Т.е. самостоятельная наколенная реализация SMTP? Зачем?
Re: Пофлеймлю :)
Только SMTP и священный грааль всех времён - HTTP и остаются. Жизнь так пуста ...
:)
Re: Пофлеймлю :)
Re: Пофлеймлю :)
Re: Пофлеймлю :)
Re: Пофлеймлю :)
то ему кроме перенастройки собственно почтовой службы на этом хосте понадобится еще всему "нативному" коду докладывать об изменениях. И молиться, чтобы нативный код эти изменения понял и оказался в состоянии реализовать.
Кстати, в том же перле ЕМНИП большинство библиотек по отсылке почты используют в качестве backend-а утилиту mail, что абсолютно правильно.
Re: Пофлеймлю :)
Но это мы уже опять переходим в область спора "стиль винды" vs "стиль unix". В первом случае монолитный софт с минимум внешних зависимостей является наилучшим выбором, т.к. дает свободу от идиотизма юзеров, "админов", обновлений винды и прочего шлака. В юниксах, видимо, с их стандартизированным подходом, многокомпонентный софт является нормальным. Хотя у меня еще есть подозрение, что в юниксовом случае админы настолько привыкли к зависимостям софта друг от друга, что их это не парит, и заниматься разборками "что сломалось" в зависимостях, для них видимо привычно.
Re: Пофлеймлю :)
Потому что нужные тебе компоненты системы перед этим несколько лет тестировались пользователями и разработчиками testing-а с гораздо лучшим покрытием, чем ты бы обеспечил в рамках своего проекта и "монолитной" реализации.
Поэтому с точки зрения линуксового админа добавление/удаление любых зависимостей из репозитория создает не больше проблем, чем для админа виндового добавление-удаление стандартных "компонентов системы" под Windows.
А "стороннее" (т.е. в linux-овой терминологии отсутствующее в официальных репозиториях), действительно в систему без крайней нужды тягать не принято. И если уж притянул -- то ты и сопровождаешь, как свой код.
Благо, нужда такая крайне редко возникает. Как правило, репозиториев хватает.
Re: Пофлеймлю :)
Но вообще идея "официальных репозиториев" меня пугает. Это означает, что разработчиками постулируется "пользователям ничего кроме того, что мы посчитали кошерным не нужно".
Re: Пофлеймлю :)
Re: Пофлеймлю :)
Re: Пофлеймлю :)
Мы занимаемся генерацией писем. Их транспортировкой, как и всех остальных, занимается MTA, настроенный админом. Все что нашему софту надо знать о хосте, где он крутится -- это поле From, которое мы вставим в свои письма (и то необязательно).
А уж админ отвечает за настройку маршрутов почты, mx-ресолвинг и прочие прелести. Нам до этого нет дела. А ему нет дела до деталей нашей реализации.
И если ему завтра скажут "вынести почтовый сервер на отдельный хост, всю почту пустить через него, закрыть 25й порт со всех остальных коробок" -- то он поправит настройки МТА на нашем хосте в одном месте, и еще на n хостах стандартным образом. И после пары пробных писем будет уверен что все теперь ходит как надо и ничего не сломалось.
И ему не придется вести учет каждой апликухи, считающей себя MTA на application сервере. И уж тем более не придется бегать за разработчиками, и умолять их переписать систему в связи с новой настройкой почтовых маршрутов, отказавшись от предположения, что апликейшн сервер всегда смотрит прямо в мир и обратно ресолвится именно по тому самому адресу, который софтина пишет в поле From.
Re: Пофлеймлю :)
В моих случая админы - это не добрые феи, которые по зову сердца перестроят системные утилиты, а выжившие из ума ленивые саботажники, которые вполне могут не быть заинтересованы в том, чтобы эта система лучше работала, потому палец о палец не ударят для чего-либо. Или админов вообще может не быть, что случается ровно в 90% случаев всех внедрений. Вот нет его, и все. Потому монолитность софта в большинстве случаев - это упрощение жизни, это подконтрольность версионности и возможность осуществлять этот контроль персоналу с достаточно низкой квалификацией (обслуживание).
Мое видение по опыту такое.. Подтверждается совершенно разными областями народного хозяйства разных стран.
Re: Пофлеймлю :)
Re: Пофлеймлю :)
Re: Пофлеймлю :)
Re: Пофлеймлю :)
Re: Пофлеймлю :)
Re: Пофлеймлю :)
Re: Пофлеймлю :)
Re: Пофлеймлю :)
Re: Пофлеймлю :)
Re: Пофлеймлю :)
Re: Пофлеймлю :)
Re: Пофлеймлю :)
Re: Пофлеймлю :)
Re: Пофлеймлю :)
1 протокол - легко!
2-3 протокола - намана!
4-8 протоколов - упс, нужно ещё пару студентов
9 и более - где-то здесь нагрянул пушной писец
Дальнейшая поддержка написанного кода. Мы же о промышленном программировании? О минимизации времени, затрат и упрощении поддержки. Сторонние компоненты тем и хороши, что мы не пишем свою ОС для каждого проекта.
Re: Пофлеймлю :)
Re: Пофлеймлю :)
Другой вопрос что если "нативной" библиотеки нету, но есть надежная и проверенная библиотека на другом языке (как правило, более низкого уровня), то никто не будет изобретать велосипед, париться и писать "нативную", если только это не дает существенного выигрыша в производительности для широкого спектра приложений.
Необходимость "пройти все одним сквозным отладчиком от GUI до драйвера" разработчикам языков программирования и библиотек широкого применения, скажем политкорректно, неочевидна.
Re: Пофлеймлю :)