Здравствуйте, kaa.python, Вы писали:
KP>Код должен быть простой настолько, насколько это возможно, настолько простой, чтоб в нем мог легко разобраться даже довольно слабый разработчик.

Тем не менее, иногда более сложные инструменты (после их изучения, конечно) позволяют сократить трудозатраты на кодинг. Не согласны?

Здравствуйте, Mr.Cat, Вы писали:

MC>Тем не менее, иногда более сложные инструменты (после их изучения, конечно) позволяют сократить трудозатраты на кодинг. Не согласны?

Могут сократить. Могут увеличить. Но, обычно, проект нужен в лучшем случае прямо сейчас. Соответственно как не крути, код должен быть максимально простым, т.к. рассчитывать на то, что все специалисты в компании знают навороченные и сложные инструменты сложно (если конечно не в гугле или майкрософте работаешь).

Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, alexeiz, Вы писали:

A>> то приходится использовать тупые указатели на функции. А это гемор, не говоря уже о том, что просто тошнить начинает от такого подхода.
A>>Была бы моя воля, всех бы уволил и набрал людей, кто хоть немного современный C++ знает.

KP>А что в плохого в простых указателях на функции?

Эээ, с чего изволите начать?
* состояние в указатель на функцию не положишь, нужно передавать отдельно.
* состояние передается обычно как void*, нужно приводить к нужному типу с помощью unsafe C-style cast-а, type-safety никакая.
* если у объекта состояния еще есть деструктор, который надо вызвать, когда ... а когда, кстати? — это еще прийдется выяснить для каждого конкретного случая. С boost::function все элементарно.
* параметры функции должны совпадать с параметрами, указанными в типе указателя на функцию. В boost::function могут производится конвертация параметров.
* по удобству использования указатели на функцию явно проигрывают boost::function, благодаря тому, что function — это гораздо более высокоуровневая конструкция, чем тупой указатель на фукцию.

Даже Страуструп в одном интервью сказал, что его уже достали низким уровнем абстракции. Доступно множество библиотек, которые предоставляют классы для инкапсуляции объекта состояния и функции, а многие до сих пор используют тупые указатели на функции.

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

В результате получаем, что с boost::function код упрощается до невозможности. Ан нет! Мы хотим указатели на функции и все тут! Уберите эти шаблоны! Не хотим ничего нового учить, никаких новых концепций нам не надо. Cи наше все!

Здравствуйте, alexeiz, Вы писали:

A>Не хотим ничего нового учить, никаких новых концепций нам не надо. Cи наше все!

Добавлю: а потом еще и жалуются — "C++ такой низкоуровневый язык, такой низкоуровневый! У него столько проблем. Вы только посмотрите, какие в нем тупые указатели на функции! Пора на новый язык переходить."

Здравствуйте, Mr.Cat, Вы писали:

MC>Тем не менее, иногда более сложные инструменты (после их изучения, конечно) позволяют сократить трудозатраты на кодинг. Не согласны?

Именно что трудозатраты и именно что на кодинг.
Более опытному специалисту, освоившему более сложные инструменты и способному все сделать быстрее, придется заплатить больше.
А насколько сложнее станет тестирование? А саппорт?

Здравствуйте, Mr.Cat, Вы писали:

А>>А может на JavaScript будем драйверы писать?
MC>На C# когда на сингулярити пересядем. ;)

Ну и пересаживайтесь, а наше всё — это Hurd.

Здравствуйте, alexeiz, Вы писали:

