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

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

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

M>[skiped...]
R>>Не используем паттерны проектирования и сложную архитектуру, т.к. могут придти программисты не разбирающиеся в этом.
M>[skiped...]

M>Конечно не используем "сложную архитектуру" но применяем патерны. Задача патернов — упростить архитектуру а не наоборот.
M>хорошая архитектура == простая архитектура, самая простая которая решает поставленные задачи.

Как бы то ни было, паттерны тоже не применяем, т.к. не все же студенты знакомы с ними. Ну оканчивается название класса на Visitor. Ну и что? Кому-то это ничего не скажет.
Так что 20 функций из С и ни фичей больше

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

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

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

J>Этот подход тоже вполне имеет право на существование.
J>Чем менее квалифицированные программисты нужны, тем меньше риски проекта, потому что в любой момент ты можешь взять с улицы первого попавшегося и он вольется в команду за пару дней.
J>А если сидит квалифицированный перец, который мыслит исключительно рекурсивными шаблонами — то даже если ты построишь процесс разработки так, что все будет хорошо, пока этот программист в штате, что случится, когда он уйдет? Кто подхватит знамя? Аналогичного по скиллам ты быстро не найдешь, а проект все это время должен развиваться (банально должны оперативно фикситься баги), а не ждать, когда же придет очередная звезда с "шаблонным" мышлением.


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

А если процесс строиить как ты предлашаешь, то тут по любому будут проблемы. И рекурсивные шаблоны тут ни при чём. Проблемы будут хотя бы в том, что один перец будет сидеть и планомерно переназывать переменные value_ в m_iValue по всему проекту, а его сосед будет планомерно переназывать переменные m_iValue в value_ по всему проекту.

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

А уж если команда — это команда. То тут она может себя не ограничивать в средствах. И использовать наиболее эффективные на её взгляд. Тут она может пользоваться не пересечением, а объединением множеств умений.

Имхо.


Есть только одна ситуация, в которой такой подход может не работать. Это когда собственно команды нет как таковой. Т.е. вначале полгода проект пописал один программист. Потом он уволился. Потом ещё через полгода наняли ещё одного программиста продолжать проект. В такой ситуации согласен с точкой зрения, которую ты привёл. Но только в такой ситуации. Если же есть команда, которая постоянно состоит хотя бы из двух-трёх человек, то не согласен.

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

E>А что и куда надо внедрить, чтобы стал проще и понятнее код с мультиметодами, например, я не знаю

здесь

Автор: remark
Дата: 08.03.06

я писал об этом. И в ветке там ещё примеры есть.

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

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

R>>Всё это перекликается ещё с такой мыслью, что все эти библиотеки, паттерны и приёмы — это готовые решения типовых проблем. И если программист ещё не сталкнулся с этой проблемой, или скорее сталкнулся, но для него ещё не стало очевидно, что это проблема, и что хорошо бы иметь готовое решение для неё, у этого программиста такие вещи, конечно, не будут вызывать ничего кроме недоумения. Конечно он будет говорить, что это ненужное усложнение.

E>Я в целом согласен, что во всей теории есть и полезное. Я, например, зачем-то книжку таки почитал и Loki посмотрел
E>Но на практичке я постоянно встречаю людей, которые применяют налево и направо навороты, и совсем не встречаю, таких, которые пишут плохо, потому что наворотов от Александреску не применили

Повезло


E>Ну на самом деле задачи просто проще методов Александреску. Увы, такая вот жизнь вокруг меня. Хотя программы в целом непростые, так скажем. И программисты квалифицированные.

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



E>Ещё могу поделиться такой историей. У нас тут был недавно сотрудник, который очень хоршо знает и паттерны и STL и вообще всё. Настолько хорошо, что препадаёт это всё в одном уважаемом очень ВУЗе

А теоретиков вообще лучше до практики не допускать
Знаешь, возможно есть много докторов по химии, которые уже и не помнят как пробирки выглядят

Меня лично интересует только то, что начикается со слов practical или applied.


