Показательные выступления на льду.

[metaclass]

Но надо сказать, что последние пляски с Qt, glibc и дебианами, а так же закономерная реакция линукс-френдленты на описание оного хорошо демонстрируют почему с софтом под линукс все так "хорошо".
Софт для end-юзеров и прочие приземленные вещи далеко не всегда пишут отмороженные гики с десятилетним опытом решения бессмысленных безумных проблем. Достаточно походить по форумам по .NET например - там огромное количество вопросов, показывающих, что в ИТ работает много _начинающих_ людей. И вот оным начинающим развлечения, подобные тому, чем я занимался вчера - совершенно ни к чему. Не должен обобщенный "программист кульных прог для бухгалтерии Вася Пупкин" сразу разбираться в тонкостях библиотек, порядка их поиска, версий компиляторов и прочей хреновине. Это должно идти потом, когда софт уже заработал, был продан и надо его улучшать, выпускать новую версию и есть на этот бабки, полученные от продажи первой версии.

Я так понимаю, не всем очевидна конечная цель работы: "написать софт, внедрить клиентам, получить бабки". И что чем меньше времени уйдет на это - тем больше бабок в единицу времени получится. И что время на "чтение гугла и манов", "пересборку QT", "изучение тонкостей поиска shared objects" - это все кем-то должно оплачиваться. Я не знаю, по моему, видеть во всем в первую очередь бизнес-смысл и енд-юзеров - достаточно полезная вещь, хорошо вправляет мозги и компенсирует техно-гиковские перегибы.

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

Comments

[theiced.livejournal.com]

>Извините, но я как бы ВООБЩЕ не в курсе какой они там софт пишет и для кого. Так что вы располагаете куда большей информацией чем я.
Nvidia - sh, skype - пакеты, что есть правильней? Я не могу судить, зависит от приложения.

Я тоже в курсе постолько-поскольку - всё из постов уважаемых ребе. Ситуация простая - приходим к кастомеру в их рассадник жаб и червей (ака серверная) и ставим софт. Просто софт. Дистр свой мы поставить НЕ МОЖЕМ.

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

Там всё ОЧЕНЬ плохо.

>А из пощупанных билд систем (MS build, ant, automake, cmake, scons) cmake имеет оптимальное, на мой взгляд, соотношение вида "функциональность/кактусы", и у него лучшее из виденных решение для интеграции с другими системами сборки.

Для C/C++ - да - cmake лучший, бесспорно. Мне в нём только одно не нравится - имя билд скрипта :)

>Конкретно gui-application на qt буста практически не требует. А если и требует (concept_check/etc) - это всё хидер онли.

Нууууу дааааа - смартпоинтеры ещё, можно согласиться.

>Если конкретно под проект Qt достаточно - я только рад, т.к. это означает что trolltech (nokia) своей цели достигли - у них есть хороший framework.

Угу - Qt очень хорош. Язык бы ещё нормальный (не с++)...

>А если аккумулировать обсуждение - то я был введен в заблуждение постановкой задачи - в постах она выглядит "какой ваш debian гадость"

Ну ребе как раз делают очень полезное дело. Они смотрят на линупсы с точки зрения ведения бизнеса по разработке коммерческого ПО и тыкают мордой в найденные рассадники червей, которые опытные линупсоиды уже не замечают (глаза замылены). И, есть мнение, от них OSSу пользы больше чем от 100500 беларуских красноглазых бебианистов.

>я то вообще ubuntu/gentoo юзаю, но на дебиане несколько лет посидел - и перечисленные проблемы классифицирую "ты жрёшь кактус иголками наружу" - т.е. конкретно стандартные решения под debian выглядят иначе.

Вот видишь - тяжёлое наследие дебиана до сих пор сказывается. Убунту кстати ОК - тама вместо фанатизма целью является удобство конечного юзера.

>Если же задача стоит как "поставлять продукт всем подо всё" то sh скрипт это наиболее простое и удобное решение.

Наиболее удобное - пакеты под всё что можно, но это ДОРОГО. Так что ТОЛЬКО sh скрипт.

[zamotivator.livejournal.com]

Я тоже в курсе постолько-поскольку - всё из постов уважаемых ребе. Ситуация простая - приходим к кастомеру в их рассадник жаб и червей (ака серверная) и ставим софт. Просто софт. Дистр свой мы поставить НЕ МОЖЕМ.
Это лишь косвенно по комментам выясняется. Писал я свой первый коммент не владея этой информацией.

Там всё ОЧЕНЬ плохо.
Верю.

Для C/C++ - да - cmake лучший, бесспорно. Мне в нём только одно не нравится - имя билд скрипта :)
=)
Нууууу дааааа - смартпоинтеры ещё, можно согласиться.
Ну они тоже хидер-онли. Я так и упомянул (concept_check/etc). А то ведь и circular_buffer неплох, function/bind.

Угу - Qt очень хорош. Язык бы ещё нормальный (не с++)..
С++ - язык, а использовать его можно по-разному. Тролли его используют хорошо. Но это всё-таки не единственный способ его использовать хорошо.