E>>Цель программирования-то не код покруче навернуть, а разработать что-то нужное и полезное.
A>К сожалению, потому что код писать с применением высокоуровневых возможностей языка проще. Но эти возможности большинство не знает.
Ну мой опыт показывает мне, что чем более высокоуровневыми конструкциями С++ пользуются разработчики, тем легче его написать WriteOnly. В результате либо падает качество разработки (те же спецы + продвинутые конструкции), либо растёт её цена (продвинутые конструкции + более крутые, и следовательно дорогие разработчики)
Фишка в том, что некоторые задачи проще решать при помощи функторов, но таких задач не много, и это не повод усложнять и, следовательно, удорожать весь остальной код.
A>Поэтому если ты в команде, где никто не знает что такое функтор (забудьте о boost::function), и любое применение функтора их в шок бросает, то приходится использовать тупые указатели на функции. А это гемор, не говоря уже о том, что просто тошнить начинает от такого подхода.
IMHO, в функторах нет ничего особенно крутого, но и в указателях на функции нет ничего плохого. Наоборот, при использовании указателей на функции и интерфейсов уменьшается количество шаблонного кода, например...

A>Была бы моя воля, всех бы уволил и набрал людей, кто хоть немного современный C++ знает.
Ну создавай свой бизнес и вперёд...
Только ты быстро очень столкнёшься с экономической неэффективностью подобных, отрентированных на "красоту кода" решений...

Здравствуйте, kaa.python, Вы писали:

KP>Могут сократить. Могут увеличить. Но, обычно, проект нужен в лучшем случае прямо сейчас. Соответственно как не крути, код должен быть максимально простым, т.к. рассчитывать на то, что все специалисты в компании знают навороченные и сложные инструменты сложно (если конечно не в гугле или майкрософте работаешь).

А разве в MS используют особо продвинутые инструменты?

Здравствуйте, alexeiz, Вы писали:

A>* состояние в указатель на функцию не положишь, нужно передавать отдельно.
Если требуется состояние, то, иногда, хватает и интерфейса. Кроме того, можно и функтор использовать, но только если не слишком много шаблонного кода прийдётся породить из-за этого
В конце концов, если рассматривать два решения -- через интерфейсы и через функторы, передающиеся в шаблонный алгоритм, то второе -- это всего лишь оптимизация первого. Ну а нужна ли в каком-то конкретном месте оптимизация -- вопрос отдельный...

A>* состояние передается обычно как void*, нужно приводить к нужному типу с помощью unsafe C-style cast-а, type-safety никакая.
Юзай интерфейсы. Интерфейсы в твоей компании использовать ведь не запрещено? void* обычно используют в чисто С'шном API. Вдруг теми же сервисами не только из C++ пользуются?

A>* если у объекта состояния еще есть деструктор, который надо вызвать, когда ... а когда, кстати? — это еще прийдется выяснить для каждого конкретного случая. С boost::function все элементарно.
1) IMHO, нетривильный деструктор функтора -- не очень хорошо.
2) Вариант с интерфейсами просто и понятно решает проблемы с владением. Например объект, реализующий интерфейс может быть автоматическим в месите вызова
3) Я бы не стал, в случае деструктора функтора, делающего что-то нетривильное (например закрывающего файл), звать его как-то неявно. Типа код вида //// Evaluation.h

struct IEvaluator {
    virtual int GetEvaluation( /* params */ ) const  = 0;
};
extern int UseEvaluator( const IEvaluator* );
// Мой файл
class ByFileEvaluator : public IEvaluator {
    //        тут реализация
} 
void foo()
{
    ByFileEvaluator evaluator( "data.file" );
    UseEvaluator( &evaluator );   
}

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

A>* параметры функции должны совпадать с параметрами, указанными в типе указателя на функцию. В boost::function могут производится конвертация параметров.
Опять же, не ясно зачем это так надо.

A>* по удобству использования указатели на функцию явно проигрывают boost::function, благодаря тому, что function — это гораздо более высокоуровневая конструкция, чем тупой указатель на фукцию.
Зато по удобству отладки/поддержки лучше средства традиционные...
Ну тупо в отладчике хорошо вижно, лог проще впихнуть, компиляция быстрее и т. д

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

A>В результате получаем, что с boost::function код упрощается до невозможности. Ан нет! Мы хотим указатели на функции и все тут! Уберите эти шаблоны! Не хотим ничего нового учить, никаких новых концепций нам не надо. Cи наше все!

Почему, как без шаблонов, так сразу не С++?

Здравствуйте, alexeiz, Вы писали:

A>>Не хотим ничего нового учить, никаких новых концепций нам не надо. Cи наше все!

A>Добавлю: а потом еще и жалуются — "C++ такой низкоуровневый язык, такой низкоуровневый! У него столько проблем. Вы только посмотрите, какие в нем тупые указатели на функции! Пора на новый язык переходить."

Все оно конечно так, да не так. Поддержка абстракций на уровне библиотек (ala boost) и на уровне языка — это две большие разницы.
И именно поэтому "пора на новый язык переходить".

Если язык А поддерживает абстракцию F как "first class citizens" ("как родную" другими словами), а язык B сам по себе не поддерживает F — а только через библиотеки, то при прочих равных работать с F будет удобнее в А.

Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, Mr.Cat, Вы писали:

А>>>А может на JavaScript будем драйверы писать?
MC>>На C# когда на сингулярити пересядем.

RO>Ну и пересаживайтесь, а наше всё — это Hurd.

Вот именно что "все". В смысле "все, приплыли". А мы вот пересядем, и дальше поплывем :-Р

Здравствуйте, <Аноним>, Вы писали:

А>Просто интересно мнение что будет следующим мэйн-стримом: C++0X или язык D?

Ну если говорить о мейнстриме в unmanaged мире, то, безусловно, первый. Поддержка его элементов уже скоро будет в том же VS 2010, а вот для D есть только пара компиляторов и оба в неособо стабильном состоянии.

Здравствуйте, Erop, Вы писали:

E>А разве в MS используют особо продвинутые инструменты?

Используют. МС большой.

Здравствуйте, alexeiz, Вы писали:

A>В результате получаем, что с boost::function код упрощается до невозможности. Ан нет! Мы хотим указатели на функции и все тут! Уберите эти шаблоны! Не хотим ничего нового учить, никаких новых концепций нам не надо. Cи наше все!

На D подобный код еще больше упрощается, вот только все равно он будет написан на C++

Здравствуйте, AndrewVK, Вы писали:

E>>А разве в MS используют особо продвинутые инструменты?
AVK>Используют. МС большой.
Ну в смысле, что "матан большой, что-нибудь да не знает", понятно...
Но масоово разве используют?

Здравствуйте, Didro, Вы писали:

D>Если язык А поддерживает абстракцию F как "first class citizens" ("как родную" другими словами), а язык B сам по себе не поддерживает F — а только через библиотеки, то при прочих равных работать с F будет удобнее в А.

IMHO, это отличие искусственное. Что там из библиотеки, а что из самого языка -- вопрос крайне мутный, кроме того, например, то, насколько ту или иную фичу поддерживают IDE, часто важнее, чем что там язык, а что нет.

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

Здравствуйте, alexeiz, Вы писали:

A>Была бы моя воля, всех бы уволил и набрал людей, кто хоть немного современный C++ знает.

Советую обратить внимание на автора этого сообщения

Автор: Alexander G
Дата: 17.11.08

Здравствуйте, kaa.python, Вы писали:

KP>Viva проект в срок, с использованием тех ресурсов, которые на данный момент доступны.
С этим никто и не спорит. Меня удручает другое — когда этим "довольно слабым разработчикам" не (дают/разрешают/предоставляют возможность) повышать квалификацию, в результате общий уровень команды так и остаётся на уровне "Си начала 90х" или "Си плюс проект". Понятно, что есть ещё и самообразование, но и компания ведь должна быть заинтересована в повышении квалификации работников. Оффтоп, но наболело

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Didro, Вы писали:

E>Если хочешь возразить, то можешь попробовать проиллюстрировать свои рассуждения на примере языка форт...

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

но мне кажется, мы говорили про C++.

Здравствуйте, Didro, Вы писали:

D>Если язык А поддерживает абстракцию F как "first class citizens" ("как родную" другими словами), а язык B сам по себе не поддерживает F — а только через библиотеки, то при прочих равных работать с F будет удобнее в А.
Зато язык В получается более общим. Хотя насчёт "удобнее" согласен.