У нас тоже был один препод, который любил считать "так, значит у списка в этом случае вычислительная сложность будет O(1), значит используем список", эх, профайлер бы ему в руки

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

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

R>>Некоторые виды дублирования нельзя устранить ни какими способами, кроме advanced-templates (не считая таких отстойных вещей как макросы и void*).

R>>Моё обоснование использования advanced-templates в двух указанных выше предпосылках.

R>>По мимо очень большой скорости правки кода, тебе так же понадобиться идеальная внимательность, т.к. при исправлении какого-либо аспекта в паре десятков мест надо везде сделать правильно.

R>>Идеальной внимательностью я кстати тоже не обладаю, поэтому не люблю, когда мне приходится "поправлять" десятки "почти похожих мест" в проекте.


E>Прекрасно!
E>Расскажи как тебе помогают в твоих многочисленных бедах мультиметоды и for_each


E>Главная проблема с шаблонами, ИМХО, такая, что часто при редактировании нетривильного шаблона очень трудно предсказать все последствия.

Одно из свойств advanced-templates в том, что "уж если вся эта бойда скомпилировалась, значит она работает так, как надо". Я в этом сам неоднократно убеждался на примере boost::bind.
Ты фактически описываешь то, что ты хочешь получить декларативно. Да, иногда, вызывает проблемы объяснить компилятору, что же именно ты хочешь получить, что бы он понял. Но уже если объяснил, то это работает. Т.к. ты не описывал, как ты хочешь это получить. А ошибки бывают обычно именно в этом.
Т.е. проблемы обычно присытствуют в компайл-тайм.
При использовании старых добрах ран-тайм средств всё проблемы просто переносятся соответственно в ран-тайм.
Выбирать каждому самому. Я лично предпочитаю проблемы в компайл-тайм.


Приведу пример. Недавно надо было поправить ядро библиотеки. Библиотека была на так сказать advanced-templates. Написана была достаточно грамотно. Так вот после исправления некоторой части кода, попытался скомпилировать. Не скомпилировалось. Многое сломалось. Где-то static_assert'ы ругаются, где-то просто компилятор. При использовании явных интерфейсов, всё бы замечательно скомпилировалось — ошибки пришлось искать в ран-тайме. Вот в частности за такие вещи мне нравятся advanced-templates и идеи А.

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

J>Здравствуйте, Константин Л., Вы писали:

J>>>На мой взгляд, этот паттерн — один из самых неудачных.
КЛ>>Неудачных паттернов не бывает. У всех у них есть свои недостатки и преимущества. Неудачным бывает место его применения. К тому же, там все просто до ужаса, в чем там можно запутаться? Ну да ладно, вам виднее.

J>Там все просто, пока ты остаешься на уровне 'hello world', пока не дойдет до реального кода, который выдержал с десяток запросов от бизнеса/пользователей.
J>А в реальном коде все превращается в монстра типа того, о котором я рассказал.
J>У тебя ведь у самого реального опыта с этим паттерном нет, насколько я понимаю из треда выше.
J>Вот когда твой код с визиторами таким образом (десяток выполненных запросов) заматереет, тогда и поговорим.

J>Я вполне допускаю, что сейчас тебе все нравится, но вот что останется от этого кода после того, как по нему 10 раз пройдутся программисты, решая совершенно разные задачи, которые перед ними поставили пользователи? Насколько им будет удобно ворочаться в твоей визиторской структуре?
J>Насколько после этих перепахиваний код останется красивым и простым, и вообще останется ли он, или очередной бедолага, у которого вдруг оказалось свободное время, просто возьмет и перепишет все заново?

Я в команде, слава богу, один

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

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