Ну ребе как раз делают очень полезное дело. Они смотрят на линупсы с точки зрения ведения бизнеса по разработке коммерческого ПО и тыкают мордой в найденные рассадники червей, которые опытные линупсоиды уже не замечают (глаза замылены). И, есть мнение, от них OSSу пользы больше чем от 100500 беларуских красноглазых бебианистов.
Это я как бэ и не спорю. Просто конкретно упомянутые проблемы - must read из серии idl в COM или manifest в SxS.

Вот видишь - тяжёлое наследие дебиана до сих пор сказывается. Убунту кстати ОК - тама вместо фанатизма целью является удобство конечного юзера.
Система пакетирования в дебиане (убунте) очень удобна для конечного пользователя. Программисту/дистрибьютору сложней, конечно, но решается проблема ровно один раз.

Наиболее удобное - пакеты под всё что можно, но это ДОРОГО. Так что ТОЛЬКО sh скрипт.
Для конечного пользователя ясен пень удобней пакеты.
nvidia - sh, skype - пакеты. Но skype себе это позволить может, а в ситуациях типа описанной sh единственное приемлимое решение. Постепенно, со временем, пакетик за пакетиком можно под все дистры спеки и прочее наколбасить, и собирать их по кноке.

[theiced.livejournal.com]

>Это лишь косвенно по комментам выясняется. Писал я свой первый коммент не владея этой информацией.

Ну это из поста следовало, из последней его фразы.

>С++ - язык, а использовать его можно по-разному. Тролли его используют хорошо. Но это всё-таки не единственный способ его использовать хорошо.

Ну они не юзают с++ные извращения. А совсем правильное использование с++ - это не использовать его совсем.

>Это я как бэ и не спорю. Просто конкретно упомянутые проблемы - must read из серии idl в COM или manifest в SxS.

Не-а. Тут проблема в том что красноглазые (в основном бебианисты) преподносят их как ПРЕИМУЩЕСТВА.

>Система пакетирования в дебиане (убунте) очень удобна для конечного пользователя. Программисту/дистрибьютору сложней, конечно, но решается проблема ровно один раз.

Особенно у того у которого rhel :))) Ну ладно - тут уже поняли что не поняли друг друга сразу :)

[zamotivator.livejournal.com]

Ну это из поста следовало, из последней его фразы.
Значит прочитал невнимательно =)

Ну они не юзают с++ные извращения. А совсем правильное использование с++ - это не использовать его совсем.
У меня перед глазами есть production использование "С++-извращений". Самая близкая аналогия - Haskell type classes. Написана на boost.mpl (metaprogramming library) - Александреску, превед!
Польза от неё несомненная - она уже съэкономила человеко-месяцы, а то и человеко-годы - а занимается эта хрень кодогенерацией и статической верификацией.
Задача - реализация вычислителей SQL-выражений.

Так что у меня есть положительный опыт промышленного использования так называемых "извращений" - и польза от них несомненная, а то, что нужна редко и готовить её толком мало кто умеет - дело десятое.
Я написал кодогенератор (eDSL) в рамках С++, остальные просто пользуют интерфейсы и радуются жизни.

Не-а. Тут проблема в том что красноглазые (в основном бебианисты) преподносят их как ПРЕИМУЩЕСТВА.
В сравнении с системой манифестов или idl - это ПРЕИМУЩЕСТВО.
А то, что с ней пришлось столкнутся - не является НЕДОСТАТКОМ, а является признаком ДРУГИХ ИНСТРУМЕНТОВ.

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

[vp.livejournal.com]

А можно пример что понимаете под С++ извращениями? :)

[zamotivator.livejournal.com]

struct CompareScheme
{
	bool operator()( const impl::Scheme< qd::common::eChar >& a_left, const impl::Scheme< qd::common::eChar >& a_right ) const
		{
			return a_left.size() == a_right.size();
		}
	bool operator()( const impl::Scheme< qd::common::eVarchar >& a_left, const impl::Scheme< qd::common::eVarchar >& a_right ) const
		{
			return a_left.size() == a_right.size();
		}
	bool operator()( const impl::Scheme< qd::common::eDecimal >& a_left, const impl::Scheme< qd::common::eDecimal >& a_right ) const
		{
			return ( a_left.precision() == a_right.precision() ) && ( a_left.scale() == a_right.scale() );
		}
    template< qd::common::EType dataType >
    bool operator()( const impl::Scheme< dataType >& , const impl::Scheme< dataType >& ) const
    {
        return true;
    }
    template< qd::common::EType leftDataType, qd::common::EType rightDataType >
    bool operator()( const impl::Scheme< leftDataType >&, const impl::Scheme< rightDataType >& ) const
    {
        return false;
    }
};

typedef qd::dsd::Function< bool, const CompareScheme&, 
qd::mpl::vector< const qd::pplan::Scheme&, const qd::pplan::Scheme& > >
CompareSchemeFunction;