R>Ну это пока проект не особо большой. А когда проект переступает определённую черту, то коды ошибок начинают постепенно всасывать, причём со временем всё больше. имхо.
В целом я абсолютно согласен, что есть некоторый объём сложности задачи, когда обработка ошибок при помощи продуманного использования исключений, и при условии внедрения некоторых других правил (полезных безотносительно получается проще и поддерживаемее, чем при помощи кодов возврата.
Ещё я согласен, что при помощи исключений можно написать более надёжную и предсказуемую программу. Но при этом это надо суметь сделать. Тем не менее, хотя сами по себе исключения сложнее кодов возврата, порог этот низкий очень и в многих задачах обрабатывать ошибки при помощи исключений проще. И тогда их конечно же надо использовать.
Но, скажем, в такой программе:

int main( int, const char*[] )
{
    chra c;
    while( cin >> c ) 
        cout << c;
    return 0;
}

Исключения использовать, ИМХО, неправильно

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

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

R>Я совершенно согласен, что мультиметоды вещь достаточно редкая, поэтому к ним такое и отношение. Но А тут совершенно ни при чём. Он лишь предложил достаточно хорошую реализацию мультиметодов. Но в том, что это редкая вещь, он не виноват.
Крнечно не виноват! Это его заслуга, что он смог придумать столь редкую задачу и решение для неё. Просто вся эта штука очень далека от реальной жизни
А виноват чувак, который решает внедрить мультиметоды туда, где они не нужны. Потому что так "покруче" будет

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

R>Как бы ты предложил это реализовать?

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

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

A_A>>Для расширения кругозора — можно узнать причины, которые мешают заменить используемую реализацию STL на другую, кроме заточенности
A_A>>кода на особенности конкретной реализации и своих доработок ее напильником?
E>Примеры причин, которые я встречал
E>...
Спасибо.

A_A>>STL такая, какая есть, потому что нацелена на универсальность использования, а более общее и универсальное решение
A_A>>всегда сложнее более частного решения.
E>Ну так я про то и спорю, что идеология, что если есть возможность вместо конкретного средства забацать (или использовать) "универсальный всемогутер", то надо делать всемогутер. А мне кажется, что нужно ровно наоборот. Чем меньше всемогутеров и чем менее они универсальны, тем обычно это ближе к оптимальному инженерному решению, а идея многих неопытных программистов и даже, как это не печально, многих преподавателей, ровно противоположенная
Чем более специализировано решение, тем более узка область его применения.
Соответственно, количество нобходимых "могутеров" возрастает при росте их специализированности.
В пределе — под каждую задачу с нуля пишется специализированное решение, что далеко не всегда оправданно.
Поэтому нужен баланс между простотой и универсальностью решения.

E>>>А многим неопытным инженерам кажется, что намного важнее применить какой-то сверхумный и сверхгибкий указатель, да ещё проследить, чтобы не было goto
A_A>>Понимание многих вещей приходит только с опытом.
E>Ну можно считать, что я пытаюсь им делиться, но некоторые с ним не согласны
Я бы удивился, если бы все были согласны. У каждого свой опыт и свой взгляд на вопросы разработки ПО.
Поэтому утверждение "STL — зло" не для всех является истинным , и для этого есть свои резоны.

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

R>Как бы то ни было, паттерны тоже не применяем, т.к. не все же студенты знакомы с ними. Ну оканчивается название класса на Visitor. Ну и что? Кому-то это ничего не скажет.
R>Так что 20 функций из С и ни фичей больше

Это всё крайности, а я за взвешенность и умеренность выступаю

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

E>>Но на практичке я постоянно встречаю людей, которые применяют налево и направо навороты, и совсем не встречаю, таких, которые пишут плохо, потому что наворотов от Александреску не применили
R>Повезло
А ты часто встречал людей, которые написали плохой код именно потому, что не применили идеи А?
Опиши как это было-то?

E>>Ну на самом деле задачи просто проще методов Александреску. Увы, такая вот жизнь вокруг меня. Хотя программы в целом непростые, так скажем. И программисты квалифицированные.
R>Смотря какие подразумевать критерии хорошего решения задачи?
Успешные многолетние проекты. С большим числом версий, миллионами инсталляций по миру. Поддержка, развите. Очень сложные задачи в смысле того, что не очевидно как это реализовывать вообще, сложные пользовательсткие интерфейсы и т. д.
Есть, в том числе, и программы, являющимися лучшими или одними из лучших в мире в своих сегментах.
R>Если только наличие требуемого поведения, то тогда конечно любую задачу можно решить очень просто...
Сопровождение и развитие ещё требуется.

R>Меня лично интересует только то, что начикается со слов practical или applied.
+1

Здравствуйте, Anton V. Kolotaev, Вы писали:

E>>Казалось бы граф. движок не должне быть сверхсложен архитектурно.
AVK> Интересно, на чем основано это мнение?

Ну, скажем так, он дожен быть намного проще ОС, например.
Нет? Возможно я неправильно понгимаю, что скрывается за словми "графический движок"

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

E>>Прекрасно!
E>>Расскажи как тебе помогают в твоих многочисленных бедах мультиметоды и for_each

E>>Главная проблема с шаблонами, ИМХО, такая, что часто при редактировании нетривильного шаблона очень трудно предсказать все последствия.

R>Одно из свойств advanced-templates в том, что "уж если вся эта бойда скомпилировалась, значит она работает так, как надо". Я в этом сам неоднократно убеждался на примере boost::bind.
Ну, в целом, ты совсем не ответил на мой вопрос

R>Ты фактически описываешь то, что ты хочешь получить декларативно. Да, иногда, вызывает проблемы объяснить компилятору, что же именно ты хочешь получить, что бы он понял. Но уже если объяснил, то это работает. Т.к. ты не описывал, как ты хочешь это получить. А ошибки бывают обычно именно в этом.

Ну в целом подход похвальный. Но есть две беды.
1) Очень уж неудобный язык описания моих желаний
2) Компилятору-то я может и объясню, но лучше бы объяснять тому, кто будет этот код поддерживать

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

A_A>Поэтому нужен баланс между простотой и универсальностью решения.
Конечно, просто мне кажется, что в STL баланс неоправданно смещён в сторону универсальности. Вот, скажем, в каких языках было нужно реализовывать алгоритм merge в библиотеке?

E>>>>А многим неопытным инженерам кажется, что намного важнее применить какой-то сверхумный и сверхгибкий указатель, да ещё проследить, A_A>Поэтому утверждение "STL — зло" не для всех является истинным , и для этого есть свои резоны.

Ну это понятно. Но я не считаю STL злом. Я злом считаю стремление к переусложнению кода. STL, имхо, пал жертвой этой моды, но безусловно это полезная и нужная библиотека. Просто если её "опростить" для нужд своего проекта, то она станет ещё лучше

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

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

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

R>>Ну это пока проект не особо большой. А когда проект переступает определённую черту, то коды ошибок начинают постепенно всасывать, причём со временем всё больше. имхо.
E>В целом я абсолютно согласен, что есть некоторый объём сложности задачи, когда обработка ошибок при помощи продуманного использования исключений, и при условии внедрения некоторых других правил (полезных безотносительно получается проще и поддерживаемее, чем при помощи кодов возврата.
E>Ещё я согласен, что при помощи исключений можно написать более надёжную и предсказуемую программу. Но при этом это надо суметь сделать. Тем не менее, хотя сами по себе исключения сложнее кодов возврата, порог этот низкий очень и в многих задачах обрабатывать ошибки при помощи исключений проще. И тогда их конечно же надо использовать.
E>Но, скажем, в такой программе:
E>

E>int main( int, const char*[] )
E>{
E>    chra c;
E>    while( cin >> c ) 
E>        cout << c;
E>    return 0;
E>}
E>

E>Исключения использовать, ИМХО, неправильно

Я согласен, что и идеи А в такой программе применять не стоит



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

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


Я тебя уверяю, что есть вещи гораааздо более сложные, и при этом люди, которым это надо разбираются в них очень хорошо.
Как пример, могу привести некоторые раздели физики — типа квантовой механики, СТО и т.д.

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

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

R>>Как бы ты предложил это реализовать?

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


У них абсолютно одинаковая семантика — "создать реализацию интерфейса ISome для переданного значения".
Ну так как бы ты это решил?

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

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

R>>Как бы то ни было, паттерны тоже не применяем, т.к. не все же студенты знакомы с ними. Ну оканчивается название класса на Visitor. Ну и что? Кому-то это ничего не скажет.
R>>Так что 20 функций из С и ни фичей больше

E>Это всё крайности, а я за взвешенность и умеренность выступаю

Я согласен. Но видимо мы считаем, что уровень умеренности должен находиться на разных уровнях

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

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

E>>>Но на практичке я постоянно встречаю людей, которые применяют налево и направо навороты, и совсем не встречаю, таких, которые пишут плохо, потому что наворотов от Александреску не применили
R>>Повезло
E>А ты часто встречал людей, которые написали плохой код именно потому, что не применили идеи А?
E>Опиши как это было-то?

Пожалуйста.
1. Видел в проекте (благо не в моём) самопальный умный указатель — зрелище достаточно убогое. Часть состояния открытая. Не защищён от большинства неправильных использований. Не обеспечивает безопасноть относительно возникновения ошибок. И т.д.

2. Видел много примеров плохого дизайна, когда люди не разделял ортоганальные аспекты. А валили всё в одну большую кучу.

Дело не именно в А. Дело в том, что люди пытались делать все очень просто, как в лабораторной в институте. Я бы даже сказал наивно. Со временем это аукалось.





E>>>Ну на самом деле задачи просто проще методов Александреску. Увы, такая вот жизнь вокруг меня. Хотя программы в целом непростые, так скажем. И программисты квалифицированные.
R>>Смотря какие подразумевать критерии хорошего решения задачи?
E>Успешные многолетние проекты. С большим числом версий, миллионами инсталляций по миру. Поддержка, развите. Очень сложные задачи в смысле того, что не очевидно как это реализовывать вообще, сложные пользовательсткие интерфейсы и т. д.
E>Есть, в том числе, и программы, являющимися лучшими или одними из лучших в мире в своих сегментах.
R>>Если только наличие требуемого поведения, то тогда конечно любую задачу можно решить очень просто...
E>Сопровождение и развитие ещё требуется.

Сопровождение и развитие — это относится к проекту, а касательно кода? Т.е. какие требования к коду, что бы проект был сопровождаемым и развиваемым?

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

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

E>>>Прекрасно!
E>>>Расскажи как тебе помогают в твоих многочисленных бедах мультиметоды и for_each

E>>>Главная проблема с шаблонами, ИМХО, такая, что часто при редактировании нетривильного шаблона очень трудно предсказать все последствия.

R>>Одно из свойств advanced-templates в том, что "уж если вся эта бойда скомпилировалась, значит она работает так, как надо". Я в этом сам неоднократно убеждался на примере boost::bind.
E>Ну, в целом, ты совсем не ответил на мой вопрос

Долго

R>>Ты фактически описываешь то, что ты хочешь получить декларативно. Да, иногда, вызывает проблемы объяснить компилятору, что же именно ты хочешь получить, что бы он понял. Но уже если объяснил, то это работает. Т.к. ты не описывал, как ты хочешь это получить. А ошибки бывают обычно именно в этом.

E>Ну в целом подход похвальный. Но есть две беды.
E>1) Очень уж неудобный язык описания моих желаний

Есть немного. Покрайней мере непривычный.


E>2) Компилятору-то я может и объясню, но лучше бы объяснять тому, кто будет этот код поддерживать

В чём проблема?



E>

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

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


R>Я тебя уверяю, что есть вещи гораааздо более сложные, и при этом люди, которым это надо разбираются в них очень хорошо.
R>Как пример, могу привести некоторые раздели физики — типа квантовой механики, СТО и т.д.


ИМХО СТО весьма несложна, но это не важно.
Имелось в виду, конечно "слишком сложные для решения возникающих на практике задач"