namespace
{
	CompareSchemeFunction g_compareSchemeFunction;
}

bool operator==( const qd::pplan::Scheme& a_left, const qd::pplan::Scheme& a_right )
{
	return g_compareSchemeFunction( CompareScheme(), a_left, a_right ); 
}

[zamotivator.livejournal.com]

В предыдущем комменте был пример использования.
Вот мааааааленький кусочек реализации dsd::Function

	template< typename Argument, typename Tag = typename tag< Argument >::type > struct size;

	template< typename Argument >
	struct size< Argument, other_tag > : public mpl::integral_c< RuntimeIndex, 1 >
	{
	};

	template< typename Argument >
	struct size< Argument, enum_tag > : 
        public mpl::integral_c< RuntimeIndex, 
            mpl::size< 
                typename get_values< Argument >::type >::value >
	{
	};

	struct template_size_step
	{
		template< typename CurrentSize, typename CurrentDepende >
		struct apply
		{
			typedef mpl::integral_c< RuntimeIndex, CurrentSize::value * size< CurrentDepende >::value > type;
		};
	};

	template< typename Argument >
	struct template_size
	{
    private:
        typedef typename get_dependes< Argument >::type Dependes;
    public:
		typedef typename mpl::fold< Dependes, mpl::integral_c< RuntimeIndex, 1 >, template_size_step >::type type;
    };

	template< typename Argument >
	struct size< Argument, template_tag > :
		public template_size< Argument >::type
	{
	};

[theiced.livejournal.com]

Во во. При виде такого кода у меня начинается мигрень и моск отказывается работать вообще.

[zamotivator.livejournal.com]

А этот код Вам никогда не придётся смотреть.
Он весь спрятан как детали реализации.

[theiced.livejournal.com]

Я про пример использования в том числе:

typedef qd::dsd::Function< bool, const CompareScheme&,
qd::mpl::vector< const qd::pplan::Scheme&, const qd::pplan::Scheme& > >
CompareSchemeFunction;


Всё. Моск выключился. Тут спецсимволов больше чем в типичном перловом коде.

[zamotivator.livejournal.com]

bool operator==( const qd::pplan::Scheme& a_left, const qd::pplan::Scheme& a_right )
{
	typedef qd::dsd::Function< /* Return Type */; bool, const CompareScheme& /* Function object for call */, 
	qd::mpl::vector< const qd::pplan::Scheme& /* Argument 1 */, const qd::pplan::Scheme& /* Argument 2 */ > >
	CompareSchemeFunction;
	static CompareSchemeFunction g_compareSchemeFunction;

	return g_compareSchemeFunction( CompareScheme(), a_left, a_right ); 
}

Так понятней?
Это уже детали реализации функции сравнения =)

[theiced.livejournal.com]

Не - честно - не могу сосредоточиться и вникнуть в этот код. Руби/жава/схема меня хорошоооо так расслабили.

[zamotivator.livejournal.com]

Эта хрень - qd::dsd::Function - вытаскивает из Scheme impl::Scheme-что-то там.

Типа множественного dynamic_cast. Паттерн-матчинг многих аргументов, другими словами - мультиметоды

[metaclass.livejournal.com]

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

[theiced.livejournal.com]

Дык - я о чём говорю. А особенно опасны дети которые с++ных книжек умных начитались и начинают ТАКОЕ городить... Насмотрелся, ага.

[zamotivator.livejournal.com]

Говорили это уже не раз. Резонный аргумент - как сделать тоже самое без "чёрной магии"?
Предлагали там всякие варианты, все оказались ХУЖЕ

[vp.livejournal.com]

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

[theiced.livejournal.com]

Ребе, осторожно. А то того и гляди тоже скоро такой код выдавать будете.

[vp.livejournal.com]

У меня другие мотивы. Код должен быть понятным мне не только сегодня, но и через 10 лет. Или же я потом сам себя буду ругать :)

[theiced.livejournal.com]

И не только `мне` - но ещё и сферическому среднеквалифицированному кодеру.

[theiced.livejournal.com]

>В сравнении с системой манифестов или idl - это ПРЕИМУЩЕСТВО.
А то, что с ней пришлось столкнутся - не является НЕДОСТАТКОМ, а является признаком ДРУГИХ ИНСТРУМЕНТОВ.

Я вообще то про плесень которая начинает произрастать при попытке сделать our-mighty-propietary-app.installer который будет ставиться и рабоать везде. Да - для OS софта это не проблема - есть майнтэйнеры дистров, есть исходники, ... - другая проблема, другие решиения.

[zamotivator.livejournal.com]

Мы практически во всём нашли взаимопонимание и общий язык.
Это не может не радовать =)

[theiced.livejournal.com]

А это потому что ты уже БЫВШИЙ бебианщик. Был бы активно действующим - не нашли бы ;)

[zamotivator.livejournal.com]

*пожал плечами*
Для меня линуксы и С++ - инструменты, а не религия.

[theiced.livejournal.com]

Для меня тоже инструменты. А для бебианщиков - религия. Это беда и беда большая.