Аннотация:
Существует множество практик, принципов, паттернов и прочих страшных слов, которые мы используем в нашей повседневной профессиональной деятельности и очень часто даже не задаём себе вопрос зачем мы это делаем. Зачем это всё нужно, плохо это или хорошо, когда плохо и когда хорошо. Зачем нужны все эти принципы? На самом деле ответ до банального очевиден. Всё это в конце концов направлено на борьбу со сложностью разработки ПО. Теперь пришла очередь задать вопрос — а что же такое сложность и как знание того что это такое поможет нам лучше понять и использовать принципы, которые как раз и направлены на борьбу с ней?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Игорь Ткачёв, Вы писали:
ИТ>Существует множество практик, принципов, паттернов и прочих страшных слов, которые мы используем в нашей повседневной профессиональной деятельности и очень часто даже не задаём себе вопрос зачем мы это делаем. Зачем это всё нужно, плохо это или хорошо, когда плохо и когда хорошо. Зачем нужны все эти принципы? На самом деле ответ до банального очевиден. Всё это в конце концов направлено на борьбу со сложностью разработки ПО. Теперь пришла очередь задать вопрос — а что же такое сложность и как знание того что это такое поможет нам лучше понять и использовать принципы, которые как раз и направлены на борьбу с ней?
Статья себе противоречит:
Это плохо работает, когда мы пытаемся заранее выделить код, который по идее можно повторно использовать, но на практике его повторно использовать не получается. Дополнительную сложность в решаемую задачу мы внесли, а взамен ничего не получили.
Следовательно, если мы не будем пытаться "заранее выделить код", то взамен ничего не потеряем, сложность уменьшим.
Следовательно, утверждение "устраняя сложность в одном месте мы всегда добавляем её где-то в другом" — неверно.
Следовательно, законом сохранения сложности и не закон вовсе.
Здравствуйте, Lloyd, Вы писали:
L>Статья себе противоречит:
Там же в самом начале написано — сложность штука противоречивая. Это было написано специально для таких как ты.
L>Следовательно, если мы не будем пытаться "заранее выделить код", то взамен ничего не потеряем, сложность уменьшим.
Если ты не будешь пытаться, то ничего ни не потеряешь, ни не уменьшишь.
L>Следовательно, утверждение "устраняя сложность в одном месте мы всегда добавляем её где-то в другом" — неверно.
Предыдущий твой посыл был не верен, так что дальнейшие выводы не имеют смысла.
L>Следовательно, законом сохранения сложности и не закон вовсе. ;)
— Суслика видишь?
— Нет.
— А он есть!
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Lloyd, Вы писали:
L>Следовательно, если мы не будем пытаться "заранее выделить код", то взамен ничего не потеряем, сложность уменьшим.
Противоположность увеличения сложности — неувеличение, а не строгое уменьшение. Поэтой при нулевых поползновениях сложность не изменится.
1)Сложность восприятия и сложность обучения — практичеки одно и тоже, только взгляд с разных сторон.
2)Сложность восприятия, сложность обучения, количественная сложность — их преодоление является разовыми затратами, тогда как алгоритмическая сложность и сложность сложность изменения преслдуют постоянно.
3)Пониятие алгоритмической сложности слишком обобщено. Напрмиер разработка парсера языка и трехзвенной бухгалтерской системы обладают высокой сложностью, но причины сложности совершенно разные.
Здравствуйте, gandjustas, Вы писали:
G>2)Сложность восприятия, сложность обучения, количественная сложность — их преодоление является разовыми затратами
В общем случае, это неверно. Лично я забываю всякую ерунду очень быстро, и, как следствие, приходится помногу раз вникать в один и тот же проект. Соответственно, чем выше порог вхождения, тем больше тратится ресурсов на "переключение контекста" между проектами.
Здравствуйте, IT, Вы писали:
L>>Следовательно, если мы не будем пытаться "заранее выделить код", то взамен ничего не потеряем, сложность уменьшим.
IT>Если ты не будешь пытаться, то ничего ни не потеряешь, ни не уменьшишь.
Переход от решения A в котором "мы пытаемся заранее выделить код, который по идее можно повторно использовать" к решению B, в котором не было предпринято такой попытки, судя по постановке должно привести в уменьшению сложности. Разве не так?
Здравствуйте, gandjustas, Вы писали:
L>>Следовательно, если мы не будем пытаться "заранее выделить код", то взамен ничего не потеряем, сложность уменьшим. G>Противоположность увеличения сложности — неувеличение, а не строгое уменьшение. Поэтой при нулевых поползновениях сложность не изменится.
Тут не термодинамика, тут любой процесс можно повернуть вспять и очень легко — окрываешь сорсконтрол и делаешь Revert Changes. И если в ревизии 101 у тебя при прочих равных сложность выше, чем в ревизии 100, то откатившись на 100-ю ревизию получишь уменьшение сложности, которого по мнению автора статьи "не существует".
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
G>>2)Сложность восприятия, сложность обучения, количественная сложность — их преодоление является разовыми затратами
T>В общем случае, это неверно. Лично я забываю всякую ерунду очень быстро, и, как следствие, приходится помногу раз вникать в один и тот же проект. Соответственно, чем выше порог вхождения, тем больше тратится ресурсов на "переключение контекста" между проектами.
Если часто надо переключаться между проектами, то это хреновый менеджемнт и сложности не относится.
Здравствуйте, Lloyd, Вы писали:
L>Переход от решения A в котором "мы пытаемся заранее выделить код, который по идее можно повторно использовать" к решению B, в котором не было предпринято такой попытки, судя по постановке должно привести в уменьшению сложности. Разве не так?
Это зависит от того было ли в решении А повторное использование кода или нет.
Если было то решение В сложнее, а если не было то решение В проще.
Ибо превращение кода в повторно используемый всегда приводит к его усложнению.
Упрощение происходит только тогда когда мы несколько раз повторно используем этот код.
И если мы по факту не смогли этот код использовать повторно то мы добавили сложность в одном месте и не убрали в другом.
Таким образом приходим к эвристике: Превращай код в повторно используемый только после того как он понадобился повторно.
Конечно бывают случаи когда точно известно что код будет использован повторно но если 100%ной уверенности нет то см эвристику.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Таким образом приходим к эвристике: Превращай код в повторно используемый только после того как он понадобился повторно.
Ага, и если так не делать, то приложения превращаются в набор "повторно используемого кода", который не может быть повторно использован.
Здравствуйте, gandjustas, Вы писали:
G>1)Сложность восприятия и сложность обучения — практичеки одно и тоже, только взгляд с разных сторон.
Сложность само по себе одно и тоже — затраченные усилия, и её виды — это как раз и есть взгляд с разных сторон. Разделение на виды само по себе вещь достаточно условная и интересно прежде всего для выявления, лучшего понимания и устранения проблемных мест. Возьмём, например, код, который плохо читаем, т.к. страдает отсутствием форматирования, соглашений, запутан и многословен. Что нужно сделать, чтобы он стал прощё? Его можно отформатировать, отрефакторить, распутать и убрать лишнее. В результате он станет проще за счёт уменьшения сложности восприятия. Теперь возьмём код, который легко читается, но базируется на технологии, которая изучающему этот код пока не известна. Пусть это будет WPF — как раз та вещь, которая обладает довольно высоким порогом вхождения. Поможет ли нам форматирование кода, его рефакторинг и распутывание лучше понять такой код? Ответ очевиден — не поможет, рефакторить можно хоть до посинения. Нужно брать в руки книжки и изучать технологию.
G>2)Сложность восприятия, сложность обучения, количественная сложность — их преодоление является разовыми затратами, тогда как алгоритмическая сложность и сложность сложность изменения преслдуют постоянно.
Это смотря как посмотреть. Плохо читаемый и многословный код придётся преодолевать каждый раз, когда он будет читаться. Сложность обучения придётся преодолевать каждому новому бойцу в команде, для которого порог вхождения в код выше его текущего предела.
G>3)Пониятие алгоритмической сложности слишком обобщено. Напрмиер разработка парсера языка и трехзвенной бухгалтерской системы обладают высокой сложностью, но причины сложности совершенно разные.
Какие?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Lloyd, Вы писали:
IT>>Если ты не будешь пытаться, то ничего ни не потеряешь, ни не уменьшишь.
L>Переход от решения A в котором "мы пытаемся заранее выделить код, который по идее можно повторно использовать" к решению B, в котором не было предпринято такой попытки, судя по постановке должно привести в уменьшению сложности. Разве не так?
Не так. Давай возьмём для примера следующий код:
var a = b + c;
Предположим, что мы можем здесь выделить операцию сложения в отдельный метод. Но мы этого не стали делать. До того как мы этого не стали делать у нас было a = b + c, а после того как мы этого не сделали у нас стало a = b + c. Было a = b + c, стало a = b + c. За счёт чего второе a = b + c, стало проще первого?
Если нам не помогут, то мы тоже никого не пощадим.
Понятием "сложность" занимается кибернетика. В частности, из возрастающей сложности управляемой системы она выводит необходимость иерарихии управляющих (под)систем. То-же самое происходит при создании софта, при этом программисты создают иерархию уровней абстракции. Собственно, она и решает те проблемы, о которых написано в статье. И приёмы уменьшения разных типов сложности (алгоритмическая сложноть, сложность восприятия и пр.) в целом тоже укладываются в эти уровни абстракции. Мы говорим о более или менее высокоуровневых языках программирования, фреймворках и т.п.
Увы, повышение уровня абстракции практически всегда приводит к ухудшению производительности программ. Это ухудшение невелико, когда эти уровни абстрации были созданы в рамках одного проекта для решения одной задачи. Но если их брать со стороны, брать некие готовые решения — то потеря производительности будет очень заметна — в разы на каждом уровне абстракции. Эта деградация производительности хороша заметна в ретроспективе развития производительности компьютеров и программного обеспечения — мы все видели, как скорость компьютеров увеличилась на несколько порядков, а вот функциональность софта — намного меньше.
Так бы и продолжалось дальше, но увы, экспоненциальное развитие скорости компьютеров практически закончилось. И просто увеличение количества уровней абстракции (вроде применения более высокоуровневых языков программирования) уже не поможет — железо не потянет. И выход тут я вижу только один — использовать компьютер. Он не имеет такого встроенного ограничения на уровень сложности программы, которую должен анализировать. Но увы, он не имеет и интеллекта, чтоб писать и анализировать программы. Вот когда этот интеллект у него появится — тогда и появится реальная альтернатива увеличению количества уровней абстракции в программе. Чтоб программы становились более сложными и функциональными, без экспоненциального увеличения требований к ресурсам.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
G>>1)Сложность восприятия и сложность обучения — практичеки одно и тоже, только взгляд с разных сторон.
IT>Сложность само по себе одно и тоже — затраченные усилия, и её виды — это как раз и есть взгляд с разных сторон. Разделение на виды само по себе вещь достаточно условная и интересно прежде всего для выявления, лучшего понимания и устранения проблемных мест. Возьмём, например, код, который плохо читаем, т.к. страдает отсутствием форматирования, соглашений, запутан и многословен. Что нужно сделать, чтобы он стал прощё? Его можно отформатировать, отрефакторить, распутать и убрать лишнее. В результате он станет проще за счёт уменьшения сложности восприятия.
Этот рефакторинг выполняется автоматически и занимает минимум времени. Гораздо больше займет собственно понимание что делает код.
IT>Теперь возьмём код, который легко читается, но базируется на технологии, которая изучающему этот код пока не известна. Пусть это будет WPF — как раз та вещь, которая обладает довольно высоким порогом вхождения. Поможет ли нам форматирование кода, его рефакторинг и распутывание лучше понять такой код? Ответ очевиден — не поможет, рефакторить можно хоть до посинения. Нужно брать в руки книжки и изучать технологию.
Понимание что делает код не появится без понимания абстракций, которыми он оперирует.
Так что для "восприятия" нужно "обучение".
G>>2)Сложность восприятия, сложность обучения, количественная сложность — их преодоление является разовыми затратами, тогда как алгоритмическая сложность и сложность сложность изменения преслдуют постоянно.
IT>Это смотря как посмотреть. Плохо читаемый и многословный код придётся преодолевать каждый раз, когда он будет читаться.
Один программист читает код один раз когда разбирается как он работает.
IT>Сложность обучения придётся преодолевать каждому новому бойцу в команде, для которого порог вхождения в код выше его текущего предела.
Это еще более редкое явление.
Преодоление этих сложностей требует гораздо меньших затрат по сравнению с преодолением сложности изменений при постоянном развитии проекта.
G>>3)Пониятие алгоритмической сложности слишком обобщено. Напрмиер разработка парсера языка и трехзвенной бухгалтерской системы обладают высокой сложностью, но причины сложности совершенно разные. IT>Какие?
В случае парсера — нетривиальные алгоритмы — неочевидное преобразование входных данных в выходные, которое вряд ли получится декомпозировать на более протые части. В случае бухгалтерской системы все можно до элементарных вещей декопозировать, но возникает пролема распределения обязанностей между программными модулями и обеспечение их взаимодействия.
Здравствуйте, gandjustas, Вы писали:
G>Этот рефакторинг выполняется автоматически и занимает минимум времени. Гораздо больше займет собственно понимание что делает код.
Это зависит от кода. Можно так написать, что простой в понимании код вообще не будет читаться, а его рефакторинг займёт гораздо больше времени, чем его понимание. В общем, без конкретного кода я не стал бы даже это обсуждать.
G>Так что для "восприятия" нужно "обучение".
Возможно термин восприятие не очень удачен, но в моём определении важно как раз то, что он отделён от обучения и относится к форме кода, а не его содержанию. Если у тебя есть более точное определение предлагай.
IT>>Сложность обучения придётся преодолевать каждому новому бойцу в команде, для которого порог вхождения в код выше его текущего предела. G>Это еще более редкое явление.
G>Преодоление этих сложностей требует гораздо меньших затрат по сравнению с преодолением сложности изменений при постоянном развитии проекта.
Опять же это всё зависит от конкретного рассматриваемого случая. В моей команде используется всё, что сегодня доступно на рынке мэйнстрима: последние версии компиляторов и их новые возможности, последние технологии и т.д. Это позволяет нам перераспределить сложность наших проектов в сложность обучения и контролировать наш код малым числом людей. Я не возьму на работу человека далёкого от всего этого, например, такого, который застыл на уровен .NET 1.1. Не возьму по простой причине — затраты на его обучение не будут, как ты утверждаешь, меньше по сравнению с преодолением других видов сложности. Они будут значительно больше, и если это будет контрактник на 10 месяцев, то за это время он не успеет сделать ничего полезного.
G>>>3)Пониятие алгоритмической сложности слишком обобщено. Напрмиер разработка парсера языка и трехзвенной бухгалтерской системы обладают высокой сложностью, но причины сложности совершенно разные. IT>>Какие? G>В случае парсера — нетривиальные алгоритмы — неочевидное преобразование входных данных в выходные, которое вряд ли получится декомпозировать на более протые части. В случае бухгалтерской системы все можно до элементарных вещей декопозировать, но возникает пролема распределения обязанностей между программными модулями и обеспечение их взаимодействия.
Я думал об этом и пока не могу однозначено разделить две вещи: уровень интеллекта и способность удерживать в голове целиком задачу определённого размера. Мне кажется это суть одно и тоже, но, возможно, я не прав. Было бы интересно обсужить эти вещи подробнее.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Не так. Давай возьмём для примера следующий код:
IT>
IT>var a = b + c;
IT>
IT>Предположим, что мы можем здесь выделить операцию сложения в отдельный метод. Но мы этого не стали делать. До того как мы этого не стали делать у нас было a = b + c, а после того как мы этого не сделали у нас стало a = b + c. Было a = b + c, стало a = b + c. За счёт чего второе a = b + c, стало проще первого?
Предлагаю рассмотреть другой вариант.
Было var a = b + c; его отрефактирили в var a = Add(b, c);
Если мы теперь вернемся к первоначальному var a = b + c;, то получим решение, которое проще (чем var a = Add(b, c)).
Т.е получаем уменьшение сложности.
Здравствуйте, Lloyd, Вы писали:
L>Предлагаю рассмотреть другой вариант. L>Было var a = b + c; его отрефактирили в var a = Add(b, c); L>Если мы теперь вернемся к первоначальному var a = b + c;, то получим решение, которое проще (чем var a = Add(b, c)). L>Т.е получаем уменьшение сложности.
Уменьшение по сравнению с чём? Исходную сложность ты не уменьшил, а излишнюю да, устранил. Или вот ещё:
if (a == true)
{
return true;
}
else if (a == false)
{
return false;
}
else if (a != true && a != false)
{
throw new ApplicationException()
}
такой код упрощается до:
return a;
при этом сложность этого кода уменьшается. Но начальная сложность никуда не делась. Если задача ставится как, например, умножить два числа, то можно применить множество практик и техник, но умножение или заменяющий его алгоритм в том или ином виде в коде присутствовать должен. От этого никуда не деться и это указано в статье.
L>Я это имел в виду.
Возможно не все формулировки и объяснения получились достаточно чёткими и однозначными. Я над этим работаю
Если нам не помогут, то мы тоже никого не пощадим.
Законы сохранения действуют в обоих направлениях, соответственно, если бы такой закон был, то при искусственном увеличении сложности в реализации какой-то функции, сложность чего-то другого уменьшалась бы.
Скорее есть закон "минимально необходимой сложности", и он во многом пересекается со статьей, но называется никак не "закон сохранения".
Например, вместо применения формулы для решения квадратного уровнения можн онаписать подсистему, которая будет рисовать параболу, сохраняь в BMP формате, потом парсить пикселы из файла и находить приблизительное решение по точкам пересечения. Можно еще написать свой архиватор "для компактного хранения этих BMP" и драйвер HDD который будет оптимально хранить полученый архив на диске. Эти операции — многократное увеличение сложности по сравнению с вычислением дискриминанта, при этом только увеличивается (что опровергает гипотезу о законе).
Или я что-то не понял?
А вообще респект за тему — управление сложностью — самое важное в разработке.
Здравствуйте, IT, Вы писали:
IT>Я думал об этом и пока не могу однозначено разделить две вещи: уровень интеллекта и способность удерживать в голове целиком задачу определённого размера. Мне кажется это суть одно и тоже, но, возможно, я не прав. Было бы интересно обсужить эти вещи подробнее.
Интеллект может справиться со сложной задачей в основном только путем декомпозиции. Поэтому не нужно стремиться удерживать в голове целиком задачу большого размера. Но это в теории, а на практике только этим и приходится заниматься
Здравствуйте, goldblueranger, Вы писали:
G>Законы сохранения действуют в обоих направлениях, соответственно, если бы такой закон был, то при искусственном увеличении сложности в реализации какой-то функции, сложность чего-то другого уменьшалась бы.
Если бы такой закон был, то его уже давно открыли бы и без нас с вами. Это и так понятно. В статье как раз написано, давайте условно назовём это законом сохранения сложности. С другой стороны исскуственное усложнение на пустом месте тоже не происходит. Искуственное увеличение сложности в реализации какой-то функции, происходит за счёт уменьшения усилий при её написании, т.е. чем меньше сложности в мозгах, тем сложнее получаемый код
G>Или я что-то не понял?
Всё примерно так.
G>А вообще респект за тему — управление сложностью — самое важное в разработке.
Именно это и хочется обсудить, а уж как там это назвать дело десятое.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, goldblueranger, Вы писали:
IT>>Я думал об этом и пока не могу однозначено разделить две вещи: уровень интеллекта и способность удерживать в голове целиком задачу определённого размера. Мне кажется это суть одно и тоже, но, возможно, я не прав. Было бы интересно обсужить эти вещи подробнее.
G>Интеллект может справиться со сложной задачей в основном только путем декомпозиции. Поэтому не нужно стремиться удерживать в голове целиком задачу большого размера. Но это в теории, а на практике только этим и приходится заниматься
Задачи, легко поддающиеся декомпозиции не являются алгоритмически сложными именно по причине возможности их декомпозиции. Но бывают и другие задачи, требующие для своего решения построения полной модели в голове. И если, допустим, за два часа такую модель не построишь, то отставив задачу на день приходится всё опять строить заново. В результате такие подходы к снаряду не заканчиваются ни чем. Требуется полное погружение на 8-10 часов в течении нескольких дней. А после того, как такую задачу удаётся продавить модель разрушается и в голове мало что остаётся.
Понятное дело, что таких задач не много, но периодически они попадаются. Так вот мне интересно, чем именно обусловлен предел. Скоростными возможностями мозгов при построении модели, размером модели или чем-то другим? Ответ на этот вопрос даст лучшее понимание природы алгоритмической сложности, позволит отбросить лишнее и сконцентрироваться на главном.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
G>>Этот рефакторинг выполняется автоматически и занимает минимум времени. Гораздо больше займет собственно понимание что делает код.
IT>Это зависит от кода. Можно так написать, что простой в понимании код вообще не будет читаться, а его рефакторинг займёт гораздо больше времени, чем его понимание. В общем, без конкретного кода я не стал бы даже это обсуждать.
Если код не был специально запутан, то рефакторинг в той же студии выполняется достаточно быстро.
G>>Так что для "восприятия" нужно "обучение".
IT>Возможно термин восприятие не очень удачен, но в моём определении важно как раз то, что он отделён от обучения и относится к форме кода, а не его содержанию. Если у тебя есть более точное определение предлагай.
Тогда подходящий термин "чтение", а "обучение" надо заменить "пониманием".
О самом обучении, те преодолении порога вхождения, ниже.
IT>>>Сложность обучения придётся преодолевать каждому новому бойцу в команде, для которого порог вхождения в код выше его текущего предела. G>>Это еще более редкое явление.
G>>Преодоление этих сложностей требует гораздо меньших затрат по сравнению с преодолением сложности изменений при постоянном развитии проекта.
IT>Опять же это всё зависит от конкретного рассматриваемого случая. В моей команде используется всё, что сегодня доступно на рынке мэйнстрима: последние версии компиляторов и их новые возможности, последние технологии и т.д. Это позволяет нам перераспределить сложность наших проектов в сложность обучения и контролировать наш код малым числом людей. Я не возьму на работу человека далёкого от всего этого, например, такого, который застыл на уровен .NET 1.1. Не возьму по простой причине — затраты на его обучение не будут, как ты утверждаешь, меньше по сравнению с преодолением других видов сложности. Они будут значительно больше, и если это будет контрактник на 10 месяцев, то за это время он не успеет сделать ничего полезного.
Тут другой фактор играет роль. Пока человек не обучен всем применяемым средствам он не сможет участовать в проекте. Тода как сложность изменения практически не будет зависить от качеств человека.
Всетаки стоит сделать разделение на сложность объективную (например вызванную высокой связностью системы или применяемыми алгоритмами) и субъективную (например знание технологий конкретными людьми).
Статья основана на предпосылках что сложность складывается, вычитается и делится арифметически.
Поробуйте к примеру рассмотреть сложность на исходных данных задачи коммивояжёра (экстремальный случай).
Я например уверен, что при упорядочивании общая энтропия кода уменьшается, а значит закон сохранения сложности — полная чушь.
Ток что софистика ваша статья.
IT>Сложность само по себе одно и тоже — затраченные усилия
Перевожу — "энтропия и энергия это одно и то же".
Да энтропия и энергия связаны напрямую, но говорить, что это одно и то же — полный бред.
IT>Задачи, легко поддающиеся декомпозиции не являются алгоритмически сложными именно по причине возможности их декомпозиции. Но бывают и другие задачи, требующие для своего решения построения полной модели в голове. И если, допустим, за два часа такую модель не построишь, то отставив задачу на день приходится всё опять строить заново.
В этом случае проблема обычно решается введением дополнительного уровня абстракции, что опять же доступно именно интелекту
IT>Я думал об этом и пока не могу однозначено разделить две вещи: уровень интеллекта и способность удерживать в голове целиком задачу определённого размера. Мне кажется это суть одно и тоже, но, возможно, я не прав. Было бы интересно обсужить эти вещи подробнее.
Да вроде просто все — уровень интеллекта ограничивает время за которое ты сможешь взместить в голову всю задачу.
Т.е. вопрос в том, успеет ли кандидат модифицировать у себя в голове модель некоей системы (задачу) в режиме реального времени или же ему придется докупать где то время.
Всю статью можно свести к одной фразе — "Сложность — понятие сложное". Утверждение, бесспорно, верное. Но его практическая применимость лично для меня под вопросом.
IT>Задачи, легко поддающиеся декомпозиции не являются алгоритмически сложными именно по причине возможности их декомпозиции. Но бывают и другие задачи, требующие для своего решения построения полной модели в голове. И если, допустим, за два часа такую модель не построишь, то отставив задачу на день приходится всё опять строить заново. В результате такие подходы к снаряду не заканчиваются ни чем. Требуется полное погружение на 8-10 часов в течении нескольких дней. А после того, как такую задачу удаётся продавить модель разрушается и в голове мало что остаётся.
IT>Понятное дело, что таких задач не много, но периодически они попадаются. Так вот мне интересно, чем именно обусловлен предел. Скоростными возможностями мозгов при построении модели, размером модели или чем-то другим? Ответ на этот вопрос даст лучшее понимание природы алгоритмической сложности, позволит отбросить лишнее и сконцентрироваться на главном.
Времени нужно потратить столько что бы запихнуть задачу в долговременную память, это у каждого человека по своему. на качество воспроизведения влияет предыдущий опыт и последующий. Задачи решаются в кратковременной паамяти, куда влазит 5+-2 составляющих (в некоем формализме).
Чем сильнее были прокачаны интеллектуальные функции(анализ — синтез, абстракция — конкретика, сравнение — сопоставление, обобщение — классификация, кодирование — декодирование) тем проще удерживать в голове модель.
Грубо говоря, уровень прокачки это уровень формализма в котором ты можешь описать задачу, например
0 установить i равным длине списка минус один, взять i-элемент, если признак равен ...
1 в цикле проверять каждый элемент списка и в случае чего удалять нахрен
2 фильтровать список по некоему признаку или так
3 мега-опэрация(мега-объект)
итого — предел времени зависит от прокачки, скорости изменения прокачки, масштаба задачи и скорости расхода этого времени на задачу.
Кстати, идея про метапрограммирование это попытка прыгнуть выше головы, когда решение бОлее верхнего уровня не дается в нужный срок, девелопер сбрасывает сложность в обратно из головы в код в надежде что код удастся лучше контролировать. Т.е. метапрограммирование — контролируемый хаос. Но все таки хаос а не порядок.
Здравствуйте, VGn, Вы писали:
VGn>Статья основана на предпосылках что сложность складывается, вычитается и делится арифметически.
Ты не внимательно её читал. Статья как раз основана на том, что сложность нельзя оценивать количественно.
VGn>Поробуйте к примеру рассмотреть сложность на исходных данных задачи коммивояжёра (экстремальный случай).
Давай конкретную реализацию задачи, поговорим о сложности/простоте её реализации.
VGn>Я например уверен, что при упорядочивании общая энтропия кода уменьшается, а значит закон сохранения сложности — полная чушь.
А что такое упорядочивание?
VGn>Ток что софистика ваша статья.
Из вики
В широком смысле термин «софист» означал искусного или мудрого человека.
Ты это имел ввиду?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VGn, Вы писали:
IT>>Задачи, легко поддающиеся декомпозиции не являются алгоритмически сложными именно по причине возможности их декомпозиции. Но бывают и другие задачи, требующие для своего решения построения полной модели в голове. И если, допустим, за два часа такую модель не построишь, то отставив задачу на день приходится всё опять строить заново.
VGn>В этом случае проблема обычно решается введением дополнительного уровня абстракции, что опять же доступно именно интелекту
В каком в этом? В каком-то твоём частном случае? Возможно, я даже спорить не буду.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Vamp, Вы писали:
V>Всю статью можно свести к одной фразе — "Сложность — понятие сложное". Утверждение, бесспорно, верное. Но его практическая применимость лично для меня под вопросом.
Применимость нужно рассматривать на конкретном коде. В принципе, можно взять какую-нибудь задачу посложнее и рассмотреть.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Ikemefula, Вы писали:
I>Времени нужно потратить столько что бы запихнуть задачу в долговременную память, это у каждого человека по своему. на качество воспроизведения влияет предыдущий опыт и последующий.
Это как?
I>Кстати, идея про метапрограммирование это попытка прыгнуть выше головы, когда решение бОлее верхнего уровня не дается в нужный срок, девелопер сбрасывает сложность в обратно из головы в код в надежде что код удастся лучше контролировать. Т.е. метапрограммирование — контролируемый хаос. Но все таки хаос а не порядок.
Мы об одном и том же метапрограммировании говорим?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas, Вы писали:
G>Если часто надо переключаться между проектами, то это хреновый менеджемнт и сложности не относится.
+1
Хочется добавить, что частое переключение между проектами,
свойственно "командам с низким уровнем обучения" (как они упомянуты в статье).
Для однодневных простеньких проектов, данный подход способен принести положительный результат,
но как дело выходит за рамки 2*2=4, проявляется вся абсурдность данного подхода.
Здравствуйте, gandjustas, Вы писали:
T>>В общем случае, это неверно. Лично я забываю всякую ерунду очень быстро, и, как следствие, приходится помногу раз вникать в один и тот же проект. Соответственно, чем выше порог вхождения, тем больше тратится ресурсов на "переключение контекста" между проектами.
G>Если часто надо переключаться между проектами, то это хреновый менеджемнт и сложности не относится.
P.S.-1 (текст ниже немного корявый, частично собран из кусков записок)
Сложность определяется не только архитектурой, но и оформлением этой архитектуры.
Хотя отделить одно от другого сложно, но условно можно. По крайней мере единственный способ изучить прграмму, это чтение кода, в том числе структура файлов проекта, навигация по коду инструментами разработки. С разными UML диаграммами проблема в том что это не программный код, а какие-то витания в облаках.
А для оформления есть важный аспект (но естейственно не единственный) — инкапсуляция.
Многие вопросы сложности сводятся к инкапсуляции. Особенно по части сложности восприятия, изучения кода.
Инкапсуляция, в одной из интерпретаций, это по сути введение ограничений, уменьшение степеней свободы.
Програмный код можно условно,приближенно считать это — множество данных и множество операций над данными.
И данные и операции организованы иерархически.Все это хозяйство является каким-то направленным иерархическим графом.
Один из важнейших типов направленных связей между элементами это — зависимости.
Т.е. если один элемент испортить, удалить, какие элементы посыпятся, перестанут компилироваться.
Важный момент, что зависимости(и другие типы связей) бывают:
— Текущие.Существующие в данный момент, в текущей версии,стадии разработки системы.
— Будущие, которые вероятнее всего появятся(потребуются) в дальнейшем
— Потенциальные. Они могут никогда вобще не потребоваться, но явных запретов,ограничений на их образование нет. Явно неограниченные ненужные связи являются вредоносными.
Связи между элементами описываются интерфейсами (не ключевое слово в C#) а в более широком смысле.
Интерфейсы бывают входящие и исходящие.
Интерфес в таком понимании, это описание способов использования одного элемента другим. Описание в каком угодно виде.
Вышесказанное это все довольно очевидные вещи,изложить их можно лучше или хуже и разными словами ....
Но хотел сказать по поводу инкапсуляции вот что:
----------
При изучении кода, происходит идентификация неявной структуры программы, со всеми иерархическими уровнями элементов и их зависимостями.
Современные средства разработки(и языковые и инструменты разработки), пока не достаточно помогают в оформлении кода (или создании дополнительных аспектов представления) таким образом чтобы можно было быстро идентифицировать структуру программы. Есть class,interface, сборки и ключевое слово internal. Но этого мало.В языке возможно уже нечего добавить, но что-то нужно со стороны средств разработки. Автоматическое построение диаграм классов это только игрушка.
---------
(Зависимости от стандартной библиотеки .NET игнорируем, по понятным причинам.)
— Если программист хорошо знаком с программой. Значит если его спросить "Что будет если удалить
вот эту функцию". Сколько функций и классов после этого перестанут компилироваться.
Если рекурсивно удалить все что не компилируется. Вопрос что тогда останется.
А если не знаком с программой, то как можно быстро ознакомиться с этим аспектом (даже сам писатель кода через определенное время станет менее знаком)?
Без хорошей среды разработки это сложно и долго.
— Или взять большой кусок кода (папку с кучей фалов или namespace). Как можно покоцать, удалить весь код за пределами этого куска, чтобы этот кусок компилировался и остался работоспособным.
Если нет понимания по таким вопросом относительно конкретной программы(проекта), вносить изменения и добавления становится довольно затруднительным.
В связи с этим есть такие проблемы:
1) Если образуются естейственные крупные инкапсуляции.
Программисты ленятся оформлять правильным образом (выделять в явном виде, накладывать ограничения).На момент написания в этом может не быть необходимости, потому что и так по памяти структура хорошо помнится.
2) Создание и оформление инкапсуляции вызывает определенные накладные расходы. В зависимости от величины элемента эти расходы,механизмы накладывания ограничений и описания интерфейса, могут быть разные.
Например некоторые виды инкапсуляции:
1)Инкапсуляция по-маленькому(один из вариантов)
Если в классе довольно сложная private функция реализуется с помощью 3-4 других вспомогательных private функций, если эти функции в классе больше нигде не используются. То разумно все это заключить в #region
С именем,например Func,encapsulation . Нестрогое объявление исходящего интерфеса, указывающее что за пределами #region видна только Func. Это только соглашение, но было бы неплохо если бы среда делала бы проверки, и выдавала предупреждения когда пытаются залезть внутрь. В стандарт языка это вносить нет смысла. Понятно что при пересечении определенной критической точки уже лучше будет вынести эту функцию в отдельный класс,возможно nested.
2)Инкапсуляцию на уровне класса пропустим.
3) Инкапсуляция по-среднему:
Реализация одного класса сложная, и для этого требуется 3-4 вспомогательных класса.Причем для других целей, другими классами, они никогда не будут использоваться. Просто так реализовать проще и понятнее, а использовать хуже, потому что эти ненужные классы будут мешаться. Проблема не в том что засоряют пространство имен, и в intelisence дольше функции искать, а в том что ухудшают адекватное восприятие структуры программы. Когда это принимает массовый характер, это губительно.
Один из способов — главный класс сделать partial. В одной части(файле) интерфейсная реализация. В других частях класса реализуются эти вспомогательные как private nested. Для большей адекватности, создать отдельную папку. В ней лежит файл с классом и папка internal где лежат вспомогательные классы. Но не совсем удобно бывает лазить по папкам с одним файлом и одной поддиректорией. Хорошо бы чтобы среда показывала такие папки в виде специальной иконки,похожей на файл, при клике на нее бы открывался этот один файл, а при раскрытии папки сразу в ней показывалось бы содержимое internal. И чтобы можно было переключить ее к виду нормальной папки и обратно... Можно namespace отдельный для вспомогательных классов, с добавкой internal.
4) Инкапсуляция по-крупному (или промежуточный вариант с предыдущим пунктом).
В основном для достаточно крупных,сложных кусков кода, поддающихся инкапсуляции по своей природе(не все куски такие).
Особенно для какой-то подсистемы, части являющейся единым целым, а не сборкой независимых утилит.
Например MS Excel — класс создатель + объектная модель. Но Excel это уж слишком крупная и явная инкапсуляция.
Но то же касается и более простых случаев, даже кусков кода 1000-3000 строк.
Использовать для этого отдельную dll сборку и защищать внутренности через internal во многих случаях неприемлемо и невозможно, и создает dll dependency hell. Проблема в том что эти сборки однонаправленное дерево, а между реальными элементами могут быть взаимные ссылки. Для особых случаев можно создать абстрактную сборку, и зависимости только от нее, чтобы разрулить циклические ссылки, но на каждые 1000 отдельную сборку не создашь.
В этом случае помещается такой кусок кода в отдельную папку [Elem]. В папке [Elem]\internal находится 95% или больше кода по числу строк. Вводится неявное соглашение содержимое [Elem]\internal доступно только из папки [Elem]. Все взаимодействие идет через входящий и исходящий интерфейс. Этот интерфейс находится в файлах в самой папке [Elem].
За попытки пробраться к коду в [Elem]\internal из внешних для [Elem] папок нещадно бить по рукам.
Хорошо бы если бы среда это контролировала, выдавала ошибки, чтобы была уверенность.
Бывает необходима и обратная(исходящая) изоляция содержания [Elem]\internal от внешнего мира (стандартные библиотеки .NET не являются внешним миром, по понятным причинам). Также нещадно бить по рукам за попытки пробраться наружу из internal наверх за пределы [Elem].
Если очень надо наверх, делаются исключения, но они явно описываются
в специальном файле [Elem]\OutgoingInterface.txt (или Uses.txt).
Либо даже для наружных элементов которые нужн,ы пишутся Wrapper'ы и помещаются в [Elem] (в нее доступ разрешен из internal).
Если Wrapper'ы не слишком трудоемкие и позволяют исключить часть ненужного функционала.
В самой папке [Elem] код сведен к минимуму. В основном Wraper'ы над тем что в internal.
Ну и естейственно [Elem]\Description.txt — где подробное описание всего элемента, с тонкостями и граблями.
Вот уж где комментарии наиболее полезны, так это на таких крупных скоплениях кода. А то бывает поналепят комментариев на каждую функцию или класс,а на более крупных скоплениях вобще ничего.Как будто их и нет. Типа, кто исходники сможет изучить тот поймет есть ли в коде вобще какие-то осмысленные крупные скопления, или полная каша из небольших классов и функций, или это большой массив независимых функций и классов.
Хорошо бы для таких конструкций поддержку со стороны среды — помечать такие папки особой иконкой и возможность включить исходящие и входящие ограничения (изоляцию), с выдачей ошибок при нарушениях, учитывая содержимое uses.txt. С возможностью отключить и включить этот режим.
Еще раз повторю что, ИМХО, через разделение на dll сборки такие проблемы не получиться решить в общем случае.
Самого языка и компилятора командной строки это скорее всего не касается, это дело среды.
---------
P.S.1 Можно сколько угодно рисовать красивые UML и прочие диаграмки. Но это просто живопись, если в самой среде разработки это все в виде каши и пущено на самотек.
P.S.2 Задачи и программы конечно бывают разные. Не для всех одинаково полезны одни и те же подходы. Когда одному или нескольким человекам нужно вмешиваться в код объемом 15-100 тыс строк, и сама система сильно связанная(по своей сути). И каждый должен понимать все детали в коде, и рефакторинг постоянный, то это одна ситуация.
Если кто-то слепил какой-то движок, потом толпы программистов шлепают под него независимые однотипные примочки в виде какой-то бизнес логики или чего-то похожего,в огромных количествах.Тогда это уже немного другая ситуация.
Здравствуйте, Lloyd, Вы писали: L>Здравствуйте, gandjustas, Вы писали:
L>Тут не термодинамика, тут любой процесс можно повернуть вспять и очень легко — окрываешь сорсконтрол и делаешь Revert Changes. И если в ревизии 101 у тебя при прочих равных сложность выше, чем в ревизии 100, то откатившись на 100-ю ревизию получишь уменьшение сложности, которого по мнению автора статьи "не существует".
И тут не математика, такое ощущение, что пытаешься представить каждую фразу в виде исчисления предикатов такого-то порядка.
Да и автор не говорил, что "не существует".
Это плохо работает, когда мы пытаемся заранее выделить код, который по идее можно повторно использовать, но на практике его повторно использовать не получается.
Если хочешь чтобы все сходилось с формальной точки зрения. Введи понятия(характеристики сложности):
Всякая сложность состоит из двук компонент:
Сложность = Объективная сложность + исскуственная(избыточная сложность,неумышленная обфускация)
всем очевидно что для функции int Sqr(int x){return x*x;} Можно до бесконечности увеличить сложность.Так что ни один программист за сутки не сможет доказать что она в квадрат возводит, разве что только экспериментально проверить...
И при этом не выполнится условие в одном месте выиграешь в другом проиграешь (и следствие в одном месте проиграешь значит в другом выиграешь). Но обективная компонента сложности останется неизменной (рост только за счет искусственной).
Существуют разные реализации одного и того же, в которых после устранения искусственной сложности, получаются ситуации когда в одном месте выигрываешь в другом проигрываешь (только по отношению оставшейся объективной сложности).
Вот можешь к каждому предложению автора где упоминается сложность добавлять префикс "объективная". Если бы обсуждался вопрос защиты программ и разные методы умышленной обфускации кода( какого нибудь JavaScript,чтоб никто не ковырялся). Тогда бы интересовала совсем другая компонента сложности.
Здравствуйте, Silver_s, Вы писали:
S_>Всякая сложность состоит из двук компонент: S_>Сложность = Объективная сложность + исскуственная(избыточная сложность,неумышленная обфускация)
S_>...Вот можешь к каждому предложению автора где упоминается сложность добавлять префикс "объективная"...
ЗдОрово! Тоже хотел отписать, что статья отличная, просто терминология местами, на мой взгляд, не удачная.
Сам автор использует префикс "изначальная", что можно понимать как сложность исходной версии (до рефакторинга и т.п.) кода, уже реализующего функционал. Так что любой рефакторинг приводит просто к перераспределению этой сложности в этом коде с возможным вынесением этой сложности в головы программистов (с выполнением закона сохранения) .
Я хотел предложить префикс "имманентная" для обозначения сложности, присущей самой задаче (она же будет минимальной возможной суммарной сложностью ее решения). И префикс "привнесенная" для обозначения того, что вызвано средствами, используемыми для решения задачи (включая мозги конкретного разработчика, который ее решал ).
Сохраняется именно "имманентная" составляющая общей сложности решения задачи.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Ikemefula, Вы писали:
I>>Времени нужно потратить столько что бы запихнуть задачу в долговременную память, это у каждого человека по своему. на качество воспроизведения влияет предыдущий опыт и последующий.
IT>Это как?
Это называется ретроактивная интерференция. Т.е. события в настоящем влияют на хранимую информацию в памяти.
I>>Кстати, идея про метапрограммирование это попытка прыгнуть выше головы, когда решение бОлее верхнего уровня не дается в нужный срок, девелопер сбрасывает сложность в обратно из головы в код в надежде что код удастся лучше контролировать. Т.е. метапрограммирование — контролируемый хаос. Но все таки хаос а не порядок.
IT>Мы об одном и том же метапрограммировании говорим?
IT>>>Задачи, легко поддающиеся декомпозиции не являются алгоритмически сложными именно по причине возможности их декомпозиции. Но бывают и другие задачи, требующие для своего решения построения полной модели в голове. И если, допустим, за два часа такую модель не построишь, то отставив задачу на день приходится всё опять строить заново.
VGn>>В этом случае проблема обычно решается введением дополнительного уровня абстракции, что опять же доступно именно интелекту
IT>В каком в этом? В каком-то твоём частном случае? Возможно, я даже спорить не буду.
Приведи пример задачи, которую нельзя декомпозировать на одном либо на разных уровнях абстракции.
IT>>>Сложность само по себе одно и тоже — затраченные усилия VGn>>Перевожу — "энтропия и энергия это одно и то же".
IT>Где такой переводчик взял?
Энтропия — мера упорядоченности системы. Не возникает ассоциаций?
Затраченные усилия -> затраченная работа -> затраченная энергия — это и дураку понятно.
Сложно?
VGn>>Статья основана на предпосылках что сложность складывается, вычитается и делится арифметически.
IT>Ты не внимательно её читал. Статья как раз основана на том, что сложность нельзя оценивать количественно.
Но в тоже время основной посыл — "не фиг с ней бороться, она всё равно никуда не девается"
VGn>>Я например уверен, что при упорядочивании общая энтропия кода уменьшается, а значит закон сохранения сложности — полная чушь.
IT>А что такое упорядочивание?
Наведение порядка
Структурирование.
VGn>>Так что софистика ваша статья.
IT>
IT>В широком смысле термин «софист» означал искусного или мудрого человека.
IT>Ты это имел ввиду?
Софистика — сознательное применение в споре или в доказательствах неправильных доводов, так называемых софизмов — всякого рода уловок, замаскированных внешней, формальной правильностью. Характерными приемами софистики являются вырывание событий из их связи с другими, применение закономерностей одной группы явлений к явлениям другой группы, одной исторической эпохи к событиям другой эпохи и т.д.
Здравствуйте, VGn, Вы писали:
VGn>>>Статья основана на предпосылках что сложность складывается, вычитается и делится арифметически. IT>>Ты не внимательно её читал. Статья как раз основана на том, что сложность нельзя оценивать количественно. VGn>Но в тоже время основной посыл — "не фиг с ней бороться, она всё равно никуда не девается"
Это уже второй раз подряд, когда ты пытаешься нагло переврать смысл написанного. Мне не понятно, ты плохо читал, ничего не понял или тебе просто по сути сказать нечего, а поговорить очень хочется?
VGn>>>Я например уверен, что при упорядочивании общая энтропия кода уменьшается, а значит закон сохранения сложности — полная чушь.
IT>>А что такое упорядочивание?
VGn>Наведение порядка VGn>Структурирование.
Ну да. SRP упорядочивает код или не упорядочивает?
IT>>В широком смысле термин «софист» означал искусного или мудрого человека.
IT>>Ты это имел ввиду?
VGn>Софистика — сознательное применение в споре или в доказательствах неправильных доводов, так называемых софизмов — всякого рода уловок, замаскированных внешней, формальной правильностью. Характерными приемами софистики являются вырывание событий из их связи с другими, применение закономерностей одной группы явлений к явлениям другой группы, одной исторической эпохи к событиям другой эпохи и т.д.
VGn>Знать надо термины, а не выдумывать их значения.
Ты за нас не переживай. Термины мы знаем и главное, умеем их правильно применять, чему тебе не мешало бы поучиться. А то я так и не понял к чему ты тут софистику упомянул. Пришлось даже обращаться к историческому смыслу термина.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VGn, Вы писали:
VGn>>>В этом случае проблема обычно решается введением дополнительного уровня абстракции, что опять же доступно именно интелекту IT>>В каком в этом? В каком-то твоём частном случае? Возможно, я даже спорить не буду. VGn>Приведи пример задачи, которую нельзя декомпозировать на одном либо на разных уровнях абстракции.
Например, добавление генерации отладочной информации в компилятор. Необходимо протянуть её от парсера до кодо-генератора через все преобразования, ничего не сломав и сохранив все детали. Давай, вводи абстракцию.
Если нам не помогут, то мы тоже никого не пощадим.
VGn>>Энтропия — мера упорядоченности системы. Не возникает ассоциаций?
IT>Продолжай.
упорядоченность
синоним: порядок, система
антоним: хаотичность
(Wiki)
сложный
3. Трудный для рассмотрения или разрешения, запутанный.
(словарь Ушакова)
VGn>>Затраченные усилия -> затраченная работа -> затраченная энергия — это и дураку понятно.
IT>А дураку понятно в каких килоджоулях сравнивать сложность обучения и сложность восприятия плохоотформатированного кода?
А то ты не вспотел?
Кстати заметь, опять с усилий на сложность перескочил. Как бы невзначай.
IT>Например, добавление генерации отладочной информации в компилятор. Необходимо протянуть её от парсера до кодо-генератора через все преобразования, ничего не сломав и сохранив все детали. Давай, вводи абстракцию.
Где здесь модель?
Думается, у тебя большие сложности с отделением сущностей от действий.
VGn>>Софистика — сознательное применение в споре или в доказательствах неправильных доводов, так называемых софизмов — всякого рода уловок, замаскированных внешней, формальной правильностью. Характерными приемами софистики являются вырывание событий из их связи с другими, применение закономерностей одной группы явлений к явлениям другой группы, одной исторической эпохи к событиям другой эпохи и т.д.
VGn>>Знать надо термины, а не выдумывать их значения.
IT>Ты за нас не переживай. Термины мы знаем и главное, умеем их правильно применять, чему тебе не мешало бы поучиться. А то я так и не понял к чему ты тут софистику упомянул. Пришлось даже обращаться к историческому смыслу термина.
ИМХО приведённое выше определение немногим менее, чем полностью описывает твою статью. Так сказать умообразные заключения.
Здравствуйте, VGn, Вы писали:
VGn>>>Энтропия — мера упорядоченности системы. Не возникает ассоциаций?
IT>>Продолжай.
VGn>упорядоченность VGn> синоним: порядок, система VGn> антоним: хаотичность VGn>(Wiki) VGn>сложный VGn>3. Трудный для рассмотрения или разрешения, запутанный. VGn>(словарь Ушакова)
Ну да. И что? В огороде бузина, а в Киеве дядька?
VGn>>>Затраченные усилия -> затраченная работа -> затраченная энергия — это и дураку понятно.
IT>>А дураку понятно в каких килоджоулях сравнивать сложность обучения и сложность восприятия плохоотформатированного кода?
VGn>А то ты не вспотел?
Я то тут при чём? Тебе понятно или нет? Или вопрос требует слишком конкретного для тебя ответа?
Тебе нужно в соседней теме с DG пообщаться. Он пытается измерять сложность в вариантах, а ты в колоджоулях. Вы должны найти с ним много общего.
VGn>Кстати заметь, опять с усилий на сложность перескочил. Как бы невзначай.
Почитай статью. Только повнимательнее, там в первых же абзацах написано.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VGn, Вы писали:
IT>>Например, добавление генерации отладочной информации в компилятор. Необходимо протянуть её от парсера до кодо-генератора через все преобразования, ничего не сломав и сохранив все детали. Давай, вводи абстракцию.
VGn>Где здесь модель?
Как это где? Весь компилятор и есть модель.
VGn>Думается, у тебя большие сложности с отделением сущностей от действий.
Вообще-то мы здесь говорим не о сущностях и не о дейтсвиях, а о программировании и решении конкретных задач с помощью программирования. Ты предложил мне привести пример задачи, я тебе её привёл. Теперь твоя очередь, давай, применяй свои любимые абстракции.
Если нам не помогут, то мы тоже никого не пощадим.
VGn>>>Софистика — сознательное применение в споре или в доказательствах неправильных доводов, так называемых софизмов — всякого рода уловок, замаскированных внешней, формальной правильностью. Характерными приемами софистики являются вырывание событий из их связи с другими, применение закономерностей одной группы явлений к явлениям другой группы, одной исторической эпохи к событиям другой эпохи и т.д.
VGn>>>Знать надо термины, а не выдумывать их значения.
IT>>Ты за нас не переживай. Термины мы знаем и главное, умеем их правильно применять, чему тебе не мешало бы поучиться. А то я так и не понял к чему ты тут софистику упомянул. Пришлось даже обращаться к историческому смыслу термина.
VGn>ИМХО приведённое выше определение немногим менее, чем полностью описывает твою статью. Так сказать умообразные заключения.
Понятно. В принципе, когда по сути сказать нечего, а поговорить очень хочется, то можно ещё дальше зайти.
А про умообразные заключения — надо будет запомнить. Это как раз очень хорошо подходит одному любителю абстракций, который в этой теме много говорил, но пока не сказал ничего конкретного.
Если нам не помогут, то мы тоже никого не пощадим.
IT>>>Например, добавление генерации отладочной информации в компилятор. Необходимо протянуть её от парсера до кодо-генератора через все преобразования, ничего не сломав и сохранив все детали. Давай, вводи абстракцию.
VGn>>Где здесь модель?
IT>Как это где? Весь компилятор и есть модель.
Ну так ты его уже и без меня начал декомпозировать. Надо просто не бояться
VGn>>Думается, у тебя большие сложности с отделением сущностей от действий.
IT>Вообще-то мы здесь говорим не о сущностях и не о дейтсвиях, а о программировании и решении конкретных задач с помощью программирования. Ты предложил мне привести пример задачи, я тебе её привёл. Теперь твоя очередь, давай, применяй свои любимые абстракции.
Оттолкнулись мы от фразы
Но бывают и другие задачи, требующие для своего решения построения полной модели в голове.
Здравствуйте, Lloyd, Вы писали: L>>>Следовательно, если мы не будем пытаться "заранее выделить код", то взамен ничего не потеряем, сложность уменьшим. G>>Противоположность увеличения сложности — неувеличение, а не строгое уменьшение. Поэтой при нулевых поползновениях сложность не изменится.
L>Тут не термодинамика, тут любой процесс можно повернуть вспять и очень легко — окрываешь сорсконтрол и делаешь Revert Changes. И если в ревизии 101 у тебя при прочих равных сложность выше, чем в ревизии 100, то откатившись на 100-ю ревизию получишь уменьшение сложности, которого по мнению автора статьи "не существует".
Это плохо работает, когда мы пытаемся заранее выделить код, который по идее можно повторно использовать, но на практике его повторно использовать не получается.
А вобще в таких случаях("заранее выделить код") приходится принимать интуитивное решение на основе разумного баланса между противоречиями. Причем противоречия принципиальные неустранимые да еще и в условиях неопределенности.
Есть две поговорки "Быстрее едешь дальше будешь", "Тише едешь дальше будешь" обе из них правильные. Примеры думаю не нужны.
Есть высказывания в XP "Никогда не делай сегодня то, что может потребоваться только завтра". Но это такая же метафорическая поговорка.
При принятии решения о "заранее выделить код" на завтра приходится учитывать.
1) Если при выборе одного из двух решений, потом в случае неудачного выбора откат назад слишком трудоемкий (в сумме труды на первый вариант + переделка на второй). Тогда тут 10 раз надо сначала подумать.
2) Надо пытаться предсказать что потребуется завтра, если пункт 1 заставляет. Причем надо оценить не только вероятности того насколько подойдет вариант, но и сложность создания обоих вариантов, а также перевода одного варианта в другой.Но ясновидцев нет. Только эмпирические интуитивные прогнозы можно делать. И бывает когда они не делаются.
3) Надо учитывать что бывают случаи, если что-то не сделаешь сегодня, то завтра на это уже в 5 раз больше усилий затратишь.
Если например у такой фичи слабая связность. int Sqr(unt x){return x*x;}
Если есть подозрения на 50% что потом потребуется более универсальный вариант. Например не в квадрат возводить, а в вещественную степень. То глупо это делать сегодня, подождать пока понадобится.
А если писал фичу две недели, и есть подозрения на 50% что потом к ней потребуется добавка которую 1 час писать, а если отложить на 2 недели, то потребуется 8 часов чтобы ту же добавку написать (переключение контекста).
Если подсчитать матожидание затрат (как бы не смешно звучало) : в первом случае 1 час, во втором 0.5*8
В реальности матожидания рассчитывать невозможно, слишком много факторов, с постоянно меняющимися стоимостями,вероятностями и прочими... Только интуитивные оценки остаются в ральных ситуациях. А в теории можно только обозначить разные факторы, чтоб знать где вобще копать.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, VGn, Вы писали:
VGn>>>>Энтропия — мера упорядоченности системы. Не возникает ассоциаций?
IT>>>Продолжай.
VGn>>упорядоченность VGn>> синоним: порядок, система VGn>> антоним: хаотичность VGn>>(Wiki) VGn>>сложный VGn>>3. Трудный для рассмотрения или разрешения, запутанный. VGn>>(словарь Ушакова)
IT>Ну да. И что? В огороде бузина, а в Киеве дядька?
Немного о месте ассоциативного подхода в лексике Ассоциативное мышление
VGn>>>>Затраченные усилия -> затраченная работа -> затраченная энергия — это и дураку понятно.
IT>>>А дураку понятно в каких килоджоулях сравнивать сложность обучения и сложность восприятия плохоотформатированного кода?
VGn>>А то ты не вспотел?
IT>Я то тут при чём? Тебе понятно или нет? Или вопрос требует слишком конкретного для тебя ответа?
Это шутка о тепловыделении, если не понял.
IT>Тебе нужно в соседней теме с DG пообщаться. Он пытается измерять сложность в вариантах, а ты в колоджоулях. Вы должны найти с ним много общего.
Ну вот. Теперь ты мне ставишь в вину именно ту логическую ошибку, которую я поставил в вину тебе. Замечательно.
VGn>>Кстати заметь, опять с усилий на сложность перескочил. Как бы невзначай.
IT>Почитай статью. Только повнимательнее, там в первых же абзацах написано.
Здравствуйте, VGn, Вы писали:
VGn>>>Где здесь модель?
IT>>Как это где? Весь компилятор и есть модель. VGn>Ну так ты его уже и без меня начал декомпозировать.
Совершенно верно, он уже и без тебя докомпозирован.
VGn>Надо просто не бояться
Вот и не бойся, давай, давай. Меньше слов — больше дела. Применяй свои абстракции.
VGn>Оттолкнулись мы от фразы
Для того, чтобы вырывать фразы из контекста ума много не надо. Надо совсем мало ума. Ты лучше сообрази как предложенную задачу декомпозировать.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VGn, Вы писали:
IT>>Я то тут при чём? Тебе понятно или нет? Или вопрос требует слишком конкретного для тебя ответа? VGn>Это шутка о тепловыделении, если не понял.
Я не понял другого. Почему ты не даёшь ответы на вполне конкретные вопросы? Хотя, что тут не понятного
IT>>Тебе нужно в соседней теме с DG пообщаться. Он пытается измерять сложность в вариантах, а ты в колоджоулях. Вы должны найти с ним много общего.
VGn>Ну вот. Теперь ты мне ставишь в вину именно ту логическую ошибку, которую я поставил в вину тебе. Замечательно.
Можешь поставить мне в вину сразу хоть весь список своих логических ошибок. А лучше, чтобы не повторяться, создай домашнюю страничку с таким списком и раздавай на неё ссылки всем своим собеседникам.
Наличие ошибки в суждениях, как и любую свою позицию, нужно обосновывать, разве ты этого не знал?
Например, у меня к тебе имеется притензия в том, что ты не отвечаешь на элементарные вполне конкретные вопросы, которые тебе задаются в ответ на твои суждения. Вот один из примеров:
IT>>А что такое упорядочивание?
VGn>Наведение порядка
VGn>Структурирование.
Ну да. SRP упорядочивает код или не упорядочивает?
Где твой ответ?
Видишь? У меня есть к тебе претензия и я могу её подкрепить конкретными примерами. Ты же просто кидаешь обвинения в воздух и почему-то считаешь их уже доказанными. Где логика, где твоё ассоциативное мышление? Ты вообще сам читаешь ссылки, которые здесь приводишь?
VGn>>>Кстати заметь, опять с усилий на сложность перескочил. Как бы невзначай. IT>>Почитай статью. Только повнимательнее, там в первых же абзацах написано. VGn>Куда, куда ты меня послал?
Да ясно всё с тобой и куда тебя следовало послать с самого начала. Жалко только времени, потраченного на бессмысленный трёп с любителями выдавать умственную ветошь за истину.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Silver_s, Вы писали:
S_>При принятии решения о "заранее выделить код" на завтра приходится учитывать. S_>1) Если при выборе одного из двух решений, потом в случае неудачного выбора откат назад слишком трудоемкий (в сумме труды на первый вариант + переделка на второй). Тогда тут 10 раз надо сначала подумать.
Если оба варианта равновероятны, то надо выбирать тот, который потребует меньше писанины.
Если нет, то тот, который наиболее вероятен.
S_>2) Надо пытаться предсказать что потребуется завтра, если пункт 1 заставляет. Причем надо оценить не только вероятности того насколько подойдет вариант, но и сложность создания обоих вариантов, а также перевода одного варианта в другой.Но ясновидцев нет. Только эмпирические интуитивные прогнозы можно делать. И бывает когда они не делаются.
Не надо предсказывать. Надо руководствоваться правилос выше.
Почти любая попытка "продумать наперед" обычно не приносит полезных результатов.
S_>3) Надо учитывать что бывают случаи, если что-то не сделаешь сегодня, то завтра на это уже в 5 раз больше усилий затратишь.
Такого не бывает, если не пытаться "продумать наперед".
S_>А если писал фичу две недели, и есть подозрения на 50% что потом к ней потребуется добавка которую 1 час писать, а если отложить на 2 недели, то потребуется 8 часов чтобы ту же добавку написать (переключение контекста). S_>Если подсчитать матожидание затрат (как бы не смешно звучало) : в первом случае 1 час, во втором 0.5*8
Неверно. Это только сдвинет переключение контекста, а не уберет его.
Кроме того переключение контекста — очень субъективная вещь.
S_>В реальности матожидания рассчитывать невозможно, слишком много факторов, с постоянно меняющимися стоимостями,вероятностями и прочими... Только интуитивные оценки остаются в ральных ситуациях. А в теории можно только обозначить разные факторы, чтоб знать где вобще копать.
Не надо копать, надо делать то что нужно сейчас и уменьшать связность.
Здравствуйте, gandjustas, Вы писали:
S_>>3) Надо учитывать что бывают случаи, если что-то не сделаешь сегодня, то завтра на это уже в 5 раз больше усилий затратишь. G>Такого не бывает, если не пытаться "продумать наперед".
Это довольно спорное утверждение. Как раз продумывать наперёд надо. Надо ли делать наперёд — это другой вопрос. Вполне конкретный пример с не продумали наперёд — Linq 2 SQL в части поддержки нескольких провайдеров. Закончилось всё закрытием проекта. Кстати, альтернативные проекты страдают такой же точно проблемой. Между тем реализация нескольких провайдеров не представляет большой сложности, если продумать наперёд, а ещё лучше сразу реализовать.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
S_>>>3) Надо учитывать что бывают случаи, если что-то не сделаешь сегодня, то завтра на это уже в 5 раз больше усилий затратишь. G>>Такого не бывает, если не пытаться "продумать наперед".
IT>Это довольно спорное утверждение. Как раз продумывать наперёд надо. Надо ли делать наперёд — это другой вопрос. Вполне конкретный пример с не продумали наперёд — Linq 2 SQL в части поддержки нескольких провайдеров. Закончилось всё закрытием проекта. Кстати, альтернативные проекты страдают такой же точно проблемой. Между тем реализация нескольких провайдеров не представляет большой сложности, если продумать наперёд, а ещё лучше сразу реализовать.
Создание фреймворка отличается от создания приложения.
Для фреймворка необходимо продумывание того что он будет делать. Но это уже продумывание будет на более высоком уровне, чем отдельные классы или фичи.
Здравствуйте, gandjustas, Вы писали:
G>Создание фреймворка отличается от создания приложения.
И отличается и пересекается, всё вместе.
G>Для фреймворка необходимо продумывание того что он будет делать. Но это уже продумывание будет на более высоком уровне, чем отдельные классы или фичи.
В том то и дело, что думали. В Linq 2 SQL даже выделенный для этого (правда засиленный) модуль есть. Но вот ни в деталях, ни на уровне отдельных классов, ни на более высоком уровне ничего путного не получилось. Я уже это неоднократно озвучивал, озвучу ещё раз:
Чем позже архитектура начинает учитывать определённые детали, тем менее приспособленной она становится для внесения соответствующих изменений.
С ростом кода его гибкость теряется и его приходится периодически размягчать с помощью соотвествующих техник и рефакторинга. Но иногда это становится невозможным, как, например, в случае с компилятором Немерле. Замечательный язык, а компилятор — отшлифованный до блеска кусок гранита. Сразу не учли всего несколько пустяков, вроде вменяемой поддержки locations, и создание интеграции для студии превратилось в многолетний кошмар. Нужно ли было сразу писать интеграцию? Вряд ли. Можно ли было учесть определённые детали? Безусловно.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Silver_s, Вы писали:
S_>>1) Если при выборе одного из двух решений... Тогда тут 10 раз надо сначала подумать. G>Если оба варианта равновероятны, то надо выбирать тот, который потребует меньше писанины. G>Если нет, то тот, который наиболее вероятен. G>Не надо предсказывать. Надо руководствоваться правилос выше.
В правиле выше сказано про вероятности. А определение вероятностей это и есть попытка сделать предсказание. Не по звездам делаются адекватные оценки вероятностей. И не по пакетам программ мат-статистики, когда о таких вещах речь идет. К тому же определить вариант где меньше писанины это тоже гадание. Да и какая писанина интересует, в краткосрочном плане или в долгосрочном?
G>Почти любая попытка "продумать наперед" обычно не приносит полезных результатов.
А вот с этим, как ни странно согласен. Главное чтобы это не вело к ложным выводам и действиям, большим потерям времени.
Но когда проходятся точки невозврата, после которой остановить паровоз и отправить обратно становится тяжело. Тогда стоит гораздо больше времени потратить на попытки предсказать к чему может привести вариант. И кроме того на поиск еще и других вариантов можно потратиться, которые на первый взгляд не видны.
Но под "продумать наперед" я не имею ввиду проектирование сверху-вниз, а потом продавливание этих первоначальных решений до потери пульса, игнорируя все факты несостоятельности таких первоначальных решений. Это как раз, надекватная оценка способностей продумать ситуацию наперед, не удалось продумать а все равно упрямится...
Думаю не станешь отрицать что существуют конторы где программисты говорят "Ой как все криво,косо сделано" Но переделать невозможно. Такие системы и конторы держатся на плаву если слабая связь между отдельными программистами(один не может проушить работу другого, и не должен знать что делает сосед). И слабая связь с предыдущими годами работы(добавления не смогут порушить старое). Переделывать в этом случае невыгодно, когда больше 200 человеко-лет вложено, переделка может обойтись дорого.
Т.е. там может быть важна(из-за чего контора на плаву держится) не столько архитектура, а поддержка пользователей,предметная область,сама бизнес логика. А в архитектурном плане много лет много человек делают абсолютно одно и тоже, клонируют кусок кода втыкают бизнес логику, и добавляют в общий массив. И плюс часть времени на борьбу с багами, обход граблей, возникающих из-за кривизны.
А бывают системы где все заходит вобще в полный тупик из-за какой-то мелочи или кривизны архитектуры. И откаты назад с глубокими переделками неизбежны, поскольку нужно не наращивание за счет количества, а качественное развитие. Там скорее принципы XP более актуальны.
S_>>А если писал фичу две недели, и есть подозрения на 50% что потом к ней потребуется добавка которую 1 час писать, а если отложить на 2 недели, то потребуется 8 часов чтобы ту же добавку написать (переключение контекста). S_>>Если подсчитать матожидание затрат (как бы не смешно звучало) : в первом случае 1 час, во втором 0.5*8 G>Неверно. Это только сдвинет переключение контекста, а не уберет его. G>Кроме того переключение контекста — очень субъективная вещь.
G>Не надо копать, надо делать то что нужно сейчас и уменьшать связность.
Да, копать сомо по себе не надо,как самоцель, надо прокачивать интуицию для таких случаев где формальный анализ бессилен.
А интуиция по оценке неких свойств системы или некой области, насколько знаю, прокачивается только путем наблюдения и экпериментального изучения (действие-наблюдение реакции,результата).
За какими факторами,свойствами, атрибутами, наблюдаешь. По ним и будешь иметь представление. За чем не наблюдаешь, того нет.
А то что нужно сейчас, конечно тоже надо делать. После этого уже возможно появятся идеи как это можно сделать лучше по-другому. Из ничего идеи трудно создать. Да и вобще мне больше нравится философия XP где все "здесь и сейчас" но не доводя до абсурда.
-----
Если на дырки в земле не обращать внимания,то суслики не существуют.И непонятно кто капусту жрет в огороде — самоликвидируется наверно.
Но в принципе, если огород в порядке нет смысла каждую неровность в земле изучать.
Это замечание уже скорее по поводу вопросов из обсуждаемой статьи.
К примеру ту же WPF могли сделать только одним способом? Или много вариантов из которых тяжело выбирать — один по своему хорош другой по своему и каждый в чем-то проигрывает. По условию бы делала команда одного проф. уровня и специализации. А не сравнивать с тем что бы сделала конвеерная бригада по производству учетных систем.Для которых слово заказчика-закон и менеджер проектов никогда не ошибается.
Или такой частный случай. Hеализация и работа property в WPF сложнее чем в WinForms? Если сложнее то зачем так сделали? Везде ли подойдет такая реализация пропертей или могут обозвать извращенцем того кто такое же сделал в другой задаче? Ясно что такие пропертя определенные неудобства тоже причиняют (кроме положительных моментов).Кроме того их еще изучить надо чтобы понять. Когда существует простой и очевидный способ из объектов просто собирать через Reflection.
Если кому то в статье бросается в глаза только то что она формально не строгая. Значит с аналогичными проблемами на практике не сталкивались, и эти вопросы просто не актуальны.
На просьбу сделать попытку изложить то же, но более формально. Скорее всего будет ответ — невозможно формализовать то чего нет.
Сложность определяется энтропией, а поскольку к данным вопросам формулы энтропии не подходят. А другие логичные формулы и строгое описание не придумываются, значит это субьективизм,ересь, и пустопорожние разговоры оторванные от жизни.
З.Ы. Надоело срочить по клаве, перехожу в читатели.
А если кратко то к каждой строчке на которые отвечал написал бы "Согласен, с оговоркой что не всегда так бывает". Кроме ... неявного утверждения что не надо гадать а просто выбирать наибольшую вероятность
Надеюсь ветка продолжится. И не в виде борьбы за чистоту терминов.
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Silver_s, Вы писали:
S_>>>1) Если при выборе одного из двух решений... Тогда тут 10 раз надо сначала подумать. G>>Если оба варианта равновероятны, то надо выбирать тот, который потребует меньше писанины. G>>Если нет, то тот, который наиболее вероятен. G>>Не надо предсказывать. Надо руководствоваться правилос выше.
S_> В правиле выше сказано про вероятности. А определение вероятностей это и есть попытка сделать предсказание. Не по звездам делаются адекватные оценки вероятностей. И не по пакетам программ мат-статистики, когда о таких вещах речь идет. К тому же определить вариант где меньше писанины это тоже гадание.
Елси нету заранее точных оценок, то варианты можно считать равновероятными.
S_>Да и какая писанина интересует, в краткосрочном плане или в долгосрочном?
В краткосрочном.
S_> Думаю не станешь отрицать что существуют конторы где программисты говорят "Ой как все криво,косо сделано" Но переделать невозможно. Такие системы и конторы держатся на плаву если слабая связь между отдельными программистами(один не может проушить работу другого, и не должен знать что делает сосед). И слабая связь с предыдущими годами работы(добавления не смогут порушить старое). Переделывать в этом случае невыгодно, когда больше 200 человеко-лет вложено, переделка может обойтись дорого.
Я сам в такой работал. Но не понял в чем необходимость переделок.
Обычно переделок много на этапе интенсивного развития пока не окончательно сформирована концепция создаваемой системы, тогда как после 200 человеко-лет работы развитие идет экстенсивно, те код просто дописывается в нужных местах и фиксятся баги.
IT>Вот и не бойся, давай, давай. Меньше слов — больше дела. Применяй свои абстракции.
Вот только демагогии не надо.
VGn>Приведи пример задачи, которую нельзя декомпозировать на одном либо на разных уровнях абстракции.
Например, добавление генерации отладочной информации в компилятор. Необходимо протянуть её от парсера до кодо-генератора через все преобразования, ничего не сломав и сохранив все детали. Давай, вводи абстракцию.
В качестве примера невозможности декомпозиции привёл компилятор, который сам же обозначил "от парсера до кодо-генератора". Чего от меня-то хочешь? Конкретного решения своей "сложной" задачи? Конкретного решения способа протягивания абстрактной отладочной информации через абстрактный компилятор к вопросу о моделях?
Я не буду этим заниматься.
IT>Ну да. SRP упорядочивает код или не упорядочивает?
IT>Где твой ответ?
Я принял вопрос за риторический. Потому что само собой ведение речи об областях ответственности уже структурирует разработку, ибо область ответственности — это как раз и есть одна из абстракций верхнего уровня.
VGn>>Это шутка о тепловыделении, если не понял.
IT>Я не понял другого. Почему ты не даёшь ответы на вполне конкретные вопросы? Хотя, что тут не понятного
IT>>>Тебе нужно в соседней теме с DG пообщаться. Он пытается измерять сложность в вариантах, а ты в колоджоулях. Вы должны найти с ним много общего.
VGn>>Ну вот. Теперь ты мне ставишь в вину именно ту логическую ошибку, которую я поставил в вину тебе. Замечательно.
IT>Можешь поставить мне в вину сразу хоть весь список своих логических ошибок. А лучше, чтобы не повторяться, создай домашнюю страничку с таким списком и раздавай на неё ссылки всем своим собеседникам.
IT>Наличие ошибки в суждениях, как и любую свою позицию, нужно обосновывать, разве ты этого не знал?
Хорошо. Иногда я выражаюсь не очень связно. Особенно когда думаю, что человек настолько образован, что ему известны предпосылки моих суждений.
Придётся разжевать.
Очень часто при анализе сложных систем и процессов используют аналогии из термодинамики. Потому что термодинамика — одна из самых стройных наук и при этом имеет большую философскую основу.
Поэтому во многих обсуждениях можно услышать "энтропия", "работа", "энергия" и т.д.
(не поверю, что ты не знаешь фразу "энтропия кода")
Поставив в заголовок "закон сохранения" ты практически автоматически перешёл на эту аналогию, потому что законы сохранения обычно ассоциируются с законами термодинамики.
Теперь о самой аналогии.
За энтропией как мерой хаоса, можно характеризовать такие вещи, как:
— беспорядок в требованиях,
— беспорядок в модели,
— беспорядок в коде,
— беспорядок в головах
Естественно, что с беспорядком борятся упорядочиванием, структуризацией, построением иерархий.
В сущности абстрагирование — это в какой-то мере и есть построение иерархии.
Собственно из теории.
Состояния с высокой энтропией являются более равновесными состояниями, чем с низкой.
Что означает:
— на структурирование необходимо затратить энергию
— система стремится перейти из структурированного состояния в хаотичное (не будем для краткости учитывать нелинейность, локальные экстремумы и т.д., хотя именно на нелинейности таких переходов и основаны те эффекты, которые ты обсуждаешь в статье)
Собственно о сложности
Как описывалось ранее и другими участниками дискуссии, человеческий разум устроен таким образом, что проще воспринимается структурированная информация, а значит связывать сложность с энтропией вполне приемлемо (отсюда и термин "энтропия кода"). Отсюда и аналогии энергии и полезной работы с усилиями по разработке кода.
Тем более, что знаменитое суждение "программирование — борьба со сложностью" в принципе связано не только со сложностью кода, но и с наведением порядка в объекте, для которого создаётся ПО.
Собственно, чем сложнее модель, тем больше энергии надо затратить на её структурирование.
Вобщем такая аналогия применяется довольно часто и мне даже трудно понять, почему ты о ней не знаешь.
Собственно и из этих предпосылок я и заявил, что тождественное приравнивание сложности и затрачиваемых усилий — это бред.
Очень нужная статья. Мне кажется её главная ценность не в постулируемом "законе" — это и так все знают, а в попытке выделить различные виды сложности, с которыми чаще всего приходится иметь дело при разработке приложений. Именно с этой точки зрения нужно оценивать любое решение при разработке ПО.
Пусть у нас имеется несколько вариантов действий из которых нужно выбрать. Можно представить каждое из возможный действий как точку в пятимерном пространстве различных типов сложностей. Разработав некоторую функцию, которая для может для точек этого пространства определять нашу способность бороться со сложностями (в идеале сразу в человек/часах), мы можем свести обсуждение вариантов к оценке коэффициентов в этой функции для каждого конкретного коллектива программистов.
Разумеется, есть разные взгляды на возможные классификации сложности. Вот продукт недолгого гугления:
Дейкстра [Э. Дейкстра. Заметки по структурному программированию // У. Дал, Э. Дейкстра, К. Хоор. Структурное программирование. -- М.: Мир, 1975. -- с. 7-97.] выделяет три интеллектуальные возможности человека, используемые при разработке ПС[ПРОГРАММНЫХ СРЕДСТВ]:
· способность к перебору,
· способность к абстракции,
· способность к математической индукции.
Способность человека к перебору связана с возможностью последовательного переключения внимания с одного предмета на другой с узнаванием искомого предмета. Эта способность весьма ограничена -- в среднем человек может уверенно (не сбиваясь) перебирать в пределах 1000 предметов (элементов). Человек должен научиться действовать с учетом этой своей ограниченности. Средством преодоления этой ограниченности является его способность к абстракции, благодаря которой человек может объединять разные предметы или экземпляры в одно понятие, заменять множество элементов одним элементом (другого рода). Способность человека к математической индукции позволяет ему справляться с бесконечными последовательностями.
Если заменить слова "способность" на "сложность", то мы получим альтернативное разбиение субъективных сложностей из приведенной в статье классификации (Сложность восприятия + Алгоритмическая сложность + Сложность обучения).
С другой стороны, оценки этих "способностей" могут быть использованы как коэффициенты для функции оценки способности борьбы со сложностью.
Вообще поднятый вопрос очень правильный и ждет своих евангелистов и баззз-вордов для продвижения в сознание масс.
G>>Почти любая попытка "продумать наперед" обычно не приносит полезных результатов.
S_>Но когда проходятся точки невозврата, после которой остановить паровоз и отправить обратно становится тяжело. Тогда стоит гораздо больше времени потратить на попытки предсказать к чему может привести вариант. И кроме того на поиск еще и других вариантов можно потратиться, которые на первый взгляд не видны.
Пример: компания "Медиател" пару лет терпела многомилионные убытки, являвшиеся фактически единственной статьёй убытка концерна Ситроникс.
Из-за того, что титульный продукт начался с относительно наколенной разработки, развился экстенсивно и разбрёлся на несколько форков с отдельными группами разработки.
Только потому, что перестраивать архитектуру в своё время было "долго".
В конце концов, на сколько я знаю, часть заказчиков была утеряна и продукт был заменён полностью.
Здравствуйте, VGn, Вы писали:
VGn>Очень часто при анализе сложных систем и процессов используют аналогии из термодинамики. Потому что термодинамика — одна из самых стройных наук и при этом имеет большую философскую основу. VGn>Поэтому во многих обсуждениях можно услышать "энтропия", "работа", "энергия" и т.д. VGn>(не поверю, что ты не знаешь фразу "энтропия кода") VGn>Поставив в заголовок "закон сохранения" ты практически автоматически перешёл на эту аналогию, потому что законы сохранения обычно ассоциируются с законами термодинамики.
Эпиграф: "Все аналогии фальшивы"
VGn>Теперь о самой аналогии. VGn>За энтропией как мерой хаоса, можно характеризовать такие вещи, как: VGn>- беспорядок в требованиях, VGn>- беспорядок в модели, VGn>- беспорядок в коде, VGn>- беспорядок в головах VGn>Естественно, что с беспорядком борятся упорядочиванием, структуризацией, построением иерархий. VGn>В сущности абстрагирование — это в какой-то мере и есть построение иерархии. VGn>Собственно из теории. VGn>Состояния с высокой энтропией являются более равновесными состояниями, чем с низкой.
Кхм, если говорить строго, то система может быть или равновесной, или нет. "Более" или "менне" здесь не применимы. VGn>Что означает: VGn>- на структурирование необходимо затратить энергию VGn>- система стремится перейти из структурированного состояния в хаотичное (не будем для краткости учитывать нелинейность, локальные экстремумы и т.д., хотя именно на нелинейности таких переходов и основаны те эффекты, которые ты обсуждаешь в статье)
Вот здесь у нас протекает аналогия с термодинамикой — при остывании жидкости она отдает энергию, при этом становясь более структурированной. Если быть точным, то структурированная термодинамическая система может иметь большую энтропию, чем неструктурированная.
Безусловно, без внешнего воздействия энтропия системы растет и её понижение требует внешнего вмешательства.
Безусловно, это относится только к термодинамике. Структурированность кода всегда падает, если не прилагать усилий.
VGn>Собственно о сложности VGn>Как описывалось ранее и другими участниками дискуссии, человеческий разум устроен таким образом, что проще воспринимается структурированная информация, а значит связывать сложность с энтропией вполне приемлемо (отсюда и термин "энтропия кода"). Отсюда и аналогии энергии и полезной работы с усилиями по разработке кода.
"Все аналогии фальшивы." Да и сама по себе энтропия в термодинамике не есть функция энергии (или наоборот).
VGn>Тем более, что знаменитое суждение "программирование — борьба со сложностью" в принципе связано не только со сложностью кода, но и с наведением порядка в объекте, для которого создаётся ПО. VGn>Собственно, чем сложнее модель, тем больше энергии надо затратить на её структурирование.
Как только дашь определение энергии для ИТ, тогда можно будет его использовать в рассуждениях. Пока я только человеко-месяц знаю — тоже не супер, но что имеем тем и пользуемся. VGn>Вобщем такая аналогия применяется довольно часто и мне даже трудно понять, почему ты о ней не знаешь.
VGn>Собственно и из этих предпосылок я и заявил, что тождественное приравнивание сложности и затрачиваемых усилий — это бред.
С этим я согласен. В предыдущем посте я как раз писал о функции, которая может "определять нашу способность бороться со сложностями". Конечно, она зависит не только от сложности. (Правда я не понял, где ты нашел противное утверждение?)
Здравствуйте, VGn, Вы писали:
VGn>Пример: компания "Медиател" пару лет терпела многомилионные убытки, являвшиеся фактически единственной статьёй убытка концерна Ситроникс. VGn>Из-за того, что титульный продукт начался с относительно наколенной разработки, развился экстенсивно и разбрёлся на несколько форков с отдельными группами разработки. VGn>Только потому, что перестраивать архитектуру в своё время было "долго". VGn>В конце концов, на сколько я знаю, часть заказчиков была утеряна и продукт был заменён полностью.
Интересно. Дашь пруфлинк — положу в избранное. Буду использовать при убеждении в необходимости рефакторинга.
M>Кхм, если говорить строго, то система может быть или равновесной, или нет. "Более" или "менне" здесь не применимы.
Как назвать равновесное состояние с меньшим уровнем энергии?
VGn>>Что означает: VGn>>- на структурирование необходимо затратить энергию VGn>>- система стремится перейти из структурированного состояния в хаотичное (не будем для краткости учитывать нелинейность, локальные экстремумы и т.д., хотя именно на нелинейности таких переходов и основаны те эффекты, которые ты обсуждаешь в статье) M>Вот здесь у нас протекает аналогия с термодинамикой — при остывании жидкости она отдает энергию, при этом становясь более структурированной.
Смотря в чём. Или ты вообще споришь с понятием энтропии?
Имхо офтопик.
M>Как только дашь определение энергии для ИТ, тогда можно будет его использовать в рассуждениях. Пока я только человеко-месяц знаю — тоже не супер, но что имеем тем и пользуемся.
Дополнение:
очевидно и в новом виде продукт потерпел неудачу. Скорее всего из-за утраты доверия.
Вместо Медиателовского (Sitronics Telecom Solutions) CRM решили поставить Siebel и доверили это Квазару.
Я даже не знаю на сколько они теперь сократили количество разработчиков.
VGn>>Приведи пример задачи, которую нельзя декомпозировать на одном либо на разных уровнях абстракции.
VGn>Например, добавление генерации отладочной информации в компилятор. Необходимо протянуть её от парсера до кодо-генератора через все преобразования, ничего не сломав и сохранив все детали. Давай, вводи абстракцию.
VGn>В качестве примера невозможности декомпозиции привёл компилятор, который сам же обозначил "от парсера до кодо-генератора". Чего от меня-то хочешь? Конкретного решения своей "сложной" задачи? Конкретного решения способа протягивания абстрактной отладочной информации через абстрактный компилятор к вопросу о моделях? VGn>Я не буду этим заниматься.
Не хочешь не занимайся. Ты просил привести пример, я привёл тебе пример. Могу даже сказать где взять исходники и на всё это взглянуть. Там абстракций уже выше крыши, по всем законам компиляторостроения, и новые абстракции на задачу не натягиваются. Но главное даже не это. Сложность такой задачи не в невозможности ввести новый уровень абстракции, а в том, что задача не решается частями. Ввод нового элемента в AST сразу ломает весь компилятор и приходится работать в слепую, пока задача не будет решена полностью.
Если нам не помогут, то мы тоже никого не пощадим.
IT>>Ну да. SRP упорядочивает код или не упорядочивает?
IT>>Где твой ответ?
VGn>Я принял вопрос за риторический. Потому что само собой ведение речи об областях ответственности уже структурирует разработку, ибо область ответственности — это как раз и есть одна из абстракций верхнего уровня.
Вопрос был вполне конкретный. А вёл я к тому, что даже процесс упорядочивания не ведёт к обязательному упрощению. Иногда бывает совсем наоборот.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VGn, Вы писали:
VGn>Хорошо. Иногда я выражаюсь не очень связно. Особенно когда думаю, что человек настолько образован, что ему известны предпосылки моих суждений. VGn>Придётся разжевать.
Вот. Уже гораздо лучше
VGn>Очень часто при анализе сложных систем и процессов используют аналогии из термодинамики. Потому что термодинамика — одна из самых стройных наук и при этом имеет большую философскую основу. VGn>Поэтому во многих обсуждениях можно услышать "энтропия", "работа", "энергия" и т.д. VGn>(не поверю, что ты не знаешь фразу "энтропия кода")
Если бы сложность разработки ПО можно было описать с помощью других аналогий, то её бы уже давно описали и без нас с тобой. Поверь мне на слово. Но пока этого не произошло. Не помогает здесь почему-то ни термодинамика, ни философия. Некоторые принципы и аналогии позаимствовать можно, но не более того.
VGn>Поставив в заголовок "закон сохранения" ты практически автоматически перешёл на эту аналогию, потому что законы сохранения обычно ассоциируются с законами термодинамики.
По поводу названия и некоторых терминов я уже отвечал. Если это тебе не нравится, предлагай свои. Меня это всё мало волнует. Если ты думаешь, что я думаю, что я изобрёл новый закон, то могу тебя обрадовать, я так не думаю. Наверное, смайлик сразу после названия был бы вполне уместен. Что поделать, есть у меня страсть к пафосным названиям, вроде Закона сохранения сложности или Память больше не ресурс
VGn>Теперь о самой аналогии. VGn>За энтропией как мерой хаоса, можно характеризовать такие вещи, как: VGn>- беспорядок в требованиях, VGn>- беспорядок в модели, VGn>- беспорядок в коде, VGn>- беспорядок в головах VGn>Естественно, что с беспорядком борятся упорядочиванием, структуризацией, построением иерархий. VGn>В сущности абстрагирование — это в какой-то мере и есть построение иерархии.
Ты забыл добавить ещё
— беспорядок упорядочивания
— беспорядок абстрагирования
VGn>Собственно из теории. VGn>Состояния с высокой энтропией являются более равновесными состояниями, чем с низкой. VGn>Что означает: VGn>- на структурирование необходимо затратить энергию VGn>- система стремится перейти из структурированного состояния в хаотичное (не будем для краткости учитывать нелинейность, локальные экстремумы и т.д., хотя именно на нелинейности таких переходов и основаны те эффекты, которые ты обсуждаешь в статье) VGn>Собственно о сложности VGn>Как описывалось ранее и другими участниками дискуссии, человеческий разум устроен таким образом, что проще воспринимается структурированная информация, а значит связывать сложность с энтропией вполне приемлемо (отсюда и термин "энтропия кода"). Отсюда и аналогии энергии и полезной работы с усилиями по разработке кода. VGn>Тем более, что знаменитое суждение "программирование — борьба со сложностью" в принципе связано не только со сложностью кода, но и с наведением порядка в объекте, для которого создаётся ПО. VGn>Собственно, чем сложнее модель, тем больше энергии надо затратить на её структурирование. VGn>Вобщем такая аналогия применяется довольно часто и мне даже трудно понять, почему ты о ней не знаешь.
Да это всё понятно и так. Без теорий. Достаточно здравого смысла.
Не понятно как твои теории объясняют то, что при упорядочивании сложность кода может увеличиваться. В программировании это называется overarchitecture. Штука, встечающаяся чуть ли не чаще, чем вообще полное отсутствие архитектуры. Любой инструмент, любая техника, любой принцип, любая теория в программировании может быть использована не только во благо, но не редко совсем наоборот. Происходит это в следствии того, что попытка устранения сложности в одном месте всегда, ВСЕГДА!, сопровождается добавлением сложности в другом. Статья именно об этом.
VGn>Собственно и из этих предпосылок я и заявил, что тождественное приравнивание сложности и затрачиваемых усилий — это бред.
Я не ставлю знака равенства между усилиями по разработке кода и затраченной энеригией в любом виде. С чего ты вообще это взял? Это твой домысел и, соответственно, твой бред. Я вообще против того, чтобы искать способы, которыми можно было бы количественно измерить сложность. И это тоже явно и не двусмысленно указано в статье. Меня не интересуют точные количественные оценки, меня интересуют тенденции.
Если нам не помогут, то мы тоже никого не пощадим.
Добавил замечание к статье, которое выкладываю ниже:
По результатам обсуждения статьи выяснилось, что некоторые читатели слишком буквально воспринимают её название, в следствии чего пытаются найти или увидеть в ней формальные определения и доказательства. Такой цели автором не ставилось. Задача статьи рассмотреть виды сложности, лучше понять её природу и неочевидные стороны. Так же хочу всех успокоить, автор вполне осознаёт, что он не открыл новый закон природы, более того, он понимает, что в строго научном смысле такого закона не существует, а выбор заголовка в большей степени обусловлен пристрастием автора к пафосным названиям.
Надеюсь это успокоит формалистов и направит обсуждение в более продуктивное русло.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
... IT>По поводу названия и некоторых терминов я уже отвечал. Если это тебе не нравится, предлагай свои. Меня это всё мало волнует. Если ты думаешь, что я думаю, что я изобрёл новый закон, то могу тебя обрадовать, я так не думаю.
Можно кстати погуглить что-нибудь вроде "сonservation of сomplexity".
VGn>>Собственно о сложности VGn>>Как описывалось ранее и другими участниками дискуссии, человеческий разум устроен таким образом, что проще воспринимается структурированная информация, а значит связывать сложность с энтропией вполне приемлемо (отсюда и термин "энтропия кода"). Отсюда и аналогии энергии и полезной работы с усилиями по разработке кода.
IT>Не понятно как твои теории объясняют то, что при упорядочивании сложность кода может увеличиваться.
Например так: алгоритмическая энтропия объекта (cложность по Колмогорову) — это длина наиболее ёмкого описания, по которому объект можно восстановить. Если при упорядочении описание увеличивается — то и сложность тоже.
Но это не имеет отношения к пониманию. Но, например, к языку программирования имеет — поскольку он является средством выражения описания объекта(в оригинале — двоичных строк). Для разных описаний сложность отличается не более чем на константу, под которой можно понимать "длину" транслятора(т.е. размер кода) с одного языка на другой.
Здравствуйте, IT, Вы писали:
IT>Если бы сложность разработки ПО можно было описать с помощью других аналогий, то её бы уже давно описали и без нас с тобой. Поверь мне на слово. Но пока этого не произошло. Не помогает здесь почему-то ни термодинамика, ни философия. Некоторые принципы и аналогии позаимствовать можно, но не более того.
Причем тут термодинамика? Уже почти сто лет существует теория информации, котороя хоть и почерпнула часть от термодинамики, но достаточно сильно от нее отличается.
В теории информации есть понятие энтропии, но нету второго начала (возрастания энтропии при любом процессе).
Вы почему-то пытаетесь придумать этот закон.
IT>Не понятно как твои теории объясняют то, что при упорядочивании сложность кода может увеличиваться. В программировании это называется overarchitecture. Штука, встечающаяся чуть ли не чаще, чем вообще полное отсутствие архитектуры. Любой инструмент, любая техника, любой принцип, любая теория в программировании может быть использована не только во благо, но не редко совсем наоборот. Происходит это в следствии того, что попытка устранения сложности в одном месте всегда, ВСЕГДА!, сопровождается добавлением сложности в другом. Статья именно об этом.
Не заметил обоснованности перехода от "может" к "всегда". Нету в теории информации постоянного возрастания энтропии.
overarchitecture — накручивание архитектуры без необходимости (без решения явных задач). Если производить упорядочивание существующего кода, то энтропия будет уменьшаться.
VGn>Очень часто при анализе сложных систем и процессов используют аналогии из термодинамики. Потому что термодинамика — одна из самых стройных наук и при VGn> этом имеет большую философскую основу. VGn>Поэтому во многих обсуждениях можно услышать "энтропия", "работа", "энергия" и т.д. VGn>Естественно, что с беспорядком борятся упорядочиванием, структуризацией, построением иерархий. VGn>В сущности абстрагирование — это в какой-то мере и есть построение иерархии. VGn>Собственно из теории. VGn>Состояния с высокой энтропией являются более равновесными состояниями, чем с низкой.
Ага. Это уже любопытно...
Но вот тут жареным запахло
Одной термодинамикой уже не отделаешся, если речь о неравновесных состояниях систем,процессов, да еще и в которых человек замешан. В этом случае все существенно усложняется.
Там где заканчиваются область компетенции термодинамики (и что от нее отпочковалось, например разделы теории информации).
Там уже начинается область, где хоть что-то пытается сделать синергетика и то что от нее отпочковалось(или припочковалось или похожее по смыслу).
Например теории организаций,многоагентных систем,интеллектуальных организаций,самоорганизующихся систем.
Неважно,теории это или нет, главное что по этим направлениям немало работ философов(или уже не философов а междисциплинарных...).
Они тоже довольно абстрактные больше философское(как и попытки применять термодинамику ко всему что состоит из многих частей). Может еще более абстрактные.
Но это все хозяство имеет корни не в термодинамике, а скорее в нелинейной динамике.
Вот с некоторой натяжкой можно сказать основная цель программистов создавать и поддерживать системы в неустойчивых состояниях.
Касается не только системы в виде программы, а и системы организации построения программ.
Чего они там философствуют можно посмотреть на подборке цитат из нескольких источников. Такие мнения не спроста возникают. Наверно это все, так или иначе знакомо, но на всякий случай закину.
Не знаю есть ли в них смысл после выдергивания из контекста, но может что-то близко теме окажется:
(перед мелкой цитатой символ "-", большие отделены чертой)
- Только сравнительно недавно стало ясно, что все новое в мире возникает в результате бифуркаций, а основной причиной самоорганизации материи на любом уровне (неживой природы, биологической, социальной) являются неустойчивые, критические состояния.
— Можно сказать также, что в неустойчивых явлениях не выполняется один из основных принципов естествознания — принцип воспроизводимости научных результатов.
— Небольшое возмущение или ошибка ведут к большим последствиям, и точное предсказание поведении таких систем на больших временных интервалах становится невозможным.
— Мозг человека функционирует вблизи критического состояния.
— Обычно среди огромного числа переменных в этой системе находится одна наиболее неустойчивая. Анализ поведения таких систем показывает, что эта неустойчивая переменная подчиняет себе все остальные переменные, которые по этой причине вообще могут быть исключены из рассмотрения. Таким образом, поведение всей самомоорганизующейся системы состоящей из огромного числа компонентов, будет определяться поведением лишь одной неустойчивой переменной, которая получила название параметра порядка.Определяющая роль наиболее неустойчивой переменной в процессах самоорганизации известна как принцип подчинения.
Параметр порядка играет роль информатора о состоянии сложной системы, поскольку благодаря появлению этой макроскопической переменной происходит гигантская компрессия информации; отпадает необходимость описывать состояние каждого элемента самоорганизующейся сложной системы.
— Было предложено простое уравнение, описывающее движения стержня. Исследование этого уравнения показывает, что действительно возможно неуправляемое человеком поддержание стержня в вертикальном положении за счет стохастического воздействия на нижний конец.
— Особое место в синергетике занимают вопросы спонтанного образования упорядоченных структур различной природы в процессах взаимодействия, когда исходные системы находятся в неустойчивых состояниях. Следуя И. Пригожину, ее можно кратко охарактеризовать как “комплекс наук о возникающих системах”.
— Зона бифуркации характеризуется принципиальной непредсказуемостью— неизвестно, станет ли дальнейшее развитие системы хаотическим или родится новая, более упорядоченная структура. Здесь резко возрастает роль неопределенности: случайность на входе в неравновесной ситуации может дать на выходе катастрофические последствия. В то же время, сама возможность спонтанного возникновения порядка из хаоса — важнейший момент процесса самоорганизации в сложной системе.
— Система, находящаяся в неравновесном состоянии, более чутка и восприимчива к воздействиям, согласованным с ее собственными свойствами. Поэтому флуктуации во внешней среде оказываются не “шумом”, а фактором генерации новых структур. Иными словами, неравновесность сложной системы может стать причиной спонтанного морфогенеза.
— Свойство самоорганизации приводит к формированию аттракторов — особых подмножеств в пространстве возможных состояний нелинейных систем, к которым притягиваются близкие траектории. Аттракторы как притягивающие множества в пространстве состояний являются асимптотически устойчивыми множествами. Аттракторы, отличные от состояний равновесия получили название “странных аттракторов”. Внутри них траектории блуждают случайным образом, будучи весьма чувствительными к изменению начальных условий.
----------------------------------------
Главные принципы синергетического подхода в современной науке таковы:
Нетрудно понять, что перечисленные принципы синергетической методологии можно разбить на три группы: принципы сложности (1 — 5), принципы неопределенности (5 — 9) и принципы эволюции (10-12).
1) Принцип неаддитивиости. Функция эффективности F(x,y)>F(x)+F(y)
(функция эффективности целого всегда больше суммы функций эффективности его частей). Хорошим примером такой величины служит негэнтропия (отрицательная энтропия) как мера упорядоченности,
поскольку по К. Шеннону условная энтропия H(x,y)<=H(x)+H(y)
Здесь равенство имеет место только для независимых элементов х и у, т. е. кооперация элементов в системе означает рост ее упорядоченности.
2) Принцип целостности.
В сложных системах свойства целого не сводятся к свойствам составляющих его частей. С одной стороны, кооперативное взаимодействие элементов в сложной системе приводит к формированию новой системы с ранее неизвестными свойствами. С другой стороны, для определения свойств частей необходимо знать свойства целого.
3) Принцип дополнительности Н. Бора.
В сложных системах возникает необходимость сочетания различных, ранее казавшихся несовместимыми, а ныне взаимодополняющих друг друга моделей и методов описания.
4) Принцип спонтанного возникновения И. Пригожина
В сложных системах возможны особые критические состояния, когда малейшие флуктуации могут внезапно привести к появлению новых структур, полностью отличающихся от обычных (в частности, это может вести к катастрофическим последствиям — эффекты снежного кома” или эпидемии).
5. Принцип несовместимости Л. Заде
При росте сложности системы уменьшается возможность ее точного описания вплоть до некоторого порога, за которым точность и релевантность информации становятся несовместимыми, взаимно исключающими характеристиками.
6. Принцип управления неопределенностями
В сложных системах требуется переход от борьбы с неопределенностями к управлению неопределенностями. Различные виды неопределенности должны преднамеренно вводиться в модель исследуемой системы, поскольку они служат фактором, благоприятствующим инновациям (системным мутациям).
7. Принцип незнания
Знания о сложных системах принципиально являются неполными, неточны- ми и противоречивыми: они обычно формируются не на основе логически строгих понятий и суждений, а исходя из индивидуальных мнений и коллективных идей. Поэтому в подобных системах важную роль играет моделирование частичного знания и незнания.
8. Принцип множественности НЕ-факторов
При разработке сложных систем требуется принимать во внимание целую гамму НЕ-факторов знаний, где наряду с обычными НЕ-факторами в смысле А.С. Нариньяни [Нариньяни, 1998], ( неопределенность, неточность, неполнота, недоопределенность,...), следует учитывать и синергетические НЕ-факторы: нелинейность, неустойчивость, неравновесность, незамкнутость...
Здесь нелинейность означает нарушение аддитивности в процессе развития системы, а неустойчивость связана с несохранением близости состояний системы в процессе ее эволюции.
9. Принцип соответствия.
Язык описания сложной системы должен соответствовать характеру располагаемой о ней информации (уровню знаний или неопределенности). Точные логико-математические, синтаксические модели не являются универсальным языком, также важны нестрогие, приближенные, семиотические модели и неформальные методы. Один и тот же объект может описываться семейством языков различной жесткости [Налимов, 1979].
10. Принцип разнообразия путей развития
Развитие сложной системы многовариантно и альтернативно, существует “спектр” путей ее эволюции. Переломный критический момент неопределенности будущего развития сложной системы связан с наличием зон бифуркации— “разветвления” возможных путей эволюции системы. Рассуждения о сложных системах могут интерпретироваться в различных “возможных мирах”, т. е. сложность предполагает объединение различных (и даже противоположных) логик. Переход от одной логики к другой отражает процесс становления системы, причем вид конкретной логики зависит от этапа эволюции системы и складывающейся ситуации.
11. Принцип единства и взаимопереходов порядка и хаоса
Эволюция сложной системы проходит через неустойчивость; хаос не только разрушителен, но и конструктивен. Организационное развитие сложных систем предполагает своего рода конъюнкцию порядка и хаоса.
12. Принцип колебательной (пульсирующей) эволюции
Процесс эволюции сложной системы носит не поступательный, а циклический или волновой характер: он сочетает в себе дивергентные (рост разнообразия) и конвергентные (свертывание разнообразия) тенденции, фазы зарождения порядка и поддержания порядка. Открытые сложные системы пульсируют: дифференциация сменяется интеграцией, разбегание — сближением, ослабление связей — их усилением и т.п.
-----------------
Гомеостатика — это наука о принципах и механизмах самосохранения, поддержания равновесия, гармонии в естественных и искусственных системах.
Тремя ведущими принципами гомеостатики являются принципы противоречия, гармонии и аналогии. В центре внимания гомеостатики находится взаимодействие противоположностей, “cклеивание” и “расщепление” антагонистов, управление внутренними противоречиями в системах, состоящих из “полярных единиц”, а также анализ возникновения патологий и катастроф в таких системах. Сам термин “гомеостазис”, введенный в научный обиход К. Бернаром и У. Кентоном, означает “остаться таким же”, т. е. гомеостатическая система остается устойчивой при внешних возмущениях.
Четырьмя ключевыми составляющими, необходимыми для существования гомеостатической системы являются:
а) внутренние противоречия;
б) иерархическая организация; в) соподчинение гомеостатов;
г) реализация в управлении принципа регулируемого противоречия (символ китайской монады) [Горский, 1998; Курейчик В. М. и Курейчик В. В. 2000].
-------------
Самоорганизующимися называются системы, которые формируются спонтанно, в результате преимущественно локальных взаимодействий между элементами. Как правило, в их основе лежит согласованное поведение большого числа взаимодействующих агентов. Подобные системы возникают при определенных граничных условиях как следствие особых состояний агентов (в синергетике такие состояния именуются притягивающими — “аттракторами”) [Хакен, 1991].
На микроуровне при самоорганизации происходит процесс распространения или усиления флуктуаций вследствие увеличения асимметрии, неравновесности системы под воздействием среды. Этот процесс остается незаметным на макроуровне до тех пор, пока изменения не достигнут некоторого критического значения, после чего спонтанно возникает новый порядок или структура.
В автономных системах преобладают положительные обратные связи, круговые процессы, рекурсивные отношения. Принято различать: а) пассивную автономию, обеспечиваемую, на- пример, с помощью мембраны (защитного экрана); б) реактивную автономию (обратные связи); в) активную автономию, предполагающую проведение целенаправленных воздействий на среду. Входные воздействия не столько определяют поведение автономного агента, сколько являются лишь “пусковыми факторами”, инициализирующими различные стратегии поведения.
--------
Понятие самоорганизации автономного агента неотделимо от таких его свойств как самовоспроизведение, самосохранение, саморегуляция (самоуправление).
Как уже отмечалось, базовым механизмом самосохранения является гомеостазис, т. е. способность агента постоянно определять и поддерживать в требуемых интервалах ряд критических параметров состояния, определяющих его гомеостатическую границу.Само существование такой организации предполагает функционирование обратных связей, сохраняющих гомеостазис.
--------
Исследование вопросов экоорганизации связано в первую очередь с открытыми системами, находящимися вдали от состояния равновесия. При этом хаос, беспорядок рассматриваются не как аномалии, которые надо преодолеть любым путем, а как одно из условий, обеспечивающих инновации — важнейшую предпосылку выживания современных организаций.
--------------------
... У него система есть не просто заданное множество элементов с фиксированными отношениями, а еще и процесс (или поток процессов) производства составляющих, связанных циклами развития и деградации. Эта сеть процессов производства составляющих и понимается под организацией системы, тогда как структура есть особый пространственно-временной образ (паттерн) произведенных составляющих. Иными словами, система рассматривается не как нечто застывшее, а как процесс постоянных преобразований, связанных с непрерывной сменой состояний равновесия.
В основе тектологии лежат понятия формирования и регулирования динамических комплексов (систем). Вводятся три типа комплексов: организованные, дезорганизованные, нейтральные, причем утверждается, что эта таксономия зависит от наблюдателя и контекста. По сути дела, А. А. Богдановым сформулирован принцип относительности в теории систем.
Для описания закономерностей функционирования и развития систем А. А. Богданов ввел понятия динамического равновесия, прогрессивного и консервативного отбора, регулятора и бирегулятора. Прогрессивный отбор, лежащий в основе возникновения, роста и развития системы, включает в себя механизмы положительного и отрицательного отбора. В случае положительного отбора в системе увеличивается неоднородность компонентов и число внутренних связей и, таким образом, повышается ее сложность и степень автономии частей. В результате, положительный отбор обычно повышает эффективность системы, но увеличивает ее неустойчивость. Поэтому необходимы меры, которые ослабляют действие этих факторов, и охватываются термином “отрицательный отбор”. При отрицательном отборе повышается порядок и однородность, возрастают уровень централизации и координации отдельных действий. Отрицательный отбор повышает структурную целостность и устойчивость системы, но одновременно снижает ее функциональную эффективность. Направленность отбора, от которой зависит формирующаяся структура системы, относительна стабильна в неизменной среде; наоборот, в быстро изменяющейся среде отбор идет то в одном, то в другом направлении.
...
Он также утверждал, что чем сложнее организация, тем больше шансов у нее столкнуться в процессе развития с кризисной ситуацией, необходимостью структурной перестройки.
--------------------------
— В русле МАС(много-агентные системы) речь идет о кооперативном взаимодействии множества агентов, которое макроскопически проявляется как самоорганизация. Такие МАС могут путем самоорганизации образовывать новые пространственные, временные или функциональные структуры...
-Во-первых, взаимодействия между агентами имеют определенную направленность — положительную или отрицательную, т. е. носят характер содействия или противодействия, притяжения или отталкивания, кооперации или конкуренции, сотрудничества или конфликта, координации или субординации, ...
— В общем случае понятие кооперации можно определить формулой: кооперация = сотрудничество + координация действий + разрешение конфликтов
Более подробно, об уровне кооперации агентов в МАС можно судить на основе следующих показателей [Durfee et al., 1987]:
1) степень распределения обязанностей, ответственности и ресурсов (в том числе, знаний);
2) уровень координации действий, включая согласование направления действий агентов в пространстве и во времени;
3) степень запараллеливания (совмещения) задач, решаемых различными агентами;
4) неизбыточность действий, довольно малое число дублирующих, повторяющих друг друга действий;
5) избегание (или малая длительность) конфликтов;
6) живучесть, понимаемая как способность МАС пережить отказ или потерю агента.
-------------
Классическими методами исследования кооперации и переговорных процессов являются методы теории полезности и теории игр, в частности, известные модели и условия оптимальности, выраженные в виде принципов равновесия.
Равновесие по Парето — это ситуация равновесия, при которой улучшение положения одного агента невозможно без ухудшения состояния другого.
Основой оптимальности по Нэшу является устойчивость МАС, обусловленная интересами и возможностями отдельных агентов, тогда как принцип оптимальности по Парето опирается на идею полезности, выгоды для МАС в целом, понимаемой как выгода сразу для всех ее агентов.
------------------------
К числу основных критериев, определяющих тип организации МАС, относятся:
— вид внешней среды, в которую погружена организация (статическая или динамическая, закрытая или открытая и т. п.);
— характер связей между агентами в организации (постоянные или переменные, вертикальные или горизонтальные);
— способ возникновения (заранее заданная, спроектированная организация или спонтанно возникающая в результате взаимодействий между агентами);
— характер распределения функций, ролей, и ответственности, определяющий гибкость связей (жесткие или гибкие, постоянные или переменные);
— вид и геометрия организационных единиц (элементарное функциональное подразделение, описываемое простой иерархией древовидного типа, или автономная междисциплинарная рабочая группа, представляющая собой сложную неоднородную сеть с преобладанием горизонтальных связей, например кольцевую структуру);
— тип управления (субординация или координация);
— структура принятия решений (моноцентризм или полицентризм);
— владение ресурсами или характер ресурсного обеспечения (централизованное или децентрализованное);
— морфология организации (монолитная, сосредоточенная или распределенная, сетевая организация);
— характер коммуникации агентов (непосредственная или опосредованная, ближняя или дистанционная);
— стратегии развития организации (жесткое планирование или самореорганизация);
— стратегии адаптации к среде (телогенез или арогенез).
-----------------------------
— Доминирование вертикальных связей порождает реактивные стратегии организационного поведения, описываемые схемой “стимул — реакция”. Приоритет горизонтальных связей претворяет в жизнь активные стратегии организационного поведения, ориентированные на потребности завтрашнего дня, на развитие организации.
— Разумная степень децентрализации управления обеспечивает большую живучесть МАС. Однако чрезмерная децентрализация приводит к трудностям координации поведения агентов, увеличению времени адаптации, а порой, просто лишает МАС возможности фокусировать усилия агентов на достижение общих целей.
— Позднее, в развитие этих идей М. Крозье сформулировал принцип относительной рациональности: “любые стратегии рациональны лишь по отношению к контексту, внутри которого они существуют” [Crozier and Serieyx, 1994].
--------------------------------
Процессы эволюции и реорганизации МАС могут быть связаны с ответами на следующие вопросы.
— Есть ли изменения среды, в которой функционирует МАС? Носят ли они регулярный, направленный характер или скорее случайны?
— Можно ли спрогнозировать будущее состояние среды и как скоро оно наступит?
— В какой степени могут быть скомпенсированы нежелательные изменения среды активными действиями МАС?
— Как и в какой степени следует изменить функции, процессы, структуру и деятельность МАС? Каковы ее новые организационные структуры, которые будут достаточно эффективны при новом состоянии среды?
— Какие агенты (и организационные уровни) в МАС в наибольшей степени будут затронуты ее структурной перестройкой? Какие организационные единицы имеют наибольший запас адаптивных резервов?
— Какие ресурсы необходимы для перестройки различных уровней системы? Основными видами изменений функций агентов в ходе эволюции МАС являются:
а) интенсификация функций — основной тип филогенетического изменения;
б) ослабление функций;
в) мобилизация функций;
г) иммобилизация функций;
д) расширение функций;
е) перераспределение функций;
ж) уменьшение числа функций (с усилением главной функции подавляются другие, второстепенные);
з) смена функций;
и) замещение функции одного агента аналогичной функцией другого агента;
к) компенсация функций различных агентов и неравномерности их адаптации к среде.
- Наконец, наиболее распространенное в сообществе специалистов по ИИ мнение связывает интеллект со способностью строить модели реальности, а интеллектуальность системы — с наличием у нее собственной внутренней модели внешнего мира. Более того, эта модель должна быть корректируемой и характеризоваться вы- сокой адаптивностью [Арбиб, 1976]. С уровнем развития внутренней модели тесно связаны возможности планирования поведения; а также формирования умений.
-В семиотической системе состояния соответствуют фиксированным формальным системам, а смена состояний заключается в изменении различных параметров формальной системы: аксиом, правил вывода, ограничений, стратегий поиска решений, ценностных ориентаций и т. п.
-Формализуя строгие, корректные выводы, классическая логика не принимает во внимание многие важные аспекты человеческих — рассуждений (здравый смысл, немонотонность, противоречивость, неточность, нечеткость). Когда человек имеет дело с неполной, неточной, противоречивой, неопределенной или нечеткой информацией, его рассуждения становятся не достоверными, а всего лишь правдоподобными, предположительными и должны подвергаться проверке и пересмотру (ревизии). Для представления такой информации, ее анализа и обоснования выводов разработаны нетрадиционные, “нестандартные” логики, являющиеся расширением классических логик. Эти расширения касаются языка логики и понятия вывода.
В стандартных логических системах, если из посылок выведено некоторое заключение, а затем к посылкам добавлена новая информация, то исходное заключение не меняется. В немонотонных логиках это уже не так. Если к старым посылкам добавить новое знание, то чаще всего получитс и новое заключение. Построение немонотонной системы вывода делает необходимым ослабление свойств дедуктивных систем классической логики.
— Модальные логики, в которых для описания агентов наряду с обычными высказываниями (предикатами) допускаются модальности типа “возможно” и “необходимо” (алетическая логика), “известно” и “неизвестно” (эпистемическая логика), “верит (убежден) и не верит” (доксастическая логика), “желает” и “не желает” (оптитативная логика) “обязательно” и “разрешено” (деонтическая логика), “всегда” и “иногда” (временная логика) и т.д., представляют собой расширения классической логики.
— Никакое сколько-нибудь сложное явление, а тем более, интеллектуальное поведение нельзя описать средствами одного-единственного языка. Как правило, для этого требуется набор языков различной жесткости (см. [Налимов, 1979; Моисеев, 1995]), сочетание различных логик анализа, множество интерпретаций интеллектуальной системы. Таким образом обеспечивается “голографическая картина” системы, связанная с использованием различных точек зрения.
— Принцип приоритета процессов координации над субординацией, т. е. это — принцип преимущественного учета горизонтальных связей в интеллектуальных процессах. Иными словами, предполагается невозможность решения сложных задач отдельными агентами, опирающимися на локальные модели (и в то же время, невозможность построения ими в одиночку полных или глобальных моделей внешнего мира). Следствием этого является преобладание кооперативных и коалиционных стратегий над чисто конкурентными и индивидуалистическими в интеллектуальном поведении.
-Примерами сложных интеллектуальных систем служат: гибридные интеллектуальные системы, системы мягких вычислений, системы с кооперативным поведением, интеллектуальные агенты, распределенные системы управления, многоагентные системы, виртуальные коллективы, интеллектуальные организации, эволюционирующие искусственные сообщества.
— Минский связывает интеллектуальность системы со степенью непонимания наблюдателем того, как она решает задачи.
Резкие скачкообразные переходы, свойственные параметру порядка в процессах самоорганизации, имеют место и в творческом процессе. Именно с таким скачком в творческом, продуктивном мышлении соотносят в психологии творчества озарение, скачок мысли, инсайт, в результате которого рождаются качественно новые идеи. Для шаблонного, репродуктивного мышления свойственно стремление свести задачу к уже известным случаям, воспользоваться уже готовыми способами.
Бифуркации, ведущие к дивергенции. С нелинейными свойствами моделей развития связан еще один вид поведения в критических точках — ветвление решений, когда в точке бифуркации нарушается единственность решения.
В биологии развития в таких случаях говорят о дивергентности, которая ведет к увеличению разнообразия видов. Это свойство является
важным фактором адаптации живых организмов к изменяющимся условиям внешней среды.
В психологин мышления и творчества есть понятие дивергентности мышления, означающее свойство мышления расходиться в разных направлениях. Американский психолог Гилфорд считает это свойство наиболее важным в творческой деятельности. В самом деле, творчество означает создание качественно нового, а в результате ветвления решений дифференциальных уравнений как раз появляются качественно новые свойства в поведении соответствующих систем.
Отбор и конвергенция После прохождения стадии дивергенции в развивающихся системах наступает процесс отбора, в ходе которого уменьшается разнообразие ранее возникших форм, растет упорядоченность в системах, уменьшается стохастичность. В настоящее время построено достаточно много математических моделей, описывающих конвергенцию в живой природе.
В научном творчестве тоже рано или поздно наступает этап, когда необходимо вписать предложенные модели и идеи в существующую систему знаний, отобрать окончательный, наиболее правильный вариант. Предложены даже математические модели конкуренции различных теорий в науке, похожие на модели конкуренции видов в биологических системах.
Конвергенция имеет место и в художественном творчестве. В процессе работы над художественным произведением автор пробует различные варианты и в конце концов оставляет один — с его точки зрения, наиболее удачный.
-------------
Основным универсальным количественным законом в лингвистике, справедливым для всех естественных языков, является степенной закон распределения слов. Впервые этот закон был открыт в 1949 году лингвистом Гарвардского университета Г. Ципфом (George Kingsley Zipf) За прошедшее время было предложено несколько моделей, объясняющие возникновение закона Ципфа, однако ни одну из них нельзя признать удовлетворительной.
Лишь совсем недавно Р. Феррери Канчо (Ramon Ferreri i Cancho) и Р.Соле (Ricard Sole) предложили модель возникновения языка как критического явления, и закон Ципфа стал естественным свойством этой модели.
Это согласуется с тем, что любое принципиально новое явление в биологической эволюции связано с феноменологией критических явлений.Модель основана на естественном предположении, что говорящий стремится к краткости и лаконизму, чтобы минимизировать свои усилия В предельном случае говорящему хотелось бы передать сообщение одним словом.
Слушающий, напротив, чтобы легче было понять сказанное, хотел бы, чтобы сообщение было максимально развернутым. Реальное сообщение всегда есть компромисс между требованиями говорящего и слушающего.
В модели Канчо Феррери и Соле язык возникает скачком, а не постепенно. То есть не существует промежуточного состояния между богатством человеческого языка и ограниченными сигнальными возможностями некоторых животных. Когда этот скачок произошел, частота использования различных слов во всех языках, как оказалось, подчиняется одному и тому же закону — степенному закону Ципфа.
-----------------
Идеи и положения регулятивного подхода находят свое применение в контексте агентификации искусственных систем, когда се большую роль начинает играть моделирование мотивов, убеждений, намерений, желаний, интуиции и ряда других компонентов психики, относящихся к потребностно-мотивационной и аффективно-чувственным сферам. Методология структурно-уровневого подхода, а также работы по функциональной организации когнитивных процессов представляют большой интерес в контексте синтеза архитектур интеллектуальных агентов. Элементы “триархической теории”, основанные на метафоре “управления государством”, предполагают выделение соответствующих функций (законодательная, исполнительная, оценочная), уровней (глобальный и локальный), форм (монархическая, анархическая, иерархическая, олигархическая), сфер (внутренняя, внешняя), ориентаций (консервативная, прогрессивная) интеллекта. Данный подход напрямую соотносится с такой актуальной проблематикой информатики и ИИ как проектирование многоагентных систем и разработка интеллектуальных организаций.
----------------
Школа гештальт-психологии, наиболее яркими представителями которой являются М. Вертгеймер, К. Бункер, В. Келер, К. Коффка, впервые ушла от выдвинутого интроспекционизмом и структурализмом принципа расчленения психики на элементы и складывания каких-то более сложных процессов и закономерностей, исходя из простых элементов. Она выдвинула принципиально новое положение о том, что первичным моментом психических процессов являются не отдельные элементы, а целостные структуры.
Главной заслугой этой школы стала разработка теории единых, неделимых психологических структур — гештальтов (см. [Вертгеймер, 1987]). Фактически в рамках гештальт-теории было возрождено античное представление о том, что целое определяет свойства частей и может быть больше суммы образующих его частей.
Ее сторонниками, пожалуй, впервые в психологии была обоснована идея о неаддитивности психики. В центре гештальтистских объяснений оказалось “псевдофизическое” представление о динамическом поле, где каждая точка взаимодействует с другими. Изменение напряжения в одной из точек порождает стремление к устранению этого напряжения и восстановления равновесия. Кроме того, было введено понятие об инсайте — внезапном озарении, мгновенном (одновременном) схватывании всех существенных отношений в ментальном пространстве. Это понятие стало основным при объяснении адаптивных форм поведения и эвристических процессов в противовес принципу полного перебора или методу проб и ошибок, восходящему к идеям бихевиоризма.
-----------------------
Как возникает интеллект в онтогенезе? Благодаря действиям. “Посредником” между ребенком и окружающим миром являются действия. И слова, и образы сами по себе мало что значат для развития интеллекта. Нужны именно действия.
-----------------------
Согласно Ж. Пиаже, для формализации теории интеллекта следует построить психологику, которая призвана ликвидировать разрыв между относительной расплывчатостью психологических теорий и дедуктивной строгостью формальных (логических) систем. Одним из главных заключений его операциональной теории является то, что алгебра логики может помочь выявить психологические структуры и представить в форме исчисления основные операции и структуры, характерные для интеллектуальных процессов. При этом психологика должна относиться к психологии интеллекта точно так же, как математическая физика относится к экспериментальной.
------------
В психологии принято выделять: вербальное и образное, репродуктивное и продуктивное, теоретическое и практическое, логическое и интуитивное мышление [Брушлинский, 1979; Тихомиров, 1984]. В частности, интуитивное мышление характеризуется быстротой протекания мыслительных процессов, отсутствием четко выраженных этапов, минимальной осознанностью. В то же время, логическое мышление, будучи развернутым во времени, имеет четко выраженные фазы и в значительной мере осознается субъектом.
----------
С другой стороны, одной из фундаментальных особенностей естественного интеллекта является широкое использование суждений и рассуждений на шкалах — сходства, предпочтения, полезности, уверенности, временных, пространственных и т. п.
В мышлении человека порядок создается из хаоса путем формирования системы оппозиционных (полярных) шкал и различения некоторых объектов с помощью оценок на этих шкалах.
-----------
По своему происхождению и функциям знания разделяются на две группы.
а) знания 1-го рода (ЧТО-знания или “холодные” знания)- общетеоретические утверждения, принципы, закономерности, зафиксированные в книгах, справочниках, инструкциях и пр., которые субъект получает извне;
б) знания 2-го рода (КАК-знания или “горячие” знания) — правила, процедуры, эвристики, формируемые в собственной практической деятельности субъекта и хранящиеся в его памяти.
----------
Для навыка характерна стереотипность: он не нуждается в помощи мышления, а функционирует за счет выработанных условных связей. Важная роль навыков состоит в том, что они разгружают психику от регулирования простых элементарных операций.
---------
Непонимание (диалог с использованием не полностью идентичных языков) является не менее ценным смысловым компонентом, что и понимание [Лотман, 2000]. При этом извне получается лишь малая доля информации, которая играет роль стимула для генерации новых идей.
....
И в-третьих, развертывание процесса коммуникации во времени предполагает формирование особых точек пересечения смысловых пространств, в которых происходит “смысловой взрыв” — резкое возрастание информативности всей системы коммуникации [Лотман, 2000]. Идея “смыслового взрыва” открыла путь синергетическим представлениям в семиотике.
Здравствуйте, gandjustas, Вы писали:
IT>>Если бы сложность разработки ПО можно было описать с помощью других аналогий, то её бы уже давно описали и без нас с тобой. Поверь мне на слово. Но пока этого не произошло. Не помогает здесь почему-то ни термодинамика, ни философия. Некоторые принципы и аналогии позаимствовать можно, но не более того. G>Причем тут термодинамика? Уже почти сто лет существует теория информации, котороя хоть и почерпнула часть от термодинамики, но достаточно сильно от нее отличается.
Вот и мне не понятно при чём тут термодинамика? Впрочем, это вопрос не ко мне, а к VGn.
G>В теории информации есть понятие энтропии, но нету второго начала (возрастания энтропии при любом процессе). G>Вы почему-то пытаетесь придумать этот закон.
Какой именно закон я пытаюсь придумать? У меня как раз складывается впечатление, что здесь все кроме меня пытаются что-то придумать и сразу же это придуманное опровергнуть.
IT>>Не понятно как твои теории объясняют то, что при упорядочивании сложность кода может увеличиваться. В программировании это называется overarchitecture. Штука, встечающаяся чуть ли не чаще, чем вообще полное отсутствие архитектуры. Любой инструмент, любая техника, любой принцип, любая теория в программировании может быть использована не только во благо, но не редко совсем наоборот. Происходит это в следствии того, что попытка устранения сложности в одном месте всегда, ВСЕГДА!, сопровождается добавлением сложности в другом. Статья именно об этом. G>Не заметил обоснованности перехода от "может" к "всегда". Нету в теории информации постоянного возрастания энтропии.
Ну нету и нету. При чём тут вообще теория информации?
G>overarchitecture — накручивание архитектуры без необходимости (без решения явных задач). Если производить упорядочивание существующего кода, то энтропия будет уменьшаться.
Ладно, я задам этот вопрос тебе тоже. SRP упорядочивает код или не упорядочивает?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
G>>В теории информации есть понятие энтропии, но нету второго начала (возрастания энтропии при любом процессе). G>>Вы почему-то пытаетесь придумать этот закон.
IT>Какой именно закон я пытаюсь придумать?
Закон возрастания энтропии.
G>>overarchitecture — накручивание архитектуры без необходимости (без решения явных задач). Если производить упорядочивание существующего кода, то энтропия будет уменьшаться. IT>Ладно, я задам этот вопрос тебе тоже. SRP упорядочивает код или не упорядочивает?
Упорядочивает.
Здравствуйте, gandjustas, Вы писали:
IT>>Какой именно закон я пытаюсь придумать? G>Закон возрастания энтропии.
Слава богу не сохранения
G>>>overarchitecture — накручивание архитектуры без необходимости (без решения явных задач). Если производить упорядочивание существующего кода, то энтропия будет уменьшаться. IT>>Ладно, я задам этот вопрос тебе тоже. SRP упорядочивает код или не упорядочивает? G>Упорядочивает.
Тогда почему при определённых сценариях упорядочивание кода и, соответственно, уменшение энтропии приводит к повышению сложности?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
G>>>>overarchitecture — накручивание архитектуры без необходимости (без решения явных задач). Если производить упорядочивание существующего кода, то энтропия будет уменьшаться. IT>>>Ладно, я задам этот вопрос тебе тоже. SRP упорядочивает код или не упорядочивает? G>>Упорядочивает.
IT>Тогда почему при определённых сценариях упорядочивание кода и, соответственно, уменшение энтропии приводит к повышению сложности?
Какой сложности?
SRP позволяет уменьшать сложность изменения ценой небольшого увеличения сложности чтения и объема кода. Только сложность чтения и объем кода видно сразу, а сложность изменения не будет проявляться пока не потребуются изменения. Поэтому вполне может казаться что применение SRP повышает сложность, хотя совокупная сложность уменьшается.
В конкретном случае может быть что сложность изменения вообще не интересет, а интересует исключительно объем кода.
Здравствуйте, gandjustas, Вы писали:
IT>>Тогда почему при определённых сценариях упорядочивание кода и, соответственно, уменшение энтропии приводит к повышению сложности?
G>Какой сложности?
Увеличивается сложность восприятия кода, растёт объём, в определённой степени проседает гибкость. Это подробно разобрано в статье.
G>В конкретном случае может быть что сложность изменения вообще не интересет, а интересует исключительно объем кода.
Главное, что упорядочивание кода может привести к усложнению. Отсюда следует один простой вывод по поводу следующего умозаключения:
VGn>Я например уверен, что при упорядочивании общая энтропия кода уменьшается, а значит закон сохранения сложности — полная чушь.
Вот такие разговоры и есть на самом деле полная чушь. Упорядочивание может усложнять код, что полностью соответствует закону сохранения сложности И понятно почему. Упорядочивание — это всего лишь один из инструментов борьбы со сложностью. Не мера сложности, не замена, не подмена, а инструмент, который в точности подчиняется закону как и любой другой инструмент.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
IT>>>Тогда почему при определённых сценариях упорядочивание кода и, соответственно, уменшение энтропии приводит к повышению сложности?
G>>Какой сложности?
IT>Увеличивается сложность восприятия кода, растёт объём, в определённой степени проседает гибкость. Это подробно разобрано в статье.
От применения SRP гибкость не проседает. Или это не SRP.
Немного растет объем и немного увеличивается слжность чтения, но сильно уменьшается сложность изменения. Крмое того выделенные классы могут более удачно повторно использоваться, что приведет еще и к сокращению объема кода.
Совокупная сложность падает.
G>>В конкретном случае может быть что сложность изменения вообще не интересет, а интересует исключительно объем кода. IT>Главное, что упорядочивание кода может привести к усложнению.
Не может, см выше. Только в случае неправильного наведения порядка.
IT>Отсюда следует один простой вывод по поводу следующего умозаключения: IT>
VGn>>Я например уверен, что при упорядочивании общая энтропия кода уменьшается, а значит закон сохранения сложности — полная чушь.
IT>Вот такие разговоры и есть на самом деле полная чушь.
IT>Упорядочивание может усложнять код, что полностью соответствует закону сохранения сложности И понятно почему.
Не понятно и не соотвествует. "Может" не означает что будет усложнять всегда.
Хотелось более формальный критерий получить когда упорядочивание, примененное правильно, будет усложнять код.
Здравствуйте, gandjustas, Вы писали:
IT>>Увеличивается сложность восприятия кода, растёт объём, в определённой степени проседает гибкость. Это подробно разобрано в статье. G>От применения SRP гибкость не проседает. Или это не SRP.
Вариант после применения SRP предлагаю додумать самому. Не забудь только про временную структуру данных и разнесение по методам или классам алгоритмов парсинга xml и генерации txt.
В данном случае это одна понятная и простая строчка кода. Для варианта с SRP, который, даже не надеюсь, ты нам здесь представишь, это будет не одна и боюсь даже не две строчки. Увеличение сложности модификации в полный рост.
G>Немного растет объем и немного увеличивается слжность чтения, но сильно уменьшается сложность изменения. Крмое того выделенные классы могут более удачно повторно использоваться, что приведет еще и к сокращению объема кода.
Немного растёт, классы могут. Главное, что сложность модификации растёт, т.е. гибкость кода страдает.
G>Совокупная сложность падает.
Правильно. Но не всегда. В одном случае падает, в другом увеличивается. Падает тоже не просто так. Увеличивается всегда, но при правильном применении падает больше, но увеличивается всегда. Ещё не понятно? Тогда ещё раз. Применение (абсолютно) любого инструмента ведёт к усложнению кода и совокупный эффект является большим вопросом.
G>>>В конкретном случае может быть что сложность изменения вообще не интересет, а интересует исключительно объем кода. IT>>Главное, что упорядочивание кода может привести к усложнению. G>Не может, см выше. Только в случае неправильного наведения порядка.
'Только в случае' для меня достаточно. Дело в том, что случаи бывают разные и главная проблема в том, что не все из них очевидны. Чем выше сложность системы, тем менее очевидны такие случаи. SRP в этом смысле как раз очень показательный принцип. Когда нужно остановиться, где та грань, после которой применение паттерна или принципа даёт обратный эффект? У тебя есть точная метрика?
IT>>Упорядочивание может усложнять код, что полностью соответствует закону сохранения сложности И понятно почему. G>Не понятно и не соотвествует. "Может" не означает что будет усложнять всегда.
Всегда и не нужно. Лично мне достаточно того, что я понимаю одну простую вещь — любой (абсолютно) инструмент может быть использован как во благо, так и совсем наоборот. На практике это означает критическое отношение к любому (абсолютно) паттерну или принципу. Даже к полюбившимся в этой ветке упорядочиванию и абстрагированию, т.к. упорядочивание и абстрагирование всегда в 100% случаях автоматически ведёт к усложнению, а вот для достижения упрощения ещё нужно попотеть.
G>Хотелось более формальный критерий получить когда упорядочивание, примененное правильно, будет усложнять код.
За формальностями к VGn.
Если нам не помогут, то мы тоже никого не пощадим.
Сложность восприятия зависит от множества факторов. Оформление кода, следование соглашениям об именованиях, запутанность/ясность алгоритма, выразительность используемых средств, поддержка среды разработки, включая подсветку кода и навигацию, и многое другое.
Во что трансформируется сложность восприятия, если "корявый" код был "причесан" -- произведено переоформление кода, переименование переменных/классов/методов, и вместо notepad-а разработчик стал использовать IDEA?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
IT>>>Увеличивается сложность восприятия кода, растёт объём, в определённой степени проседает гибкость. Это подробно разобрано в статье. G>>От применения SRP гибкость не проседает. Или это не SRP.
IT>Да ну?
IT>Было:
IT>
IT>Вариант после применения SRP предлагаю додумать самому. Не забудь только про временную структуру данных и разнесение по методам или классам алгоритмов парсинга xml и генерации txt.
А где здесь отвественности, которые стоило бы разделить?
Применять здесь SRP абсолютно незачем.
G>>Немного растет объем и немного увеличивается слжность чтения, но сильно уменьшается сложность изменения. Крмое того выделенные классы могут более удачно повторно использоваться, что приведет еще и к сокращению объема кода. IT>Немного растёт, классы могут. Главное, что сложность модификации растёт, т.е. гибкость кода страдает.
С чего ты взял что сложность модификации растет?
Правильное прмиенение SRP уменьшает связность между различным функционалом, что позволяет вносить изменения в одном месте не беспокоясь что что-то сломается в другом.
G>>Совокупная сложность падает. IT>Правильно. Но не всегда. В одном случае падает, в другом увеличивается. Падает тоже не просто так. Увеличивается всегда, но при правильном применении падает больше, но увеличивается всегда.
Видиимо увеличивается только в случае неправильного применения SRP.
IT>Ещё не понятно? Тогда ещё раз. Применение (абсолютно) любого инструмента ведёт к усложнению кода и совокупный эффект является большим вопросом.
Это пока еще не удалось доказать. даже с примерами такого туговато.
G>>>>В конкретном случае может быть что сложность изменения вообще не интересет, а интересует исключительно объем кода. IT>>>Главное, что упорядочивание кода может привести к усложнению. G>>Не может, см выше. Только в случае неправильного наведения порядка.
IT>'Только в случае' для меня достаточно. Дело в том, что случаи бывают разные и главная проблема в том, что не все из них очевидны. Чем выше сложность системы, тем менее очевидны такие случаи. SRP в этом смысле как раз очень показательный принцип. Когда нужно остановиться, где та грань, после которой применение паттерна или принципа даёт обратный эффект? У тебя есть точная метрика?
Есть, прямо из определения SRP — когда один компонент отвечает за один аспект функционала.
IT>>>Упорядочивание может усложнять код, что полностью соответствует закону сохранения сложности И понятно почему. G>>Не понятно и не соотвествует. "Может" не означает что будет усложнять всегда.
IT>Всегда и не нужно. Лично мне достаточно того, что я понимаю одну простую вещь — любой (абсолютно) инструмент может быть использован как во благо, так и совсем наоборот. На практике это означает критическое отношение к любому (абсолютно) паттерну или принципу. Даже к полюбившимся в этой ветке упорядочиванию и абстрагированию, т.к. упорядочивание и абстрагирование всегда в 100% случаях автоматически ведёт к усложнению, а вот для достижения упрощения ещё нужно попотеть.
Применение паттерна или принципа только ради его применения ведет к усложнению. Если головой понимаешь зачем применять, то получишь упрощение.
Здравствуйте, eao197, Вы писали:
E>Во что трансформируется сложность восприятия, если "корявый" код был "причесан" -- произведено переоформление кода, переименование переменных/классов/методов, и вместо notepad-а разработчик стал использовать IDEA?
Статья скорее от том что будет дальше, после того как уже сделано, то что ты описал.
Не до бесконечности же это будет продолжаться ... wikipedia Парето
Вернее как-то так. Уменьшать общую сложность программы(с целью получения выгоды) можно до определенного предела, а дальше возможны улучшения только путем компромисов. В какую сторону все сместится при поиске компромиса зависит от разных обстоятельств, которые могут меняться.
Этот предел скорее всего не абсолютный, а соответствует нынешним реалиям. Может в далеком будущем появятся технологии, снижающие общую сложность создания программ, из-за выноса сложностей в другое место.
Сложность кода не может быть ниже сложности обьекта, который код моделирует (не всего обьекта понятно, а только программируемого аспекта). Вот обьективная предпосылка "Закона сохранения минимальной сложности".
Здравствуйте, IO, Вы писали:
IO>Сложность кода не может быть ниже сложности обьекта, который код моделирует (не всего обьекта понятно, а только программируемого аспекта). Вот обьективная предпосылка "Закона сохранения минимальной сложности".
IO>Сложность кода не может быть ниже сложности обьекта, который код моделирует (не всего обьекта понятно, а только программируемого аспекта). Вот обьективная предпосылка "Закона сохранения минимальной сложности".
Это вообще говоря неверно. напрмиер сделать учетную систему в 1C гораздо проще, чем написать её на ассемблере (вместе с БД).
Сложность задачи и сложность кода, решающего задачу вещи вообще говоря ортогональные.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, IT, Вы писали:
IT>>Если бы сложность разработки ПО можно было описать с помощью других аналогий, то её бы уже давно описали и без нас с тобой. Поверь мне на слово. Но пока этого не произошло. Не помогает здесь почему-то ни термодинамика, ни философия. Некоторые принципы и аналогии позаимствовать можно, но не более того. G>Причем тут термодинамика? Уже почти сто лет существует теория информации, котороя хоть и почерпнула часть от термодинамики, но достаточно сильно от нее отличается. G>В теории информации есть понятие энтропии, но нету второго начала (возрастания энтропии при любом процессе). G>Вы почему-то пытаетесь придумать этот закон.
В термодинамике закон возрастания энтропии сформулирован для замкнутых систем
IT>Всегда и не нужно. Лично мне достаточно того, что я понимаю одну простую вещь — любой (абсолютно) инструмент может быть использован как во благо, так и совсем наоборот. На практике это означает критическое отношение к любому (абсолютно) паттерну или принципу. Даже к полюбившимся в этой ветке упорядочиванию и абстрагированию, т.к. упорядочивание и абстрагирование всегда в 100% случаях автоматически ведёт к усложнению, а вот для достижения упрощения ещё нужно попотеть.
Аналогия суждения: "использование автомобиля всегда ведёт к дополнительным затратам, потому что в соседний ларёк ездить за пивом на авто не эффективно"
IO>Сложность кода не может быть ниже сложности обьекта, который код моделирует (не всего обьекта понятно, а только программируемого аспекта). Вот обьективная предпосылка "Закона сохранения минимальной сложности".
Моделирование всегда снижает сложность. Иначе это не моделирование.
Здравствуйте, VGn, Вы писали:
IO>>Сложность кода не может быть ниже сложности обьекта, который код моделирует (не всего обьекта понятно, а только программируемого аспекта). Вот обьективная предпосылка "Закона сохранения минимальной сложности".
VGn>Моделирование всегда снижает сложность. Иначе это не моделирование.
Моделирование снижает сложность обьекта путем выделение некоторого аспекта. Речь же идет о минимальной сложности кода, необходимой для реализации модели.
Здравствуйте, gandjustas, Вы писали:
IO>>Сложность кода не может быть ниже сложности обьекта, который код моделирует (не всего обьекта понятно, а только программируемого аспекта). Вот обьективная предпосылка "Закона сохранения минимальной сложности".
G>Это вообще говоря неверно. напрмиер сделать учетную систему в 1C гораздо проще, чем написать её на ассемблере (вместе с БД).
В данном случае бОльшая часть программируемого аспекта обьекта уже реализована в библиотеках 1С в отличие от ассемблера, но общая сложность решения не уменьшилась.
G>Сложность задачи и сложность кода, решающего задачу вещи вообще говоря ортогональные.
Речь не о сложности задачи, а о сложности решения.
IO>Моделирование снижает сложность обьекта путем выделение некоторого аспекта. Речь же идет о минимальной сложности кода, необходимой для реализации модели.
Если бы автоматизация была дороже ручного процесса, её бы никто не производил.
Так что сложность кода реализующего модель никак не может быть сложнее объекта (в деньгах).
Здравствуйте, eao197, Вы писали:
E>Во что трансформируется сложность восприятия, если "корявый" код был "причесан" -- произведено переоформление кода, переименование переменных/классов/методов, и вместо notepad-а разработчик стал использовать IDEA?
В уровень подготовки программиста и сложность используемых инструментов.
Вообще, переписывание, причёсывание, рефакторинг и т.п. больше похожи на выкинули старое и добавили новое. Поэтому, здесь можно говорить не о трансформации, а об откате к предыдущему состоянию и добавлении нового кода.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas, Вы писали:
G>А где здесь отвественности, которые стоило бы разделить?
Парсинг XML, алгоритм преобразования, генерация выходного потока. Тоже самое как и случае с компилятором: парсинг, преобразования, генерация.
G>Применять здесь SRP абсолютно незачем.
В данном примере это очевидно и мне и тебе, да и всем остальным.
G>>>Немного растет объем и немного увеличивается слжность чтения, но сильно уменьшается сложность изменения. Крмое того выделенные классы могут более удачно повторно использоваться, что приведет еще и к сокращению объема кода. IT>>Немного растёт, классы могут. Главное, что сложность модификации растёт, т.е. гибкость кода страдает. G>С чего ты взял что сложность модификации растет?
Ну сам немного подумай. В приведённом примере нужно добавить только одну строчку, а после применения SRP много больше чем одну.
G>Правильное прмиенение SRP уменьшает связность между различным функционалом, что позволяет вносить изменения в одном месте не беспокоясь что что-то сломается в другом.
Правильность — это оптимальное внесение сложности применяемым инструментом. Т.е. правильность — это как раз следствие, которое мне сейчас обсуждать не интересно.
G>Видиимо увеличивается только в случае неправильного применения SRP.
Но ведь увеличивается?
IT>>Ещё не понятно? Тогда ещё раз. Применение (абсолютно) любого инструмента ведёт к усложнению кода и совокупный эффект является большим вопросом. G>Это пока еще не удалось доказать. даже с примерами такого туговато.
Т.е. теперь ты уже не согласен со своим предыдущим утверждением? SRP не добавляет сложности?
IT>>'Только в случае' для меня достаточно. Дело в том, что случаи бывают разные и главная проблема в том, что не все из них очевидны. Чем выше сложность системы, тем менее очевидны такие случаи. SRP в этом смысле как раз очень показательный принцип. Когда нужно остановиться, где та грань, после которой применение паттерна или принципа даёт обратный эффект? У тебя есть точная метрика? G>Есть, прямо из определения SRP — когда один компонент отвечает за один аспект функционала.
В моём примере с XML -> TXT SRP можно применить во всей красе. В результате мы получим три компонента: парсер XML, модуль преобразования, генератор TXT. В результате твоя точная метрика даст усложнение кода в разы.
IT>>Всегда и не нужно. Лично мне достаточно того, что я понимаю одну простую вещь — любой (абсолютно) инструмент может быть использован как во благо, так и совсем наоборот. На практике это означает критическое отношение к любому (абсолютно) паттерну или принципу. Даже к полюбившимся в этой ветке упорядочиванию и абстрагированию, т.к. упорядочивание и абстрагирование всегда в 100% случаях автоматически ведёт к усложнению, а вот для достижения упрощения ещё нужно попотеть. G>Применение паттерна или принципа только ради его применения ведет к усложнению. Если головой понимаешь зачем применять, то получишь упрощение.
Правильно. А где граница между ведёт к усложнению или получишь упрощение?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VGn, Вы писали:
VGn>Аналогия суждения: "использование автомобиля всегда ведёт к дополнительным затратам, потому что в соседний ларёк ездить за пивом на авто не эффективно"
Ты не согласен с такой своей аналогией?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas, Вы писали:
IO>>Сложность кода не может быть ниже сложности обьекта, который код моделирует (не всего обьекта понятно, а только программируемого аспекта). Вот обьективная предпосылка "Закона сохранения минимальной сложности".
G>Это вообще говоря неверно. напрмиер сделать учетную систему в 1C гораздо проще, чем написать её на ассемблере (вместе с БД).
Всё верно. Твой пример как раз хорошо показывает зависимость сложности кода от сложности используемых инструментов.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VGn, Вы писали:
IO>>Сложность кода не может быть ниже сложности обьекта, который код моделирует (не всего обьекта понятно, а только программируемого аспекта). Вот обьективная предпосылка "Закона сохранения минимальной сложности".
VGn>Моделирование всегда снижает сложность. Иначе это не моделирование.
Ты опять начинаешь разговаривать с телепатами.
Если нам не помогут, то мы тоже никого не пощадим.
Хорошая и важная статья. Только мне кажется что некоторые читатели могут после прочтения сделать неверные выводы, и решить что раз сложность никуда не девается, то и делать ничего не нужно. Тем не менее это неверно. Со сложностью надо бороться и всегда стараться свести ее к минимуму. Макконнелл в своей книге называет управление сложностью — главным техническим аспектом разработки ПО:
Важность управления сложностью
Программные проекты редко терпят крах по техническим причинам. Чаще всего провал объясняется неадекватной выработкой требований, неудачным планированием или неэффективным управлением. Если же провал обусловлен все-таки преимущественно технической причиной, очень часто ею оказывается неконтролируемая сложность. Иначе говоря, приложение стало таким сложным, что разработчики перестали по-настоящему понимать, что же оно делает. Если работа над проектом достигает момента, после которого уже никто не может полностью понять, как изменение одного фрагмента программы повлияет на другие
фрагменты, прогресс прекращается.
Управление сложностью — самый важный технический аспект разработки ПО. По-моему, управление сложностью настолько важно, что оно должно быть Главным Техническим Императивом Разработки ПО.
Сложность — не новинка в мире разработки ПО. Один из пионеров информатики Эдсгер Дейкстра обращал внимание на то, что компьютерные технологии — единственная отрасль, заставляющая человеческий разум охватывать диапазон, простирающийся от отдельных битов до нескольких сотен мегабайт информации, что соответствует отношению 1 к 109, или разнице в девять порядков (Dijkstra, 1989).
Такое гигантское отношение просто ошеломляет. Дейкстра выразил это так: «По сравнению с числом семантических уровней средняя математическая теория кажется почти плоской. Создавая потребность в глубоких концептуальных иерархиях, компьютерные технологии бросают нам абсолютно новый интеллектуальный вызов, не имеющий прецедентов в истории». Разумеется, за прошедшее с 1989 г. время
сложность ПО только выросла, и сегодня отношение Дейкстры вполне может характеризоваться 15 порядками. Дейкстра пишет, что ни один человек не обладает интеллектом, способным вместить все детали современной компьютерной программы (Dijkstra, 1972), поэтому нам — разработчикам ПО — не следует пытаться охватить всю программу сразу. Вместо этого мы должны попытаться организовать программы так, чтобы можно было безопасно работать с их отдельными фрагментами по очереди. Целью этого является минимизация объема программы, о котором нужно думать в конкретный момент времени. Можете считать это своеобразным умственным жонглированием: чем больше умственных шаров программа заставляет поддерживать в воздухе, тем выше вероятность того, что вы уроните один из них и допустите ошибку при проектировании или кодировании.
На уровне архитектуры ПО сложность проблемы можно снизить, разделив систему на подсистемы. Несколько несложных фрагментов информации понять проще, чем один сложный. В разбиении сложной проблемы на простые фрагменты и заключается цель всех методик проектирования ПО. Чем более независимы подсистемы, тем безопаснее сосредоточиться на одном аспекте сложности в конкретный момент времени. Грамотно определенные объекты разделяют аспекты проблемы так, чтобы вы могли решать их по очереди. Пакеты обеспечивают такое же преимущество на более высоком уровне агрегации.
Стремление к краткости методов программы помогает снизить нагрузку на интеллект. Этому же способствует написание программы в терминах проблемной области, а не низкоуровневых деталей реализации, а также работа на самом высоком уровне абстракции.
Суть сказанного в том, что программисты, компенсирующие изначальные ограничения человеческого ума, пишут более понятный и содержащий меньшее число ошибок код.
Как бороться со сложностью?
Чаще всего причинами неэффективности являются:
— сложное решение простой проблемы;
— простое, но неверное решение сложной проблемы;
— неадекватное сложное решение сложной проблемы.
Как указал Дейкстра, сложность современного ПО обусловлена самой его природой, поэтому, как бы вы ни старались, вы все равно столкнетесь со сложностью, присущей самой проблеме реального мира. Исходя из этого, можно предложить двойственный подход к управлению сложностью:
— старайтесь свести к минимуму объем существенной сложности, с которым придется работать в каждый конкретный момент времени;
— сдерживайте необязательный рост несущественной сложности.
Как только вы поймете, что все остальные технические цели разработки ПО вторичны по отношению к управлению сложностью, многие принципы проектирования окажутся простыми.
Кстати, думаю что стоит обратить внимание и на сложность требований, приводящих к резкому увеличению сложности разрабатываемого ПО. Считается, что увеличение сложности задачи на 25% приводит к усложнению программного решения на 100% (Факты и заблуждения профессионального программирования (с) Роберт Гласс):
Факт 21
Увеличение сложности задачи на 25% приводит к усложнению программного решения на 100%, Это не условие, которое можно попытаться изменить (хотя сложность всегда желательно свести к минимуму), это реальное положение дел.
Правда я немного не согласен с тем, что это нельзя изменить. По возможности надо обращать внимание на сложность требований и главное эффективность от их реализации. К примеру, нередко я получаю относительно сложные и заморочные таски для разрабатываемой бизнес системы, и понимаю что их реализация резко повысит сложность кода/проекта, а необходимость и эффективность этих требований под большим вопросом. Нередко получается обсудить это с заказчиком и упростить задачу, что приводит к сдерживанию сложности и ускорению решения.
Здравствуйте, VGn, Вы писали:
VGn>ИМХО приведённое выше определение немногим менее, чем полностью описывает твою статью. Так сказать умообразные заключения.
А, по-моему, тебе завидно, что сам так написать не можешь, вот и пытаешься чужой труд с дерьмом смешать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
IT>По результатам обсуждения статьи выяснилось, что некоторые читатели слишком буквально воспринимают её название, в следствии чего пытаются найти или увидеть в ней формальные определения и доказательства. Такой цели автором не ставилось. Задача статьи рассмотреть виды сложности, лучше понять её природу и неочевидные стороны. Так же хочу всех успокоить, автор вполне осознаёт, что он не открыл новый закон природы, более того, он понимает, что в строго научном смысле такого закона не существует, а выбор заголовка в большей степени обусловлен пристрастием автора к пафосным названиям.
IT>Надеюсь это успокоит формалистов и направит обсуждение в более продуктивное русло.
Ну, так назови статью адекватным образом. Например, "Виды сложности и преобразования между ними", или "Видя сложности и как с ними бороться", или "Заметки о том как бороться со сложностью".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IO, Вы писали:
IO>Сложность кода не может быть ниже сложности обьекта, который код моделирует (не всего обьекта понятно, а только программируемого аспекта). Вот обьективная предпосылка "Закона сохранения минимальной сложности".
На то она и модель чтобы быть проще оригинала. Так что твое утверждение не верно. Верно будет утверждать, что модель должна быть проще оригинала. И если это не так, то это превышении необходимого уровня сложности.
Сложность же кода действительно должна быть минимально необходимой для решения задачи. Кстати, не все задачи являются моделированием. Это перекос вызванный засильем ООП в умах масс. Многие задачи являются задачами трансформации. Их, как не странно, куда больше чем задач моделирования. В прочем, трансформировать можно модели.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
IT>>Надеюсь это успокоит формалистов и направит обсуждение в более продуктивное русло.
VD>Ну, так назови статью адекватным образом. Например, "Виды сложности и преобразования между ними", или "Видя сложности и как с ними бороться", или "Заметки о том как бороться со сложностью".
Тогда пропадёт вся интрига.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
G>>А где здесь отвественности, которые стоило бы разделить?
IT>Парсинг XML, алгоритм преобразования, генерация выходного потока. Тоже самое как и случае с компилятором: парсинг, преобразования, генерация.
И так все разделено? Объекты xml и file отвечают за парсинг и генерацию соотвественно, а сам метод за проеобразования.
G>>Применять здесь SRP абсолютно незачем. IT>В данном примере это очевидно и мне и тебе, да и всем остальным.
Тогда к чему пример был?
Вроде как цель была показать пример где применение SRP увеличивает сложность.
G>>>>Немного растет объем и немного увеличивается слжность чтения, но сильно уменьшается сложность изменения. Крмое того выделенные классы могут более удачно повторно использоваться, что приведет еще и к сокращению объема кода. IT>>>Немного растёт, классы могут. Главное, что сложность модификации растёт, т.е. гибкость кода страдает. G>>С чего ты взял что сложность модификации растет?
IT>Ну сам немного подумай. В приведённом примере нужно добавить только одну строчку, а после применения SRP много больше чем одну.
Не нужно там применение SRP в принципе. В прмиере нету отвественностей которые надо разделять.
Все рассуждения идут от неверной посылки, следовательно сами рассуждения вполне могут быть неверными.
G>>Правильное прмиенение SRP уменьшает связность между различным функционалом, что позволяет вносить изменения в одном месте не беспокоясь что что-то сломается в другом. IT>Правильность — это оптимальное внесение сложности применяемым инструментом. Т.е. правильность — это как раз следствие, которое мне сейчас обсуждать не интересно.
Правильность — соответсвие инструмента задаче. В приведенном выше коде не возникает задачи разделять отвественности, они там и так разделены, поэтому и инструмент применять не надо.
А изменение сложности как раз следствие.
G>>Видиимо увеличивается только в случае неправильного применения SRP. IT>Но ведь увеличивается?
Любую программу можно написать плохо, давайте теперь дакажем что не стоит применять ни один паттерн, ООП и вообще писать надо только на ассемблере.
IT>>>Ещё не понятно? Тогда ещё раз. Применение (абсолютно) любого инструмента ведёт к усложнению кода и совокупный эффект является большим вопросом. G>>Это пока еще не удалось доказать. даже с примерами такого туговато.
IT>Т.е. теперь ты уже не согласен со своим предыдущим утверждением? SRP не добавляет сложности?
Не добавляет.
IT>В моём примере с XML -> TXT SRP можно применить во всей красе. В результате мы получим три компонента: парсер XML, модуль преобразования, генератор TXT. В результате твоя точная метрика даст усложнение кода в разы.
Покажи в коде как это будет.
Сейчас есть:
объект xml — занимается парсингом, file — выводом, а сама функция — преобразование.
Что тут можно от чего отделить и какой код в результате будет?
IT>>>Всегда и не нужно. Лично мне достаточно того, что я понимаю одну простую вещь — любой (абсолютно) инструмент может быть использован как во благо, так и совсем наоборот. На практике это означает критическое отношение к любому (абсолютно) паттерну или принципу. Даже к полюбившимся в этой ветке упорядочиванию и абстрагированию, т.к. упорядочивание и абстрагирование всегда в 100% случаях автоматически ведёт к усложнению, а вот для достижения упрощения ещё нужно попотеть. G>>Применение паттерна или принципа только ради его применения ведет к усложнению. Если головой понимаешь зачем применять, то получишь упрощение.
IT>Правильно. А где граница между ведёт к усложнению или получишь упрощение?
Граница в правильном применении. Определение выше.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
IO>>>Сложность кода не может быть ниже сложности обьекта, который код моделирует (не всего обьекта понятно, а только программируемого аспекта). Вот обьективная предпосылка "Закона сохранения минимальной сложности".
G>>Это вообще говоря неверно. напрмиер сделать учетную систему в 1C гораздо проще, чем написать её на ассемблере (вместе с БД).
IT>Всё верно. Твой пример как раз хорошо показывает зависимость сложности кода от сложности используемых инструментов.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, IO, Вы писали:
IO>>Сложность кода не может быть ниже сложности обьекта, который код моделирует (не всего обьекта понятно, а только программируемого аспекта). Вот обьективная предпосылка "Закона сохранения минимальной сложности".
VD>На то она и модель чтобы быть проще оригинала. Так что твое утверждение не верно. Верно будет утверждать, что модель должна быть проще оригинала. И если это не так, то это превышении необходимого уровня сложности.
Ладно, попробую уточнить.
1. Есть обьект — как правило его сложность бесконечна, если он не абстрактен.
2. Есть моделируемый аспект обьекта — сложность ниже.
3. Есть модель моделируемого аспекта обьекта — сложность еще ниже.
4. Есть реализация модели — вот тут минимальная сложность равна п.3 (именно ето я имел ввиду). Нужно стремится к такой минимальной сложности. В идеале — инструмент позволяет задать реализацию в тех же терминах и тем же способом, которым сформулирована модель.
VD>Сложность же кода действительно должна быть минимально необходимой для решения задачи. Кстати, не все задачи являются моделированием. Это перекос вызванный засильем ООП в умах масс. Многие задачи являются задачами трансформации. Их, как не странно, куда больше чем задач моделирования. В прочем, трансформировать можно модели.
Наверно с самого начала лучше было написать про _решение_ и его минимальную сложность. И сложность кода не ниже сложности решения.
Здравствуйте, IO, Вы писали:
IO>1. Есть обьект — как правило его сложность бесконечна, если он не абстрактен. IO>2. Есть моделируемый аспект обьекта — сложность ниже. IO>3. Есть модель моделируемого аспекта обьекта — сложность еще ниже. IO>4. Есть реализация модели — вот тут минимальная сложность равна п.3 (именно ето я имел ввиду). Нужно стремится к такой минимальной сложности. В идеале — инструмент позволяет задать реализацию в тех же терминах и тем же способом, которым сформулирована модель.
Неверно, так как реализация зависит от технических средств, которые могут упростить решение до тривиального.
Например средства бизнес-аналитики, как MS SSAS, позволяют строить реализацию экономических моделей очень простым способом.
Тогда как при программировании на ЯП общего назначения создать такую модель будет чрезвычайно сложно.
Здравствуйте, IT, Вы писали:
VD>>Ну, так назови статью адекватным образом. Например, "Виды сложности и преобразования между ними", или "Видя сложности и как с ними бороться", или "Заметки о том как бороться со сложностью".
IT>Тогда пропадёт вся интрига.
Ничего никуда не пропадет. Да и интриги особой я тут не вижу. Что есть, то есть.
Закона сохранения сложности конечно не в природе. Есть возможность трансформировать сложность из одного вида в другой и возможность уменьшать сложность там где она банально избыточна. Кроме того, конечно же, есть возможность уменьшать сложность методом JPEG, т.е. с потерей качества.
Ты очень правильно затронул данную тему.
На мой взгляд если статью переименовать и несколько доработать, то она станет только лучше и интереснее. За одно отпадет большая часть нападок.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
VGn>>Аналогия суждения: "использование автомобиля всегда ведёт к дополнительным затратам, потому что в соседний ларёк ездить за пивом на авто не эффективно"
IT>Ты не согласен с такой своей аналогией?
Тебя развели, а ты купился.
Твое суждение было "любой (абсолютно) инструмент может быть использован как во благо, так и совсем наоборот...". Если уж строить аналогии, которые в прочем не уместны, то про автомобили нужно было писать "автомобиль может быть использован как по делу, так и не эффективно, например в соседний ларёк ездить за пивом на авто не эффективно".
В таком же, извращенном, виде — это высказывание принципиально ложно, так как нарушает базовые законы логики.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>>>Ну, так назови статью адекватным образом. Например, "Виды сложности и преобразования между ними", или "Видя сложности и как с ними бороться", или "Заметки о том как бороться со сложностью".
IT>>Тогда пропадёт вся интрига.
VD>На мой взгляд если статью переименовать и несколько доработать, то она станет только лучше и интереснее. За одно отпадет большая часть нападок.
Если отпадёт большая часть нападок, то будет не интересно.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas, Вы писали:
IT>>Парсинг XML, алгоритм преобразования, генерация выходного потока. Тоже самое как и случае с компилятором: парсинг, преобразования, генерация. G>И так все разделено? Объекты xml и file отвечают за парсинг и генерацию соотвественно, а сам метод за проеобразования.
Так и в компиляторе у нас есть file и file, но почему-то народ над ними строит лексеры, парсеры, генераторы и пр. Не знаешь почему?
G>>>Применять здесь SRP абсолютно незачем. IT>>В данном примере это очевидно и мне и тебе, да и всем остальным. G>Тогда к чему пример был? G>Вроде как цель была показать пример где применение SRP увеличивает сложность.
А я и показал. Бестолковое применение SRP приводит к усложнению. Точнее любое применение SRP приводит к усложнению, а вот положительный эффект под вопросом.
IT>>Ну сам немного подумай. В приведённом примере нужно добавить только одну строчку, а после применения SRP много больше чем одну. G>Не нужно там применение SRP в принципе. В прмиере нету отвественностей которые надо разделять. G>Все рассуждения идут от неверной посылки, следовательно сами рассуждения вполне могут быть неверными.
Пока ты не дашь точный и однозначный критерий когда применять SRP надо, а когда не надо, все эти разговоры будут переливанием из пустого в порожднее. Я для наглядности дал два примера, в обоих из которых применить SRP можно. Но в одном случае это даёт эффект, а во втором бессмысленно. Для наглядности. Ты же утверждаешь, что я не прав, потому что в случае XML -> FILE применение SRP не нужно. Я с тобой соглашусь, что я не прав, если ты мне дашь точное правило для определения границы, где нужно применять SRP, а где не нужно, где у нас белое, а где чёрное.
G>>>Видиимо увеличивается только в случае неправильного применения SRP. IT>>Но ведь увеличивается? G>Любую программу можно написать плохо, давайте теперь дакажем что не стоит применять ни один паттерн, ООП и вообще писать надо только на ассемблере.
Любую программу не просто можно написать плохо, любая программа написана плохо. В том числе из-за того, что нет точного критерия когда и где нужно применять тот или иной паттерн.
IT>>В моём примере с XML -> TXT SRP можно применить во всей красе. В результате мы получим три компонента: парсер XML, модуль преобразования, генератор TXT. В результате твоя точная метрика даст усложнение кода в разы. G>Покажи в коде как это будет. G>Сейчас есть: G>
Здравствуйте, gandjustas, Вы писали:
IT>>Всё верно. Твой пример как раз хорошо показывает зависимость сложности кода от сложности используемых инструментов.
G>От этого сложность самой задачи не меняется.
Сложность задачи меня мало интересует, исключительно как изначальная сложность. С ней в общем-то всё понятно. Интересна как раз сложность получаемого решения.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Тебя развели, а ты купился.
Ну зачем сразу наговаривать на человека? У нас с ним просто своеобразный стиль общения — он мощно телепатирует, я пытаюсь принять его поток сознания. Пока у меня неважно получается, но прогресс имеется.
Если нам не помогут, то мы тоже никого не пощадим.
Перераспределение сложности означает одну простую вещь — устраняя сложность в одном месте мы всегда добавляем её где-то в другом. Если этого не происходит, то скорее всего мы просто чего-то не видим и не осознаём. Сложность никогда не уходит без следа, она трансформируется и сохраняется в виде других видов сложности. Давайте условно назовём это законом сохранения сложности.
Отсюда следует один очевидный вывод — не существует идеальных способов борьбы со сложностью.
Non sequitur.
Вывод-то не следует!
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Отсюда следует один очевидный вывод — не существует идеальных способов борьбы со сложностью.[/q]
T>Non sequitur.
T>Вывод-то не следует!
Назови мне идеальный способ. Пожалуйста, я тебя очень прошу!
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
IT>>>Парсинг XML, алгоритм преобразования, генерация выходного потока. Тоже самое как и случае с компилятором: парсинг, преобразования, генерация. G>>И так все разделено? Объекты xml и file отвечают за парсинг и генерацию соотвественно, а сам метод за проеобразования. IT>Так и в компиляторе у нас есть file и file, но почему-то народ над ними строит лексеры, парсеры, генераторы и пр. Не знаешь почему?
Не вдавайся в демагогию. Можешь в своем коде показать где есть различные отвественности, которые нужно разделять?
G>>>>Применять здесь SRP абсолютно незачем. IT>>>В данном примере это очевидно и мне и тебе, да и всем остальным. G>>Тогда к чему пример был? G>>Вроде как цель была показать пример где применение SRP увеличивает сложность.
IT>А я и показал. Бестолковое применение SRP приводит к усложнению. Точнее любое применение SRP приводит к усложнению, а вот положительный эффект под вопросом.
Не показал, потому что применение SRP там ненужно.
Покажи пример где нужно применение SRP и оно приведет к увеличению совокупной сложности.
IT>>>Ну сам немного подумай. В приведённом примере нужно добавить только одну строчку, а после применения SRP много больше чем одну. G>>Не нужно там применение SRP в принципе. В прмиере нету отвественностей которые надо разделять. G>>Все рассуждения идут от неверной посылки, следовательно сами рассуждения вполне могут быть неверными.
IT>Пока ты не дашь точный и однозначный критерий когда применять SRP надо, а когда не надо, все эти разговоры будут переливанием из пустого в порожднее.
Криетрий прямо из определения: есть отвественноти, которые надо разделить.
IT>Я для наглядности дал два примера, в обоих из которых применить SRP можно.
Покажи где есть отвественности которые надо разделить, а еще хорошо бы и код, который получится в результате.
IT>>>В моём примере с XML -> TXT SRP можно применить во всей красе. В результате мы получим три компонента: парсер XML, модуль преобразования, генератор TXT. В результате твоя точная метрика даст усложнение кода в разы. G>>Покажи в коде как это будет. G>>Сейчас есть: G>>
G>>объект xml — занимается парсингом, file — выводом, а сама функция — преобразование. G>>Что тут можно от чего отделить и какой код в результате будет?
IT>Ты статью читал?
Читал. Ответь на вопрос выше.
IT>>>Правильно. А где граница между ведёт к усложнению или получишь упрощение? G>>Граница в правильном применении. Определение выше.
IT>Ты про эту воду в ступе: IT>
IT>Правильность — соответсвие инструмента задаче.
IT>А как определеить соответствие? У тебя есть универсальный метод определения?
Конечно, дл любого паттерна, принципа и даже парадигмы прогнаммирования есть границы применимости, которые описываются авторами патернов. Если задача попадает в эти границы, то соотвествующий паттерн\принцип стоит прмиенять.
В частности для SRP простое условие — в одном компоненте собрано несколько ответственностей.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, thesz, Вы писали:
T>>Отсюда следует один очевидный вывод — не существует идеальных способов борьбы со сложностью.[/q]
T>>Non sequitur.
T>>Вывод-то не следует!
IT>Назови мне идеальный способ. Пожалуйста, я тебя очень прошу!
Из одного параграфа не следует "вывода" второго. Меня больше ничего не интересует.
Если возвращаться к теме статьи, то ты не определил количественную меру сложности, поэтому не можешь сформулировать и закона сохранения (выглядящего, наверное, как-то так: для двух разбиений одной задачи sum(a_i*c_i)=sum(a_j*c_j), где a_i — веса метрик сложности одного разбиения c_i, а a_j и c_j — (такие же) веса и метрики сложности другого).
Если мы сформулируем это понятие количественно, то мы сможем обнаруживать и "идеальные для данных условий разбиения данной задачи". То есть, такие разбиения {c_i}, что любое {c_j}, отличное от него, будет иметь больший взвешенный суммарный вес. Если, конечно, считать, что a_i одинаково для наших условий — команды, времени и тп.
Как-то так.
Хотя бы сложность по Колмогорову упомянул, что ли.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Если возвращаться к теме статьи, то ты не определил количественную меру сложности, T>Если мы сформулируем это понятие количественно,
А если не смогем количественно, не отказываться же от практических наблюдениий?
Вобще-то у MS есть количественные алгоритмы оценки в студии. Например Maintainability Index, показывающий сложность(или наоборот,простоту) поддержки кода. Врядли MS не старался его сделать получше, но что получилось всем прекрасно видно.
MaintainabilityIndex в Project и Namespace считается как среднее для классов. Если два класса по 50% то общий индекс 50%. Если добавить делегат(или пустой класс) то у него 100%, и среднее повысится (50%+50%+100%)/3=67%.
А можно ли сказать, что программу станет легче поддерживать если туда набросать много ненужных делегатов?
Да и Cyclomatic Complexity, при суммировании по всему коду не совсем то...
Количественные оценки было бы неплохо. Но есть ли для начала идеи, как хотя бы студийные метрики сделать хоть немного адекватнее? Или что еще добавить туда? Хотя они и не все аспекты создания ПО смогут охватить, но если будут в алгоритмическом виде это повысит полезность.
Здравствуйте, gandjustas, Вы писали:
IT>>Ты статью читал? G>Читал. Ответь на вопрос выше.
Сначала мы с моими вопросами разберёмся, а потом на твои будем отвечать.
G>Конечно, дл любого паттерна, принципа и даже парадигмы прогнаммирования есть границы применимости, которые описываются авторами патернов. Если задача попадает в эти границы, то соотвествующий паттерн\принцип стоит прмиенять. G>В частности для SRP простое условие — в одном компоненте собрано несколько ответственностей.
Это всё бла-бла-бла. Как формально определить ответственности? У тебя или у авторов паттерна есть критерий?
Для меня, например, алгоритм разбора xml, алгоритм преобразования и алгоритм генерации текста — это разные ответственности. Для тебя, как я понимаю, — нет. Всё вместе это называется предпочтения. У меня они свои, у тебя свои. Там где начинаются предпочтения заканчивается логика. И наоборот. Бороться с предпочтениями можно только формальными методами. Я ещё раз повторю свой вопрос. У тебя есть формальные правила для определения применимости SRP?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, thesz, Вы писали:
T>Из одного параграфа не следует "вывода" второго. Меня больше ничего не интересует.
Понятно.
T>Если возвращаться к теме статьи, то ты не определил количественную меру сложности, поэтому не можешь сформулировать и закона сохранения
Не определил по одной простой причине — её не существует.
T>Хотя бы сложность по Колмогорову упомянул, что ли.
Блин, ещё один измеряльщик. Ну тогда сравни мне сложность восприятия безобразно оформленного кода, алгоритмическую сложность кода, объём кода, сложность обучения, необходимую для понимания кода, и сложность понимания поставленной задачи. При этом, желательно, чтобы формула была универсальной для любого программиста.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, thesz, Вы писали:
T>>Если возвращаться к теме статьи, то ты не определил количественную меру сложности, T>>Если мы сформулируем это понятие количественно, S_> А если не смогем количественно, не отказываться же от практических наблюдениий?
Да ты посмотри на его практические наблюдения. NS на NS и NS погоняет.
А всё потому, что циферек нет.
Кстати, в дедлайне есть намёк на то, как интуицию переводить в количество.
S_>Количественные оценки было бы неплохо. Но есть ли для начала идеи, как хотя бы студийные метрики сделать хоть немного адекватнее?
Это дело автора статьи.
Хотя есть старые добрые LOC. Очень много показывают.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, thesz, Вы писали:
T>>Если возвращаться к теме статьи, то ты не определил количественную меру сложности, поэтому не можешь сформулировать и закона сохранения IT>Не определил по одной простой причине — её не существует.
Это отговорка.
T>>Хотя бы сложность по Колмогорову упомянул, что ли. IT>Блин, ещё один измеряльщик. Ну тогда сравни мне сложность восприятия безобразно оформленного кода, алгоритмическую сложность кода, объём кода, сложность обучения, необходимую для понимания кода, и сложность понимания поставленной задачи. При этом, желательно, чтобы формула была универсальной для любого программиста.
Взвешенная сумма? Полином?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>Если возвращаться к теме статьи, то ты не определил количественную меру сложности, поэтому не можешь сформулировать и закона сохранения IT>>Не определил по одной простой причине — её не существует.
T>Это отговорка.
Ну давай попробуем найти твою количественную меру. Мы её тут в соседней ветке с DarkGray уже месяц ищем. В основном занимаемся сравнением мягкого с тёплым и пушистым.
IT>>Ну тогда сравни мне сложность восприятия безобразно оформленного кода, алгоритмическую сложность кода, объём кода, сложность обучения, необходимую для понимания кода, и сложность понимания поставленной задачи. При этом, желательно, чтобы формула была универсальной для любого программиста.
T>Взвешенная сумма? Полином?
Сумма чего?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Это всё бла-бла-бла. Как формально определить ответственности? У тебя или у авторов паттерна есть критерий?
Конечно есть. http://en.wikipedia.org/wiki/Single_responsibility_principle
IT>Для меня, например, алгоритм разбора xml, алгоритм преобразования и алгоритм генерации текста — это разные ответственности. Для тебя, как я понимаю, — нет.
С чего ты взял? это разные отвественности и они уже реализуются разными компонентами, объект xml отвечает за разбор xml_я, file за генерацию текста, а сам метод Convert за преобразование.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, thesz, Вы писали:
T>>>>Если возвращаться к теме статьи, то ты не определил количественную меру сложности, поэтому не можешь сформулировать и закона сохранения IT>>>Не определил по одной простой причине — её не существует. T>>Это отговорка. IT>Ну давай попробуем найти твою количественную меру. Мы её тут в соседней ветке с DarkGray уже месяц ищем. В основном занимаемся сравнением мягкого с тёплым и пушистым.
Честное слово, я в этом не виноват.
IT>>>Ну тогда сравни мне сложность восприятия безобразно оформленного кода, алгоритмическую сложность кода, объём кода, сложность обучения, необходимую для понимания кода, и сложность понимания поставленной задачи. При этом, желательно, чтобы формула была универсальной для любого программиста. T>>Взвешенная сумма? Полином? IT>Сумма чего?
Количественных характеристик?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
IT>>Ну давай попробуем найти твою количественную меру. Мы её тут в соседней ветке с DarkGray уже месяц ищем. В основном занимаемся сравнением мягкого с тёплым и пушистым.
T>Честное слово, я в этом не виноват.
Ну извини что так получилось. Так будем искать количественную меру или будем заниматься демагогией?
IT>>>>Ну тогда сравни мне сложность восприятия безобразно оформленного кода, алгоритмическую сложность кода, объём кода, сложность обучения, необходимую для понимания кода, и сложность понимания поставленной задачи. При этом, желательно, чтобы формула была универсальной для любого программиста. T>>>Взвешенная сумма? Полином? IT>>Сумма чего?
T>Количественных характеристик?
Каких, чего? Конкретней, пожалуйста, для каждого вида сложности. Нам понадобятся количественные характеристики для определения (я начну, а ты продолжай):
— сложности восприятия кода, даже не знаю что предложить, DG пытался здесь притулить количество вариантов рассмотрения.
— алгоритмической сложности, DG говорил о количестве вариантов поведения кода.
— объёма кода, видимо количество строк или мегабайт.
— сложности обучения
— гибкости
— сложности понимания поставленной задачи (ещё один вид, который я бы выделил в отдельный).
Интересны количесвенные характеристики каждого вида и функции, с помощью которых их можно было бы привести к единой мере для дальнейших манипуляций.
Если нам не помогут, то мы тоже никого не пощадим.
Reason to change? Ты понимаешь смысл слова reason или тебе перевести?
IT>>Для меня, например, алгоритм разбора xml, алгоритм преобразования и алгоритм генерации текста — это разные ответственности. Для тебя, как я понимаю, — нет. G>С чего ты взял? это разные отвественности и они уже реализуются разными компонентами, объект xml отвечает за разбор xml_я, file за генерацию текста, а сам метод Convert за преобразование.
С того и взял. Для меня компонент xml и file — это способы доступа к конкретному формату, а не алгоритм разбора и генерации конкретных данных в моеё бизнес логике. Точно такие же компоненты у меня есть и для компилятора. Впрочем, мы начинаем ходить по кругу, что означает бессмысленность дальнейшей дискуссии.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Каких, чего? Конкретней, пожалуйста, для каждого вида сложности. Нам понадобятся количественные характеристики для определения (я начну, а ты продолжай):
IT>- объёма кода, видимо количество строк или мегабайт.
Байт, инструкций.
IT>- сложности обучения
Надо взвешивать инструменты (библиотеки, языковые елементы). Наверно сначала вручную...
IT>- сложности восприятия кода, даже не знаю что предложить, DG пытался здесь притулить количество вариантов рассмотрения.
Частично — производное от предыдуших.
Также наличие нелинейных выражений со множеством инструкций. Структуру дерева "нелинейного выражения" сложно упаковать.
IT>- алгоритмической сложности, DG говорил о количестве вариантов поведения кода.
В общем случае тяжело...
IT>- гибкости
Dependency?..
IT>- сложности понимания поставленной задачи (ещё один вид, который я бы выделил в отдельный).
Статья уже о решениях.
Сначала ваш спор не читал, так шо сори если не в тему.
Здравствуйте, IO, Вы писали:
IO>Байт, инструкций. IO>Надо взвешивать инструменты (библиотеки, языковые елементы). Наверно сначала вручную... IO>Частично — производное от предыдуших. IO>Также наличие нелинейных выражений со множеством инструкций. Структуру дерева "нелинейного выражения" сложно упаковать. IO>В общем случае тяжело... IO>Dependency?..
IO>Сначала ваш спор не читал, так шо сори если не в тему.
Теперь нужно научиться всё это теплое и мягкое между собой сравнивать. Есть идеи?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, thesz, Вы писали:
IT>>>Ну давай попробуем найти твою количественную меру. Мы её тут в соседней ветке с DarkGray уже месяц ищем. В основном занимаемся сравнением мягкого с тёплым и пушистым. T>>Честное слово, я в этом не виноват. IT>Ну извини что так получилось. Так будем искать количественную меру или будем заниматься демагогией?
Волен ли я сделать выбор?
IT>>>>>Ну тогда сравни мне сложность восприятия безобразно оформленного кода, алгоритмическую сложность кода, объём кода, сложность обучения, необходимую для понимания кода, и сложность понимания поставленной задачи. При этом, желательно, чтобы формула была универсальной для любого программиста. T>>>>Взвешенная сумма? Полином? IT>>>Сумма чего? T>>Количественных характеристик? IT>Каких, чего? Конкретней, пожалуйста, для каждого вида сложности. Нам понадобятся количественные характеристики для определения (я начну, а ты продолжай): IT>- сложности восприятия кода, даже не знаю что предложить, DG пытался здесь притулить количество вариантов рассмотрения.
Время на одну полезную строку после приведения к стандарту кодирования?
IT>- алгоритмической сложности, DG говорил о количестве вариантов поведения кода.
Количество возможных мест, где мы можем ошибиться с выбором варианта решения?
IT>- объёма кода, видимо количество строк или мегабайт.
Полезные строки кода.
IT>- сложности обучения
Обучение чему? Квантуем это "чего" и получаем метрику "время на единицу чего".
IT>- гибкости
Даёшь удовлетворительное определение гибкости, квантуешь, получаешь метрику гибкости.
А можешь выбросить из рассмотрения, пока не найдёшь.
IT>- сложности понимания поставленной задачи (ещё один вид, который я бы выделил в отдельный).
Зависит от метрики сложности задачи и скорости понимания (которая у всех разная).
IT>Интересны количесвенные характеристики каждого вида и функции, с помощью которых их можно было бы привести к единой мере для дальнейших манипуляций.
Это исследование надо проводить, на это я пойтить не могу.
Но в результате всё сведётся к прогнозу времени.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
IT>>Ну извини что так получилось. Так будем искать количественную меру или будем заниматься демагогией?
T>Волен ли я сделать выбор?
Да ради бога, только выбор не очень большой.
IT>>- сложности восприятия кода, даже не знаю что предложить, DG пытался здесь притулить количество вариантов рассмотрения. T>Время на одну полезную строку после приведения к стандарту кодирования?
Не знаю что он понимал под рассмотрением, но как минимум тут возникает сразу два вопроса: что такое полезная строка и что такое стандарт кодирования? Как они формализуются?
IT>>- алгоритмической сложности, DG говорил о количестве вариантов поведения кода. T>Количество возможных мест, где мы можем ошибиться с выбором варианта решения?
Критерий ошибочности? Два разных алгоритма можгут безошибочно решать одну и ту же задачу, только один будет простым, другой сложным.
IT>>- объёма кода, видимо количество строк или мегабайт. T>Полезные строки кода.
Опять же критерий полезности.
IT>>- сложности обучения T>Обучение чему? Квантуем это "чего" и получаем метрику "время на единицу чего".
Чего — например, ООП. Можно квантануть до наследования, инкапсуляция, полиморфизм. Какова будет метрика?
IT>>- гибкости T>Даёшь удовлетворительное определение гибкости, квантуешь, получаешь метрику гибкости.
Гибкость — сложность модификации кода. Как будем квантовать?
T>А можешь выбросить из рассмотрения, пока не найдёшь.
Не-не-не. Не надо ничего выбрасывать, надо наоборот добавлять.
IT>>- сложности понимания поставленной задачи (ещё один вид, который я бы выделил в отдельный). T>Зависит от метрики сложности задачи и скорости понимания (которая у всех разная).
Разная у всех не только сложность понимания, но ещё и обучаемость и предел алгоритмической сложности. Это всё тоже нужно как-то включать в формальное определение.
IT>>Интересны количесвенные характеристики каждого вида и функции, с помощью которых их можно было бы привести к единой мере для дальнейших манипуляций. T>Это исследование надо проводить, на это я пойтить не могу.
А зря.
T>Но в результате всё сведётся к прогнозу времени.
Время — это хорошо, но надо подумать. Есть моменты.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IO, Вы писали:
IO>Из "закона сохранения сложности" следует, что сложность при рефакторинге переходит из одного вида в другой. IO>Берем два варианта решения одной задачи и измеряем куда и сколько переместилось сложности. IO>Получим что-то типа "100 единиц сложности восприятия по статистике равно 300 единицам сложности обьема".
Ну то есть тёплое с мягким.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, IO, Вы писали:
IO>>Из "закона сохранения сложности" следует, что сложность при рефакторинге переходит из одного вида в другой. IO>>Берем два варианта решения одной задачи и измеряем куда и сколько переместилось сложности. IO>>Получим что-то типа "100 единиц сложности восприятия по статистике равно 300 единицам сложности обьема".
IT>Ну то есть тёплое с мягким.
Ну да, я же отвечал на вопрос "Теперь нужно научиться всё это теплое и мягкое между собой сравнивать."...
А что не так?
Здравствуйте, IT, Вы писали:
IT>Не знаю что он понимал под рассмотрением, но как минимум тут возникает сразу два вопроса: что такое полезная строка и что такое стандарт кодирования? Как они формализуются?
Берешь студию, запускаешь метрики и тебе показывается количество полезных строк.
ставишь fxcop+stylecop и получаешь нарушения "стандарта".
Потом делишь количество строк на кол-во нарушений и получаешь более менее нормальную метрику.
Также из студии можно использовать полезные вещи, такие как "цикломатическая сложность" и "свзяность классов".
Причем имеют смысл эти метрики на строку кода по всему проекту.
Вот эти 3 метрики + количество строк кода дают вполне пригодную оценку "качества кода", при минимизации метрик качество растет.
IT>>>- алгоритмической сложности, DG говорил о количестве вариантов поведения кода. T>>Количество возможных мест, где мы можем ошибиться с выбором варианта решения?
IT>Критерий ошибочности? Два разных алгоритма можгут безошибочно решать одну и ту же задачу, только один будет простым, другой сложным.
IT>>>- объёма кода, видимо количество строк или мегабайт. T>>Полезные строки кода. IT>Опять же критерий полезности.
IT>>>- сложности обучения T>>Обучение чему? Квантуем это "чего" и получаем метрику "время на единицу чего".
IT>Чего — например, ООП. Можно квантануть до наследования, инкапсуляция, полиморфизм. Какова будет метрика?
Связность.
IT>>>- гибкости T>>Даёшь удовлетворительное определение гибкости, квантуешь, получаешь метрику гибкости. IT>Гибкость — сложность модификации кода. Как будем квантовать?
Обратная величина к линейной функции от связности и цикломатической сложности при фиксированном объеме кода.
Гибкость падает при увеличении количества строк и константных других параметров.
IT>>>- сложности понимания поставленной задачи (ещё один вид, который я бы выделил в отдельный). T>>Зависит от метрики сложности задачи и скорости понимания (которая у всех разная). IT>Разная у всех не только сложность понимания, но ещё и обучаемость и предел алгоритмической сложности. Это всё тоже нужно как-то включать в формальное определение.
Субъективные факторы, типа сложности обучения, лучше не учитывать в формальных выкладках.
IT>>>Интересны количесвенные характеристики каждого вида и функции, с помощью которых их можно было бы привести к единой мере для дальнейших манипуляций. T>>Это исследование надо проводить, на это я пойтить не могу. IT>А зря.
Не очень получится, в зависимости от задачи одни метрики могут быть более приоритетные, чем другие.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, thesz, Вы писали:
IT>>>Ну извини что так получилось. Так будем искать количественную меру или будем заниматься демагогией? T>>Волен ли я сделать выбор? IT>Да ради бога, только выбор не очень большой.
Мне главное иметь возможность. За каковую большое спасибо.
IT>>>- сложности восприятия кода, даже не знаю что предложить, DG пытался здесь притулить количество вариантов рассмотрения. T>>Время на одну полезную строку после приведения к стандарту кодирования? IT>Не знаю что он понимал под рассмотрением, но как минимум тут возникает сразу два вопроса: что такое полезная строка и что такое стандарт кодирования? Как они формализуются?
PSP/TSP, спец Влад Балин aka Gaperton.
Давай условимся, на некоторое время, что мы работаем со вполне определёнными людьми, у которых выработаны определённые критерии совместной работы и характеристики которых мы знаем. В частности, у них есть стандарт кодирования.
От группы к группе он может отличаться, но внутри группы он постоянен.
Полезная строка кода — это строка кода, в которой может быть ошибка после компиляции программы. Для фиксированного стандарта кодирования производительность программиста в полезных строках кода достаточно стабильна.
IT>>>- алгоритмической сложности, DG говорил о количестве вариантов поведения кода. T>>Количество возможных мест, где мы можем ошибиться с выбором варианта решения? IT>Критерий ошибочности? Два разных алгоритма можгут безошибочно решать одну и ту же задачу, только один будет простым, другой сложным.
Ну вот как ты определишь "один простой, а другой сложный"?
По-моему, в сложном алгоритме проще ошибиться.
Вот число 21 в виде числа Пеано:
S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))))))))))
Если мы его сложим с числом S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S Z)))))))))))))))))))), то получим S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S(S (S (S (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))))))))))))))))))))))))))))))) или 42.
Запись чисел Пеано сложна для чтения. И их сложность растёт с ростом чисел — в числе 42 41 скобка, а в 21 — 20.
Если помимо Z и S мы соберёмся добавить ещё какой-либо конструктор, получится, что вероятность ошибиться (просто опечататься) в конструкторе будет пропорциональна длине (абсолютной величине) числа.
Зато сложение очень просто:
type family NPlus a b
type instance NPlus Z b = b
type instance NPlus (S a) b = S (NPlus a b)
Для двоичной позиционной записи чисел код сложения длинней в несколько раз. Читать же двоичные числа много проще.
Поэтому числа Пеано требуют практики.
Вот и размен: для Пеано проще доказывать теоремы, работать же лучше с позиционной системой счисления. Обычные программисты предпочитают второе, HOT программисты — первое. "Integers are for sissies!" (C) ироничный J. Shapiro, создатель BitC.
IT>>>- объёма кода, видимо количество строк или мегабайт. T>>Полезные строки кода. IT>Опять же критерий полезности.
Чуть выше.
IT>>>- сложности обучения T>>Обучение чему? Квантуем это "чего" и получаем метрику "время на единицу чего". IT>Чего — например, ООП. Можно квантануть до наследования, инкапсуляция, полиморфизм. Какова будет метрика?
Самое простое — подход а-ля IQ. Создаём большой список вопросов по теме, от простых до сложных, проводим тесты. Метрика понимания — количество отвеченных вопросов за определённое время. Можно ввести вес вопросов.
IT>>>- гибкости T>>Даёшь удовлетворительное определение гибкости, квантуешь, получаешь метрику гибкости. IT>Гибкость — сложность модификации кода. Как будем квантовать?
По-моему, гибкость обратно пропорциональна сложности модификации.
Тем не менее. Сложность — количество мест, где мы можем ошибиться. Большой код сложен, короткий и запутанный код также сложен. Модификация — изменение кода для решения задачи. Получается, что чем сложней модификация, тем выше количество ошибок на решение задачи.
Соответственно, гибкость будет обратно пропорциональна количеству ошибок на решение задачи.
T>>А можешь выбросить из рассмотрения, пока не найдёшь. IT>Не-не-не. Не надо ничего выбрасывать, надо наоборот добавлять.
Это не мой подход.
IT>>>- сложности понимания поставленной задачи (ещё один вид, который я бы выделил в отдельный). T>>Зависит от метрики сложности задачи и скорости понимания (которая у всех разная). IT>Разная у всех не только сложность понимания, но ещё и обучаемость и предел алгоритмической сложности. Это всё тоже нужно как-то включать в формальное определение.
То есть, скорость понимания снижается от уровня сложности задачи. Это можно связать.
IT>>>Интересны количесвенные характеристики каждого вида и функции, с помощью которых их можно было бы привести к единой мере для дальнейших манипуляций. T>>Это исследование надо проводить, на это я пойтить не могу. IT>А зря.
Я разработчик, не когнитивный исследователь.
T>>Но в результате всё сведётся к прогнозу времени. IT>Время — это хорошо, но надо подумать. Есть моменты.
Это единственный невосполнимый ресурс.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
IT>>>>- сложности понимания поставленной задачи (ещё один вид, который я бы выделил в отдельный). T>>>Зависит от метрики сложности задачи и скорости понимания (которая у всех разная). IT>>Разная у всех не только сложность понимания, но ещё и обучаемость и предел алгоритмической сложности. Это всё тоже нужно как-то включать в формальное определение.
T>То есть, скорость понимания снижается от уровня сложности задачи. Это можно связать.
Скорость понимания условий задачи? Просто,ИМХО, две большие разницы — сложность условий задачи и сложность решения.
Бывают задачи простые,краткие, с недвусмысленными условиями.Но с очень сложным решением.
А бывает наоборот, описание задачи намного длиннее и сложнее чем решение. (не обязательно от заказчика, но и какие-то локальные подзадачи)
Сложность понимания условий задачи мерять в секундах тяжеловато. ИМХО, легче ее мерять в количестве букв в тексте на естейственном языке (не ЯП), необходимых чтобы ее достаточно точно описать.
Я вот тут попытался дать способ вычисления одного показателя на эту тему: http://www.rsdn.ru/forum/philosophy/3487882.1.aspx
Он якобы имеет какое-то отношение к инкапсуляции...
Вот когда в реализации системы(задачи) образуется много подсистем(подзадач) допускающих намного более краткое описание на человеческом языке, чем их реализяция на ЯП. То какая-то общая сложность снижается.Даже если реализация на ассемблере была, без стандартов на кодирование.Все равно при изучении такого кода это можно разглядеть.
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, thesz, Вы писали:
IT>>>>>- сложности понимания поставленной задачи (ещё один вид, который я бы выделил в отдельный). T>>>>Зависит от метрики сложности задачи и скорости понимания (которая у всех разная). IT>>>Разная у всех не только сложность понимания, но ещё и обучаемость и предел алгоритмической сложности. Это всё тоже нужно как-то включать в формальное определение. T>>То есть, скорость понимания снижается от уровня сложности задачи. Это можно связать.
S_>Скорость понимания условий задачи? Просто,ИМХО, две большие разницы — сложность условий задачи и сложность решения.
Буду краток: что всё это значит?
S_>Бывают задачи простые,краткие, с недвусмысленными условиями.Но с очень сложным решением.
Пример?
S_>А бывает наоборот, описание задачи намного длиннее и сложнее чем решение. (не обязательно от заказчика, но и какие-то локальные подзадачи)
Пример?
S_>Сложность понимания условий задачи мерять в секундах тяжеловато. ИМХО, легче ее мерять в количестве букв в тексте на естейственном языке (не ЯП), необходимых чтобы ее достаточно точно описать.
S_>Он якобы имеет какое-то отношение к инкапсуляции... S_>Вот когда в реализации системы(задачи) образуется много подсистем(подзадач) допускающих намного более краткое описание на человеческом языке, чем их реализяция на ЯП.
За счёт чего? Правильно, за счёт контекста.
S_>То какая-то общая сложность снижается.Даже если реализация на ассемблере была, без стандартов на кодирование.Все равно при изучении такого кода это можно разглядеть.
Вообще не понял.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали: T>Здравствуйте, Silver_s, Вы писали: S_>>Здравствуйте, thesz, Вы писали:
S_>>Скорость понимания условий задачи? Просто,ИМХО, две большие разницы — сложность условий задачи и сложность решения. T>Буду краток: что всё это значит?
Это значит если тебя попросят написать коллекцию такую как Dictionart<TKey,TValue> но чтобы на один ключ много value можно было повесить.
Либо вторая задача. Реализовать интерфейс IList<T> но чтобы не в виде массива хранил, а связанным списком.С удалением любого элемента со сложностью O(1). И с поведением стандартного List<T>.
Думаю тебе одного этого предложения хватит(если .NET интересуешся) чтобы понять что требуется. 10-20 секунд. А провозишься с написанием гораздо дольше.
Если такие задачи возникнут, то есть возможность сплавить их на сторону. Поймать на улице первого встречного программиста сунуть ему задачу + оплату. И долго не объяснять куда это все будет встраиваться, ему это знать и не нужно.
S_>>Бывают задачи простые,краткие, с недвусмысленными условиями.Но с очень сложным решением. T>Пример?
Пример я там где то приводил. Написать функцию на входе .bmp с сайтов, где пишут введите код на картинке если вы человек а не web робот. На выходе строка которую нужно будет вводить.
S_>>А бывает наоборот, описание задачи намного длиннее и сложнее чем решение. (не обязательно от заказчика, но и какие-то локальные подзадачи) T>Пример?
Например есть у мяня полезный модуль A и еще один полезный модуль B. Нужно заставить их работать совместно. Переконвертировать какие-то данные выдаваемые из модуля A в формат который сможет пережевать модуль B. И чего-то там между ними синхронизировать.
А дальше длинная портянка текста на 400 строк с описанием интерфейсов этих модулей и форматов данных, протоколов обмена данными с ними.
В результате будешь сначала долго,долго изучать все эти протоколы, чтобы понять что и как нужно сделать. А потом напишешь код, ктороый возможно строчек на 50-100 всего будет.
S_>>Сложность понимания условий задачи мерять в секундах тяжеловато. ИМХО, легче ее мерять в количестве букв в тексте на естейственном языке (не ЯП), необходимых чтобы ее достаточно точно описать.
T>И что ты с этим потом будешь делать?
T>Правильно, приводить к оценке времени.
Ну,да, можно и к времени свести.
S_>>Я вот тут попытался дать способ вычисления одного показателя на эту тему: S_>>http://www.rsdn.ru/forum/philosophy/3487882.1.aspx
S_>>Он якобы имеет какое-то отношение к инкапсуляции... S_>>Вот когда в реализации системы(задачи) образуется много подсистем(подзадач) допускающих намного более краткое описание на человеческом языке, чем их реализяция на ЯП.
T>За счёт чего? Правильно, за счёт контекста.
За счет того что подзадачи можно раздать первым встречным, быстро проверить правильность их решения. И собрать все вместе.
Если что-то не работает, то искать ошибки уж не внутри реализации IList (приведенный выше). Если он тест прошел, про его внутренности можно забыть практически навсегда. Есть только класс реализующий этот IList а кода нету, сложность системы его использующей стала меньше.
Просто есть такой закон неофициальный чем меньшим количеством слов можно полностью(или почти) описать суть задачи, или способы работы с подсистемой,модулем. Тем легче протестировать ее правильность решения. И тем меньше проблем она потом будет создавать.
Собственно вопрос не в том, легче ли работать с системой поддающейся декомпозиции на подзадачи.Тут ответ очевидный.
А есть ли этот неофициальный закон, о минимальном числе слов на естейственном языке.
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, thesz, Вы писали: T>>Здравствуйте, Silver_s, Вы писали: S_>>>Здравствуйте, thesz, Вы писали:
S_>>>Скорость понимания условий задачи? Просто,ИМХО, две большие разницы — сложность условий задачи и сложность решения. T>>Буду краток: что всё это значит? S_> Это значит если тебя попросят написать коллекцию такую как Dictionart<TKey,TValue> но чтобы на один ключ много value можно было повесить. S_> Либо вторая задача. Реализовать интерфейс IList<T> но чтобы не в виде массива хранил, а связанным списком.С удалением любого элемента со сложностью O(1). И с поведением стандартного List<T>.
Ты приводишь примеры там, где требуются объяснения.
S_>Думаю тебе одного этого предложения хватит(если .NET интересуешся) чтобы понять что требуется. 10-20 секунд. А провозишься с написанием гораздо дольше. S_> Если такие задачи возникнут, то есть возможность сплавить их на сторону. Поймать на улице первого встречного программиста сунуть ему задачу + оплату. И долго не объяснять куда это все будет встраиваться, ему это знать и не нужно.
Что всё это значит? Я не вижу связи между двумя этими параграфами самими по себе и между примерами перед этим.
S_>>>Бывают задачи простые,краткие, с недвусмысленными условиями.Но с очень сложным решением. T>>Пример? S_>Пример я там где то приводил. Написать функцию на входе .bmp с сайтов, где пишут введите код на картинке если вы человек а не web робот. На выходе строка которую нужно будет вводить.
Вся простота формулировки твоей задачи скрывается в контексте.
Выяви этот контекст, задача потеряет простоту формулировки. Либо приобретёт простоту реализации.
S_>>>А бывает наоборот, описание задачи намного длиннее и сложнее чем решение. (не обязательно от заказчика, но и какие-то локальные подзадачи) T>>Пример? S_>Например есть у мяня полезный модуль A и еще один полезный модуль B. Нужно заставить их работать совместно. Переконвертировать какие-то данные выдаваемые из модуля A в формат который сможет пережевать модуль B. И чего-то там между ними синхронизировать. S_> А дальше длинная портянка текста на 400 строк с описанием интерфейсов этих модулей и форматов данных, протоколов обмена данными с ними. S_> В результате будешь сначала долго,долго изучать все эти протоколы, чтобы понять что и как нужно сделать. А потом напишешь код, ктороый возможно строчек на 50-100 всего будет.
Вот, лишили задачу контекста, ввели его в формулировку. Задача стала сложной в формулировке.
Скорее всего, из-за избыточного контекста.
S_>>>Сложность понимания условий задачи мерять в секундах тяжеловато. ИМХО, легче ее мерять в количестве букв в тексте на естейственном языке (не ЯП), необходимых чтобы ее достаточно точно описать. T>>И что ты с этим потом будешь делать? T>>Правильно, приводить к оценке времени. S_> Ну,да, можно и к времени свести.
Ничего другого и не нужно. Время — это единственный невосполнимый ресурс, единственная реальная ценность.
S_>>>Я вот тут попытался дать способ вычисления одного показателя на эту тему: S_>>>http://www.rsdn.ru/forum/philosophy/3487882.1.aspx
S_>>>Он якобы имеет какое-то отношение к инкапсуляции... S_>>>Вот когда в реализации системы(задачи) образуется много подсистем(подзадач) допускающих намного более краткое описание на человеческом языке, чем их реализяция на ЯП. T>>За счёт чего? Правильно, за счёт контекста. S_> За счет того что подзадачи можно раздать первым встречным, быстро проверить правильность их решения. И собрать все вместе.
Ты опять перескакиваешь. Пожалуй, я откажусь от дальнейшей дискуссии.
S_>Если что-то не работает, то искать ошибки уж не внутри реализации IList (приведенный выше). Если он тест прошел, про его внутренности можно забыть практически навсегда. Есть только класс реализующий этот IList а кода нету, сложность системы его использующей стала меньше.
S_> Просто есть такой закон неофициальный чем меньшим количеством слов можно полностью(или почти) описать суть задачи, или способы работы с подсистемой,модулем. Тем легче протестировать ее правильность решения. И тем меньше проблем она потом будет создавать. S_> Собственно вопрос не в том, легче ли работать с системой поддающейся декомпозиции на подзадачи.Тут ответ очевидный. S_>А есть ли этот неофициальный закон, о минимальном числе слов на естейственном языке.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Вот, лишили задачу контекста, ввели его в формулировку. Задача стала сложной в формулировке. T>>>За счёт чего? Правильно, за счёт контекста. S_>> За счет того что подзадачи можно раздать первым встречным, быстро проверить правильность их решения. И собрать все вместе. T>Ты опять перескакиваешь. Пожалуй, я откажусь от дальнейшей дискуссии.
Ну пусть будет контекст, не возражаю.
Я собственно хотел сказать только о том что:
Один из критериев того что задачу удалось разбить на подзадачи. Это насколько трудоемко создать исчерпывающую документацию для подзадачи. Или исчерпывающие требования, если еще не разработано. Исчерпывающие — значит по одной такой документации и описанию контекста , "на стороне" смогут реализовать эту подзадачу. Реализовать так, чтобы эту подзадачу можно было встроить в основную задачу с минимальными исправлениями.
Вот если к документации(описанию требований) подзадачи, нужно прилагать контекст в виде исходников всей системы(не меньше).
То это тяжелый случай. Например, найди причину бага в системе, непонятно где возникающего. Смогут эффективно справиться, только те кто уже знаком с контекстом.
Но к контекстам,в принципе, применимы принципы наследования и повторного использования.
Если кому-то пришлось изучить .NET для одного проекта, он сможет эти знания(контекст) применить и для других проектов. Или какую-то библиотеку изучил потом, знания повторно использует...
Если группа разработчиков над одним проектом работает, уже они в каком-то общем контексте.
Но тем не менее, даже и для кода над которым работает один разработчик. Если в нем нет подзадач (либо невозможно,либо не захотел), которые возможно кратко(в сравнении с объемом кода) и исчерпывающе задокументировать с минимальным прилагаемым контекстом. То тяжело ему прийдется (в зависимости от объемов кода). Если при описании повторно запользует контекст, который или общий для большого числа разработчиков, либо общий для большого числа задач которые сам решал (но другие с этим контекстом могут быть и незнакомы). Тогда может все упроститья. Но количество этих контекстов не безгранично (в которых может ориентироваться один человек).
Я, кстати , не устанавливаю прямую связь между "возможность кратко,исчерпывающе задокументировать части программы". И тем хорошо ли написана программа и какая связность в ней.
Для массивов независимых модулей содержащих бизнесс логику. Хрошо,как раз, когда большое число бизнесс-правил заказчика упаковано в небольшое число строк кода. И кратко это никак не задокомунтируешь. Сам код бизнес правил это и есть краткая документация (если все хорошо сделано)
А если прийдется делать свою реализацию IList , то это плохо, похоже на велосипедостроение. Написание кода не относящегося к задаче. Или плохо просто то, что легко и кратко формулируемая задача, решается сложно и долго.
Но при повышении связности системы, количества повторного использования велосипедов, и еще чего-то...cитуация может поменяться на противоположную. К тому же в самой решаемой задаче может присутствовать потребность в велосипеде, не таком как уже есть.
Велисипедом это я называю условно потому что, задачи с краткими понятными концепциями, с простым использованием, но со сложной реализацией, уже как правило реализованы много раз. Если они полезны на практике.
Если пример хочется кроме IList. Возьмем систему рисования графиков, диаграмм. Наверно и не одну тысячу раз это делали. И не одна сотня продуктов есть. Но прийдется делать снова, если не найдется продукт в котором сойдутся все потребности.
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, thesz, Вы писали:
T>>Вот, лишили задачу контекста, ввели его в формулировку. Задача стала сложной в формулировке. T>>>>За счёт чего? Правильно, за счёт контекста. S_>>> За счет того что подзадачи можно раздать первым встречным, быстро проверить правильность их решения. И собрать все вместе. T>>Ты опять перескакиваешь. Пожалуй, я откажусь от дальнейшей дискуссии.
S_> Ну пусть будет контекст, не возражаю. S_>Я собственно хотел сказать только о том что: S_>Один из критериев того что задачу удалось разбить на подзадачи. Это насколько трудоемко создать исчерпывающую документацию для подзадачи. Или исчерпывающие требования, если еще не разработано. Исчерпывающие — значит по одной такой документации и описанию контекста , "на стороне" смогут реализовать эту подзадачу.
Контекст не поддаётся описанию.
Он содержится в недомолвках разговора коллег.
S_>То это тяжелый случай. Например, найди причину бага в системе, непонятно где возникающего. Смогут эффективно справиться, только те кто уже знаком с контекстом.
S_> Но к контекстам,в принципе, применимы принципы наследования и повторного использования.
Это только к тем контекстам, что ты смог придумать.
Вот я тебя сейчас попрошу написать ядро системы моделирования цифровой аппаратуры, синхронного варианта с одной тактовой частотой.
Ты поковыряешься и что-то выдашь.
Теперь я попрошу написать ядро системы моделирования синхронной аппаратуры с несколькими тактовыми частотами.
Тебе придётся выбросить всё, что написал до этого и написать заново.
А теперь я попрошу включить в ядро поддержку комбинаторной логики.
И снова тебе придётся выбросить всё, что ты до этого написал.
Что самое интересное, если написать сразу ядро с поддержкой комбинационной логики, то оно будет мало подходяще для первых двух случаев.
А вроде одно в другое включается, в обе стороны.
S_>Если кому-то пришлось изучить .NET для одного проекта, он сможет эти знания(контекст) применить и для других проектов. Или какую-то библиотеку изучил потом, знания повторно использует...
Ты смотришь, в случае .Нет, на умеренно общий контекст. А в случае библиотеки — на узкий класс проектов.
Теперь выкинь из описания задачи нижележащий фреймворк, оставь только саму суть. И попробуй расширь класс проектов.
После чего посмотри, сможет ли тебе помочь .Net в решении задачи, и позволит ли помочь тебе знание библиотеки сторонним разработчиком.
S_>Если группа разработчиков над одним проектом работает, уже они в каком-то общем контексте.
Вот это здравая мысль.
S_>Но тем не менее, даже и для кода над которым работает один разработчик. Если в нем нет подзадач (либо невозможно,либо не захотел), которые возможно кратко(в сравнении с объемом кода) и исчерпывающе задокументировать с минимальным прилагаемым контекстом. То тяжело ему прийдется (в зависимости от объемов кода). Если при описании повторно запользует контекст, который или общий для большого числа разработчиков, либо общий для большого числа задач которые сам решал (но другие с этим контекстом могут быть и незнакомы). Тогда может все упроститья. Но количество этих контекстов не безгранично (в которых может ориентироваться один человек).
А это я снова не понял.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте thesz, Вы писали:
T>Контекст не поддаётся описанию. T>Он содержится в недомолвках разговора коллег.
Ну если это вводится по определению. Тогда для контекстов поддающихся описанию просто прийдется придумать другой термин.
S_>> Но к контекстам,в принципе, применимы принципы наследования и повторного использования. T>Это только к тем контекстам, что ты смог придумать.
Не хочу злоупотреблять термином контекст, когда он неопределен. При моделировании описанном ниже, даже если код не унаследуешь.
Опыт, знания все равно перенесешь от предыдущих вариантов...
T>Вот я тебя сейчас попрошу написать ядро системы моделирования цифровой аппаратуры, синхронного варианта с одной тактовой частотой. T>Теперь я попрошу написать ядро системы моделирования синхронной аппаратуры с несколькими тактовыми частотами. T>Тебе придётся выбросить всё, что написал до этого и написать заново. T>А теперь я попрошу включить в ядро поддержку комбинаторной логики. T>И снова тебе придётся выбросить всё, что ты до этого написал. T>Что самое интересное, если написать сразу ядро с поддержкой комбинационной логики, то оно будет мало подходяще для первых двух случаев. T>А вроде одно в другое включается, в обе стороны.
Если скажешь что перепрыгнул с вопроса о наследовании контекстов, на это вот все. Для меня в примеденном примере вопрос о наследовании контекстов десятый,двадцатый. Заначит в данном конкретном случае фтопку фразу "наследование контекстов" Философия, философией, а ....
Поскольку с моделями цифровой аппаратуры не знаком. Поэтому не совсем понимаю как можно добавить комбинаторную логику в модель оставив старую модель неизменной. Просто дописав какой-то "клей" который эти две штуки свяжет или как-то по-другому. Не знаю и какого объема(в человоко-днях и в строках кода) часть выбрасывается и переписывается заново. Куда больше времени тратится на написание кода или на что-то другое.Не знаю и сколько таких вариантов моделей нужно. Только 3 или 300 и ни одну повторно не получается использовать. Неизвестно насколько в этой задаче можно жертвовать производительностью(оптимизацией). Без этого оптимум не опредлить.Наверное именно оптимум нужен, а не просто повторно использовать какие-то строчки кода как самоцель.
Когда 300 штук похожих кусков, сократить их толщину почти всегда можно, чем-то пожертвовав. Для трех штук эти жертвы могут не оправданными.
T>А это я снова не понял.
Это можно и в мусорку.
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте thesz, Вы писали:
T>>Контекст не поддаётся описанию. T>>Он содержится в недомолвках разговора коллег. S_>Ну если это вводится по определению. Тогда для контекстов поддающихся описанию просто прийдется придумать другой термин.
КОНТЕ'КСТ, а, м. [латин. contextus — сплетение, соединение] (филол.).
Связное словесное целое по отношению к входящему в него определенному слову или фразе. Надо взять фразу в контексте, и тогда она станет понятной.
Все контексты поддаются описанию.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
КОНТЕ'КСТ, а, м. [латин. contextus — сплетение, соединение] (филол.). T>Связное словесное целое по отношению к входящему в него определенному слову или фразе. Надо взять фразу в контексте, и тогда она станет понятной.
T>Все контексты поддаются описанию.
Когда сложные и общие термины(по словарю) часто применяют в конкретной области они немного другой смысл могут приобретать.
А теперь не о контекстах, а снова IDictionary<TKey,TValue> поскольку он широко известен. Да и вобще об интерфейсах.
Что есть этот IDictionary ? Он имеет конкретное в ЯП значение, список членов. И плюс соглашения что каждый член означает и какое поведение ожидается. Почти все подробно закомментировано в MSDN. Но не все. Например не сказано что если объект добавлен в IDictionary, то он не может изчезнуть, пока не будет удален (через один из базовых интерфесов), или сам перепрыгнуть на другой key.
Все описать невозможно, часть соглашений "переходит по наследству" от всего .NET, часть просто от здравого смысла программистов, и вобще от здравого смысла.
Это соглашение IDictionary появилось в .Net потому что это велосипед. Его легко изучить и запомнить, можно часто использовать для разных целей, и не очень просто реализовать. И реализовать можно по разному просто но не эффективно, сложно но эффективнее, оптимизированно под конкретный сценарий или под общийслучай.
Все эти соглашения это тоже контекст.
Контекст который образуется в конкретной задаче. Это уже локальный контекст в коде. "На уме" у программиста он может быть и не быть. Если есть, то может быть краткосрочным и долгосрочным (раз естейственная память такая). Краткосрочный он недолгий зато может быть на порядок больше по объему. ... и пошло и поехало...
Здравствуйте, mkizub, Вы писали:
M>Увы, повышение уровня абстракции практически всегда приводит к ухудшению производительности программ. Это ухудшение невелико, когда эти уровни абстрации были созданы в рамках одного проекта для решения одной задачи. Но если их брать со стороны, брать некие готовые решения — то потеря производительности будет очень заметна — в разы на каждом уровне абстракции.
Это неправда. Никакой связи между "готовностью" решений и abstraction penalty нет. Есть связь между качеством "клея", который собирает из абстракций конкретную реализацию, и abstraction penalty. Готовые решения из STL очень высокоабстрактны, и никаким образом не созданы в рамках "одного проекта" с прикладной задачей. Тем не менее, никакого "ухудшения производительности" по сравнению с C RTL нет — скорее наоборот.
M>Эта деградация производительности хороша заметна в ретроспективе развития производительности компьютеров и программного обеспечения — мы все видели, как скорость компьютеров увеличилась на несколько порядков, а вот функциональность софта — намного меньше.
Это тоже неправда. То, о чём ты говоришь, это "воспринимаемая функциональность" и "воспринимаемая производительность", perceived functionality vs perceived performance. Обе имеют большее отношение к психологии, чем к технике. Например, показ progress indicator во время долгой операции снижает объективную производительность и увеличивает воспринимаемую.
Список "фич" того же офиса за десять лет вырос на порядок, а его воспринимаемая функциональность практически не изменилась.
M>Так бы и продолжалось дальше, но увы, экспоненциальное развитие скорости компьютеров практически закончилось. И просто увеличение количества уровней абстракции (вроде применения более высокоуровневых языков программирования) уже не поможет — железо не потянет.
И это тоже неправда. Простой пример: запись вида int a = b + c / d — e; находится на совсем другом уровне абстракции, чем набор из mov EAX, .... Тем не менее, производительность программы будет ничуть не хуже.
M>И выход тут я вижу только один — использовать компьютер. Он не имеет такого встроенного ограничения на уровень сложности программы, которую должен анализировать.
Какого ограничения? M>Но увы, он не имеет и интеллекта, чтоб писать и анализировать программы. Вот когда этот интеллект у него появится — тогда и появится реальная альтернатива увеличению количества уровней абстракции в программе. Чтоб программы становились более сложными и функциональными, без экспоненциального увеличения требований к ресурсам.
Угу. Прекрасный пост — из набора неверных утверждений делается совершенно бессмысленный вывод.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
VD>Твое суждение было "любой (абсолютно) инструмент может быть использован как во благо, так и совсем наоборот...". Если уж строить аналогии, которые в прочем не уместны, то про автомобили нужно было писать "автомобиль может быть использован как по делу, так и не эффективно, например в соседний ларёк ездить за пивом на авто не эффективно".
Аналогия относилась к окончаннию фразы, а именно —
упорядочивание и абстрагирование всегда в 100% случаях автоматически ведёт к усложнению
что, на мой взгляд, как раз и является ложным выводом.
Здравствуйте, IO, Вы писали: IO>Ну да, я же отвечал на вопрос "Теперь нужно научиться всё это теплое и мягкое между собой сравнивать."... IO>А что не так?
Что-то мне подсказывает, что тут одни под сложностью понимают запутанность, другие — трудность.
Тем временем третьи с четвёртыми пытаются подставить обе в одно уравнение и определить, можно это делать или нет.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
IO>>Из "закона сохранения сложности" следует, что сложность при рефакторинге переходит из одного вида в другой.
IT>Ну то есть тёплое с мягким.
Ну так весь фокус в том, что ты первый начал.
Как тогда понимать твой "закон сохранения"?
Идея вроде: "оно никуда не делось, оно всё где-то тут"?
Ну так аргументируй количественно, раз начал количественные оценки. "Сохранение", "переход" и есть такие количественные оценки.
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, thesz, Вы писали:
S_>КОНТЕ'КСТ, а, м. [латин. contextus — сплетение, соединение] (филол.). T>>Связное словесное целое по отношению к входящему в него определенному слову или фразе. Надо взять фразу в контексте, и тогда она станет понятной.
T>>Все контексты поддаются описанию.
S_>Когда сложные и общие термины(по словарю) часто применяют в конкретной области они немного другой смысл могут приобретать.
S_>А теперь не о контекстах, а снова IDictionary<TKey,TValue> поскольку он широко известен. Да и вобще об интерфейсах. S_>Что есть этот IDictionary ? Он имеет конкретное в ЯП значение, список членов. И плюс соглашения что каждый член означает и какое поведение ожидается. Почти все подробно закомментировано в MSDN. Но не все. Например не сказано что если объект добавлен в IDictionary, то он не может изчезнуть, пока не будет удален (через один из базовых интерфесов), или сам перепрыгнуть на другой key. S_>Все описать невозможно, часть соглашений "переходит по наследству" от всего .NET, часть просто от здравого смысла программистов, и вобще от здравого смысла.
S_>Это соглашение IDictionary появилось в .Net потому что это велосипед. Его легко изучить и запомнить, можно часто использовать для разных целей, и не очень просто реализовать. И реализовать можно по разному просто но не эффективно, сложно но эффективнее, оптимизированно под конкретный сценарий или под общийслучай. S_>Все эти соглашения это тоже контекст.
S_>Контекст который образуется в конкретной задаче. Это уже локальный контекст в коде. "На уме" у программиста он может быть и не быть. Если есть, то может быть краткосрочным и долгосрочным (раз естейственная память такая). Краткосрочный он недолгий зато может быть на порядок больше по объему. ... и пошло и поехало...
Ещё раз: все контексты поддаются описанию. Вне зависимости от их природы.
А поскольку у тебя кратковременная память на порядок больше по объёму памяти долговременной, судя по контексту, я совсем прекращу общение.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Я и говорю, и пошло и поехало ... Да этот вопрос лучше закрыть. Ничего интересного здесь не откопаем. А чтобы очевидные банальности корректно изложить, кучу ненужного текста пришлось бы настрочить. Тем более, если есть прямое желание понять написанное неправильно.
S_>>Контекст который образуется в конкретной задаче. Это уже локальный контекст в коде. "На уме" у программиста он может быть и не быть. Если есть, то может быть краткосрочным и долгосрочным (раз естейственная память такая). Краткосрочный он недолгий зато может быть на порядок больше по объему. ... и пошло и поехало...
T>А поскольку у тебя кратковременная память на порядок больше по объёму памяти долговременной, судя по контексту.
Да и твои слова легко передернуть. "Краткосрочный" слово мужского рода и не может относиться к памяти.
Как можно делать вывод что краткосрочная память больше по объему если в ней все быстро забывается? То что слово контекст это синоним слова память это чушь.
Попробуй попрограммировать так: посмотреть на исходники, потом через-пол часа продиктовать не глядя что, нужно написать и где подправить.
А что ты хотел чтобы я написал вместо одного предложения, вот это:
Краткорсрочная память отличается от долгосрочной тем что, за фиксированный промежуток времени через нее проходит и в ней обрабатывается на порядок больший объем информации, чем попадает в долгосрочную память. Кроме того краткосрочная память обладает меньшей избирательностью, и запоминает любую, даже несущественную информацию. В долгосрочную память попадают только наиболее существенная обобщаемая, и хорошо связанная(с тем что уже есть) информация. Программный код не является, тем что хорошо запоминается в долговременной памяти.
Поэтому невозможно большой по объему код за короткое время запомнить долговременно без потери детализации. А при работе с кодом детали имеют важное значение.
Большой по объему контекст обработать с высокой степенью детализации возможно только в краткосрочной памяти. Периодически бегая по тексту программы. Либо потратить десяток лет на точное долгосрочное заучивание исходников.
Да и в таком тексте я прекрасно вижу к чему можно придраться.
Надеюсь, я не слишком поздно ? Но раньше не мог — именно с 20 июля находился в условиях нулевой сложности на берегу моря
Нет такого закона. Исходное положение неверно. Задача проектирования — уменьшение сложности до минимума. И только так.
Вот простой пример. Вспомним старые добрые ДОС-времена, когда некий сетевой код пытался изобразить собой и протокол , и клиент, и драйвер одновременно. Монолит. С появлением новых плат сложность такого кода росла. Пришли времена Windows, эти понятия разделили. Если бы сейчас кто-то попытался бы написать для Windows универсальный сетевой протокол-клиент-драйвер (я оставляю в стороне вопрос, можно ли такое вообще сделать для Windows), то сложность его была бы таковой, что он, скореее всего, никогда бы не был написан.
То же самое для видеокарт.
Целью проектирования является уменьшение сложности, для чего, собственно, и вводится понятие компонента (в широком смысле этого слова). Внутрення сложность компонента может быть сколь угодно высока, но его внешняя сложность должна быть небольшой. При работе с компонентом нас его внутрення сложность не интересует, он для нас (в идеале) black box. А внутри него — те же правила для его подкомпонентов.
Здравствуйте, gandjustas, Вы писали:
G>Вот эти 3 метрики + количество строк кода дают вполне пригодную оценку "качества кода", при минимизации метрик качество растет.
Ну допустим мы получили три числа: 25, 42 и 18. Что с ними дальше делать?
IT>>Чего — например, ООП. Можно квантануть до наследования, инкапсуляция, полиморфизм. Какова будет метрика? G>Связность.
Связность может быть сильная, а может быть слабая. Я вовсе не против этого, но это не количественная метрика.
IT>>Гибкость — сложность модификации кода. Как будем квантовать? G>Обратная величина к линейной функции от связности и цикломатической сложности при фиксированном объеме кода.
Формулу не напишешь? Я тебе подскажу два аргумента, например, связность — много, цикломатическая сложность — 25.
IT>>Разная у всех не только сложность понимания, но ещё и обучаемость и предел алгоритмической сложности. Это всё тоже нужно как-то включать в формальное определение. G>Субъективные факторы, типа сложности обучения, лучше не учитывать в формальных выкладках.
Ну да. А может лучше сразу не заниматься такой бесполезной фигнёй как формальные выкладки?
T>>>Это исследование надо проводить, на это я пойтить не могу. IT>>А зря. G>Не очень получится, в зависимости от задачи одни метрики могут быть более приоритетные, чем другие.
Включи в свои формулы приоритетность, в чём проблема?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, thesz, Вы писали:
T>Вот и размен: для Пеано проще доказывать теоремы, работать же лучше с позиционной системой счисления. Обычные программисты предпочитают второе, HOT программисты — первое. "Integers are for sissies!" (C) ироничный J. Shapiro, создатель BitC.
Зашибись! И что?
IT>>Опять же критерий полезности. T>Чуть выше.
IT>>Чего — например, ООП. Можно квантануть до наследования, инкапсуляция, полиморфизм. Какова будет метрика? T>Самое простое — подход а-ля IQ. Создаём большой список вопросов по теме, от простых до сложных, проводим тесты. Метрика понимания — количество отвеченных вопросов за определённое время. Можно ввести вес вопросов.
Во-первых, допустим получишь ты в результате теста число 36 и как ты его дальше будешь сравнивать со строками кода?
Во-вторых, придут индусы и вызубрят все ответы, получат лучшие балы, а знать как не знали так и не будут знать ничего.
IT>>Гибкость — сложность модификации кода. Как будем квантовать? T>Соответственно, гибкость будет обратно пропорциональна количеству ошибок на решение задачи.
Допустим. Теперь надо сравнить число 36, отличное знание ООП индусами и количество ошибок (кстати, о каких ошибках речь? наша задача вроде как писать рабочий код, а не ошибочный).
T>>>А можешь выбросить из рассмотрения, пока не найдёшь. IT>>Не-не-не. Не надо ничего выбрасывать, надо наоборот добавлять. T>Это не мой подход.
Т.е. если функциональное требование не вписывается в твою модель, то выбросить нужно функциональное требование, а не модель?
T>То есть, скорость понимания снижается от уровня сложности задачи. Это можно связать.
Скорость понимания больше всего зависит от знания предметной области. Как будем это связывать?
IT>>>>Интересны количесвенные характеристики каждого вида и функции, с помощью которых их можно было бы привести к единой мере для дальнейших манипуляций. T>>>Это исследование надо проводить, на это я пойтить не могу. IT>>А зря. T>Я разработчик, не когнитивный исследователь.
Пока ты больше похож на отбрасывальщика неустраивающих тебя требований.
T>>>Но в результате всё сведётся к прогнозу времени. IT>>Время — это хорошо, но надо подумать. Есть моменты. T>Это единственный невосполнимый ресурс.
Это не важно. Важнее уменее сравнивать 5 лет обучения в университете против 3 года в ПТУ и как результат 100 строк кода за час против 2000 за месяц на одной задаче.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VGn, Вы писали:
IT>>Ну то есть тёплое с мягким.
VGn>Ну так весь фокус в том, что ты первый начал. VGn>Как тогда понимать твой "закон сохранения"? VGn>Идея вроде: "оно никуда не делось, оно всё где-то тут"? VGn>Ну так аргументируй количественно, раз начал количественные оценки. "Сохранение", "переход" и есть такие количественные оценки.
Количественно не получается, потому что нельзя. Я уже устал это повторять.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет такого закона. Исходное положение неверно. Задача проектирования — уменьшение сложности до минимума. И только так.
Ну допустим. Пока у нас 4 никак не связанных друг с другом предложения.
PD>Вот простой пример.
Пример тоже как-то никак не связан с предыдущим выступлением.
PD>То же самое для видеокарт.
Ну да.
PD>И это не только к программированию относится.
Не спорю.
Можно ворос? Спасибо! А поделу что-нибудь есть сказать?
Мне, например, крайне интересно было бы услышать про случаи, когда применение того или иного инструмента приводит к полному или частичному устранению сложности без побочных эффектов. Я в своё время один такой пример нашёл — pattern matching. Чистое без примесей устранение алгоритмической сложности за счёт декларативности. Но поразмыслив немного в результате я обнаружил другие виды сложности и другие трансформации. Но может быть есть ещё что-то пока недосупное моему ограниченному воображению?
Ещё мне было бы крайне интересно поговорить о метриках сложности. Идея использовать в качестве общего знаменателя для видов сложности время весьма занятна, но пока буксует на месте. Ещё в процессе дискуссии обнаружился ещё один вид сложности — сложность понимания решаемой задачи. Скоро выйдет обновление статьи с этими дополнениями. Вот такие вещи мне было бы крайне интересно с тобой обсудить. А "нет такого закона"... Я прощу прощения у почтенной публики за то, что мне приходится здесь каждого второго тыкать носом в статью, но пожалуй придётся это сделать ещё раз:
Ты статью читал?
Привожу ещё раз цитату специально для тех, кто дальше названия не заглядывал:
По результатам обсуждения статьи выяснилось, что некоторые читатели слишком буквально воспринимают её название, в следствии чего пытаются найти или увидеть в ней формальные определения и доказательства. Такой цели автором не ставилось. Задача статьи рассмотреть виды сложности, лучше понять её природу и неочевидные стороны. Так же хочу всех успокоить, автор вполне осознаёт, что он не открыл новый закон природы, более того, он понимает, что в строго научном смысле такого закона не существует, а выбор заголовка в большей степени обусловлен пристрастием автора к пафосным названиям.
Если нам не помогут, то мы тоже никого не пощадим.
VGn>>Ну так весь фокус в том, что ты первый начал. VGn>>Как тогда понимать твой "закон сохранения"? VGn>>Идея вроде: "оно никуда не делось, оно всё где-то тут"? VGn>>Ну так аргументируй количественно, раз начал количественные оценки. "Сохранение", "переход" и есть такие количественные оценки.
IT>Количественно не получается, потому что нельзя. Я уже устал это повторять.
Здравствуйте, VGn, Вы писали:
IT>>Количественно не получается, потому что нельзя. Я уже устал это повторять.
VGn>Тогда и нечего было эту муть начинать.
Зачем ты тогда влез в эту муть? Видимо всё таки стоило начинать и не такая уж это муть
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, thesz, Вы писали:
T>>Вот и размен: для Пеано проще доказывать теоремы, работать же лучше с позиционной системой счисления. Обычные программисты предпочитают второе, HOT программисты — первое. "Integers are for sissies!" (C) ироничный J. Shapiro, создатель BitC. IT>Зашибись! И что?
Пример "сохранения сложности". Неужто ты не рад?
IT>>>Опять же критерий полезности. T>>Чуть выше. IT>
Ничем не могу помочь.
IT>>>Чего — например, ООП. Можно квантануть до наследования, инкапсуляция, полиморфизм. Какова будет метрика? T>>Самое простое — подход а-ля IQ. Создаём большой список вопросов по теме, от простых до сложных, проводим тесты. Метрика понимания — количество отвеченных вопросов за определённое время. Можно ввести вес вопросов. IT>Во-первых, допустим получишь ты в результате теста число 36 и как ты его дальше будешь сравнивать со строками кода?
Взвешено.
IT>Во-вторых, придут индусы и вызубрят все ответы, получат лучшие балы, а знать как не знали так и не будут знать ничего.
Всё не вызубрят.
IT>>>Гибкость — сложность модификации кода. Как будем квантовать? T>>Соответственно, гибкость будет обратно пропорциональна количеству ошибок на решение задачи. IT>Допустим. Теперь надо сравнить число 36, отличное знание ООП индусами и количество ошибок (кстати, о каких ошибках речь? наша задача вроде как писать рабочий код, а не ошибочный).
В рабочем коде обязательно содержатся ошибки.
Насчёт сравнения — выводи веса.
T>>>>А можешь выбросить из рассмотрения, пока не найдёшь. IT>>>Не-не-не. Не надо ничего выбрасывать, надо наоборот добавлять. T>>Это не мой подход. IT>Т.е. если функциональное требование не вписывается в твою модель, то выбросить нужно функциональное требование, а не модель?
Сперва надо разобраться с моделью попроще, потом переходить к модели сложней.
Так делают все разумные люди.
Сперва надо разобраться без функциональных требований, потом ввести функциональные.
T>>То есть, скорость понимания снижается от уровня сложности задачи. Это можно связать. IT>Скорость понимания больше всего зависит от знания предметной области. Как будем это связывать?
Тестами на знание предметной области а-ля IQ получив численное представление о знании предметной области?
Тем более, что так все и делают: тестируют на собеседовании и отвергают, если не подходит.
IT>>>>>Интересны количесвенные характеристики каждого вида и функции, с помощью которых их можно было бы привести к единой мере для дальнейших манипуляций. T>>>>Это исследование надо проводить, на это я пойтить не могу. IT>>>А зря. T>>Я разработчик, не когнитивный исследователь. IT>Пока ты больше похож на отбрасывальщика неустраивающих тебя требований.
Да. На любом этапе существования любой модели есть вещи, которые она объяснить не может. См. историю науки.
После того, как мы успешно объяснили (создали модель, правильно предсказывающую результат по известным условиям) какую-то часть интересующей нас области, мы можем переходить к объяснению того, что мы объяснить пока не могли.
По-моему, это разумно.
T>>>>Но в результате всё сведётся к прогнозу времени. IT>>>Время — это хорошо, но надо подумать. Есть моменты. T>>Это единственный невосполнимый ресурс. IT>Это не важно. Важнее уменее сравнивать 5 лет обучения в университете против 3 года в ПТУ и как результат 100 строк кода за час против 2000 за месяц на одной задаче.
Проводи исследования и вводи веса.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Маленькое дополнение. То, что ты называешь IQ-сложностью стоит разделить на два вида:
1) Алгоритмическая сложность. Т.е. сложность логики, алгоритмов. Она, собственно, напрямую определяется той логикой, которая в итоге реализуется программой.
2) Структурная сложность. Т.е. сложность архитектуры программы, структуры обрабатываемых данных, сложности, количества и противоречивости требований.
Это разделение мне кажется важным, потому что, не смотря на определенную связь между первым и вторым видом, инструменты для борьбы все таки разные. Скажем, большинство техник структурного программирования и ФП направлены на первый вид, а вот ООП, КОП — на второй. Именно поэтому ООП и ФП, КОП и ФП вобщем то ортогональны друг другу, а вот ФП и структурное программирование, ООП и КОП уже не очень.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Маленькое дополнение. То, что ты называешь IQ-сложностью стоит разделить на два вида: AVK>1) Алгоритмическая сложность. Т.е. сложность логики, алгоритмов. Она, собственно, напрямую определяется той логикой, которая в итоге реализуется программой. AVK>2) Структурная сложность. Т.е. сложность архитектуры программы, структуры обрабатываемых данных, сложности, количества и противоречивости требований.
Пожалуй это будет тем самым недостающим кирпичиком
Если нам не помогут, то мы тоже никого не пощадим.
IT>>>Количественно не получается, потому что нельзя. Я уже устал это повторять.
VGn>>Тогда и нечего было эту муть начинать.
IT>Зачем ты тогда влез в эту муть? Видимо всё таки стоило начинать и не такая уж это муть
А как назвать утверждения, подтвердить которые автор не может в принципе? Причём ещё и сам об этом заявляет. Или тебе о верности твоих гипотез напели звёзды?
Здравствуйте, VGn, Вы писали:
IT>>Зачем ты тогда влез в эту муть? Видимо всё таки стоило начинать и не такая уж это муть
VGn>А как назвать утверждения, подтвердить которые автор не может в принципе? Причём ещё и сам об этом заявляет. Или тебе о верности твоих гипотез напели звёзды?
Вопросом на вопрос отвечать не прилично. Вообще же мы общаемся, если ты не заметил, в форуме "Философия программирования" и обсуждаем здесь всякую чушь, которую практически никогда нельзя ни доказать, ни опровергнуть формально. Есть вещи, которые в принципе нельзя описать формально, но они ещё как влияют на процесс разработки. Тебе их перечислить? Вот немногие из них: интуиция, озарение, талант, лень, ответственность, опыт, уровень образования, удача, усталось, комфортные условия работы. Формулу не применить, тебе уже не интересно? А мне интересно как всё это влияет на процесс разработки. Учитывая, что управление сложностью — это ключевой момент в разработке софта, то понимание структуры сложности, внутренних механизмов и влияния на код, для меня является гораздо важнее, чем формулы для вычисления абстрактных попугаев.
Если завтра будет холодно, скажем 5-10 С, ты просто оденешься потеплее или будешь до посинения требовать более точного числа для принятия решения, скажем до сотой градуса? А если ещё и дождик будет моросить, тебя будет интересовать сколько точно накапает в пробирки метеорологов или может просто взять зонтик и одним махом решить проблему?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Юрий Жмеренецкий, Вы писали:
ЮЖ>Но это не имеет отношения к пониманию. Но, например, к языку программирования имеет — поскольку он является средством выражения описания объекта(в оригинале — двоичных строк). Для разных описаний сложность отличается не более чем на константу, под которой можно понимать "длину" транслятора(т.е. размер кода) с одного языка на другой.
Почему же не имеет отношения к пониманию ? У человека мозг устроет определенным образом, описание состоящее более чем 7-9 эл-тов просто отказывается воспринимать. Соотвественно нужно наращивать абстракции что бы удержать описание в этих пределах.
Здравствуйте, VladD2, Вы писали:
VD>Твое суждение было "любой (абсолютно) инструмент может быть использован как во благо, так и совсем наоборот...". Если уж строить аналогии, которые в прочем не уместны, то про автомобили нужно было писать "автомобиль может быть использован как по делу, так и не эффективно, например в соседний ларёк ездить за пивом на авто не эффективно".
VD>В таком же, извращенном, виде — это высказывание принципиально ложно, так как нарушает базовые законы логики.
Высказывание "любой (абсолютно) инструмент может быть использован как во благо, так и совсем наоборот..." не ложно, оно принципиально истинно
Можно всю строку заменить заменить на true или хоть на коня в вакууме — ничего не изменится
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, VGn, Вы писали:
IT>>> Видимо всё таки стоило начинать и не такая уж это муть VGn>> Или тебе о верности твоих гипотез напели звёзды?
IT>Вообще же мы общаемся, если ты не заметил, в форуме "Философия программирования" и обсуждаем здесь всякую чушь, которую практически никогда нельзя ни доказать, ни опровергнуть формально.
Не все чушь оформляют в статьи.
IT>Есть вещи, которые в принципе нельзя описать формально, но они ещё как влияют на процесс разработки. Тебе их перечислить? Вот немногие из них: интуиция, озарение, талант, лень, ответственность, опыт, уровень образования, удача, усталось, комфортные условия работы.
Такие вещи принимают во внимание, а не формулируют законы сохранения лени
и однозначного преобразования удачи в другие виды
IT> Учитывая, что управление сложностью — это ключевой момент в разработке софта, то понимание структуры сложности, внутренних механизмов и влияния на код, для меня является гораздо важнее, чем формулы для вычисления абстрактных попугаев.
Без весовых характеристик анализ структуры никому не нужен.
Но это тебе уже и без меня объяснили.
IT>Если завтра будет холодно, скажем 5-10 С, ты просто оденешься потеплее или будешь до посинения требовать более точного числа для принятия решения, скажем до сотой градуса?
5-10 С — уже количественный диапазон. Оценив его я надену осеннюю куртку, а не ватник или футболку.
IT>А если ещё и дождик будет моросить, тебя будет интересовать сколько точно накапает в пробирки метеорологов или может просто взять зонтик и одним махом решить проблему?
Бывает такой дождик, который мне абсолютно по**й. Выгляну в окно и оценю качественно, как может развиться погода.
Может там вообще ураган назревает.
Здравствуйте, IT, Вы писали:
IT>Скоро выйдет обновление статьи с этими дополнениями.
Мне кажется полезно будет обозначить сложности, которые тут накопали символами (напр. Sm — сложность модели, So — сложность обьекта, Sr — сложность решения, и т.д.). Чтоб не путаться. Также формально написать зависимости "больше", "меньше", "равно сумме".
Также разделить две задачи — уменьшение и перераспределение сложности. (не путать!!)
IT>Ещё мне было бы крайне интересно поговорить о метриках сложности. Идея использовать в качестве общего знаменателя для видов сложности время весьма занятна, но пока буксует на месте.
Для того, чтобы колличественно сравнить разные виды сложности не нужно "разноцветные попугаи сложности" переводить в один цвет.
Курс можно вивести статистически, я ж написал. И не заморачиваться внутренними причинами откуда какой коефициент появился и почему "8.42 часов написания раздутого быдлокода равно 1 часу обучения правильному программированию"
IT>в строго научном смысле такого закона не существует
Существует в строго научном. Есть минимальный обьем знаний, который вмещает модель. В процессе построения решения, ети знания трансформируются в различные сложности. В каких пропорциях — зависит от программиста. Рефакторинг в большей степени направлен на уменьшение сложности, в меньшей — на перераспределение. Но минимальная сложность решения сохраняется.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
G>>Вот эти 3 метрики + количество строк кода дают вполне пригодную оценку "качества кода", при минимизации метрик качество растет.
IT>Ну допустим мы получили три числа: 25, 42 и 18. Что с ними дальше делать?
Хочется уточнить, какая именно задача стоит:
1) уменшить сложность
2) перераспределить сложность
3) оценить насколько сложность решения выше минимальной
Простой пример. Есть "индусский" код.
Измерили "колличественную сложность" СКол, "сложность восприятия" СВоспр
СКол = 50
СВоспр = 10
Можно просто почистить явные дублирования, будет СКол = 40, СВоспр = 10 (уменьшение сложности)
Можно переделать решение на трех-етажных шаблонах, будет СКол = 10, СВоспр = 80 (перераспределение сложности)
Переводим все колличества сложностей решения в АПС, суммируем и получаем сложность конкретного кода в АПС. Можно смело сравнивать со сложностью другого кода, решающего ту же задачу. Лучше код, у которого сложность ниже.
А вот как "оценить насколько сложность решения выше минимальной" — отдельная тема...
Наверно надо найти способ колличественно измерить сложность самой модели решения (колл. понятий, зависимостей)...
Хотя есть еще нюанс — сложность можно засунуть в инструмент (напр. использовать библиотечный алгоритм). Но вот вопрос — как в общем случае количественно оценить, сколько единиц сложности модели можно засунуть в используемые инструменты.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, thesz, Вы писали:
T>>Ещё раз: все контексты поддаются описанию. Вне зависимости от их природы.
I>Поддаются, но не существует языка в которым можно описать любой контекст.
Тем не менее, существует язык, в котором можно описать любое выбранное множество.
Это важней.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
I>>Поддаются, но не существует языка в которым можно описать любой контекст.
T>Тем не менее, существует язык, в котором можно описать любое выбранное множество.
Здравствуйте, gandjustas, Вы писали:
G>Также из студии можно использовать полезные вещи, такие как "цикломатическая сложность" и "свзяность классов". G>Причем имеют смысл эти метрики на строку кода по всему проекту. G>Вот эти 3 метрики + количество строк кода дают вполне пригодную оценку "качества кода", при минимизации метрик качество растет.
IT>>Гибкость — сложность модификации кода. Как будем квантовать? G>Обратная величина к линейной функции от связности и цикломатической сложности при фиксированном объеме кода. G>Гибкость падает при увеличении количества строк и константных других параметров.
На количество строк делить конечно надо, или как-то учитывать.
Но все же подобные количественные метрики имеют смысл только с учетом здравого смысла. А чем больше арифметических преобразований над ними проделано тем меньше возможностей применить здравый смысл. Потому что эти преобразования грубое приближение.
---------------
Class Coupling:
(именно из студии а не вобще связности разные)
Считает связи у каждого класса, а затем для всего кода считается как объединение множеств.Со всеми вытекающими последствиями...
При фиксированном обьеме кода,если один и то-то же код модифицируем. Увеличение показателя Class Coupling всего кода, увеличивает читабельность кода и качество кода... но так продолжается до точки оптимума затем качество наоборот уменьшается.
Если взять уже оптимальный код, все классы объединить в один класс (там где это возможно), то этот показатель СС из студии уменьшится (нет классов нет и CC), а качество резко упадет.
Если разбиваем сложный смешанный класс на два простых по ответственностям, для повышения читабельности. То студийный CC для всего кода увеличится на 1. Т.е. это увеличение качества вместе с CC.
Но увеличение CC выше оптимума начинает ухудшть код.
Связь CC с качеством чисто статистическая,слабая, зашумленная случайными отклонениями. Случайный шум здесь из-за неучтенных факторов. Но связь есть, она прямая до точки оптимума, после нее обратная.
Т.е. тоже в очень грубом приближении но в более близком, качество определяется не абсолютным значением студийного CC а величиной(обратной) его отклонения от оптимума в любою сторону.
Интереснее было бы смотреть такой CC между двумя частями проекта. Т.е. возможность фильтровать связи, в том числе например учитывать связи с классами стандартной библиотеки или нет.
--------------
Цикломатическая сложность:
Для блока кода(функция класс,namespase,project) cуммируется общее количество if,"?:",циклов, функций(статических,обычных,конструкторов), проопертей. Причем у пропертей get,set считаются отдельно(добавляют сразу 2).
Т.е. пустой класс с 10 пустыми пропертями int prop{get;set;} дает цикломатическую сложность 21 (1 конструктор и по 2 на каждый prop). Функция с 20 вложенными циклами даст тоже 21. Там где можно считать что это одно и тоже(10 пропертей против 20 циклов), там можно этот показатель и использовать.
Если сложную функцию разбить для простоты на 3 функции, цикл.слож. увеличится на 2. Хотя разбивали то для снижения сложности.
Связь прямая до оптимума, после него обратная.
Чем больше функций в коде тем код качественнее, читабельнее (при том же объеме,с тем же поведением в рантайм). После точки оптимума наоборот чем больше функций тем код хуже. Тоже связь статистическая зашумленная неучтенными факторами.
Количество if и циклов может показывать не столько качество, сколько тип кода. Если нужнно много циклов в алгоритмах их не так-то просто убрать. Ну в обработке коллекций, циклы на Linq выражения заменить конечно можно, но .... Нельзя сказать что программа некачественная потому что слишком много if,for.
А если просуммировать количество циклов и функций(как делает цикл. слож.) то что в результате получится? Количество функций связано с качеством совсем другой зависимостью, чем количество if,for.
MaintainabiltyIndex замученый арифметическимми преобразованиями уже не понятно что показывает и как им пользоваться.
--------------
Лучше бы студия отдельно все считала, отдельно циклы, отдельно функции,отдельно if'ы, ...
А потом показывала бы красивые картинки, диаграммы. Какие-то диаграммы распределения функций по числу вызовов, по размеру функции, классов по числу членов, по соотношению числа приватных и публичных членов... Эти картинки хоть можно принять к сведению будет, какая то инфа о характере кода.
И желательна возможность написания своих скриптов для получения суммарных показателей.
А для связей между классами какие-то картинки где бы была видна кластеризация, и чтобы сотни классов на одной картинке было видно, но это уже сложно.
Еще можно было бы подсчитывать показатель объема повторной используемости функций. Т.е. взять число IL инструкций программы, затем все функции условно подставить(распаковать) в точку вызова, и вычислить на сколько процентов вырастет число инструкций. Когда функция вызывается из одного места, то повторной используемости нет, ее могли выделить только для уменьшения сложности. А когда большая функция вызывается из разных 10 мест, то это уже совсем другое...
При изучении незнакомого кода, например откуда-то скачанного. Полезно сначала посмотреть на метрики, но хотелось бы чего то посерьезнее чем сейчас в студии.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, thesz, Вы писали:
I>>>Поддаются, но не существует языка в которым можно описать любой контекст.
T>>Тем не менее, существует язык, в котором можно описать любое выбранное множество.
I>Расскажи про него.
Берем язык L. Берем контекст, который им описан быть не может. Добавляем в L конструкции по описанию контекста, получаем L'.
Таким образом мы можем сконструировать язык для описания любого набора контекстов.
Вуаля.
Вопрос упрощения работы с этим языком — сжатия множества описаний в более короткое представление, — является отдельной стоящей задачей.
Кстати, так обычно и поступают: добавляют в язык конструкции, потом упрощают. См. историю развития языка математики, физики и прочих наук.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
I>>Расскажи про него.
T>Берем язык L. Берем контекст, который им описан быть не может. Добавляем в L конструкции по описанию контекста, получаем L'.
T>Таким образом мы можем сконструировать язык для описания любого набора контекстов.
Ну да, не хватает только волшебной палочки.
Теоретически это и ежу ясно. На практике — возможности человека очень сильно ограничены. Меня интересует именно практика и решение хочется получить скажем, если не завтра, то в следуюещем году, ждать две-три тысячи лет как с математикой как то скучновато.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, thesz, Вы писали:
I>>>Расскажи про него.
T>>Берем язык L. Берем контекст, который им описан быть не может. Добавляем в L конструкции по описанию контекста, получаем L'.
T>>Таким образом мы можем сконструировать язык для описания любого набора контекстов. I>Ну да, не хватает только волшебной палочки.
I>Теоретически это и ежу ясно. На практике — возможности человека очень сильно ограничены. Меня интересует именно практика и решение хочется получить скажем, если не завтра, то в следуюещем году, ждать две-три тысячи лет как с математикой как то скучновато.
Ты, что, никогда не описывал то, что никогда раньше не встречал?
Ты с самого рождения знал всё на свете?
Если нет, не знал и да, описывал, то у тебя есть такой опыт.
Поэтому бери свою собственную волшебную палочку и используй её, скажем, завтра. Нечего до следующего года ждать.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, gandjustas, Вы писали:
G>>Также из студии можно использовать полезные вещи, такие как "цикломатическая сложность" и "свзяность классов". G>>Причем имеют смысл эти метрики на строку кода по всему проекту. G>>Вот эти 3 метрики + количество строк кода дают вполне пригодную оценку "качества кода", при минимизации метрик качество растет.
IT>>>Гибкость — сложность модификации кода. Как будем квантовать? G>>Обратная величина к линейной функции от связности и цикломатической сложности при фиксированном объеме кода. G>>Гибкость падает при увеличении количества строк и константных других параметров.
S_> На количество строк делить конечно надо, или как-то учитывать. S_> Но все же подобные количественные метрики имеют смысл только с учетом здравого смысла. А чем больше арифметических преобразований над ними проделано тем меньше возможностей применить здравый смысл. Потому что эти преобразования грубое приближение.
S_>--------------- S_>Class Coupling: S_>(именно из студии а не вобще связности разные) S_>Считает связи у каждого класса, а затем для всего кода считается как объединение множеств.Со всеми вытекающими последствиями... S_>При фиксированном обьеме кода,если один и то-то же код модифицируем. Увеличение показателя Class Coupling всего кода, увеличивает читабельность кода и качество кода... но так продолжается до точки оптимума затем качество наоборот уменьшается.
S_> Если взять уже оптимальный код, все классы объединить в один класс (там где это возможно), то этот показатель СС из студии уменьшится (нет классов нет и CC), а качество резко упадет. S_>Если разбиваем сложный смешанный класс на два простых по ответственностям, для повышения читабельности. То студийный CC для всего кода увеличится на 1. Т.е. это увеличение качества вместе с CC. S_>Но увеличение CC выше оптимума начинает ухудшть код. S_> Связь CC с качеством чисто статистическая,слабая, зашумленная случайными отклонениями. Случайный шум здесь из-за неучтенных факторов. Но связь есть, она прямая до точки оптимума, после нее обратная. S_> Т.е. тоже в очень грубом приближении но в более близком, качество определяется не абсолютным значением студийного CC а величиной(обратной) его отклонения от оптимума в любою сторону.
Это надо брать очень маленький изолированный кусок кода чтобы стабильно получать такой эффект. Если мерять по всему проекту, то запихивание всего в один класс приведет к дублированию кода (увеличению количества строк) и увеличению цикломатической сложности.
S_>-------------- S_>Цикломатическая сложность: S_> Для блока кода(функция класс,namespase,project) cуммируется общее количество if,"?:",циклов, функций(статических,обычных,конструкторов), проопертей. Причем у пропертей get,set считаются отдельно(добавляют сразу 2). S_>Т.е. пустой класс с 10 пустыми пропертями int prop{get;set;} дает цикломатическую сложность 21 (1 конструктор и по 2 на каждый prop). Функция с 20 вложенными циклами даст тоже 21. Там где можно считать что это одно и тоже(10 пропертей против 20 циклов), там можно этот показатель и использовать.
S_> Если сложную функцию разбить для простоты на 3 функции, цикл.слож. увеличится на 2. Хотя разбивали то для снижения сложности.
А повторное использование таких функций даст уменьшение кода и цикломатической сложности для всего проекта.
S_>Связь прямая до оптимума, после него обратная. S_>Чем больше функций в коде тем код качественнее, читабельнее (при том же объеме,с тем же поведением в рантайм). После точки оптимума наоборот чем больше функций тем код хуже. Тоже связь статистическая зашумленная неучтенными факторами.
Опять чтобы получать стабильно такой эффект надо мерить очень маленький изолированный кусок кода.
S_> Количество if и циклов может показывать не столько качество, сколько тип кода. Если нужнно много циклов в алгоритмах их не так-то просто убрать. Ну в обработке коллекций, циклы на Linq выражения заменить конечно можно, но .... Нельзя сказать что программа некачественная потому что слишком много if,for.
S_>А если просуммировать количество циклов и функций(как делает цикл. слож.) то что в результате получится? Количество функций связано с качеством совсем другой зависимостью, чем количество if,for. S_>MaintainabiltyIndex замученый арифметическимми преобразованиями уже не понятно что показывает и как им пользоваться.
А кто вообще сказал что mantainability index == качество кода? Его стоит понимать буквально — как некий показатель сложности поддержки кода. Причем он имеет смысл только для всего проекта, а не для отдельных кусков.
Для качества нужна другая метрика, но она вероятнее всего будет состоять из тех-же компонент: строки, связность итп, только в совершенно другой зависимости.
Здравствуйте, gandjustas, Вы писали:
G>Это надо брать очень маленький изолированный кусок кода чтобы стабильно получать такой эффект. Если мерять по всему проекту, то запихивание всего в один класс приведет к дублированию кода (увеличению количества строк) и увеличению цикломатической сложности.
Ну пусть даже и не всего. Взять все классы не наследующиеся от базовых поставить на них partial и переименовать к одному имени.(плюс мелкие детали пофиксить). Class Coupling уменьшится в результате такого эксперимента. Цикл.сложн. не изменится. Вместо кучи мелких классов получится один жирный. Который может все если попросить, и может использоваться вместо каждого из мелких. Метрики никак не отреагируют на такое извращение, а если и отреагируют то намекнут на улучшение кода. Извращения метрики даже поощряют (если их интерпретировать как метрики качества).
S_>> Если сложную функцию разбить для простоты на 3 функции, цикл.слож. увеличится на 2. Хотя разбивали то для снижения сложности. G>А повторное использование таких функций даст уменьшение кода и цикломатической сложности для всего проекта.
Если повторное использование удастся, то да.
S_>>Связь прямая до оптимума, после него обратная. S_>>Чем больше функций в коде тем код качественнее, читабельнее (при том же объеме,с тем же поведением в рантайм). После точки оптимума наоборот чем больше функций тем код хуже. Тоже связь статистическая зашумленная неучтенными факторами.
G>Опять чтобы получать стабильно такой эффект надо мерить очень маленький изолированный кусок кода.
Ну если во всем проекте все функции вызывающиеся из одного места в коде (были разбиты на отдельные функции только для упрощения) подставить в точку вызова(раскрыть) то могут и огромные нечитабельные функции возникнуть при уменьшении Ц.Слож.
Конечно никто специально так не хулиганит. Но все же цикл.слож больше меряет количество кода, но более крупными объектами, чем строки. А не качество,простоту.
G>А кто вообще сказал что mantainability index == качество кода? Его стоит понимать буквально — как некий показатель сложности поддержки кода. Причем он имеет смысл только для всего проекта, а не для отдельных кусков.
Но то как он усредняется для всех классов любых размеров, как среднее арифметическое, сильно его портит.
G>Для качества нужна другая метрика, но она вероятнее всего будет состоять из тех-же компонент: строки, связность итп, только в совершенно другой зависимости.
Да но она не простая получится.
Здравствуйте, VGn, Вы писали:
IT>>Вообще же мы общаемся, если ты не заметил, в форуме "Философия программирования" и обсуждаем здесь всякую чушь, которую практически никогда нельзя ни доказать, ни опровергнуть формально.
VGn>Не все чушь оформляют в статьи.
И не говори, большинство оформляет чушь в чушь.
IT>>Есть вещи, которые в принципе нельзя описать формально, но они ещё как влияют на процесс разработки. Тебе их перечислить? Вот немногие из них: интуиция, озарение, талант, лень, ответственность, опыт, уровень образования, удача, усталось, комфортные условия работы.
VGn>Такие вещи принимают во внимание, а не формулируют законы сохранения лени VGn>и однозначного преобразования удачи в другие виды
И до этого очередь дойдёт. Есть у меня одно интересное наблюдение, в том числе и в этой теме, которое всё больше и больше тянет на закон.
IT>> Учитывая, что управление сложностью — это ключевой момент в разработке софта, то понимание структуры сложности, внутренних механизмов и влияния на код, для меня является гораздо важнее, чем формулы для вычисления абстрактных попугаев.
VGn>Без весовых характеристик анализ структуры никому не нужен. VGn>Но это тебе уже и без меня объяснили.
Мне нужен. Более того, весовые характеристики, которые тут пытаются объяснять точно нафиг никому не нужны. Проку от них ноль, а неокрепшие умы способны запутать окончательно.
IT>>Если завтра будет холодно, скажем 5-10 С, ты просто оденешься потеплее или будешь до посинения требовать более точного числа для принятия решения, скажем до сотой градуса? VGn>5-10 С — уже количественный диапазон. Оценив его я надену осеннюю куртку, а не ватник или футболку.
Это ты расскажи кому-нибудь другому. А в 6-11 ты что оденешь? А в 4-9? И где грань? 4.52 или 10.46? Этот диапазон ты автоматически даже не напрягаясь переведёшь в тепло, холодно или теплее, холоднее. Холодно для футболки, тепло для фуфайки. На самом деле в прогнозе было бы вообще достаточно сказать, что будт немногим выше 0. И всё. Для принятия решения этого достаточно.
IT>>А если ещё и дождик будет моросить, тебя будет интересовать сколько точно накапает в пробирки метеорологов или может просто взять зонтик и одним махом решить проблему?
VGn>Бывает такой дождик, который мне абсолютно по**й. Выгляну в окно и оценю качественно, как может развиться погода. VGn>Может там вообще ураган назревает.
Т.е. количественные характеристики для принятия решения тебе не нужны? Что и требовалось доказать.
VGn>Так что не сработали твои аналогии.
Как раз наоборот. Ты сам продемонстрировал полную бесполезность и бессмысленность своей теории метрик.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, gandjustas, Вы писали:
G>>Это надо брать очень маленький изолированный кусок кода чтобы стабильно получать такой эффект. Если мерять по всему проекту, то запихивание всего в один класс приведет к дублированию кода (увеличению количества строк) и увеличению цикломатической сложности.
S_> Ну пусть даже и не всего. Взять все классы не наследующиеся от базовых поставить на них partial и переименовать к одному имени.(плюс мелкие детали пофиксить). Class Coupling уменьшится в результате такого эксперимента. Цикл.сложн. не изменится. Вместо кучи мелких классов получится один жирный. Который может все если попросить, и может использоваться вместо каждого из мелких. Метрики никак не отреагируют на такое извращение, а если и отреагируют то намекнут на улучшение кода. Извращения метрики даже поощряют (если их интерпретировать как метрики качества).
Посмотрел свои проекты, количество таких классов незаметно отличается от нуля.
S_>>> Если сложную функцию разбить для простоты на 3 функции, цикл.слож. увеличится на 2. Хотя разбивали то для снижения сложности. G>>А повторное использование таких функций даст уменьшение кода и цикломатической сложности для всего проекта. S_> Если повторное использование удастся, то да.
Разбиение кода на мелкие независимые части повышает вероятность повторного использования. (что вообще говоря увеличивает качество кода).
S_>>>Связь прямая до оптимума, после него обратная. S_>>>Чем больше функций в коде тем код качественнее, читабельнее (при том же объеме,с тем же поведением в рантайм). После точки оптимума наоборот чем больше функций тем код хуже. Тоже связь статистическая зашумленная неучтенными факторами.
G>>Опять чтобы получать стабильно такой эффект надо мерить очень маленький изолированный кусок кода. S_> Ну если во всем проекте все функции вызывающиеся из одного места в коде (были разбиты на отдельные функции только для упрощения) подставить в точку вызова(раскрыть) то могут и огромные нечитабельные функции возникнуть при уменьшении Ц.Слож.
Это если не используется полиморфизм и функциональная композиция.
S_> Конечно никто специально так не хулиганит. Но все же цикл.слож больше меряет количество кода, но более крупными объектами, чем строки. А не качество,простоту.
Никто обратного и не утверждал.
G>>А кто вообще сказал что mantainability index == качество кода? Его стоит понимать буквально — как некий показатель сложности поддержки кода. Причем он имеет смысл только для всего проекта, а не для отдельных кусков. S_> Но то как он усредняется для всех классов любых размеров, как среднее арифметическое, сильно его портит.
Ничего не портит. Еще раз: mantainability index — некоторый показатель сложности поддержки кода (с качетсвом корелляция очень слабая). Большой качественный код поддерживать сложнее, чем маленький и некачественный.
Здравствуйте, gandjustas, Вы писали:
G>>>А кто вообще сказал что mantainability index == качество кода? Его стоит понимать буквально — как некий показатель сложности поддержки кода. Причем он имеет смысл только для всего проекта, а не для отдельных кусков. S_>> Но то как он усредняется для всех классов любых размеров, как среднее арифметическое, сильно его портит. G>Ничего не портит. Еще раз: mantainability index — некоторый показатель сложности поддержки кода (с качетсвом корелляция очень слабая). Большой качественный код поддерживать сложнее, чем маленький и некачественный.
Разберем по косточкам.
Во первых ляп, то что mantainability index считается и для enum,delegate,interface для них всегда он равен 100, на уровне всего проекта эти штуки учавствуют в усреднении наравне с классами. Что приводит к случайному результату. Если проект такой где много enum то они исказят результат.
Но даже если есть только классы одинаковой крупности.
Maintainability Index = 100 — (3.04*Ln(Halstead Volume) + 0.134* (Cyclomatic Complexity) + 9.47*Ln(Lines of Code) )
С обрезанием ниже нуля.
Выражение в скобках это получается сложность поддержки. Также можно сказать судя по формуле это мера количества кода, но более сбалансированная как-то, логарифмы даже берут от строк. Halstead Volume — тоже количество кода, с учетом операндов и др. фичей.
Он как бы показывает накопление сложности при накоплении объема кода.
На уровне функции вроде все нормально. На уровне класса, как они делают не говорят, но не просто среднее арифметическое по функциям, и результат похож на правду. Но на уровне проекта совсем по-другому.
Так вот, когда начинаем усреднять такую сложность поддержки в проекте по классам. Значит уже отказываемся от того что при накоплении числа классов сложность поддержки будет расти. Внутри класса накапливается, а дальше нет. Из-за инкапсуляции внутри классов такой эффект может наблюдаться, но он уж не такой резкий.
Проблема именно в слишком резком разделении.
Причем внутри класса также подсчет делается усреднением сложности функций а не накоплением. Просто это усреднение улучшенное, а не просто ср. арифметическое(как на уровне проекта). Например только одна функция в классе со сложностью 50%, то и класс будет сложностью поддержки около 50%. Если еще 1000 таких функций добавить у каждой по 50%, показатель сложности класа не изменится.
Так что на уровне проекта этот Maintainability Index не является интегрированным показателем учитывающим множество факторов,
а фактически показывает усредненный размер функций в проекте. Хотя и размер не в строках, а сбалансированный. Но суть то не меняется.
Здравствуйте, thesz, Вы писали:
I>>Теоретически это и ежу ясно. На практике — возможности человека очень сильно ограничены. Меня интересует именно практика и решение хочется получить скажем, если не завтра, то в следуюещем году, ждать две-три тысячи лет как с математикой как то скучновато.
T>Ты, что, никогда не описывал то, что никогда раньше не встречал?
9. Принцип соответствия.
Язык описания сложной системы должен соответствовать характеру располагаемой о ней информации (уровню знаний или неопределенности). Точные логико-математические, синтаксические модели не являются универсальным языком, также важны нестрогие, приближенные, семиотические модели и неформальные методы. Один и тот же объект может описываться семейством языков различной жесткости [Налимов, 1979].
T>Ты с самого рождения знал всё на свете? T>Если нет, не знал и да, описывал, то у тебя есть такой опыт.
Целые институты работают и не могут описать многие проблемы и на это уходят даже не годы, а десятилетия.
Здравствуйте, Silver_s, Вы писали:
S_> Ну пусть даже и не всего. Взять все классы не наследующиеся от базовых поставить на них partial и переименовать к одному имени.(плюс мелкие детали пофиксить). Class Coupling уменьшится в результате такого эксперимента. Цикл.сложн. не изменится. Вместо кучи мелких классов получится один жирный. Который может все если попросить, и может использоваться вместо каждого из мелких. Метрики никак не отреагируют на такое извращение, а если и отреагируют то намекнут на улучшение кода. Извращения метрики даже поощряют (если их интерпретировать как метрики качества).
Ну потому что все упирается в то, насколько грамотно соблюдается SRP. А вот к нему метрики придумать непросто, потому что сама responsibility штука не особо формализуемая.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
AndrewVK wrote:
> Ну потому что все упирается в то, насколько грамотно соблюдается SRP. > А вот к нему метрики придумать непросто, потому что сама > responsibility штука не особо формализуемая.
Соблюдение SRP хорошо коррелирует с высоким cohesion, как и обратное — а
все виды cohesion вычисляются по формулам
Здравствуйте, mazurkin, Вы писали: M>AndrewVK wrote:
>> Ну потому что все упирается в то, насколько грамотно соблюдается SRP. >> А вот к нему метрики придумать непросто, потому что сама >> responsibility штука не особо формализуемая.
M>Соблюдение SRP хорошо коррелирует с высоким cohesion, как и обратное — а M>все виды cohesion вычисляются по формулам
А тулзы какие нибудь существуют? Которые могли бы сказать этот класс надо рзбить на 2 части — в первой части, такие фунции и мемберы, во второй части такие. Не обязательно чтобы сами разбивали, хотя бы указали такой класс.
Здравствуйте, mazurkin, Вы писали:
M>Соблюдение SRP хорошо коррелирует с высоким cohesion, как и обратное — а M>все виды cohesion вычисляются по формулам
Проблема только в том, что SRP это не просто cohesion, а баланс между cohesion и coupling. И вот этот баланс как раз таки слабо формализуем.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, thesz, Вы писали:
I>>>Теоретически это и ежу ясно. На практике — возможности человека очень сильно ограничены. Меня интересует именно практика и решение хочется получить скажем, если не завтра, то в следуюещем году, ждать две-три тысячи лет как с математикой как то скучновато.
T>>Ты, что, никогда не описывал то, что никогда раньше не встречал?
I>
I>9. Принцип соответствия.
I>Язык описания сложной системы должен соответствовать характеру располагаемой о ней информации (уровню знаний или неопределенности). Точные логико-математические, синтаксические модели не являются универсальным языком, также важны нестрогие, приближенные, семиотические модели и неформальные методы. Один и тот же объект может описываться семейством языков различной жесткости [Налимов, 1979].
Кто сей есть?
T>>Ты с самого рождения знал всё на свете? T>>Если нет, не знал и да, описывал, то у тебя есть такой опыт.
I>Целые институты работают и не могут описать многие проблемы и на это уходят даже не годы, а десятилетия.
Тогда тебе остаётся сидеть на попе, сидеть ровно.
Я не пойму, тебе шашечки, или ехать?
Если ехать, то ты всю свою жизнь описывал неописуемые контексты. Если шашечки, то жди десятилетия без надежды.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Я не пойму, тебе шашечки, или ехать?
T>Если ехать, то ты всю свою жизнь описывал неописуемые контексты. Если шашечки, то жди десятилетия без надежды.
Теоретически описать можно что угодно. Практически — то что сейчас школьники изучают в школе люди описывали более двух тысяч лет.
Цитирую себя "ждать две-три тысячи лет как с математикой как то скучновато."
Итого — "все контексты поддаются описанию. Вне зависимости от их природы." есть бред. высказываение из ряда абсолютных истин
Контексты описываются, только время описания в общем случае стремится к бесконечности.
Здравствуйте, IT, Вы писали:
IT>Можно ворос? Спасибо! А поделу что-нибудь есть сказать?
По делу есть сказать именно то, что сказано. Не желающим это понять ничем не поможешь.
IT>Мне, например, крайне интересно было бы услышать про случаи, когда применение того или иного инструмента приводит к полному или частичному устранению сложности без побочных эффектов. Я в своё время один такой пример нашёл — pattern matching. Чистое без примесей устранение алгоритмической сложности за счёт декларативности. Но поразмыслив немного в результате я обнаружил другие виды сложности и другие трансформации. Но может быть есть ещё что-то пока недосупное моему ограниченному воображению?
Я тебе привел примеры, но они тебя не устраивают. О чем тогда говорить ?
IT>Ещё мне было бы крайне интересно поговорить о метриках сложности. Идея использовать в качестве общего знаменателя для видов сложности время весьма занятна, но пока буксует на месте. Ещё в процессе дискуссии обнаружился ещё один вид сложности — сложность понимания решаемой задачи. Скоро выйдет обновление статьи с этими дополнениями. Вот такие вещи мне было бы крайне интересно с тобой обсудить. А "нет такого закона"... Я прощу прощения у почтенной публики за то, что мне приходится здесь каждого второго тыкать носом в статью, но пожалуй придётся это сделать ещё раз:
IT>Ты статью читал?
Читал, читал.
IT>Привожу ещё раз цитату специально для тех, кто дальше названия не заглядывал:
IT>[q] IT>По результатам обсуждения статьи выяснилось, что некоторые читатели слишком буквально воспринимают её название, в следствии чего пытаются найти или увидеть в ней формальные определения и доказательства. Такой цели автором не ставилось. Задача статьи рассмотреть виды сложности, лучше понять её природу и неочевидные стороны. Так же хочу всех успокоить, автор вполне осознаёт, что он не открыл новый закон природы, более того, он понимает, что в строго научном смысле такого закона не существует, а выбор заголовка в большей степени обусловлен пристрастием автора к пафосным названиям.
Да, насчет пафоса я как-то пропустил. Ну что же, спишем все это на пафос автора и закроем тему.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, thesz, Вы писали:
T>>Я не пойму, тебе шашечки, или ехать?
T>>Если ехать, то ты всю свою жизнь описывал неописуемые контексты. Если шашечки, то жди десятилетия без надежды. I>Теоретически описать можно что угодно. Практически — то что сейчас школьники изучают в школе люди описывали более двух тысяч лет.
Да. А описание того, что сейчас изучают те, кто когда-то изобретали описание для школьников — лучшие умы человечества, — появилось в течении последних лет пятидесяти.
I>Цитирую себя "ждать две-три тысячи лет как с математикой как то скучновато."
Так не жди. Решай свои задачи прямо сейчас.
I>Итого — "все контексты поддаются описанию. Вне зависимости от их природы." есть бред. высказываение из ряда абсолютных истин
Замени "все" на "все практически полезные", получишь ровно то же самое.
Если ты не можешь чего-то хоть как-то формализовать, это для тебя бесполезно.
Даже любовь, прошу прощения.
I>Контексты описываются, только время описания в общем случае стремится к бесконечности.
Да ни хрена.
Вот, мы с тобой уже спорим насчёт времени описания контекста, хотя до этого обсуждения ни один из нас не задумывался даже об их существовании и важности.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>Если ехать, то ты всю свою жизнь описывал неописуемые контексты. Если шашечки, то жди десятилетия без надежды. I>>Теоретически описать можно что угодно. Практически — то что сейчас школьники изучают в школе люди описывали более двух тысяч лет.
T>Да. А описание того, что сейчас изучают те, кто когда-то изобретали описание для школьников — лучшие умы человечества, — появилось в течении
последних лет пятидесяти.
Т.е. прямо завтра можно сделать то что требует 50 лет ?
I>>Цитирую себя "ждать две-три тысячи лет как с математикой как то скучновато."
T>Так не жди. Решай свои задачи прямо сейчас.
Я не жду, в той области что я занимаюсь, мега прорывов в ближайшие сто лет не предвидится.
I>>Итого — "все контексты поддаются описанию. Вне зависимости от их природы." есть бред. высказываение из ряда абсолютных истин
T>Замени "все" на "все практически полезные", получишь ровно то же самое.
В твоей формуле отсутсвует время.
I>>Контексты описываются, только время описания в общем случае стремится к бесконечности.
T>Да ни хрена.
см. выше
T>Вот, мы с тобой уже спорим насчёт времени описания контекста, хотя до этого обсуждения ни один из нас не задумывался даже об их существовании и важности.
Это ты не задумывался, что сразу и видно. Там где я работаю контекст уже описывается не один десяток лет.
Здравствуйте, Ikemefula, Вы писали: I>Почему же не имеет отношения к пониманию ? У человека мозг устроет определенным образом, описание состоящее более чем 7-9 эл-тов просто отказывается воспринимать.
Это миф. I>Соотвественно нужно наращивать абстракции что бы удержать описание в этих пределах.
Про способности человека к восприятию информации лучше почитать E.Tufte. Вкратце: человек умеет значительно больше, чем воспринимать описание, состоящее из 9 элементов.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, thesz, Вы писали:
T>>>>Если ехать, то ты всю свою жизнь описывал неописуемые контексты. Если шашечки, то жди десятилетия без надежды. I>>>Теоретически описать можно что угодно. Практически — то что сейчас школьники изучают в школе люди описывали более двух тысяч лет.
T>>Да. А описание того, что сейчас изучают те, кто когда-то изобретали описание для школьников — лучшие умы человечества, — появилось в течении последних лет пятидесяти. I>Т.е. прямо завтра можно сделать то что требует 50 лет ?
Ты придуриваешься?
Мои и твои задачи не требуют полёта высокой мысли.
I>>>Цитирую себя "ждать две-три тысячи лет как с математикой как то скучновато." T>>Так не жди. Решай свои задачи прямо сейчас. I>Я не жду, в той области что я занимаюсь, мега прорывов в ближайшие сто лет не предвидится.
В чём тогда проблема?
I>>>Итого — "все контексты поддаются описанию. Вне зависимости от их природы." есть бред. высказываение из ряда абсолютных истин T>>Замени "все" на "все практически полезные", получишь ровно то же самое. I>В твоей формуле отсутсвует время.
В твоей фразе отсутствует буква.
Добавь время по вкусу.
I>>>Контексты описываются, только время описания в общем случае стремится к бесконечности. T>>Да ни хрена. I>см. выше
Куда смотреть-то?
T>>Вот, мы с тобой уже спорим насчёт времени описания контекста, хотя до этого обсуждения ни один из нас не задумывался даже об их существовании и важности. I>Это ты не задумывался, что сразу и видно. Там где я работаю контекст уже описывается не один десяток лет.
Ух ты!
Где же ты работаешь?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>Да. А описание того, что сейчас изучают те, кто когда-то изобретали описание для школьников — лучшие умы человечества, — появилось в течении последних лет пятидесяти. I>>Т.е. прямо завтра можно сделать то что требует 50 лет ?
T>Ты придуриваешься?
Ты ведь сам написал про 50 лет
T>Мои и твои задачи не требуют полёта высокой мысли.
Ну ка, расскажи про мои задачи. Может чтото новое узнаю.
T>>>Так не жди. Решай свои задачи прямо сейчас. I>>Я не жду, в той области что я занимаюсь, мега прорывов в ближайшие сто лет не предвидится.
T>В чём тогда проблема?
Здравствуйте, Sinclair, Вы писали:
I>>Почему же не имеет отношения к пониманию ? У человека мозг устроет определенным образом, описание состоящее более чем 7-9 эл-тов просто отказывается воспринимать. S>Это миф.
Ну да, вероятно когнитивные науки нагло врут по этому поводу.
I>>Соотвественно нужно наращивать абстракции что бы удержать описание в этих пределах. S>Про способности человека к восприятию информации лучше почитать E.Tufte. Вкратце: человек умеет значительно больше, чем воспринимать описание, состоящее из 9 элементов.
Объем внимания в среднем 7+-2 объекта. Поэтому нужно обобщать, абстрагироваться и тд для чтого что бы решать сложные задачи.
Т.е. вся шахматная доска сворачивается например в такое описание — "чёрный угрожает пешке на ферзевом фланге", а все детали выталкиваются в долговременную память.
Итоговое описание все равно вмещается в объем внимания который 7+-2 объекта.
E.Tufte кстати говоря, пишет про то же самое. Процитируй и покажу пальцем.
Здравствуйте, Ikemefula, Вы писали: I>Ну да, вероятно когнитивные науки нагло врут по этому поводу
Пруфлинк на "когнитивные науки" в студию.
I>Объем внимания в среднем 7+-2 объекта. Поэтому нужно обобщать, абстрагироваться и тд для чтого что бы решать сложные задачи.
Пруфлинк на "объем внимания" в студию.
Если дашь себе труд поискать, то выяснишь, что никакие когнитивные психологи никогда ничего про "объем внимания" и "максимальное количество элементов в описании" не публиковали.
I>E.Tufte кстати говоря, пишет про то же самое. Процитируй и покажу пальцем.
Ага, щас прямо. Тафте — как раз когнитивный психолог, поэтому такую хрень не пишет никогда.
Прямо сейчас у меня под рукой ничего нету, но он писал про ровно обратное. В частности, он страшно критиковал паверпоинт как раз за то, что он не позволяет всунуть в слайд сколь-нибудь достаточное количество информации.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Если дашь себе труд поискать, то выяснишь, что никакие когнитивные психологи никогда ничего про "объем внимания" и "максимальное количество элементов в описании" не публиковали.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Юрий Жмеренецкий, Вы писали:
ЮЖ>>Но это не имеет отношения к пониманию. Но, например, к языку программирования имеет — поскольку он является средством выражения описания объекта(в оригинале — двоичных строк). Для разных описаний сложность отличается не более чем на константу, под которой можно понимать "длину" транслятора(т.е. размер кода) с одного языка на другой.
I>Почему же не имеет отношения к пониманию ? У человека мозг устроет определенным образом, описание состоящее более чем 7-9 эл-тов просто отказывается воспринимать. Соотвественно нужно наращивать абстракции что бы удержать описание в этих пределах.
Потому что это определение оперирует двоичными строками. А что там за ними скрыто — дело десятое. Ключевой момент здесь — "длина наиболее ёмкого описания, по которому объект можно восстановить".
Если взять функцию, в которой отсутствуют комментарии и используются только односимвольные идентификаторы и сжать ее (без потерь), то получившаяся строка будет иметь сложность (длину) C. Если теперь переписать ее с использованием осмысленных идентификаторов (+ добавить комментарии) и тоже сжать этим же методом, то длина сжатого переписанного представления будет больше С. Если такое переписывание можно назвать "упорядочиванием", то используемое определение объясняет каким образом "при упорядочивании сложность кода может увеличиваться".
Но, повторюсь, к пониманию это определение не имеет никакого отношения, т.к. с таким же успехом можно переписать функцию с использованием бессмысленных (и в совокупности хуже сжимаемых) идентификаторов.
Максимум что можно сказать про понимание — это то, что увеличение (такой) сложности вызвано необходимостью имееть понятное человеку описание. Как только описание само по себе становится сложным для понимания, то очевидным выходом является смена базиса, с помощью которого описывается объект, на более "высокоуровневый". Вот на этом уровное уже можно говорить о 7-9-ти элементах.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, thesz, Вы писали:
T>>>>Да. А описание того, что сейчас изучают те, кто когда-то изобретали описание для школьников — лучшие умы человечества, — появилось в течении последних лет пятидесяти. I>>>Т.е. прямо завтра можно сделать то что требует 50 лет ? T>>Ты придуриваешься? I>Ты ведь сам написал про 50 лет
50 лет — это теория категорий, например.
В применении к программированию.
Лямбда куб добрался до практики за 5 лет (1992->1997). Линейные типы за 0 лет: линейная логика появилась в 1987, тогда же появился Clean.
Это всё очень сложные концепции.
Я думаю, что твои и мои типичные случаи переходят из теории в практику за месяцы.
T>>Мои и твои задачи не требуют полёта высокой мысли. I>Ну ка, расскажи про мои задачи. Может чтото новое узнаю.
Расскажи, где ты работаешь.
T>>>>Так не жди. Решай свои задачи прямо сейчас. I>>>Я не жду, в той области что я занимаюсь, мега прорывов в ближайшие сто лет не предвидится. T>>В чём тогда проблема? I>Уже было сказано.
Расскажи, где ты работаешь.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
I>>>>Т.е. прямо завтра можно сделать то что требует 50 лет ? T>>>Ты придуриваешься? I>>Ты ведь сам написал про 50 лет
T>50 лет — это теория категорий, например.
Правильно тебя понимаю, один раздел математики потребовал 50 лет а не один день ?
T>Я думаю, что твои и мои типичные случаи переходят из теории в практику за месяцы.
Ну, расскажи про мои случаи. Хочу узнать, чем занимались несколько институтов много лет.
T>>>Мои и твои задачи не требуют полёта высокой мысли. I>>Ну ка, расскажи про мои задачи. Может чтото новое узнаю.
T>Расскажи, где ты работаешь.
Это я от тебя хочу услышать. Ты то говоришь так как будто все знаешь.
T>>>>>Так не жди. Решай свои задачи прямо сейчас. I>>>>Я не жду, в той области что я занимаюсь, мега прорывов в ближайшие сто лет не предвидится. T>>>В чём тогда проблема? I>>Уже было сказано.
T>Расскажи, где ты работаешь.
Хочу от тебя это услышать. Ты ведь все знаешь, да ?
Здравствуйте, Sinclair, Вы писали:
I>>Ну да, вероятно когнитивные науки нагло врут по этому поводу S>Пруфлинк на "когнитивные науки" в студию.
http://virtualcoglab.cs.msu.su/CogSci_R.html
I>>Объем внимания в среднем 7+-2 объекта. Поэтому нужно обобщать, абстрагироваться и тд для чтого что бы решать сложные задачи. S>Пруфлинк на "объем внимания" в студию.
Ну ты и загнул то. Объём это одна из основных характеристик внимания.
I>>E.Tufte кстати говоря, пишет про то же самое. Процитируй и покажу пальцем. S>Ага, щас прямо. Тафте — как раз когнитивный психолог, поэтому такую хрень не пишет никогда.
Он какой то слишком универсальный ученый, занимается всем подряд. Мне больше
S>Прямо сейчас у меня под рукой ничего нету, но он писал про ровно обратное. В частности, он страшно критиковал паверпоинт как раз за то, что он не позволяет всунуть в слайд сколь-нибудь достаточное количество информации.
Что там с поверпоинтом, не в курсе.
Информации можно всунуть сколько угодно, если она соотвествующим образом структурирована.
Внимание прокачивается вобщем то но не до небес.
Здравствуйте, Юрий Жмеренецкий, Вы писали:
I>>Почему же не имеет отношения к пониманию ? У человека мозг устроет определенным образом, описание состоящее более чем 7-9 эл-тов просто отказывается воспринимать. Соотвественно нужно наращивать абстракции что бы удержать описание в этих пределах.
ЮЖ>Максимум что можно сказать про понимание — это то, что увеличение (такой) сложности вызвано необходимостью имееть понятное человеку описание. Как только описание само по себе становится сложным для понимания, то очевидным выходом является смена базиса, с помощью которого описывается объект, на более "высокоуровневый". Вот на этом уровное уже можно говорить о 7-9-ти элементах.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, thesz, Вы писали:
I>>>>>Т.е. прямо завтра можно сделать то что требует 50 лет ? T>>>>Ты придуриваешься? I>>>Ты ведь сам написал про 50 лет
T>>50 лет — это теория категорий, например. I>Правильно тебя понимаю, один раздел математики потребовал 50 лет а не один день?
Да.
T>>Я думаю, что твои и мои типичные случаи переходят из теории в практику за месяцы. I>Ну, расскажи про мои случаи. Хочу узнать, чем занимались несколько институтов много лет.
Ты не несколько институтов. Ты всего лишь один человек.
Поскольку ты отказываешься рассказывать, чем ты занимаешься — судя по всему, ты боишься, что я смогу разобраться в твоих проблемах лучше тебя самого, — то я подожду ещё один ответ и если он меня не удовлетворит, начну тебя игнорировать, как не способного к сотрудничеству.
T>>>>Мои и твои задачи не требуют полёта высокой мысли. I>>>Ну ка, расскажи про мои задачи. Может чтото новое узнаю. T>>Расскажи, где ты работаешь. I>Это я от тебя хочу услышать. Ты то говоришь так как будто все знаешь.
Я знаю достаточно, чтобы экстраполировать и на твой случай тоже.
T>>>>>>Так не жди. Решай свои задачи прямо сейчас. I>>>>>Я не жду, в той области что я занимаюсь, мега прорывов в ближайшие сто лет не предвидится. T>>>>В чём тогда проблема? I>>>Уже было сказано. T>>Расскажи, где ты работаешь. I>Хочу от тебя это услышать. Ты ведь все знаешь, да ?
Я знаю только то, что практически любые программистские проблемы решаемы и описуемы.
Дальше дело техники, различной в общем случае.
Поэтому — выкладывай твою предметную область.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>50 лет — это теория категорий, например. I>>Правильно тебя понимаю, один раздел математики потребовал 50 лет а не один день?
T>Да.
А как же про завтра ?
T>>>Я думаю, что твои и мои типичные случаи переходят из теории в практику за месяцы. I>>Ну, расскажи про мои случаи. Хочу узнать, чем занимались несколько институтов много лет.
T>Ты не несколько институтов. Ты всего лишь один человек.
Я это и без тебя знаю. При этом вижу что разработка области длится много больше одного дня, при чем разрабатывают вобщем то не программисты.
T>Поскольку ты отказываешься рассказывать, чем ты занимаешься — судя по всему, ты боишься, что я смогу разобраться в твоих проблемах лучше тебя самого, — то я подожду ещё один ответ и если он меня не удовлетворит, начну тебя игнорировать, как не способного к сотрудничеству.
Я не буду нарушать твою монополию на знания Меня устраивает тот факт что ты вещаешь истины ничего не зная про них.
T>Я знаю достаточно, чтобы экстраполировать и на твой случай тоже.
И при этом ты не знаешь в какой области я работаю.
T>>>>>>>Так не жди. Решай свои задачи прямо сейчас. I>>>>>>Я не жду, в той области что я занимаюсь, мега прорывов в ближайшие сто лет не предвидится. T>>>>>В чём тогда проблема? I>>>>Уже было сказано. T>>>Расскажи, где ты работаешь. I>>Хочу от тебя это услышать. Ты ведь все знаешь, да ?
T>Я знаю только то, что практически любые программистские проблемы решаемы и описуемы.
Ну вот ты уже плавно отошел от предметной области к программистским проблемам.
Типа если программист может писать код значит все описуемо.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Ikemefula, Вы писали: I>>Ну да, вероятно когнитивные науки нагло врут по этому поводу S>Пруфлинк на "когнитивные науки" в студию.
I>>Объем внимания в среднем 7+-2 объекта. Поэтому нужно обобщать, абстрагироваться и тд для чтого что бы решать сложные задачи. S>Пруфлинк на "объем внимания" в студию.
S>Если дашь себе труд поискать, то выяснишь, что никакие когнитивные психологи никогда ничего про "объем внимания" и "максимальное количество элементов в описании" не публиковали.
ИМХО, слишком буквально эти данные воспринимать не стоит. Поскольку они сами точно не знают какие объекты меряют в этих 7+-2.
Вобще-то, даже пытаются мерять пропускную способность человека по обработке информации. Много разных исследователей проводило много разных экспериментов. В результате намеряли что у человека пропускная способность 5 бит в секунду, максимум 15-30 бит/сек.
Может биты появились уже после пересказа. В оригинале вроде были обекты...
Максимальная пропускная способность не превышает нескольких десятков бит/с и достигается в тех случаях, когда память не используется, что характерно для бессознательных рефлексов.
Пропускная способность при этом приближается к предельно возможной величине и составляет 10-50 бит/с.
При использовании оперативной памяти пропускная способность снижается до 0,5-5 бит/с, если же используется долговременная память, то пропускная способность составляет всего 0,04-0,2 бит/с.
Эксперименты проводить легче, чем результаты интерпретировать. Просто сами точно не понимают что называют битами, объектами.
Хотя доля истины в этом есть.
Здравствуйте, Ikemefula, Вы писали: I>Он какой то слишком универсальный ученый, занимается всем подряд. Мне больше
Тафте занимается представлением информации — то есть ровно тем, о чем мы сейчас говорим. S>>Прямо сейчас у меня под рукой ничего нету, но он писал про ровно обратное. В частности, он страшно критиковал паверпоинт как раз за то, что он не позволяет всунуть в слайд сколь-нибудь достаточное количество информации. I>Что там с поверпоинтом, не в курсе.
А ты поинтересуйся. Его статья про недостатки паверпоинта валялась в свободном доступе. I>Информации можно всунуть сколько угодно, если она соотвествующим образом структурирована.
Воот. А вот о том, как правильно структурировать визуальную информацию, Тафте как раз и пишет.
Вот, к примеру, какая-нибудь карта галактики из его примеров — показывает характеристики ~17000 объектов. Если бы ты был прав, то "мозг человека" отказался бы воспринимать эту информацию. Тем не менее, карта остаётся крайне полезной и удобной в восприятии.
Таблицы — другой способ передавать огромные количества информации. Прилично оформленная таблица позволяет одним взглядом окинуть 100-400 отдельных фактов, и обнаружить основные закономерности. Очевидно, это более чем на порядок превышает мифические "7-9 объектов", о которых так любят рассуждать дилетанты.
Надо полагать, что и в языке программирования рассчитывать на магические семёрки и девятки смысла нет. Надо думать о том, как убрать мусор. Это ровно противоположно направлению "давайте добавим структурирующего мусора для упрощения восприятия".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>>Прямо сейчас у меня под рукой ничего нету, но он писал про ровно обратное. В частности, он страшно критиковал паверпоинт как раз за то, что он не позволяет всунуть в слайд сколь-нибудь достаточное количество информации. I>>Что там с поверпоинтом, не в курсе. S>А ты поинтересуйся. Его статья про недостатки паверпоинта валялась в свободном доступе.
Мне сильно кажется что он слегка не понимает разницу между профессионалами и любителями.
I>>Информации можно всунуть сколько угодно, если она соотвествующим образом структурирована. S>Воот. А вот о том, как правильно структурировать визуальную информацию, Тафте как раз и пишет.
Твое ВООТ ни к месту. Я говорю уже в десятый раз что надо структурировать и соответсвующим образом представлять информацию. Но это не значит что ты отменяешь такую характеристику объем внимания.
S>Вот, к примеру, какая-нибудь карта галактики из его примеров — показывает характеристики ~17000 объектов. Если бы ты был прав, то "мозг человека" отказался бы воспринимать эту информацию. Тем не менее, карта остаётся крайне полезной и удобной в восприятии.
Эти 17000 тыщ объектов сворачваются аккурат в 5+-2 объекта, может и больше чуток, потому что тем, кто постоянно пялится в такие карты объем внимания будет выше среднего(но только для карт оных).
S>Таблицы — другой способ передавать огромные количества информации. Прилично оформленная таблица позволяет одним взглядом окинуть 100-400 отдельных фактов, и обнаружить основные закономерности. Очевидно, это более чем на порядок превышает мифические "7-9 объектов", о которых так любят рассуждать дилетанты.
100-400 ты не воспринимаешь, ты воспрнимаешь одну таблицу как один объект и то, только потому, что работаешь с этими таблицами постоянно.
А вот когда сфокусируешься на одной таблице, то опять же все 100-400 строк ты небудешь воспринимать, только десяток-другой и то потому что это однородная информация.
S>Надо полагать, что и в языке программирования рассчитывать на магические семёрки и девятки смысла нет. Надо думать о том, как убрать мусор. Это ровно противоположно направлению "давайте добавим структурирующего мусора для упрощения восприятия".
Мусор никто не добавляет, это у тебя в голове такое видение. "структурирующй мусор" как ты назвал, это табличное представление, оформление карт и тд и тд и тд — представление информации, оно нужно человеку именно потому что есть определенные ограничения как например объем внимания, кол.во параллельных активностей и тд и тд. Грубо говоря, господу богу структурироване ни к чему, у него нет такого ограничения как объем внимания.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, thesz, Вы писали:
T>>>>50 лет — это теория категорий, например. I>>>Правильно тебя понимаю, один раздел математики потребовал 50 лет а не один день?
T>>Да.
I>А как же про завтра ?
С несложными проблемами типа моей и твоей можно и завтра. Особенно, если нужно.
T>>>>Я думаю, что твои и мои типичные случаи переходят из теории в практику за месяцы. I>>>Ну, расскажи про мои случаи. Хочу узнать, чем занимались несколько институтов много лет. T>>Ты не несколько институтов. Ты всего лишь один человек. I>Я это и без тебя знаю. При этом вижу что разработка области длится много больше одного дня, при чем разрабатывают вобщем то не программисты.
T>>Поскольку ты отказываешься рассказывать, чем ты занимаешься — судя по всему, ты боишься, что я смогу разобраться в твоих проблемах лучше тебя самого, — то я подожду ещё один ответ и если он меня не удовлетворит, начну тебя игнорировать, как не способного к сотрудничеству. I>Я не буду нарушать твою монополию на знания Меня устраивает тот факт что ты вещаешь истины ничего не зная про них.
Я "вещаю" о том, что относится к, практически, любой области программирования.
Не нашёл ничего такого, чтобы могло подтвердить твою точку зрения: что существуют контексты, которые целые институты описывают годами.
Единственное, что чуток выходит за рамки обычного программиста, это Го. Ну, так с ним тоже справились не так давно.
T>>Я знаю достаточно, чтобы экстраполировать и на твой случай тоже. I>И при этом ты не знаешь в какой области я работаю.
Это не важно с практической точки зрения.
T>>>>>>>>Так не жди. Решай свои задачи прямо сейчас. I>>>>>>>Я не жду, в той области что я занимаюсь, мега прорывов в ближайшие сто лет не предвидится. T>>>>>>В чём тогда проблема? I>>>>>Уже было сказано. T>>>>Расскажи, где ты работаешь. I>>>Хочу от тебя это услышать. Ты ведь все знаешь, да ?
T>>Я знаю только то, что практически любые программистские проблемы решаемы и описуемы. I>Ну вот ты уже плавно отошел от предметной области к программистским проблемам.
Программирование, чтобы ты знал, это раздел конструктивной математики.
Если ты можешь описать какую-то область математически в конструктивном ключе, то ты можешь запрограммировать решение её проблем.
I>Типа если программист может писать код значит все описуемо.
Именно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Ikemefula, Вы писали:
I>Мне сильно кажется что он слегка не понимает разницу между профессионалами и любителями.
Понятно. Рекомендую воздержаться от дальнейших высказываний сюда до прочтения Tufte.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Потому что это мой личный, а не корпоративный емейл, во вторых и тот и другой я не раскидываю где попало.
T>Единственное, что чуток выходит за рамки обычного программиста, это Го. Ну, так с ним тоже справились не так давно.
Ты не пробовал читать свои же ссылки ?
800-core supercomputer, beat 8-dan professional go player Myungwan Kim in a 9-stone handicap game.
Тут написано, что компьютер на порядки мощнее Deep Blue выирал у _среднего_ профессионала на максимальной стандартной форе на стандартной доске. Причем это средний сам может брать фору у топ-профессионалов.
Фора такая — компьютер в начале сделал 9 ходов подряд. Я с профессионалами играл на такой же и даже меньшей форе
Так шта Го до решения еще больше чем у нас. Компьютер сравнялся с человеком только на ученической доске. Вобщем если не считать ученическую доску, "успехи" компьютера не изменились за 10-15 лет.
Премию в 1 млн долларов пока еще никто не получил.
I>>Типа если программист может писать код значит все описуемо.
T>Именно.
Здравствуйте, Sinclair, Вы писали:
I>>Мне сильно кажется что он слегка не понимает разницу между профессионалами и любителями. S>Понятно. Рекомендую воздержаться от дальнейших высказываний сюда до прочтения Tufte.
Если бы ты вместо Tufte написал Solso, можно было бы еще подумать.
А так ты повторяешь вобщем то чуть не слово в слово то что написано во введении букваря по когнитивной психологии, только думаешь что это мега открытие.
Зайди в книжный и купи букварь такой, узнаешь почему Tufte пишет именно так а не иначе.
А про поверпоёнт все сильно — не понимает человек, что есть любители и профессионалы. Это не значит, что его претензии несправедливы.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, thesz, Вы писали:
T>>Дал себе труд поискать по phusakouski@gmail.com I>Потому что это мой личный, а не корпоративный емейл, во вторых и тот и другой я не раскидываю где попало.
Что поиск по мылу phusakouski, что поиск "Mad Hollander" дают ссылки на ".Net drawing".
Всё, я перестаю интересоваться этой проблемой. А то, боюсь, правда окажется немного не той, что я хотел бы ждать.
T>>Единственное, что чуток выходит за рамки обычного программиста, это Го. Ну, так с ним тоже справились не так давно. I>Ты не пробовал читать свои же ссылки ? I>
800-core supercomputer, beat 8-dan professional go player Myungwan Kim in a 9-stone handicap game.
I>Тут написано, что компьютер на порядки мощнее Deep Blue выирал у _среднего_ профессионала на максимальной стандартной форе на стандартной доске.
"На порядки мощнее"?..
I>Причем это средний сам может брать фору у топ-профессионалов.
I>Фора такая — компьютер в начале сделал 9 ходов подряд. Я с профессионалами играл на такой же и даже меньшей форе
I>Так шта Го до решения еще больше чем у нас. Компьютер сравнялся с человеком только на ученической доске. Вобщем если не считать ученическую доску, "успехи" компьютера не изменились за 10-15 лет.
Другие, и профессиональные игроки в том числе, считают это прорывом.
I>Премию в 1 млн долларов пока еще никто не получил.
Ничего. Они за год достигли этого уровня.
Посмотрим, что будет дальше.
I>>>Типа если программист может писать код значит все описуемо. T>>Именно. I>Я уже понял по твоему "тоже справились".
Ты читаешь только то, что подходит под твои идеи.
А там ещё про конструктивную математику было. Это важнее.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, thesz, Вы писали: I>>>А как же про завтра ? T>>С несложными проблемами типа моей и твоей можно и завтра. Особенно, если нужно. I>NP-полные задачи это несложно по твоему ?
Несложно.
Что, контекст описания (решения) NP-полной задачи настолько сложен?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
I>>>>А как же про завтра ? T>>>С несложными проблемами типа моей и твоей можно и завтра. Особенно, если нужно. I>>NP-полные задачи это несложно по твоему ?
T>Несложно.
Я уверен, ты их решаешь за O(1).
T>Что, контекст описания (решения) NP-полной задачи настолько сложен?
Да, задачи решаются годами. Нужен результат определенного уровня, а не любой.
Здравствуйте, thesz, Вы писали:
T>Что поиск по мылу phusakouski, что поиск "Mad Hollander" дают ссылки на ".Net drawing".
Точнее результатов у тебя никаких нет но ты чего то силишься додумать.
Про мою предметную область я на этом сайте не единожды упоминал, искать нужно сначал перед носом, а не лишь бы где.
.Net drawing — это неосновная активность, всего лишь визуализация.
I>>Ты не пробовал читать свои же ссылки ? I>>
800-core supercomputer, beat 8-dan professional go player Myungwan Kim in a 9-stone handicap game.
I>>Тут написано, что компьютер на порядки мощнее Deep Blue выирал у _среднего_ профессионала на максимальной стандартной форе на стандартной доске.
T>"На порядки мощнее"?..
Да, минима в сто раз мощнее чем Deep Blue.
I>>Так шта Го до решения еще больше чем у нас. Компьютер сравнялся с человеком только на ученической доске. Вобщем если не считать ученическую доску, "успехи" компьютера не изменились за 10-15 лет.
T>Другие, и профессиональные игроки в том числе, считают это прорывом.
Нет никакого прорыва. Ты вряд ли играл и в го с компьютерными го-программами, но тем не менее уверенно вещаешь чего. Это неудивительно.
I>>Премию в 1 млн долларов пока еще никто не получил.
T>Ничего. Они за год достигли этого уровня.
За год они достигли того, чего и без них было 15 лет последних.
Кроме того, они используют метод статистического моделирования, который вобщем то имеет ограничение по качеству результата. Мне сильно кажется, что люди хотят заполучить этот миллион.
T>А там ещё про конструктивную математику было. Это важнее.
Было высказывание из разряда абсолютных истин, можно заменить хоть на true хоть на коня в вакууме
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, thesz, Вы писали:
I>>>>>А как же про завтра ? T>>>>С несложными проблемами типа моей и твоей можно и завтра. Особенно, если нужно. I>>>NP-полные задачи это несложно по твоему ?
T>>Несложно. I>Я уверен, ты их решаешь за O(1).
Я могу описать алгоритм решения за O(1).
Ведь именно про описание мы здесь и говорим.
T>>Что, контекст описания (решения) NP-полной задачи настолько сложен? I>Да, задачи решаются годами. Нужен результат определенного уровня, а не любой.
Ищутся способы решения, а не "задачи решаются".
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
I>>Ты не пробовал читать свои же ссылки ? I>>
800-core supercomputer, beat 8-dan professional go player Myungwan Kim in a 9-stone handicap game.
I>>Тут написано, что компьютер на порядки мощнее Deep Blue выирал у _среднего_ профессионала на максимальной стандартной форе на стандартной доске.
T>"На порядки мощнее"?..
Здравствуйте, thesz, Вы писали:
T>>>Несложно. I>>Я уверен, ты их решаешь за O(1).
T>Я могу описать алгоритм решения за O(1).
T>Ведь именно про описание мы здесь и говорим.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, thesz, Вы писали:
T>>Что поиск по мылу phusakouski, что поиск "Mad Hollander" дают ссылки на ".Net drawing". I>Точнее результатов у тебя никаких нет но ты чего то силишься додумать.
Да, я очень сильный.
I>Про мою предметную область я на этом сайте не единожды упоминал, искать нужно сначал перед носом, а не лишь бы где. I>.Net drawing — это неосновная активность, всего лишь визуализация.
Значит, с основной активностью тебе всё понятно. Крута!
I>>>Ты не пробовал читать свои же ссылки ? I>>>
800-core supercomputer, beat 8-dan professional go player Myungwan Kim in a 9-stone handicap game.
I>>>Тут написано, что компьютер на порядки мощнее Deep Blue выирал у _среднего_ профессионала на максимальной стандартной форе на стандартной доске.
T>>"На порядки мощнее"?.. I>Да, минима в сто раз мощнее чем Deep Blue.
Учти инфляцию.
Да ещё учти расхождение игр, например, снижение комбинаторной сложности шахмат в процессе игры.
I>>>Так шта Го до решения еще больше чем у нас. Компьютер сравнялся с человеком только на ученической доске. Вобщем если не считать ученическую доску, "успехи" компьютера не изменились за 10-15 лет. T>>Другие, и профессиональные игроки в том числе, считают это прорывом. I>Нет никакого прорыва. Ты вряд ли играл и в го с компьютерными го-программами, но тем не менее уверенно вещаешь чего. Это неудивительно.
Тебе выгодно, чтобы прорыва не было.
Мне выгодно то, что невыгодно тебе.
На слешдоте это считают прорывом, поскольку до того программы не поднимались до такого уровня. Я с этим согласен.
Можешь привести в качестве аргумента другое обсуждение этого же события. Мы рассмотрим все варианты.
I>>>Премию в 1 млн долларов пока еще никто не получил. T>>Ничего. Они за год достигли этого уровня. I>За год они достигли того, чего и без них было 15 лет последних.
Судя по обсуждению, не было.
I>Кроме того, они используют метод статистического моделирования, который вобщем то имеет ограничение по качеству результата. Мне сильно кажется, что люди хотят заполучить этот миллион.
Какие бяки!
T>>А там ещё про конструктивную математику было. Это важнее.
I>Было высказывание из разряда абсолютных истин, можно заменить хоть на true хоть на коня в вакууме
Конструктивная математика хорошо определена.
Ты просто читаешь то, что тебе выгодно.
Не могу заставить тебя поступать по другому, так хоть получу некоторый положительный заряд из общения с тобой.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, thesz, Вы писали:
I>>>Ты не пробовал читать свои же ссылки ? I>>>
800-core supercomputer, beat 8-dan professional go player Myungwan Kim in a 9-stone handicap game.
I>>>Тут написано, что компьютер на порядки мощнее Deep Blue выирал у _среднего_ профессионала на максимальной стандартной форе на стандартной доске.
T>>"На порядки мощнее"?..
I>Вопрос к тебе на тему умения читать
I>15 Teraflops и 11.38 GFLOPS
I>сколько порядков разницы ?
Сколько там лет прошло, 12? Это сколько удвоений производительности по закону Мура? 8? Два в восьмой степени это сколько — 256? 15 терафлопов, они же 15e12 флопов делить на 11.38e9 это сколько получится, чуть больше тысячи, 1318.1? 1318.1 поделить на 256 сколько получится, 5.15?
То есть, если бы Deep Blue был бы собран на текущей элементной базе, он был бы всего в 5 раз медленнее компьютера, что играл в Го.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, thesz, Вы писали:
T>>>>Несложно. I>>>Я уверен, ты их решаешь за O(1).
T>>Я могу описать алгоритм решения за O(1).
T>>Ведь именно про описание мы здесь и говорим.
I>В каких терминах ты будешь описывать ?
Само решение я как-то описал на Хаскеле в терминах кривоватых BDD. Работало, но медленно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>"На порядки мощнее"?..
I>>Вопрос к тебе на тему умения читать
I>>15 Teraflops и 11.38 GFLOPS
I>>сколько порядков разницы ?
T>Сколько там лет прошло, 12? Это сколько удвоений производительности по закону Мура? 8? Два в восьмой степени это сколько — 256? 15 терафлопов, они же 15e12 флопов делить на 11.38e9 это сколько получится, чуть больше тысячи, 1318.1? 1318.1 поделить на 256 сколько получится, 5.15?
Вообще то 6 удвоений а не 8. Вижу, для тебя и арифметика слишком сложная задача ибо "every two years"
T>То есть, если бы Deep Blue был бы собран на текущей элементной базе, он был бы всего в 5 раз медленнее компьютера, что играл в Го.
Если бы да кабы, то рослиб во рту грибы. Конечно, топы немного подтянулись в гре против такого компьютера, но радикального ничего не случилось.
итого
1 Компьютер вроде дип блю до сих пор уделывает гроссов мирового уровня.
2 При этом в 1000 раз более мощный компьютер в го не может уделать среднего любителя.
Здравствуйте, thesz, Вы писали:
T>>>Что поиск по мылу phusakouski, что поиск "Mad Hollander" дают ссылки на ".Net drawing". I>>Точнее результатов у тебя никаких нет но ты чего то силишься додумать.
T>Да, я очень сильный.
Балаболка.
I>>Про мою предметную область я на этом сайте не единожды упоминал, искать нужно сначал перед носом, а не лишь бы где. I>>.Net drawing — это неосновная активность, всего лишь визуализация.
T>Значит, с основной активностью тебе всё понятно. Крута!
Чего тебе понятно мне не известно.
T>>>"На порядки мощнее"?.. I>>Да, минима в сто раз мощнее чем Deep Blue.
T>Учти инфляцию.
Какую инфляцию ? Человеческий моз давным давно не удваивет перформанс и в шахматах он играет на уровне старенького дип блю.
А вот для ГО даже в тысячу раз более мощный компьютер даёт почти что нулевой результат.
T>Да ещё учти расхождение игр, например, снижение комбинаторной сложности шахмат в процессе игры.
не пори чушь наукообразными высказываниями. Игры отличаются это и ежу ясно. ну нужно злоупотреблять абсолютными истинами.
T>>>Другие, и профессиональные игроки в том числе, считают это прорывом. I>>Нет никакого прорыва. Ты вряд ли играл и в го с компьютерными го-программами, но тем не менее уверенно вещаешь чего. Это неудивительно.
T>Тебе выгодно, чтобы прорыва не было.
Я играю в го потому что мне игра нравится, а не потому что в нее компьютер плохо играет.
T>Мне выгодно то, что невыгодно тебе.
Это называется комплекс противоречия.
T>На слешдоте это считают прорывом, поскольку до того программы не поднимались до такого уровня. Я с этим согласен.
Ну для слешдота это возможно и прорыв. Для гошных ресурсов это больше насмешка.
Тот факт, что статья появилсь на слешдоте говорит не о прорыве в решении задачи, а о росте популярности го в западном мире.
Нет никакого прорыва — черепаха переползла линию старта.
T>Можешь привести в качестве аргумента другое обсуждение этого же события. Мы рассмотрим все варианты.
Нет никакого желания устраивать тебе ликбез, ибо в го ты скорее всего не играешь, а без этого обсуждать что либо бессмысленно.
I>>За год они достигли того, чего и без них было 15 лет последних.
T>Судя по обсуждению, не было.
Ты бы еще в журнал мурзилка заглянул.
I>>Было высказывание из разряда абсолютных истин, можно заменить хоть на true хоть на коня в вакууме
T>Конструктивная математика хорошо определена.
Вот еще одно высказывание из ряда абсолютных истин.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, thesz, Вы писали:
T>>>>"На порядки мощнее"?..
I>>>Вопрос к тебе на тему умения читать
I>>>15 Teraflops и 11.38 GFLOPS
I>>>сколько порядков разницы ?
T>>Сколько там лет прошло, 12? Это сколько удвоений производительности по закону Мура? 8? Два в восьмой степени это сколько — 256? 15 терафлопов, они же 15e12 флопов делить на 11.38e9 это сколько получится, чуть больше тысячи, 1318.1? 1318.1 поделить на 256 сколько получится, 5.15?
I>Вообще то 6 удвоений а не 8. Вижу, для тебя и арифметика слишком сложная задача ибо "every two years"
Поскольку я твёрдо решил гыгыкать при каждом удобном случае при общении с тобой, то вот очередной гыгык:
У меня-то арифметика, к тому же правильная, а ты так вообще читать не умеешь.
T>>То есть, если бы Deep Blue был бы собран на текущей элементной базе, он был бы всего в 5 раз медленнее компьютера, что играл в Го. I>Если бы да кабы, то рослиб во рту грибы. Конечно, топы немного подтянулись в гре против такого компьютера, но радикального ничего не случилось. I>итого I>1 Компьютер вроде дип блю до сих пор уделывает гроссов мирового уровня. I>2 При этом в 1000 раз более мощный компьютер в го не может уделать среднего любителя.
ты не тот закон смотришь.
T>Поскольку я твёрдо решил гыгыкать при каждом удобном случае при общении с тобой, то вот очередной гыгык:
Ну, лошадь, что возьмёшь
T>>>То есть, если бы Deep Blue был бы собран на текущей элементной базе, он был бы всего в 5 раз медленнее компьютера, что играл в Го. I>>Если бы да кабы, то рослиб во рту грибы. Конечно, топы немного подтянулись в гре против такого компьютера, но радикального ничего не случилось. I>>итого I>>1 Компьютер вроде дип блю до сих пор уделывает гроссов мирового уровня. I>>2 При этом в 1000 раз более мощный компьютер в го не может уделать среднего любителя.
T>Computer Beats <b>Pro</b> At US Go Congress. У оппонента компьютера был 8-й профессиональный дан.
T>Второй гыгык за это сообщение.
Да, компьютер сделал 9 ходов подряд. Профессионал с которым была игра давно ушел во второй эшелон, он играет на уровне сильных любителей.
Более того профессионал этот на первых местах никогда небыл, потому что у него всего лишь 8й дан до сих пор и уже играет в любительских турнирах.
Среднему же любителю профессионал вроде того что здесь, не может дать такую фору с надеждой на победу.
I>>Вот о чем речь.
T>Продолжай, прошу тебя!
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, thesz, Вы писали:
T>>>>Что поиск по мылу phusakouski, что поиск "Mad Hollander" дают ссылки на ".Net drawing". I>>>Точнее результатов у тебя никаких нет но ты чего то силишься додумать.
T>>Да, я очень сильный.
I>Балаболка.
Я жму лёжа 135 кг. А до того, как повредил колено, мог присесть со штангой в 190 кг.
Я действительно сильный.
I>>>Про мою предметную область я на этом сайте не единожды упоминал, искать нужно сначал перед носом, а не лишь бы где. I>>>.Net drawing — это неосновная активность, всего лишь визуализация. T>>Значит, с основной активностью тебе всё понятно. Крута! I>Чего тебе понятно мне не известно.
Мне понятно, что тебе всё понятно в твоей текущей области деятельности.
Но тогда мне непонятно, почему ты добивался от меня признания существования непонятных контекстов.
Непонятно.
Понятно, что ты хотел выиграть спор. Непонятно, как ты хотел его выиграть, поскольку понимал, что тебе придётся рассказать про понятные тебе и другим контексты. То есть, тебе всё понятно, но при этом ты хотел показать мне, что обладаешь пониманием области, контексты которой непонятны.
Это непонимание беспокоит моё понимание ситуации.
T>>>>"На порядки мощнее"?.. I>>>Да, минима в сто раз мощнее чем Deep Blue. T>>Учти инфляцию. I>Какую инфляцию ? Человеческий моз давным давно не удваивет перформанс и в шахматах он играет на уровне старенького дип блю.
Один из мозгов, выдающийся. Я, например, не решусь. Хотя я тоже выдающийся мозг.
I>А вот для ГО даже в тысячу раз более мощный компьютер даёт почти что нулевой результат.
На уровне среднего любителя.
T>>Да ещё учти расхождение игр, например, снижение комбинаторной сложности шахмат в процессе игры. I>не пори чушь наукообразными высказываниями. Игры отличаются это и ежу ясно. ну нужно злоупотреблять абсолютными истинами.
Если сравнить, кто из нас двоих чаще говорит другому, чего тому не надо делать, получится очень интересный вывод насчёт того, кто же из нас двоих должен куда пойти.
Гыгык.
T>>>>Другие, и профессиональные игроки в том числе, считают это прорывом. I>>>Нет никакого прорыва. Ты вряд ли играл и в го с компьютерными го-программами, но тем не менее уверенно вещаешь чего. Это неудивительно. T>>Тебе выгодно, чтобы прорыва не было. I>Я играю в го потому что мне игра нравится, а не потому что в нее компьютер плохо играет.
По-моему, одно из важнейших качеств программиста: умение понять другого человека, даже более того, почувствовать его. Программист должен быть эмпатом.
Ты же демонстрируешь не только отсутствие эмпатии, но и обычного понимания написанного.
Твоим коллегам, наверное, трудно с тобой.
T>>Мне выгодно то, что невыгодно тебе. I>Это называется комплекс противоречия.
Это называется дурацкий спор.
Не я его начал, не мне и прекращать.
T>>На слешдоте это считают прорывом, поскольку до того программы не поднимались до такого уровня. Я с этим согласен. I>Ну для слешдота это возможно и прорыв. Для гошных ресурсов это больше насмешка.
На US Go Congress это тоже сочли прорывом.
I>Тот факт, что статья появилсь на слешдоте говорит не о прорыве в решении задачи, а о росте популярности го в западном мире.
Или о том, что компьютеры-таки добрались до го.
I>Нет никакого прорыва — черепаха переползла линию старта.
Ух ты!
T>>Можешь привести в качестве аргумента другое обсуждение этого же события. Мы рассмотрим все варианты. I>Нет никакого желания устраивать тебе ликбез, ибо в го ты скорее всего не играешь, а без этого обсуждать что либо бессмысленно.
Зачем ликбез? Приведи обсуждение того события на форумах, посвящённых Го. Чем больше форум, тем лучше.
Я почитаю.
А мы сравним реакцию других игроков в Го с твоей.
Пока мы её не видим, эту реакцию, мы склонные считать твою реакцию представительной, что неправильно. Поскольку она не представительна, и при этом выгодна тебе.
Можно было бы "отмести её, как неорганизованную," но так я получу меньше гыгыков.
I>>>За год они достигли того, чего и без них было 15 лет последних. T>>Судя по обсуждению, не было. I>Ты бы еще в журнал мурзилка заглянул.
В каком номере это обсуждается?
I>>>Было высказывание из разряда абсолютных истин, можно заменить хоть на true хоть на коня в вакууме T>>Конструктивная математика хорошо определена. I>Вот еще одно высказывание из ряда абсолютных истин.
Но ведь это так!
У неё есть область определения, чётко определено что считается, а что не считается конструктивным доказательством.
По-моему, здесь нет никаких абсолютных истин.
Или я неправ?
А если неправ, то где?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Да, при расчёте производительности я учитывал закон увеличения производительности и делал это неправильно. Ведь надо же было учитывать не тот закон!
T>>Поскольку я твёрдо решил гыгыкать при каждом удобном случае при общении с тобой, то вот очередной гыгык: I>Ну, лошадь, что возьмёшь
Должна же быть польза от общения с тобой.
Пока она ровно вот такая — развлечься.
T>>>>То есть, если бы Deep Blue был бы собран на текущей элементной базе, он был бы всего в 5 раз медленнее компьютера, что играл в Го. I>>>Если бы да кабы, то рослиб во рту грибы. Конечно, топы немного подтянулись в гре против такого компьютера, но радикального ничего не случилось. I>>>итого I>>>1 Компьютер вроде дип блю до сих пор уделывает гроссов мирового уровня. I>>>2 При этом в 1000 раз более мощный компьютер в го не может уделать среднего любителя.
T>>Computer Beats <b>Pro</b> At US Go Congress. У оппонента компьютера был 8-й профессиональный дан. T>>Второй гыгык за это сообщение. I>Да, компьютер сделал 9 ходов подряд. Профессионал с которым была игра давно ушел во второй эшелон, он играет на уровне сильных любителей.
Хорошо, что "на уровне сильных любителей". Не так давно было "не может уделать среднего любителя".
Прогресс налицо.
I>Более того профессионал этот на первых местах никогда небыл, потому что у него всего лишь 8й дан до сих пор и уже играет в любительских турнирах.
Ну, бывает.
I>Среднему же любителю профессионал вроде того что здесь, не может дать такую фору с надеждой на победу.
Я думаю, что ты неправильно считаешь "среднего любителя". Я думаю, что до первого дана добирается не всякий игравший в Го.
I>>>Вот о чем речь. T>>Продолжай, прошу тебя! I>Продолжаю. Ты внимательно читай, балаболка.
Как же без этого.
Это же источник радости, что ты, как я могу невнимательно читать. Некоторые вещи я перечитываю по нескольку раз, так они нравится.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
I>>Балаболка.
T>Я жму лёжа 135 кг. А до того, как повредил колено, мог присесть со штангой в 190 кг.
T>Я действительно сильный.
Ты все равно балаболка. Сильный или нет — разницы не меняет. Ты уж мне поверь.
T>Понятно, что ты хотел выиграть спор. Непонятно, как ты хотел его выиграть, поскольку понимал, что тебе придётся рассказать про понятные тебе и другим контексты. То есть, тебе всё понятно, но при этом ты хотел показать мне, что обладаешь пониманием области, контексты которой непонятны.
Я не отказываюсь от того что знаю просто из за форумного трындежа. А спор это больше для развлекухи.
I>>А вот для ГО даже в тысячу раз более мощный компьютер даёт почти что нулевой результат.
T>На уровне среднего любителя.
Ты не понял — компьютер делал 9 ходов подряд. Среднему любителю надо 6-7. И сравнивать нужно соотвественно с любителем, пока что компьютер в начале партии делает столько ошибок, что менее 6 камней форы играет очень нестабильно — разброс примерно в 8 уровней(1 уровень — 1 камень форы).
T>По-моему, одно из важнейших качеств программиста: умение понять другого человека, даже более того, почувствовать его. Программист должен быть эмпатом.
Понять и принять другую точку зрения вещи мягко говоря разные.
I>>Это называется комплекс противоречия.
T>Это называется дурацкий спор.
Ну так не будь дураком, закончи его.
T>Не я его начал, не мне и прекращать.
Как думаешь, кто больший дурак, тот кто начал, или тот кто продолжил и не может прекратить ?
I>>Ну для слешдота это возможно и прорыв. Для гошных ресурсов это больше насмешка.
T>На US Go Congress это тоже сочли прорывом.
Прорывом был сам факт игры а не перформанс.
I>>Тот факт, что статья появилсь на слешдоте говорит не о прорыве в решении задачи, а о росте популярности го в западном мире.
T>Или о том, что компьютеры-таки добрались до го.
для тебя выделено ниже
I>>Нет никакого прорыва — черепаха переползла линию старта.
T>>>Можешь привести в качестве аргумента другое обсуждение этого же события. Мы рассмотрим все варианты. I>>Нет никакого желания устраивать тебе ликбез, ибо в го ты скорее всего не играешь, а без этого обсуждать что либо бессмысленно.
T>Зачем ликбез? Приведи обсуждение того события на форумах, посвящённых Го. Чем больше форум, тем лучше.
На полном серьезе — давай оговорим сначала мой профит а потом я показывают тебе ссылки, идёт ?
Будут качественные, с комментариями других сильных игроков и возможно профессионалов. Но сначала профит.
I>>Вот еще одно высказывание из ряда абсолютных истин.
T>Но ведь это так!
Я ведь не спорю.
T>У неё есть область определения, чётко определено что считается, а что не считается конструктивным доказательством.
T>По-моему, здесь нет никаких абсолютных истин.
T>Или я неправ?
T>А если неправ, то где?
В том то и дело, что все это абсолютные истины. Ты лучше true повторяй, эффекту будет столько же.
Здравствуйте, thesz, Вы писали:
T>Да, при расчёте производительности я учитывал закон увеличения производительности и делал это неправильно. Ведь надо же было
учитывать не тот закон!
Ну допустим. И что это менят ? Компьютер все равно мощнее в 1000 раз того компьютера, который в шахматах порвал топ 1 а результата нет.
Как ни крути, это нельзя отменить твоими гыгыками.
T>>>Второй гыгык за это сообщение. I>>Да, компьютер сделал 9 ходов подряд. Профессионал с которым была игра давно ушел во второй эшелон, он играет на уровне сильных любителей.
T>Хорошо, что "на уровне сильных любителей". Не так давно было "не может уделать среднего любителя".
Не может. Потому и играет с профессионалом(номинально, из хилых) на ученической (9 камней — ученическая) форе.
T>Прогресс налицо.
Нет прогресса. Прогресс будет когда этот комп возьмет уровень в игре на равных против настоящего любителя.
Ты сам то понял что процитировал ? Нет разницы между сильным любителем и профессионалом второго эшелона. Я же тебе сказал — этот про ничем вобщем не выделялся и его место во втором эшелоне.
Он в первые пять десятков и близко не входит. Проф. он чисто номинальный, потому что сдал экзамен когда то.
I>>Среднему же любителю профессионал вроде того что здесь, не может дать такую фору с надеждой на победу.
T>Я думаю, что ты неправильно считаешь "среднего любителя". Я думаю, что до первого дана добирается не всякий игравший в Го.
Разумеется, это истина из ряда абсолютных. И до моего уровня не каждый добирается. И до уровня много слабее не каждый добирается.
Более того — даже на уровень выше уровня правил тоже не каждый добирается, прикинь ?
Я уже говорил — не надо злоупотреблять абсолютными истинами.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, thesz, Вы писали:
I>>>Балаболка. T>>Я жму лёжа 135 кг. А до того, как повредил колено, мог присесть со штангой в 190 кг. T>>Я действительно сильный. I>Ты все равно балаболка. Сильный или нет — разницы не меняет. Ты уж мне поверь.
Восстановим последовательность событий:
T>>>Да, я очень сильный.
I>>Балаболка.
T>Я жму лёжа 135 кг. А до того, как повредил колено, мог присесть со штангой в 190 кг.
T>Я действительно сильный.
Что мы здесь видим? Мы видим, что на фразу "Да, я очень сильный" был ответ "Балаболка". Ikemefula не удосужился проверить, сильный ли его оппонент и наградил его нелестным эпитетом, означающим "брехун" или "пустомеля". В ответ на приведённые thesz доказательства физической его силы Ikemefula продолжает настаивать на своём, продолжая называть thesz брехуном.
Как легко убедиться любому умеющему читать, Ikemefula предпочитает стоять на своём не обращая внимания на очевидные факты.
Можно предположить, что Ikemefula демонстрирует такое поведение и в других сферах деятельности, но это выходит за отведённые нам рамки.
Ваша Честь, обвинение закончило своё выступление.
T>>Понятно, что ты хотел выиграть спор. Непонятно, как ты хотел его выиграть, поскольку понимал, что тебе придётся рассказать про понятные тебе и другим контексты. То есть, тебе всё понятно, но при этом ты хотел показать мне, что обладаешь пониманием области, контексты которой непонятны. I>Я не отказываюсь от того что знаю просто из за форумного трындежа. А спор это больше для развлекухи.
Но ты и не стремишься узнать что-то новое. Изменить своё мнение. Или я неправ?
Если я неправ, приведи ссылку, где кому-то удалось заставить тебя изменить своё мнение. Или где ты самостоятельно его изменил, хорошенько подумав.
Мне действительно интересно.
I>>>А вот для ГО даже в тысячу раз более мощный компьютер даёт почти что нулевой результат. T>>На уровне среднего любителя. I>Ты не понял — компьютер делал 9 ходов подряд. Среднему любителю надо 6-7. И сравнивать нужно соотвественно с любителем, пока что компьютер в начале партии делает столько ошибок, что менее 6 камней форы играет очень нестабильно — разброс примерно в 8 уровней(1 уровень — 1 камень форы).
Да понял я, понял. Про разницу в рангах в статье про Го есть. А я умею читать.
Но я не думаю, что это неустранимый недостаток.
T>>По-моему, одно из важнейших качеств программиста: умение понять другого человека, даже более того, почувствовать его. Программист должен быть эмпатом. I>Понять и принять другую точку зрения вещи мягко говоря разные.
Пока ты демонстрируешь не только отсутствие принятия, но и отсутствие понимания.
I>>>Это называется комплекс противоречия. T>>Это называется дурацкий спор. I>Ну так не будь дураком, закончи его.
Хорошо. Этим ответом я его заканчиваю.
T>>Не я его начал, не мне и прекращать. I>Как думаешь, кто больший дурак, тот кто начал, или тот кто продолжил и не может прекратить ?
Совсем небольшая рефлексия — тоже одно из важнейших качеств программиста, — позволит тебе понять всю глубину твоего падения.
I>>>Ну для слешдота это возможно и прорыв. Для гошных ресурсов это больше насмешка. T>>На US Go Congress это тоже сочли прорывом. I>Прорывом был сам факт игры а не перформанс.
То, что он выиграл.
I>>>Тот факт, что статья появилсь на слешдоте говорит не о прорыве в решении задачи, а о росте популярности го в западном мире. T>>Или о том, что компьютеры-таки добрались до го. I>для тебя выделено ниже
Что же тобой выделено ниже?
I>>>Нет никакого прорыва — черепаха переползла линию старта. T>>>>Можешь привести в качестве аргумента другое обсуждение этого же события. Мы рассмотрим все варианты. I>>>Нет никакого желания устраивать тебе ликбез, ибо в го ты скорее всего не играешь, а без этого обсуждать что либо бессмысленно. T>>Зачем ликбез? Приведи обсуждение того события на форумах, посвящённых Го. Чем больше форум, тем лучше. I>На полном серьезе — давай оговорим сначала мой профит а потом я показывают тебе ссылки, идёт ?
Я буду считать тебя вменяемым собеседником, это дорогого стоит.
I>Будут качественные, с комментариями других сильных игроков и возможно профессионалов. Но сначала профит.
Да брось ты, нет у тебя ничего.
Время да ресурсы оттягиваешь, только чтобы ничего не делать.
Дела — вот важное.
I>>>Вот еще одно высказывание из ряда абсолютных истин. T>>Но ведь это так! I>Я ведь не спорю.
Ура!
T>>У неё есть область определения, чётко определено что считается, а что не считается конструктивным доказательством. T>>По-моему, здесь нет никаких абсолютных истин. T>>Или я неправ? T>>А если неправ, то где? I>В том то и дело, что все это абсолютные истины. Ты лучше true повторяй, эффекту будет столько же.
Хорошо. Что мне нужно было сделать вместо упоминания о конструктивной математике?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, thesz, Вы писали:
T>>Да, при расчёте производительности я учитывал закон увеличения производительности и делал это неправильно. Ведь надо же было учитывать не тот закон! I>Ну допустим. И что это менят ? Компьютер все равно мощнее в 1000 раз того компьютера, который в шахматах порвал топ 1 а результата нет. I>Как ни крути, это нельзя отменить твоими гыгыками.
Да просто смешно. То, что разницу в производительности нельзя отменить гыгыками не отменяет самих гыгыков насчёт твоего ответа.
А мне больше и не надо.
T>>>>Второй гыгык за это сообщение. I>>>Да, компьютер сделал 9 ходов подряд. Профессионал с которым была игра давно ушел во второй эшелон, он играет на уровне сильных любителей. T>>Хорошо, что "на уровне сильных любителей". Не так давно было "не может уделать среднего любителя". I>Не может. Потому и играет с профессионалом(номинально, из хилых) на ученической (9 камней — ученическая) форе.
На среднем любителе его не проверяли.
T>>Прогресс налицо. I>Нет прогресса. Прогресс будет когда этот комп возьмет уровень в игре на равных против настоящего любителя.
Кто такой "настоящий любитель"? Чем он отличается от среднего любителя?
I>Кроме того, есть мнение, что проф этот играл крайне слабо.
Ни о каком "втором эшелоне" в моей цитате речи не идёт.
8-й дан это круто.
I>Он в первые пять десятков и близко не входит. Проф. он чисто номинальный, потому что сдал экзамен когда то.
"Пять десятков" и "профессиональный" это совершенно различные вещи. Ты, видимо, считаешь, что профессионалов в мире всего пять десятков. А также считаешь, что сдать экзамен на восьмой дан просто.
Склоняю голову перед столь незамутнённым мнением.
I>>>Среднему же любителю профессионал вроде того что здесь, не может дать такую фору с надеждой на победу. T>>Я думаю, что ты неправильно считаешь "среднего любителя". Я думаю, что до первого дана добирается не всякий игравший в Го. I>Разумеется, это истина из ряда абсолютных. И до моего уровня не каждый добирается. И до уровня много слабее не каждый добирается.
Гыгык.
thesz: я думаю, что ты неправильно считаешь.
ikemefula: разумеется, это истина из разряда абсолютных.
У меня крепнет подозрение, что в твоём мозге остаётся только последняя фраза.
I>Более того — даже на уровень выше уровня правил тоже не каждый добирается, прикинь ?
Беда.
I>Я уже говорил — не надо злоупотреблять абсолютными истинами.
Что же мне делать? Как мне быть?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
I>>Ну допустим. И что это менят ? Компьютер все равно мощнее в 1000 раз того компьютера, который в шахматах порвал топ 1 а результата нет. I>>Как ни крути, это нельзя отменить твоими гыгыками.
T>Да просто смешно. То, что разницу в производительности нельзя отменить гыгыками не отменяет самих гыгыков насчёт твоего ответа.
Разница не в производительности а в сложности задачи.
I>>>>Да, компьютер сделал 9 ходов подряд. Профессионал с которым была игра давно ушел во второй эшелон, он играет на уровне сильных любителей. T>>>Хорошо, что "на уровне сильных любителей". Не так давно было "не может уделать среднего любителя". I>>Не может. Потому и играет с профессионалом(номинально, из хилых) на ученической (9 камней — ученическая) форе.
T>На среднем любителе его не проверяли.
В том то и дело, нечего проверять.
I>>Нет прогресса. Прогресс будет когда этот комп возьмет уровень в игре на равных против настоящего любителя.
T>Кто такой "настоящий любитель"? Чем он отличается от среднего любителя?
Настоящий это такой что бы компьютер обыграл его на равных в турнире и разработчики получили свой миллион долларов.
I>>Кроме того, есть мнение, что проф этот играл крайне слабо.
T>8-й профессиональный дан. Как ни крути, а это круто.
Это не круто. Про. даны получают за достижения на турнирах и кол.во партий, со временем этот разряд не понижается, как бы плохо ни играл человек.
Этот профессионал уже скатился в любители и играет с ними — на проф. турнирах у него нет никакого перформанса.
Т.е. от любителей его отделяет членство в проф. ассоциации, а не сила игры.
I>>Ты сам то понял что процитировал ? Нет разницы между сильным любителем и профессионалом второго эшелона. Я же тебе сказал — этот про ничем вобщем не выделялся и его место во втором эшелоне.
T>Ни о каком "втором эшелоне" в моей цитате речи не идёт.
Идет, только ты про это не понял.
T>8-й дан это круто.
Это не круто, этот профессионал из тех, кто уже не в состоянии зарабатывать игрой.
T>"Пять десятков" и "профессиональный" это совершенно различные вещи. Ты, видимо, считаешь, что профессионалов в мире всего пять десятков. А также считаешь, что сдать экзамен на восьмой дан просто.
Нет экзамена на восьмой дан. И этот профессионал уже не выступает в проф. турнирах, только в любительских. Он только формально профессионал.
I>>Разумеется, это истина из ряда абсолютных. И до моего уровня не каждый добирается. И до уровня много слабее не каждый добирается.
T>Гыгык.
Видишь, тебе самому от своего бреда.
I>>Я уже говорил — не надо злоупотреблять абсолютными истинами.
T>Что же мне делать? Как мне быть?
Здравствуйте, thesz, Вы писали:
T>Восстановим последовательность событий: T>
T>>>Да, я очень сильный.
I>>>Балаболка.
T>>Я жму лёжа 135 кг. А до того, как повредил колено, мог присесть со штангой в 190 кг.
T>>Я действительно сильный.
T>Что мы здесь видим? Мы видим, что на фразу "Да, я очень сильный" был ответ "Балаболка". Ikemefula не удосужился проверить, сильный ли его оппонент и наградил его нелестным эпитетом, означающим "брехун" или "пустомеля".
Ну если ты знаешь обо мне лучше меня, почему бы мне не попробовать такой же прием относительно тебя ?
Ты ведь вещал чего то про мою область деятельсности ,почему бы мне не назвать тебя за подобное балаболкой ?
А сильный ты или нет, разницы не меняет.
> В ответ на приведённые thesz доказательства физической его силы Ikemefula продолжает настаивать на своём, продолжая называть thesz брехуном.
Где доказательства, твои слова что ли ? Но вообще мне все равно, сильный ты или нет, балаболка ты по другой причине.
T>Как легко убедиться любому умеющему читать, Ikemefula предпочитает стоять на своём не обращая внимания на очевидные факты.
Я внимание то обращаю, но в первую очередь считаю тебя балаболкой а жим и сед дела не меняют.
T>Можно предположить, что Ikemefula демонстрирует такое поведение и в других сферах деятельности, но это выходит за отведённые нам рамки.
Пользуюсь твоим же примером.
I>>Я не отказываюсь от того что знаю просто из за форумного трындежа. А спор это больше для развлекухи.
T>Но ты и не стремишься узнать что-то новое. Изменить своё мнение. Или я неправ?
Нет, ты не прав. Я правда не стремлюсь поменять мнение, но чтото новое узнаю постоянно.
T>Если я неправ, приведи ссылку, где кому-то удалось заставить тебя изменить своё мнение. Или где ты самостоятельно его изменил, хорошенько подумав. T>Мне действительно интересно.
На этом форуме последний раз было в разговоре с kuj по поводу Silverlight.
I>>Ты не понял — компьютер делал 9 ходов подряд. Среднему любителю надо 6-7. И сравнивать нужно соотвественно с любителем, пока что компьютер в начале партии делает столько ошибок, что менее 6 камней форы играет очень нестабильно — разброс примерно в 8 уровней(1 уровень — 1 камень форы).
T>Да понял я, понял. Про разницу в рангах в статье про Го есть. А я умею читать.
Ага, википедия да ? Разницы в проф. рангах никакой нет. Разряд не понижается со временем как бы провально не играл хозяин ранга. А вот в любительских или понижается или же есть рейтинг силы игры относительно других любителей.
T>Хорошо. Этим ответом я его заканчиваю.
Договорились — в случае чего я тебе напомню.
T>>>На US Go Congress это тоже сочли прорывом. I>>Прорывом был сам факт игры а не перформанс.
T>То, что он выиграл.
Неубедительная победа для прорыва — правильнее сказать, что это победа над бывшим профессионалом, потому что по факту он такой и есть — в проф. турнирах ничего нет, пошел в любительские.
T>Что же тобой выделено ниже? I>>>>Нет никакого прорыва — черепаха переползла линию старта.
Вот, смотри, что же было выделено.
T>>>Зачем ликбез? Приведи обсуждение того события на форумах, посвящённых Го. Чем больше форум, тем лучше. I>>На полном серьезе — давай оговорим сначала мой профит а потом я показывают тебе ссылки, идёт ?
T>Я буду считать тебя вменяемым собеседником, это дорогого стоит.
Мне твое мнение обо мне мягко говоря не интересно.
I>>Будут качественные, с комментариями других сильных игроков и возможно профессионалов. Но сначала профит. T>Да брось ты, нет у тебя ничего.
T>Время да ресурсы оттягиваешь, только чтобы ничего не делать.
Давай по простому — 100$ через посредника.
I>>>>Вот еще одно высказывание из ряда абсолютных истин. T>>>Но ведь это так! I>>Я ведь не спорю. T>Ура!
Чему ты радуешься ? Абсолютные истины сиречь тавтология. Перечитай четыре строки выше.
T>>>А если неправ, то где? I>>В том то и дело, что все это абсолютные истины. Ты лучше true повторяй, эффекту будет столько же.
T>Хорошо. Что мне нужно было сделать вместо упоминания о конструктивной математике?
Тебе вообще не нужно было упоминать это. Если бы ты промолчал, толку было бы больше.
"Если ты можешь описать какую-то область математически в конструктивном ключе, то ты можешь запрограммировать решение её проблем."
Вот это высказывание есть абсолютная истина.
Твое высказывание означает примерно следующее — если есть инструмент, то его можно применить
Представь себе, я это хорошо знаю. От ответа про O(1) ты ушел, стало быть больше от тебя ждать нечего.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, thesz, Вы писали:
T>>Восстановим последовательность событий: T>>
T>>>Да, я очень сильный.
I>>>>Балаболка.
T>>>Я жму лёжа 135 кг. А до того, как повредил колено, мог присесть со штангой в 190 кг.
T>>>Я действительно сильный.
T>>Что мы здесь видим? Мы видим, что на фразу "Да, я очень сильный" был ответ "Балаболка". Ikemefula не удосужился проверить, сильный ли его оппонент и наградил его нелестным эпитетом, означающим "брехун" или "пустомеля". I>Ну если ты знаешь обо мне лучше меня, почему бы мне не попробовать такой же прием относительно тебя ?
Я говорил о нашем общем опыте, об опыте программирования.
Точнее, даже об опыте написания программ — который у всех примерно одинаков.
I>Ты ведь вещал чего то про мою область деятельсности ,почему бы мне не назвать тебя за подобное балаболкой ?
Я так думаю, что термин пустобрёх был бы более подходящ именно там, а не в месте, где я на самом деле прав.
I>А сильный ты или нет, разницы не меняет.
О, да. Разницу никто изменить не в состоянии.
Вот дело изменить можно, даже устойчивое словосочетание есть "меняет дело".
>> В ответ на приведённые thesz доказательства физической его силы Ikemefula продолжает настаивать на своём, продолжая называть thesz брехуном. I>Где доказательства, твои слова что ли ?
Видео есть на ты-трубе, народ меня видел.
I>Но вообще мне все равно, сильный ты или нет, балаболка ты по другой причине.
Наверное, было бы уместней называть меня балаболкой там, где я таковым являюсь.
Предоставив, конечно, доказательство моего балабольства.
T>>Как легко убедиться любому умеющему читать, Ikemefula предпочитает стоять на своём не обращая внимания на очевидные факты. I>Я внимание то обращаю, но в первую очередь считаю тебя балаболкой а жим и сед дела не меняют.
О! Уже дело не меняют.
А разницу меняют?
Вот лично я могу тебя назвать тупым болваном в любом месте моего ответа, поскольку ты тупой болван в любом своём проявлении.
Я же балаболка только в том, что касается никому не известных контекстов, что ты описываешь у себя на работе. Да и то — я "балабол" в желательном наклонении, так сказать. Не объективно, с доказательствами, а субъективно, по твоему заявлению.
Рядом же с тем, что я могу подтвердить, никак нельзя ставить определение меня, как пустомели.
Это всё семантика, но точно такая же семантика используется и при описании контекстов.
Поэтому мне описывать контексты легко, а у тебя неописуемое в ежедневной работе.
T>>Можно предположить, что Ikemefula демонстрирует такое поведение и в других сферах деятельности, но это выходит за отведённые нам рамки. I>Пользуюсь твоим же примером.
Повторюсь, поскольку это единственное, что мне осталось.
Если бы ты показал, что твои контексты сложны в описании, тогда можно было бы называть меня болтуном. И то, только там, где мы разговариваем о твоих сложных контекстах.
Поскольку ты не показал, что твои контексты сложны в описании, я могу предполагать что угодно. Например, основываться на своём опыте. А мой опыт говорит, что у всех контексты просты в описании, надо только инструмент подобрать.
Ты же назвал меня балаболом, когда я сказал, что я сильный. Но тому есть доказательства, их много. Поэтому я не могу быть назван балаболом, когда говорю о своей силе.
Я тебе на это указал. Ты продолжаешь упорствовать. Более того, ты сравниваешь наши ситуации и считаешь, что волен обзывать меня, пользуясь моим примером.
Но я тебя не обзывал. Я всего лишь сказал, что твои контексты также просты в описании, как и чьи-либо ещё.
Поэтому ситуации у нас разные.
Поэтому ты — тупой болван.
I>>>Я не отказываюсь от того что знаю просто из за форумного трындежа. А спор это больше для развлекухи. T>>Но ты и не стремишься узнать что-то новое. Изменить своё мнение. Или я неправ? I>Нет, ты не прав. Я правда не стремлюсь поменять мнение, но чтото новое узнаю постоянно.
Стремишься или просто узнаешь? Стремишься, или в тебя впихивают это новое, бия им по голове, когда ты в очередной раз проявляешь свои ярчайшие качества?
Если только второе, то ты никогда не поменяешь свою позицию. Так и останешься и тупым, и болваном.
BTW, один из критериев G-фактора — стремление обобщить полученные знания, встроить их в картину мира. Поменять её, сделать стройней.
T>>Если я неправ, приведи ссылку, где кому-то удалось заставить тебя изменить своё мнение. Или где ты самостоятельно его изменил, хорошенько подумав. T>>Мне действительно интересно. I>На этом форуме последний раз было в разговоре с kuj по поводу Silverlight.
При поиске была обнаружена сепулька!
I>>>Ты не понял — компьютер делал 9 ходов подряд. Среднему любителю надо 6-7. И сравнивать нужно соотвественно с любителем, пока что компьютер в начале партии делает столько ошибок, что менее 6 камней форы играет очень нестабильно — разброс примерно в 8 уровней(1 уровень — 1 камень форы). T>>Да понял я, понял. Про разницу в рангах в статье про Го есть. А я умею читать. I>Ага, википедия да ? Разницы в проф. рангах никакой нет. Разряд не понижается со временем как бы провально не играл хозяин ранга. А вот в любительских или понижается или же есть рейтинг силы игры относительно других любителей.
Базы данных рейтинга профессионалов Go я не нашёл (потому, что ELO мало популярен), поэтому здесь снова та же ситуация: твои слова без каких-либо доказательств супротив известных фактов, что у противника компьютера был 8 дан и что 8-й дан просто так не дают.
Лично я думаю, что здесь было бы уместным представить рейтинг Myungwan Kim, чтобы я мог проникнуться и сравнить его с рейтингами других игроков.
T>>Хорошо. Этим ответом я его заканчиваю. I>Договорились — в случае чего я тебе напомню.
Спасибо. Буду весьма признателен.
T>>>>На US Go Congress это тоже сочли прорывом. I>>>Прорывом был сам факт игры а не перформанс. T>>То, что он выиграл. I>Неубедительная победа для прорыва — правильнее сказать, что это победа над бывшим профессионалом, потому что по факту он такой и есть — в проф. турнирах ничего нет, пошел в любительские.
У него 8p. Покажи, пожалуйста, историю его игр и рейтинг, чтобы я мог убедиться воочию.
T>>Что же тобой выделено ниже? I>>>>>Нет никакого прорыва — черепаха переползла линию старта. I>Вот, смотри, что же было выделено.
Что же?
T>>>>Зачем ликбез? Приведи обсуждение того события на форумах, посвящённых Го. Чем больше форум, тем лучше. I>>>На полном серьезе — давай оговорим сначала мой профит а потом я показывают тебе ссылки, идёт ? T>>Я буду считать тебя вменяемым собеседником, это дорогого стоит. I>Мне твое мнение обо мне мягко говоря не интересно.
Другие будут считать тебя вменяемым собеседником. Это тоже дорогого стоит.
I>>>Будут качественные, с комментариями других сильных игроков и возможно профессионалов. Но сначала профит. T>>Да брось ты, нет у тебя ничего. T>>Время да ресурсы оттягиваешь, только чтобы ничего не делать. I>Давай по простому — 100$ через посредника.
Давай.
Передавай деньги lomeo, допустим. Или vshabanov. Или, если хочешь, прямо мне без посредников, когда будешь в Москве.
Можешь с деньгами не спешить, это не очень важно.
Лучше расскажи то, о чём я тебя прошу.
I>>>>>Вот еще одно высказывание из ряда абсолютных истин. T>>>>Но ведь это так! I>>>Я ведь не спорю. T>>Ура! I>Чему ты радуешься ? Абсолютные истины сиречь тавтология. Перечитай четыре строки выше.
Их уже пять. Читать первые четыре или последние четыре? Или какие-то отдельные четыре строки? Какую пропускать в таком случае?
T>>>>А если неправ, то где? I>>>В том то и дело, что все это абсолютные истины. Ты лучше true повторяй, эффекту будет столько же. T>>Хорошо. Что мне нужно было сделать вместо упоминания о конструктивной математике? I>Тебе вообще не нужно было упоминать это. Если бы ты промолчал, толку было бы больше.
Не думаю. Я, например, выяснил, что ты тупой болван. Теперь ещё знаю, что у тебя нет вкуса и чувства юмора.
Толк, несомненно, есть.
I>"Если ты можешь описать какую-то область математически в конструктивном ключе, то ты можешь запрограммировать решение её проблем." I>Вот это высказывание есть абсолютная истина.
Вообще-то, здесь присутствует [b]условие{/b]. Эта штука фальсифицируема, условие опровержения очень простое: описываемую сущность нельзя описать конструктивно.
Поэтому моё высказывание не является абсолютной истиной.
I>Твое высказывание означает примерно следующее — если есть инструмент, то его можно применить
Моё высказывание означает что если есть инструмент, то его можно применять только в определённых условиях.
I>Представь себе, я это хорошо знаю. От ответа про O(1) ты ушел, стало быть больше от тебя ждать нечего.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, thesz, Вы писали:
I>>>Ну допустим. И что это менят ? Компьютер все равно мощнее в 1000 раз того компьютера, который в шахматах порвал топ 1 а результата нет. I>>>Как ни крути, это нельзя отменить твоими гыгыками.
T>>Да просто смешно. То, что разницу в производительности нельзя отменить гыгыками не отменяет самих гыгыков насчёт твоего ответа. I>Разница не в производительности а в сложности задачи.
Это не отменяет источника радости в твоём ответе.
Да что там, в твоих ответах!
I>>>>>Да, компьютер сделал 9 ходов подряд. Профессионал с которым была игра давно ушел во второй эшелон, он играет на уровне сильных любителей. T>>>>Хорошо, что "на уровне сильных любителей". Не так давно было "не может уделать среднего любителя". I>>>Не может. Потому и играет с профессионалом(номинально, из хилых) на ученической (9 камней — ученическая) форе. T>>На среднем любителе его не проверяли. I>В том то и дело, нечего проверять.
Его не проверяли, это факт. "Нечего проверять" — это твои слова.
Факты выигрывают у слов.
I>>>Нет прогресса. Прогресс будет когда этот комп возьмет уровень в игре на равных против настоящего любителя. T>>Кто такой "настоящий любитель"? Чем он отличается от среднего любителя? I>Настоящий это такой что бы компьютер обыграл его на равных в турнире и разработчики получили свой миллион долларов.
И так у нас всегда.
I>>>Кроме того, есть мнение, что проф этот играл крайне слабо. T>>8-й профессиональный дан. Как ни крути, а это круто. I>Это не круто. Про. даны получают за достижения на турнирах и кол.во партий, со временем этот разряд не понижается, как бы плохо ни играл человек.
Ну, тогда покажи его рейтинг.
I>Этот профессионал уже скатился в любители и играет с ними — на проф. турнирах у него нет никакого перформанса.
Я не нашёл в сети тому подтверждения.
I>Т.е. от любителей его отделяет членство в проф. ассоциации, а не сила игры.
Я не нашёл этому подтверждения.
I>>>Ты сам то понял что процитировал ? Нет разницы между сильным любителем и профессионалом второго эшелона. Я же тебе сказал — этот про ничем вобщем не выделялся и его место во втором эшелоне. T>>Ни о каком "втором эшелоне" в моей цитате речи не идёт. I>Идет, только ты про это не понял.
Да, я дурак.
Это полезно, считать оппонента дураком.
T>>8-й дан это круто. I>Это не круто, этот профессионал из тех, кто уже не в состоянии зарабатывать игрой.
Бедный 31-летний мужик. Вот же ему не повезло!
Ещё только в конце прошлого года играл на чемионатах уровня US Go Congress, а как проиграл компьютеру, так скатился во второй эшелон.
Пьёт, наверное. Потому и сдал.
T>>"Пять десятков" и "профессиональный" это совершенно различные вещи. Ты, видимо, считаешь, что профессионалов в мире всего пять десятков. А также считаешь, что сдать экзамен на восьмой дан просто. I>Нет экзамена на восьмой дан. И этот профессионал уже не выступает в проф. турнирах, только в любительских. Он только формально профессионал.
А тогда, на момент своей игры с компьютером, он был реально профессионал?
А подтверждение или опровержение тому где-либо в сети есть?
I>>>Разумеется, это истина из ряда абсолютных. И до моего уровня не каждый добирается. И до уровня много слабее не каждый добирается. T>>Гыгык. I>Видишь, тебе самому от своего бреда.
Тебе тоже 31 год? Ты тоже сдал от проигрыша компьютеру?
Я за тебя беспокоюсь.
Ты даже издёвку закончить не можешь.
I>>>Я уже говорил — не надо злоупотреблять абсолютными истинами. T>>Что же мне делать? Как мне быть? I>Тебе уже ничего не поможет.
Ай!
Я пропал!
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>Да просто смешно. То, что разницу в производительности нельзя отменить гыгыками не отменяет самих гыгыков насчёт твоего ответа. I>>Разница не в производительности а в сложности задачи.
T>Это не отменяет источника радости в твоём ответе.
T>Да что там, в твоих ответах!
Я в курсе. Ты главноене останавливайся.
I>>>>>>Да, компьютер сделал 9 ходов подряд. Профессионал с которым была игра давно ушел во второй эшелон, он играет на уровне сильных любителей. T>>>>>Хорошо, что "на уровне сильных любителей". Не так давно было "не может уделать среднего любителя". I>>>>Не может. Потому и играет с профессионалом(номинально, из хилых) на ученической (9 камней — ученическая) форе. T>>>На среднем любителе его не проверяли. I>>В том то и дело, нечего проверять.
T>Его не проверяли, это факт. "Нечего проверять" — это твои слова. T>Факты выигрывают у слов.
Иными словам ты дальше википедии не видишь, потому и не в курсе что же означает 1 про дан.
T>И так у нас всегда.
Да, так всегда — ты говоришь совершенно не представляя того, о чем речь.
I>>Это не круто. Про. даны получают за достижения на турнирах и кол.во партий, со временем этот разряд не понижается, как бы плохо ни играл человек.
T>Ну, тогда покажи его рейтинг.
10297 12/31/2099 Comp Feng Yun Go School NJ 9.79502 0.38434 9/1/2008 Feng, Yun
10298 12/31/2199 Comp CA 9.62704 0.26327 2/1/2009 Jiang, Ming Jiu
16670 6/17/2009 Comp Santa Monica Go Club CA 9.61621 0.59634 9/1/2008 Kim, Myung Wan
9229 10/15/2009 Full VA 9.40566 0.32603 5/1/2009 Li, Jie
15824 9/30/2009 Full Seattle Go Center WA 9.39401 0.28076 10/1/2008 Jang, Bi
9893 6/1/2010 Full New York Wei-chi Society NY 9.34364 0.27879 7/1/2009 Liu, Zhi Yuan [Andy]
Видишь, он на третьем месте даже в Америке. Правда впереди него тоже профы, но сути это не меняет — американская ассоциация любительская де факто.
I>>Этот профессионал уже скатился в любители и играет с ними — на проф. турнирах у него нет никакого перформанса.
T>Я не нашёл в сети тому подтверждения.
Это потому что ты дальше википедии ничего не видишь. Он вроде евангелиста, получает чтото вроде пособия-пенсии за то что учит людей играть в го.
I>>Т.е. от любителей его отделяет членство в проф. ассоциации, а не сила игры.
T>Я не нашёл этому подтверждения.
А где ты искал ? В Мурзилке ?
I>>>>Ты сам то понял что процитировал ? Нет разницы между сильным любителем и профессионалом второго эшелона. Я же тебе сказал — этот про ничем вобщем не выделялся и его место во втором эшелоне. T>>>Ни о каком "втором эшелоне" в моей цитате речи не идёт. I>>Идет, только ты про это не понял.
T>Да, я дурак.
Самокритично, не ожидал.
T>>>8-й дан это круто. I>>Это не круто, этот профессионал из тех, кто уже не в состоянии зарабатывать игрой.
T>Бедный 31-летний мужик. Вот же ему не повезло! T>Ещё только в конце прошлого года играл на чемионатах уровня US Go Congress, а как проиграл компьютеру, так скатился во второй эшелон.
US Go Open это любительский турнир вобще то по статусу.
Покажешь там US GO Open — дам 1000 долларов.
T>Пьёт, наверное. Потому и сдал.
Ты главное не сдавайся, я эту беседу потом транслирую в гошный форум а особо яростные выпады даже на блог свой засуну в разделе юмора. ты войдешь в историю.
I>>Нет экзамена на восьмой дан. И этот профессионал уже не выступает в проф. турнирах, только в любительских. Он только формально профессионал.
T>А тогда, на момент своей игры с компьютером, он был реально профессионал?
Он профессионал где то с 94го года и до сих пор им является. Но он вобщем то не может заработать своей игрой в профлиге ибо побед как то маловато.
Проф. даны начисляются за определенное количество побед над другими про, при чем без разницы, у кого победа — у топа или у пенсионера.
В то время, когда он получил свой 8д еще не было разделения на мажорные, минорные и тд турниры и все игры шли в зачет.
Понижения разряда не предусмотрено в принципе.
T>А подтверждение или опровержение тому где-либо в сети есть?
Про него почти нет информаци, потому что не было результатов заметных.
Вот его последние успехи — нашел где то три победы в отборочных
Здравствуйте, thesz, Вы писали:
T>>>Что мы здесь видим? Мы видим, что на фразу "Да, я очень сильный" был ответ "Балаболка". Ikemefula не удосужился проверить, сильный ли его оппонент и наградил его нелестным эпитетом, означающим "брехун" или "пустомеля".
Не наградил, а обнаружил свойство и опубликовал сей факт.
I>>Ну если ты знаешь обо мне лучше меня, почему бы мне не попробовать такой же прием относительно тебя ?
T>Я говорил о нашем общем опыте, об опыте программирования.
берем контекст выше по ветке
I>Точнее результатов у тебя никаких нет но ты чего то силишься додумать.
T>Да, я очень сильный.
I>Балаболка.
T>Я жму лёжа 135 кг. А до того, как повредил колено, мог присесть со штангой в 190 кг.
T>Я действительно сильный.
Видно что ты занят тем что и обычно — подменой понятий. Посему твое высказыние ">Я говорил о нашем общем опыте, об опыте программирования."
есть еще и враньё.
то есть ты не только балаболка но и врунишка.
I>>Ты ведь вещал чего то про мою область деятельсности ,почему бы мне не назвать тебя за подобное балаболкой ?
T>Я так думаю, что термин пустобрёх был бы более подходящ именно там, а не в месте, где я на самом деле прав.
Оно так и появилось — сразу же когда ты свернул в сторону и начал молоть чушь "Я сильный".
T>Видео есть на ты-трубе, народ меня видел.
Да расслабься, мне буквально фиолетово, сильный ты или нет. Ну сильный, ну жмешь 135, что с того ?
Сам факт что ты свернул на жим доказывает что ты балаболка.
I>>Но вообще мне все равно, сильный ты или нет, балаболка ты по другой причине. T>Наверное, было бы уместней называть меня балаболкой там, где я таковым являюсь.
Так и было сделано.
T>Предоставив, конечно, доказательство моего балабольства.
См. выше. там же доказательсва что ты и врунишка вдобавок.
T>>>Как легко убедиться любому умеющему читать, Ikemefula предпочитает стоять на своём не обращая внимания на очевидные факты. I>>Я внимание то обращаю, но в первую очередь считаю тебя балаболкой а жим и сед дела не меняют.
T>О! Уже дело не меняют.
нет конечно. балабока ты потому, что свернул в сторону.
T>Я же балаболка только в том, что касается никому не известных контекстов, что ты описываешь у себя на работе. Да и то — я "балабол" в желательном наклонении, так сказать. Не объективно, с доказательствами, а субъективно, по твоему заявлению.
ты балаболка потому что подменяешь понятия направо и налево. ты еще десять раз напиши про жим — это все будет доказательсвтом того что ты балаболка.
T>>>Можно предположить, что Ikemefula демонстрирует такое поведение и в других сферах деятельности, но это выходит за отведённые нам рамки. I>>Пользуюсь твоим же примером.
T>Поскольку ты не показал, что твои контексты сложны в описании, я могу предполагать что угодно.
Разумеется, я не собираюсь доказывать что я не верблюд. Кто что говорит, тот то и доказывает.
Ты ведь скаал что мои случаи простые, так ведь ? Вот и докажи своё же бред.
T>Ты же назвал меня балаболом, когда я сказал, что я сильный. Но тому есть доказательства, их много. Поэтому я не могу быть назван балаболом, когда говорю о своей силе.
Ты балаболка потому что подменяешь понятия когда нечего ответить.
T>Я тебе на это указал. Ты продолжаешь упорствовать. Более того, ты сравниваешь наши ситуации и считаешь, что волен обзывать меня, пользуясь моим примером. T>Но я тебя не обзывал. Я всего лишь сказал, что твои контексты также просты в описании, как и чьи-либо ещё.
Я тебя не обзывал, просто констатировал факт.
T>BTW, один из критериев G-фактора — стремление обобщить полученные знания, встроить их в картину мира. Поменять её, сделать стройней.
Ух какая умная ссылка. Снова на Википедию !
Слушай, а в Википедии нет странички случаем как ты обыграл меня в го ? Может сразу такую ссылку дашь ?
I>>Ага, википедия да ? Разницы в проф. рангах никакой нет. Разряд не понижается со временем как бы провально не играл хозяин ранга. А вот в любительских или понижается или же есть рейтинг силы игры относительно других любителей.
T>Это называется ELO rating. Он не очень популярен в Go.
Это не обязательно ELO. Elo — это один из алгоритмов рейтинговых систем. не надо злоупотреблять википедией.
T>Базы данных рейтинга профессионалов Go я не нашёл (потому, что ELO мало популярен), поэтому здесь снова та же ситуация: твои слова без каких-либо доказательств супротив известных фактов, что у противника компьютера был 8 дан и что 8-й дан просто так не дают.
Разумеется, ты не нашел. Потому что не искал. Зашел бы на мой блог, который ты мог видеть в поиске, когда делал всякиезапросы по Mad Hollander, то наверняка бы нашел.
T>Лично я думаю, что здесь было бы уместным представить рейтинг Myungwan Kim, чтобы я мог проникнуться и сравнить его с рейтингами других игроков.
Профа этого зовут так 김명완, по моему самая высокая позиция — 31 в дек. 2005го. В 2002м возможно был где то во втором десятке, но нет сведений.
Корейцы публикуют тоьлко 50 позиций. в 2008м его нет вообще. Так шта...
T>>>Хорошо. Этим ответом я его заканчиваю. I>>Договорились — в случае чего я тебе напомню.
T>Спасибо. Буду весьма признателен.
Напиминаю — ты уже дважды нарушил обещание.
I>>Неубедительная победа для прорыва — правильнее сказать, что это победа над бывшим профессионалом, потому что по факту он такой и есть — в проф. турнирах ничего нет, пошел в любительские.
T>У него 8p. Покажи, пожалуйста, историю его игр и рейтинг, чтобы я мог убедиться воочию.
история игр проф. такого класса не записывается специально, разве что он сыграет с топами
У меня в базе есть штук двадцать его партий, при этом у топов в базе от 100 более партии.
I>>Вот, смотри, что же было выделено. T>Что же?
черепаха переползла линию старта
Так видно ?
I>>Мне твое мнение обо мне мягко говоря не интересно. T>Другие будут считать тебя вменяемым собеседником. Это тоже дорогого стоит.
Ты знаешь, я мне и это не интересно.
I>>Давай по простому — 100$ через посредника. T>Давай.
Назови посредника, что бы я его знал хотя бы по форуму, можно из числа форумчан. Посредник должен дать знать например на емейл, что деньги получены , гарантирует передачу их мне в случае выполнение определенных условий — предоставления ссылок на обсуждение той партии, а после этого я выкладываю ссылки.
T>Лучше расскажи то, о чём я тебя прошу.
Я предложил свои условия. Хочешь — соглашайся, хочешь — нет.
T>Толк, несомненно, есть.
Спасибо, о великий человек !
T>Вообще-то, здесь присутствует [b]условие{/b]. Эта штука фальсифицируема, условие опровержения очень простое: описываемую сущность нельзя описать конструктивно.
"существует язык, в котором можно описать любое выбранное множество"
Стало быть твоя штукенция нефальсифицируема.
I>>Твое высказывание означает примерно следующее — если есть инструмент, то его можно применить
T>Моё высказывание означает что если есть инструмент, то его можно применять только в определённых условиях.
Это тебе так кажется.
I>>Представь себе, я это хорошо знаю. От ответа про O(1) ты ушел, стало быть больше от тебя ждать нечего.
T>Размер программы решения SAT-задачи не изменится от размерности задачи SAT.
Ну вот, ты ловко все свел к частному случаю. Началось с языков, контекстов, потом перешло на множества, а свелость к SAT.
Очень круто ! Впечатляет !
Почему бы не свести все к аксиомам евклидовой геометрии ?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, thesz, Вы писали:
T>>Ну, тогда покажи его рейтинг. I>
I>10297 12/31/2099 Comp Feng Yun Go School NJ 9.79502 0.38434 9/1/2008 Feng, Yun
I>10298 12/31/2199 Comp CA 9.62704 0.26327 2/1/2009 Jiang, Ming Jiu
I>16670 6/17/2009 Comp Santa Monica Go Club CA 9.61621 0.59634 9/1/2008 Kim, Myung Wan
I>9229 10/15/2009 Full VA 9.40566 0.32603 5/1/2009 Li, Jie
I>15824 9/30/2009 Full Seattle Go Center WA 9.39401 0.28076 10/1/2008 Jang, Bi
I>9893 6/1/2010 Full New York Wei-chi Society NY 9.34364 0.27879 7/1/2009 Liu, Zhi Yuan [Andy]
I>
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, thesz, Вы писали:
T>>>>Что мы здесь видим? Мы видим, что на фразу "Да, я очень сильный" был ответ "Балаболка". Ikemefula не удосужился проверить, сильный ли его оппонент и наградил его нелестным эпитетом, означающим "брехун" или "пустомеля". I>Не наградил, а обнаружил свойство и опубликовал сей факт.
"Обнаружил"
Знаешь, сколько было до тебя таких первопроходцев?..
I>>>Ну если ты знаешь обо мне лучше меня, почему бы мне не попробовать такой же прием относительно тебя ? T>>Я говорил о нашем общем опыте, об опыте программирования. I>берем контекст выше по ветке I>
I>>Точнее результатов у тебя никаких нет но ты чего то силишься додумать.
T>>Да, я очень сильный.
I>>Балаболка.
T>>Я жму лёжа 135 кг. А до того, как повредил колено, мог присесть со штангой в 190 кг.
T>>Я действительно сильный.
I>Видно что ты занят тем что и обычно — подменой понятий. Посему твое высказыние ">Я говорил о нашем общем опыте, об опыте программирования." I>есть еще и враньё. I>то есть ты не только балаболка но и врунишка.
"Reconsider that" (C) Texas, "Summer son"
I>>>Ты ведь вещал чего то про мою область деятельсности ,почему бы мне не назвать тебя за подобное балаболкой ?
T>>Я так думаю, что термин пустобрёх был бы более подходящ именно там, а не в месте, где я на самом деле прав.
I>Оно так и появилось — сразу же когда ты свернул в сторону и начал молоть чушь "Я сильный".
T>>Видео есть на ты-трубе, народ меня видел.
I>Да расслабься, мне буквально фиолетово, сильный ты или нет. Ну сильный, ну жмешь 135, что с того ?
Это такой риторический приём. Долго объяснять.
I>Сам факт что ты свернул на жим доказывает что ты балаболка.
Нихрена. Там по контексту была такая возможность. Правда, чтобы это понять, надо иметь чувство юмора и вкус.
T>>Предоставив, конечно, доказательство моего балабольства. I>См. выше. там же доказательсва что ты и врунишка вдобавок.
Это надо было предоставлять там, где ты назвал меня брехуном. А не постфактум.
Предоставленное тобой является просто натягиванием "подмены понятий" на юмористический оборот.
Я бы, пожалуй, заплатил бы за возможность посмотреть, как ты Чарли Чаплина смотришь.
T>>>>Как легко убедиться любому умеющему читать, Ikemefula предпочитает стоять на своём не обращая внимания на очевидные факты. I>>>Я внимание то обращаю, но в первую очередь считаю тебя балаболкой а жим и сед дела не меняют. T>>О! Уже дело не меняют. I>нет конечно. балабока ты потому, что свернул в сторону.
Так это ж понятно, почему. Я же решил развлекаться, как только понял, что с тобой разговаривать бесполезно.
Ты, видимо, пропустил это мимо ушей. Но в форуме это есть, на всякий случай.
T>>Я же балаболка только в том, что касается никому не известных контекстов, что ты описываешь у себя на работе. Да и то — я "балабол" в желательном наклонении, так сказать. Не объективно, с доказательствами, а субъективно, по твоему заявлению. I>ты балаболка потому что подменяешь понятия направо и налево. ты еще десять раз напиши про жим — это все будет доказательсвтом того что ты балаболка.
Я прусь от возможности потыкать тебя палочкой.
У тебя реакции на одни и те же воздействия совершенно разные и непредсказуемые. Такое бывает в случае либо человека сильно умней меня, либо сильно глупей.
Поскольку вывод я уже сделал, я просто развлекаюсь.
Правда, количество гыгыков на строку моего сообщения сильно упало из-за низкого количества вариантов твоих ответов.
Я в сомнении, что мне делать дальше.
T>>>>Можно предположить, что Ikemefula демонстрирует такое поведение и в других сферах деятельности, но это выходит за отведённые нам рамки. I>>>Пользуюсь твоим же примером. T>>Поскольку ты не показал, что твои контексты сложны в описании, я могу предполагать что угодно. I>Разумеется, я не собираюсь доказывать что я не верблюд. Кто что говорит, тот то и доказывает. I>Ты ведь скаал что мои случаи простые, так ведь ? Вот и докажи своё же бред.
Ты программист.
По опыту, все встречавшиеся мне контексты, описываемые программистами, не были сложными.
Описываемые тобой контексты не являются сложными.
QED
T>>BTW, один из критериев G-фактора — стремление обобщить полученные знания, встроить их в картину мира. Поменять её, сделать стройней. I>Ух какая умная ссылка. Снова на Википедию !
А почему нет?
I>Слушай, а в Википедии нет странички случаем как ты обыграл меня в го ? Может сразу такую ссылку дашь ?
Нет. Там всё достаточно близко к правде. Как в обычной энциклопедии, только скорость оборота больше.
T>>Базы данных рейтинга профессионалов Go я не нашёл (потому, что ELO мало популярен), поэтому здесь снова та же ситуация: твои слова без каких-либо доказательств супротив известных фактов, что у противника компьютера был 8 дан и что 8-й дан просто так не дают. I>Разумеется, ты не нашел. Потому что не искал. Зашел бы на мой блог, который ты мог видеть в поиске, когда делал всякиезапросы по Mad Hollander, то наверняка бы нашел.
Заходил на твой блог. На паре первых страниц не было ничего интересного.
Я же к Го отношусь, как к обычным настольным играм — есть времяпрепровождение поинтересней и по полезней.
Например, приседания.
T>>Лично я думаю, что здесь было бы уместным представить рейтинг Myungwan Kim, чтобы я мог проникнуться и сравнить его с рейтингами других игроков. I>http://cyberoro.com/news/rank.htm?category=1 I>Профа этого зовут так 김명완, по моему самая высокая позиция — 31 в дек. 2005го. В 2002м возможно был где то во втором десятке, но нет сведений. I>Корейцы публикуют тоьлко 50 позиций. в 2008м его нет вообще. Так шта...
...мы ничего не можем сказать на самом деле.
T>>>>Хорошо. Этим ответом я его заканчиваю. I>>>Договорились — в случае чего я тебе напомню. T>>Спасибо. Буду весьма признателен. I>Напиминаю — ты уже дважды нарушил обещание.
Нихрена. Перечитай и попробуй подумать. Я закончил спор моим комментарием, а ты продолжил.
После твоего продолжения начался новый спор.
Опять же, он такой дурацкий не по моей вине.
I>>>Вот, смотри, что же было выделено. T>>Что же? I>черепаха переползла линию старта I>Так видно ?
И что это означает?
I>>>Мне твое мнение обо мне мягко говоря не интересно. T>>Другие будут считать тебя вменяемым собеседником. Это тоже дорогого стоит. I>Ты знаешь, я мне и это не интересно.
Да уж.
Доктор Хаус, прямо.
Но тот образован, хотя бы.
I>>>Давай по простому — 100$ через посредника. T>>Давай. I>Назови посредника, что бы я его знал хотя бы по форуму, можно из числа форумчан. Посредник должен дать знать например на емейл, что деньги получены , гарантирует передачу их мне в случае выполнение определенных условий — предоставления ссылок на обсуждение той партии, а после этого я выкладываю ссылки. T>>Лучше расскажи то, о чём я тебя прошу. I>Я предложил свои условия. Хочешь — соглашайся, хочешь — нет.
Какие-то странные условия.
Я же, вроде, сказал, что мне твои деньги особо не нужны, мне больше интересна информация.
T>>Толк, несомненно, есть. I>Спасибо, о великий человек !
Не за что.
T>>Вообще-то, здесь присутствует [b]условие{/b]. Эта штука фальсифицируема, условие опровержения очень простое: описываемую сущность нельзя описать конструктивно. I>"существует язык, в котором можно описать любое выбранное множество" I>Стало быть твоя штукенция нефальсифицируема.
Это ты о чём сейчас?
У меня упоминания аксиомы выбора не было.
I>>>Твое высказывание означает примерно следующее — если есть инструмент, то его можно применить T>>Моё высказывание означает что если есть инструмент, то его можно применять только в определённых условиях. I>Это тебе так кажется.
Опровергни.
Развёрнуто, не одной фразой.
I>>>Представь себе, я это хорошо знаю. От ответа про O(1) ты ушел, стало быть больше от тебя ждать нечего. T>>Размер программы решения SAT-задачи не изменится от размерности задачи SAT. I>Ну вот, ты ловко все свел к частному случаю. Началось с языков, контекстов, потом перешло на множества, а свелость к SAT.
Каков вопрос, таков и ответ.
Ты попросил оценку описания решения задачи SAT, я её привёл.
Я бы хотел увидеть опровержение, и где и как я оказался неправ.
I>Очень круто ! Впечатляет !
Великолепно.
Единственное, что портит картину, это пробелы перед знаками препинания. Их не ставят специально, надо сказать, из-за того, что с пробелами они могут попасть на другую строку.
И получится
Впечатляет
!
что некрасиво.
I>Почему бы не свести все к аксиомам евклидовой геометрии ?
Потому, что это невозможно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
I>>Не наградил, а обнаружил свойство и опубликовал сей факт.
T>"Обнаружил"
T>Знаешь, сколько было до тебя таких первопроходцев?..
Ну значит действительно все в порядке — результат вопспроизводится.
I>>Да расслабься, мне буквально фиолетово, сильный ты или нет. Ну сильный, ну жмешь 135, что с того ?
T>Это такой риторический приём. Долго объяснять.
Я это понял еще тогда когда писал слово балаболка
I>>Сам факт что ты свернул на жим доказывает что ты балаболка.
T>Нихрена. Там по контексту была такая возможность. Правда, чтобы это понять, надо иметь чувство юмора и вкус.
Ну да, была возможность улизнуть и ты её воспользовался.
Я не против, просто ярлычек тебе прилепил на спину, что бы в следующий раз сэкономить время.
I>>См. выше. там же доказательсва что ты и врунишка вдобавок. T>Это надо было предоставлять там, где ты назвал меня брехуном. А не постфактум.
Мне доказательсва не нужны. Они тебе были нужны. Ты про них спросил — я предоставил.
T>У тебя реакции на одни и те же воздействия совершенно разные и непредсказуемые. Такое бывает в случае либо человека сильно умней меня, либо сильно глупей.
У меня и то и другое сразу.
T>По опыту, все встречавшиеся мне контексты, описываемые программистами, не были сложными. T>Описываемые тобой контексты не являются сложными.
Да, логика железная.
I>>Слушай, а в Википедии нет странички случаем как ты обыграл меня в го ? Может сразу такую ссылку дашь ?
T>Нет. Там всё достаточно близко к правде. Как в обычной энциклопедии, только скорость оборота больше.
И наполняют её частенько ламеры а материал слишком общий.
I>>Разумеется, ты не нашел. Потому что не искал. Зашел бы на мой блог, который ты мог видеть в поиске, когда делал всякиезапросы по Mad Hollander, то наверняка бы нашел.
T>Заходил на твой блог. На паре первых страниц не было ничего интересного.
На первой странице как раз рейтингист висит по ссылке.
T>Я же к Го отношусь, как к обычным настольным играм — есть времяпрепровождение поинтересней и по полезней.
T>Например, приседания.
Ну кому что. Я предпочитаю интеллектуальные развлечения. А у тебя наверное на это силов не остаётся
I>>http://cyberoro.com/news/rank.htm?category=1 I>>Профа этого зовут так 김명완, по моему самая высокая позиция — 31 в дек. 2005го. В 2002м возможно был где то во втором десятке, но нет сведений. I>>Корейцы публикуют тоьлко 50 позиций. в 2008м его нет вообще. Так шта...
T>...мы ничего не можем сказать на самом деле.
Мы можем сказать, что в 2008 его не было в 50 первых позициях,
он ушел в любительские турниры
и кроме того, за всю его историю успехов нет — три вторых места в минорном турнире и четверть фнал на одном из чемпионатов мира (таких чемпионатов в год по два три штуки)
T>>>Спасибо. Буду весьма признателен. I>>Напиминаю — ты уже дважды нарушил обещание.
T>Нихрена. Перечитай и попробуй подумать. Я закончил спор моим комментарием, а ты продолжил.
Я то ничего не заканчивал.
T>Опять же, он такой дурацкий не по моей вине.
Ну да, ты не виноват
I>>черепаха переползла линию старта I>>Так видно ?
T>И что это означает?
Это означает что прорыв чисто номинальный. В качестве эталонов выступают профы второго эшелона которые частенько проигрывают сильнейшим любителям в турнирах.
I>>Назови посредника, что бы я его знал хотя бы по форуму, можно из числа форумчан. Посредник должен дать знать например на емейл, что деньги получены , гарантирует передачу их мне в случае выполнение определенных условий — предоставления ссылок на обсуждение той партии, а после этого я выкладываю ссылки.
Ау !!!
T>>>Лучше расскажи то, о чём я тебя прошу. I>>Я предложил свои условия. Хочешь — соглашайся, хочешь — нет.
T>Какие-то странные условия.
Нормальные — я уверен в своей правоте и хочу на этом заработать денег, что бы сходиь в кабак, пропить а потом рассказать у себя в блоге про эту историю.
T>Я же, вроде, сказал, что мне твои деньги особо не нужны, мне больше интересна информация.
Зато мне нужны твои деньги.
T>Это ты о чём сейчас?
О том что ты родил нефальсифицируемую идею.
I>>Это тебе так кажется. T>Опровергни.
Я уже показал что там тавтология. надо было читать.
I>>Почему бы не свести все к аксиомам евклидовой геометрии ?
T>Потому, что это невозможно.
Я верю, что у тебя все возможно. Ты так ловко рассуждаешь про то, чего никогда не видел, не слышал, при чем для всего этого тебе достаточно одной википедии и слешдота.
Очень полезная статья. Натолкнула на решение одной из задач планирования времени работы над проектами.
Благодарю Автора!
Сложность понимания задачи
Полагаю, что аналитик нужен в любом случае. И на крупных и на мелких проектах. Подводные камни -- если заказчик не знает точно что хочет, аналитик должен быть достаточно изобретателен, с высоким уровнем абстрактного мышления и просто обязан разбираться в бизнес-задачах заказчика. Он должен прорабатывать все возможные варианты от начала и до предполагаемого завершения задачи -- это время и деньги. Как итог большая нагрузка на этого самого аналитика. Выбор методологии зависит от выводов аналитика.
Agile — методологию можно использовать только на небольших проектах или на проектах не предполагающих дальнейшего развития.
XP — приемлимо только на крупных проектах или не больших проектах, предполагающих дальнейшее развитие.
Если заказчик знает чего хочет, а некоторые ещё и пожелания имеют к постановке процесса разработки и самим разработчикам, то аналитик не особо и нужен.Весь анализ сделан.
Т е осязаемый коэффициент данной составляющей -- насколько очевидно окончание проекта. Т е заказчик увидел проект на каком-то этапе и решил его доработать. В итоге часть задач запланированных уже не надо будет исполнять, а новые не проработанные и ломающие структуру проекта вполне могут появится. Чем ближе к истине аналитик просчитал пожелания заказчика, тем больше шансов у проекта нормально развиваться.
Метод определения -- контрольные точки по пожеланиям заказчика. Совпало -- отлично (к = 1). Не совпало, надо определить на сколько далеко не совпало. А вот это "на сколько далеко" уже считается через графики. Как минимум такая возможность есть.
Т е получается в моём понимании -- величина "Сложность понимания задачи" -- динамическая и может меняться в процессе выполнения задачи в зависимости от точности её постановки или дальнейших изменений.
Сложность обучения
Часто бывает, что некоторые менеджеры пытаются снизить свои риски за счёт поддержания в команде достаточно низкого уровня обучения. Это даёт возможность быстрой и безболезненной замены одной посредственности другой.
Проще жить менеджеру проекта. Не боится текучки -- это один из плюсов. Но такой вариант годится только для хорошо отлаженных проектов или для простых одноразовых проектов (не предполагающих дальнейшего развития.)
Нетрудно догадаться, что в соответствии с законом сохранения сложности, вся сложность разрабатываемых приложений у таких команд находится в самом коде. Как правило, такого кода много, он не гибок, трудно читаем и обладает завышенной алгоритмической сложностью, которая часто зашкаливает за допустимый для членов команды предел.
Корень сего в том, что каждый из участников команды хочет повысить свой уровень кустарным способом и как правило все новоизученные технологии применяет на проекте. А поскольку таким образом может поступать каждый участник команды, то и код действительно будет разношёрстный.
Результат, как правило, тоже предсказуем — затягивание сроков, превышение бюджетов, провалы проектов.
Сроки потому и затягиваются что менеджер проекта изначально не учёл силы команды. Т е таблетка -- рассчёт возможностей команды по скилам учатников.
Т е такого результата вполне возможно избежать, если заранее подготовится.
Как с этим бороться? Правильно, обучать людей, перекладывая сложность из кода в их головы и используемые ими инструменты, балансировать между своими рисками и управлением сложностью. И всегда помнить, что примитивными могзами сложные задачи просто не решаются.
Обучая людей и не принимая во внимание то что они дорожают как специалисты можно получить текучку кадров либо удорожание проекта. И то и другое вполне может быть причиной срыва сроков.
Теперь капкан.
Программист, изначально имеющий не достаточную для проекта подготовку и получивший эту подготовку для выполнения задачи через время, обязательно посмотрит на тот код что он уже написал и обязательно захочет его рефакторить. Хорошо как это его пожелание совпадёт с необходимостью, заложенной МП в самом начале разработки. Если же не заложено, то программист может понять всю сложность изменений в таком им же написанном коде и попросту сбежать как минимум с проекта, как максимум с компании.
Выводы
1. на проект необходимо заранее брать людей с необходимой квалификацией. Риска на много меньше и объективность перспектив проекта намного точнее.
2. если программист должен обучаться, то явно не на живых проектах (как это часто делается).
3. обученный специалист стоит дороже. Если компания этого не понимает, то она теряет специалиста а значит и время и деньги в него вложенные.
Таким образом сложность обучения даже можно просчитать в суммах, а через сумммы и в часах. Далее идут тесты конкретного человека на способность поглатить необходимую инфу за вычисленный промежуток времени.
Алгоритмическая сложность
Бывают ситуации, когда выполнение текущей задачи ни чем не осложнено, но она не рассматривается сразу в контексте других, как минимум выполненных уже задач. И когда приходит время оптимизации выясняется что оптимизация попросту не выгодна. В этом случае проект просто переписывается. Однако если каждое изменение соотносить с тем что уже готово, то полагаю данную сложность можно вообще минимизировать. На практике эта сложность может быть представлена в виде графика.
По другим пунктам на данный момент напечатать ничего не могу.
Если у вас есть конкретные методики оценки проектов через сложность но не только в процессе разработки, но и до неё, очень бы хотелось их увидеть. Было бы полезно
S>Если заказчик знает чего хочет, а некоторые ещё и пожелания имеют к постановке процесса разработки и самим разработчикам, то аналитик не особо и нужен.Весь анализ сделан.
Очевидно ты не совсем знаком с областью проблем, решаемых аналитиком. Почитай Вигерса. Настолько устоялся обычай, что аналитик — прокладка без крылышек, что даже вот приходится разъяснять, что аналитик должен вообще что-то делать кроме макулатуры.
S>Метод определения -- контрольные точки по пожеланиям заказчика. Совпало -- отлично (к = 1). Не совпало, надо определить на сколько далеко не совпало. А вот это "на сколько далеко" уже считается через графики. Как минимум такая возможность есть.
Господа, давайте общаться. Графики хорошо, но погружение намного лучше.
S>
S>Часто бывает, что некоторые менеджеры пытаются снизить свои риски за счёт поддержания в команде достаточно низкого уровня обучения. Это даёт возможность быстрой и безболезненной замены одной посредственности другой.
S>Проще жить менеджеру проекта. Не боится текучки -- это один из плюсов. Но такой вариант годится только для хорошо отлаженных проектов или для простых одноразовых проектов (не предполагающих дальнейшего развития.)
ИМХО он вообще не годится, потому как намного рискованей для результата (не для жопы манагера, а для успешности проекта)
S>Обучая людей и не принимая во внимание то что они дорожают как специалисты можно получить текучку кадров либо удорожание проекта. И то и другое вполне может быть причиной срыва сроков.
(-)
Зависимость эффективнности от квалификации растёт нелинейно и довольно значительно. Так что проекту будет только выигрыш, если конечно изначально не закладывались на принцип "программисты — винтики".
S>Программист, изначально имеющий не достаточную для проекта подготовку и получивший эту подготовку для выполнения задачи через время, обязательно посмотрит на тот код что он уже написал и обязательно захочет его рефакторить. Хорошо как это его пожелание совпадёт с необходимостью, заложенной МП в самом начале разработки. Если же не заложено, то программист может понять всю сложность изменений в таком им же написанном коде и попросту сбежать как минимум с проекта, как максимум с компании.
Довольно надуманный вывод. Возможно, но не обязательно.
Более того, если вы берёте людей, которые не развиваются, то значит вы изначально ошиблись в своей оценке их квалификации.
S>Выводы S>1. на проект необходимо заранее брать людей с необходимой квалификацией. Риска на много меньше и объективность перспектив проекта намного точнее.
+ S>2. если программист должен обучаться, то явно не на живых проектах (как это часто делается).
— S>3. обученный специалист стоит дороже. Если компания этого не понимает, то она теряет специалиста а значит и время и деньги в него вложенные.
—
Здравствуйте, VGn, Вы писали:
VGn>Очевидно ты не совсем знаком с областью проблем, решаемых аналитиком. Почитай Вигерса.
Как раз читаю. Только практика и теория слегка рознятся. Некоторые компаниии (знаю не по наслышке) вкладывают именно этот, указанный мной смысл, а не описываемый. И приходится ориентироваться именно на то что имеется а не на то как должно быть. У меня есть желание прикрутить данную статью от автора с моими поправками на мою реальность и реализовать её на практике. Не судите строго за мои отступления от хорошо описанной теории. VGn>Настолько устоялся обычай, что аналитик — прокладка без крылышек, что даже вот приходится разъяснять, что аналитик должен вообще что-то делать кроме макулатуры.
И разъясняйте если не сложно. Будет полезно всем участникам.
VGn>Господа, давайте общаться. Графики хорошо, но погружение намного лучше.
Можно практический пример? Возможно я не совсем понимаю о чём идёт речь.
VGn>ИМХО он вообще не годится, потому как намного рискованей для результата (не для жопы манагера, а для успешности проекта)
Да Успех проекта под большим вопросом, но если на мне как на манагере не завязано финансирование проекта, то как знать что лучше. Вобщем сплошние риски. И в идеале конечно это не нормально.
VGn>(-) VGn>Зависимость эффективнности от квалификации растёт нелинейно и довольно значительно. Так что проекту будет только выигрыш, если конечно изначально не закладывались на принцип "программисты — винтики".
Пркатический пример (из жизни) Некий программист пришёл на проект изучил технологию, применил её. Сам работает нормально. Внимание вопрос -- как часто руководство компаний замечает своих сотрудников? Зачастую приходится напоминать о себе и доказывать свою состоятельность для повышения зп. Есть2-й вариант.. Подучиться и уйти "туда где ценят". А именно принцип "программисты — винтики" -- применяем 90 процентами компаний. Да и не только программисты. Мнение "а что мы специалиста не найдём дешевле да лучше?" очень часто используем. И по этому рассматривать оторванную от реальности ситуацию не очень хотелось бы. Возможно у вас примеры другие есть Но у меня имено такие. т ч несогласие не понятно.
VGn>Довольно надуманный вывод. Возможно, но не обязательно.
Практика. VGn>Более того, если вы берёте людей, которые не развиваются, то значит вы изначально ошиблись в своей оценке их квалификации.
Нет Дело тут не только в развитии.
Например
1. есть чел мегаквалификации, но решает задачи ниже уровня своей квалификации т к по проекту большая и не требуется. Куда и на чём ему развиваться? Если конечно не самостоятельно в отрыве от производства.
2. Наша ситуация. Есть чел низкой квалификации. Большая не требуется -- куда ему развиваться?
3. пришёл чел с низкой квалификацией. Развился и выполняет задачи. Он хотел бы далее расти, но его не пускают ибо это потеря человека именно с данного проекта. Результат или он уйдёт по компании или из компании но точно с проекта. Может конечно остаться на проекте с передвижением по иерархии, но на моей памяти такие случаи единичны.
S>>Выводы S>>1. на проект необходимо заранее брать людей с необходимой квалификацией. Риска на много меньше и объективность перспектив проекта намного точнее. VGn>+ S>>2. если программист должен обучаться, то явно не на живых проектах (как это часто делается). VGn>- В чём не согласие? Да я знаю что практика как раз такова, что обучение как раз на живых пректах и происходит. Но тогда надо и риски соответствующие закладывать. S>>3. обученный специалист стоит дороже. Если компания этого не понимает, то она теряет специалиста а значит и время и деньги в него вложенные. VGn>-
Ну на это я ответил выше.
Хочу обратить внимание на то что меня интересует применение данной статьи от автора на практике. А занчит я и пытаюсь её заточить под реальность именно мою. Хотелось бы побольше именно практических решений увидеть.
VGn>>Очевидно ты не совсем знаком с областью проблем, решаемых аналитиком. Почитай Вигерса. S>Как раз читаю. Только практика и теория слегка рознятся. Некоторые компаниии (знаю не по наслышке) вкладывают именно этот, указанный мной смысл, а не описываемый. И приходится ориентироваться именно на то что имеется а не на то как должно быть. У меня есть желание прикрутить данную статью от автора с моими поправками на мою реальность и реализовать её на практике. Не судите строго за мои отступления от хорошо описанной теории. VGn>>Настолько устоялся обычай, что аналитик — прокладка без крылышек, что даже вот приходится разъяснять, что аналитик должен вообще что-то делать кроме макулатуры. S>И разъясняйте если не сложно. Будет полезно всем участникам.
Ну так если читал, то должно быть понятно, что аналитик должен не только выявлять требования но и отслеживать их, оценивать риски изменения этих требований, общаться с заказчиком и с исполнителями по поводу их реализуемости.
Контроли версий (в какой-то мере) и контроль конфигураций (довольно плотно) — тоже активности аналитика.
Поэтому кстати у нас в России разделяют аналитиков на "бизнес" и "системных", хотя я бы не стал, потому что связь между рассматриваемыми проблемами довольно плотная.
А у нас обычно все эти активности размазываются тонким слоем по куче людей, включая разработчиков, менеджеров и даже сейлзов. Логические связи рвутся. В итоге получается "испорченный телефон" и в разы выросшие издержки.
VGn>>Господа, давайте общаться. Графики хорошо, но погружение намного лучше. S>Можно практический пример? Возможно я не совсем понимаю о чём идёт речь.
Всё о том же. Плотное общение и погружение в процесс даёт больше эффекта. Время, выделенное на подсчёт метрик, гораздо эффективнее можно потратить на логический анализ. Так что здесь нужно продумывание эффективности. (Я не имею в виду, что метрики вообще не нужны но при прочих равных они не могут быть так эффективны в этом случае, как хотелось бы.)
VGn>>(-) VGn>>Зависимость эффективнности от квалификации растёт нелинейно и довольно значительно. Так что проекту будет только выигрыш, если конечно изначально не закладывались на принцип "программисты — винтики".
S>Пркатический пример (из жизни) Некий программист пришёл на проект изучил технологию, применил её. Сам работает нормально. Внимание вопрос -- как часто руководство компаний замечает своих сотрудников? Зачастую приходится напоминать о себе и доказывать свою состоятельность для повышения зп. Есть2-й вариант.. Подучиться и уйти "туда где ценят". А именно принцип "программисты — винтики" -- применяем 90 процентами компаний. Да и не только программисты. Мнение "а что мы специалиста не найдём дешевле да лучше?" очень часто используем. И по этому рассматривать оторванную от реальности ситуацию не очень хотелось бы. Возможно у вас примеры другие есть Но у меня имено такие. т ч несогласие не понятно.
Ну так это проблема эффективности работы менеджера, а не каких-то там качеств разработчика.
VGn>>Более того, если вы берёте людей, которые не развиваются, то значит вы изначально ошиблись в своей оценке их квалификации. S>Нет Дело тут не только в развитии. S>Например S>1. есть чел мегаквалификации, но решает задачи ниже уровня своей квалификации т к по проекту большая и не требуется. Куда и на чём ему развиваться? Если конечно не самостоятельно в отрыве от производства.
Ну так двигайте его. Ротация — хорошая штука.
Врядли человек может развиться за время разработки одного проекта и джуниора в гуру.
Так что тут могут быть только такие проблемы:
— сразу взяли overqualified
— затянули проект до безобразия
— неверная мотивация
S>2. Наша ситуация. Есть чел низкой квалификации. Большая не требуется -- куда ему развиваться? S>3. пришёл чел с низкой квалификацией. Развился и выполняет задачи. Он хотел бы далее расти, но его не пускают ибо это потеря человека именно с данного проекта. Результат или он уйдёт по компании или из компании но точно с проекта. Может конечно остаться на проекте с передвижением по иерархии, но на моей памяти такие случаи единичны.
Честно говоря видел мало проектов, где действительно нужна низкая квалификация. В рамках одного проекта может быть такая роль, но она обычно составляет малую часть объёма работ. И тут ротация, кстати, вполне возможна.
Зато видел несколько проектов aka "давайте нагоним студентов, они нам толпой быстро всё сваяют", что кончалось печально.
S>>>2. если программист должен обучаться, то явно не на живых проектах (как это часто делается). VGn>>- В чём не согласие? Да я знаю что практика как раз такова, что обучение как раз на живых пректах и происходит. Но тогда надо и риски соответствующие закладывать.
А на чём ещё?
В теории рекомендуют заниматься такими делами на этапе прототипирования aka Технического проекта. Но в российском бардаке этапы размазывают, как кому вздумается, а значит и активности размазываются так же.
Так что корень проблемы не в том, что программист хочет учиться, а в том что ему не дают этап, где он может этим активно заниматься.
Здравствуйте, VGn, Вы писали:
VGn>Зато видел несколько проектов aka "давайте нагоним студентов, они нам толпой быстро всё сваяют", что кончалось печально.
А я до сих пор вижу И заканчивается оочень печально и потом начинается поиск крайних
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Игорь Ткачёв, Вы писали:
PD>Целью проектирования является уменьшение сложности, для чего, собственно, и вводится понятие компонента (в широком смысле этого слова). Внутрення сложность компонента может быть сколь угодно высока, но его внешняя сложность должна быть небольшой. При работе с компонентом нас его внутрення сложность не интересует, он для нас (в идеале) black box. А внутри него — те же правила для его подкомпонентов.
PD>И это не только к программированию относится.
Я бы сюда добавил что развитие цивилизации вообще, и программирования в частности идет в направлении создания новых категорий, упрощающих представление объектов. Так могу привести пример изобретения слова "дифференциал", которое спровоцировало массу исследований в математике. Хотя суть была известна задолго до этого. Просто формулировка "отношение приращения функции к приращению аргумента" заставляла расходовать мысленные усилия заслоняя собой истиную природу явления. Можно опуститься еще в ранние времена когда было изобретено сложение, и затем умножение. Ведь и этих понятий когда-то не было. Более близкие и понятные нам времена когда были "изобретены" процедуры и затем процедурное программирование. Может кто и помнит волшебные времена, когда такого понятия не было, и каково было вдохновление програмистов узнавших новый метод "процедурное программирование".
затем изобретение полиморфизма, изобретение типов, затем классов это все значительно уменьшает сложность решения задачи, а иногда и вообще изобретение новых категорий делает возможным решение задачи не решаемой (из-за сложности) другими методами.
Сюда же необходимо отнести способность применить новую категоризацию (это не обязательно разбиение на классы) которая может значительно уменьшить сложность задачи. Чисто теоретически задача вообще может быть неалгоритмизована в одних категориях и алгортимизована в других.
К этому могу добавить рассуждения о логической сложности. К этой категории сложности необходимо отнести количество условных операторов и их вложенности. Задача может быть и легко формулируема, но огромное количество условных операторов может сделать ее даже нереализуемой. Не говоря уже о том, что такие программы чрезвычайно не гибки, и сложны как в учебе, так и в сопровождении. Видя перед собой большое количество If-ов, голова начинает буксовать конкретно.
Вообще нужная статья. Мне часто приходится говорить что мои решения менее сложны. Но вот даже сослаться не на что. Четких цифр и определений нет.
Кстати, есть способ уменьшить логическую сложность.
Здравствуйте, batu, Вы писали:
B>Я бы сюда добавил что развитие цивилизации вообще, и программирования в частности идет в направлении создания новых категорий, упрощающих представление объектов. Так могу привести пример изобретения слова "дифференциал", которое спровоцировало массу исследований в математике. Хотя суть была известна задолго до этого. Просто формулировка "отношение приращения функции к приращению аргумента" заставляла расходовать мысленные усилия заслоняя собой истиную природу явления. Можно опуститься еще в ранние времена когда было изобретено сложение, и затем умножение. Ведь и этих понятий когда-то не было. Более близкие и понятные нам времена когда были "изобретены" процедуры и затем процедурное программирование. Может кто и помнит волшебные времена, когда такого понятия не было, и каково было вдохновление програмистов узнавших новый метод "процедурное программирование".
Эти времена не помню, но помню, как впервые узнал про структурный подход. Нас ему не учили. Прочитал книгу (до сих пор жалею, что ее потерял) и с удовлетворением отметил, что интуитивно я эти принципы и ранее применял — еще один г-н Журден.
Ну а как ООП внедрялось — помню хорошо.
B>затем изобретение полиморфизма, изобретение типов
Можешь себе представить программирование без типов ? Нет, базовые типы, конечно, есть, а вот структур нет. Вообще нет. Фортран-4. И ничего — жили, хотя и не сказать, что очень хорошо. С типами я столкнулся, когда перешел на Паскаль, и поначалу они меня напрягали — мало мне того, что я должен помнить имена переменных, так еще и типы я должен помнить . Ничего — привык.
А вот ООП никакой отрицательной реакции не вызывало. Принял сразу.
Статья в целом неплохая. Ибо программисты и менеджеры часто оперируют понятием "сложно", "не сложно", и делают вид, что понимают друг друга. На самом деле, первые говорят о своем субъективном восприятии "геморроя", связанного с задачей, а вторые чаще всего имеют в виду трудоемкость (напрямую связанную с длительностью).
Термин "сложность" давно пора раскрыть. А лучше всего — изъять нафиг из обращения, как противоречивый, путающий людей, и ничего не говорящий. Русский язык велик и могуч, да и в английском много других слов .
По факту же, у тебя написано, как бы это сказать, очень сложно. По своей сути все гораздо проще.
Если вещи, которые в процессе разработки ПО объективно и точно поддаются измерению. Их, в целом, немного.
1) Объем. В строках кода, количестве классов, количестве функций — это не принципиально. Это — объем.
2) Время. С этим вопросов нет, не так-ли?
3) Количество ошибок.
4) И, как тебе вероятно известно, есть метрики "сложности". Это, например, Cyclomatic Complexity, которая косвенно характеризует количество тестов, необходимых для вылова тех самых ошибок, которые в п.3.
То есть. Очевидно, что 10000 строк кода написать и отдалить дольше, чем эти 100, если не брать маргинальные примеры, конечно. Другими словами, налицо корелляция объема и трудозатрат. Объем — какая это "сложность"? Речь о "трудоемкости", а не "сложности", и не надо их смешивать. Это раз.
Далее. Пусть у нас имеется код объемом (1), скажем, в 100 строк за вычетом комментариев.
Код такого объема, очевидно, может быть написан за разное время — задачи-то разные. Отношение строки кода/время называется "продуктивностью". Очевидно, что для "сложной" задачи коэффициент "продуктивность" будет меньше, чем для простой, не так ли? Что также объективно наблюдаемо — для "сложной" задачи мы в целом пишем меньшее количество строк кода за одно и то же время, чем для "простой".
А почему так получается? Потому, что для "сложной" задачи мы допускаем больше ошибок (3). Иногда мы сразу видим, что не знаем, как написать правильно (без ошибок). Иногда — мы понимаем, что допустили ошибку, когда начинаем писать код. Иногда — понимаем при тестировании. А иногда — когда программой начинают пользоваться клиенты.
То есть, сложность состоит в том, чтобы написать без ошибок. Какие классы ошибок бывают? Разберем по видам технических решений, которые мы принимаем. В каждом из них мы можем ошибиться.
0) Требования. Ошибочные предстваления о том, что надо сделать.
1) Архитектурная. Неверный выбор базовых технологий и/или общих принципов построения системы.
2) Дизайн. "Структурная" ошибка. Неверная нарезка функциональности на компоненты.
3) Детальный дизайн. Ошибка в алгоритмах или структурах данных.
4) Кодирование. Здесь понятно.
Понятно также, что чем выше уровнем техническое решение, тем дороже ошибка.
Но при внесении изменений в существующий код эта стройная картина ломается, и уже начинает играть ведущую роль цикломатика (метрика 4). Систему с множеством режимов (спагетти) тяжело удержать в голове, и не допустить ошибок при внесении в нее изменений. Элементарные правки уровня (4) зачастую вызывают непредсказуемые ошибки, дорогие в диагностике и исправлении. Такой код называется "хрупким".
"Рефакторинг" — есть приведение ее в состояние, когда начинает выполняться указанная выше закономерность.
Вот и вся "сложность". Все, как видишь, очень просто.
PD>Можешь себе представить программирование без типов ? Нет, базовые типы, конечно, есть, а вот структур нет. Вообще нет. Фортран-4. И ничего — жили, хотя и не сказать, что очень хорошо. С типами я столкнулся, когда перешел на Паскаль, и поначалу они меня напрягали — мало мне того, что я должен помнить имена переменных, так еще и типы я должен помнить . Ничего — привык.
PD>А вот ООП никакой отрицательной реакции не вызывало. Принял сразу.
Я Паскаль хорошо принял. Аккуратно слепленый, рекурсия, структуры.. ООП это песня. Хотя я на VB его принял. Сначала было ущербно. Особенно события буксовали. Вот с того момента мне и захотелось развить эту тему. Доразвивался.. Хотя приятно видеть свои задумки реализоваными, но до серьезных изменений MS не додумался еще. А я все толкусь. Надоело, если честно, агитировать..
Здравствуйте, Gaperton, Вы писали:
G>Если вещи, которые в процессе разработки ПО объективно и точно поддаются измерению. Их, в целом, немного. G>1) Объем. В строках кода, количестве классов, количестве функций — это не принципиально. Это — объем. G>2) Время. С этим вопросов нет, не так-ли? G>3) Количество ошибок. G>4) И, как тебе вероятно известно, есть метрики "сложности". Это, например, Cyclomatic Complexity, которая косвенно характеризует количество тестов, необходимых для вылова тех самых ошибок, которые в п.3.
А как тут учитывается "сложность" связанная с необходимым объемом знания для написания кода.
Гипотетический пример — написать парсер языка без специальных инструментов. Влоб такая задача решается крайне плохо, используя некоторые теоретически знания — гораздо лучше.
Многие современные языки как раз торгуют объем-время на эту самую сложность понимания.
Здравствуйте, Gaperton, Вы писали:
G>Статья в целом неплохая. Ибо программисты и менеджеры часто оперируют понятием "сложно", "не сложно", и делают вид, что понимают друг друга. На самом деле, первые говорят о своем субъективном восприятии "геморроя", связанного с задачей, а вторые чаще всего имеют в виду трудоемкость (напрямую связанную с длительностью).
Согласен, есть такое дело.
G>По факту же, у тебя написано, как бы это сказать, очень сложно. По своей сути все гораздо проще.
G>Если вещи, которые в процессе разработки ПО объективно и точно поддаются измерению. Их, в целом, немного. G>1) Объем. В строках кода, количестве классов, количестве функций — это не принципиально. Это — объем.
А что даёт такая метрика?
G>2) Время. С этим вопросов нет, не так-ли?
Вопросов есть. Допустим, Вася решает задачу A за один день, а Коля решает ту же задачу за два дня. При этом задача A — это маленькая часть задачи B. Но, Вася решает всю задачу B за два месяца, а Коля за один. Парадокс? Возможно, но только не в программировании.
Вопрос. Что даст такая метрика без учёта способностей Васи и Коли?
G>3) Количество ошибок.
Кстати, Вася за два месяца сделал в два раза больше ошибок, чем Коля за один.
G>4) И, как тебе вероятно известно, есть метрики "сложности". Это, например, Cyclomatic Complexity, которая косвенно характеризует количество тестов, необходимых для вылова тех самых ошибок, которые в п.3.
G>То есть. Очевидно, что 10000 строк кода написать и отдалить дольше, чем эти 100, если не брать маргинальные примеры, конечно. Другими словами, налицо корелляция объема и трудозатрат. Объем — какая это "сложность"? Речь о "трудоемкости", а не "сложности", и не надо их смешивать. Это раз.
А что такое трудоёмкость? Мы её будем мерять в человеках? А может гораздо точнее будет в Васях или Колях?
G>Вот и вся "сложность". Все, как видишь, очень просто.
Даже слишком просто. Мало знать, что один код сложнее, чем другой. Сам по себе этот факт с практической точки зрения совершенно не интересен. Интересно знать — почему, т.к. зная почему уже можно принимать конкретные решения. А чтобы знать, нужно понимать детали. Вот как раз о деталях эта статья.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
G>>Если вещи, которые в процессе разработки ПО объективно и точно поддаются измерению. Их, в целом, немного. G>>1) Объем. В строках кода, количестве классов, количестве функций — это не принципиально. Это — объем.
IT>А что даёт такая метрика?
Дает объективную характеристику объема кода.
А еще — дает неплохие корелляции с количеством ошибок и временем, для каждого отдельно взятого Васи, и Коли.
G>>2) Время. С этим вопросов нет, не так-ли?
IT>Вопросов есть. Допустим, Вася решает задачу A за один день, а Коля решает ту же задачу за два дня. При этом задача A — это маленькая часть задачи B. Но, Вася решает всю задачу B за два месяца, а Коля за один. Парадокс? Возможно, но только не в программировании.
IT>Вопрос. Что даст такая метрика без учёта способностей Васи и Коли?
Такая метрика объективно даст время решения задачи Васей и Колей. Никакого учета их способностей для измерения времени, которое они на задачу потратят, очевидно, не требуется.
G>>3) Количество ошибок.
IT>Кстати, Вася за два месяца сделал в два раза больше ошибок, чем Коля за один.
Бывает сплошь и рядом.
G>>4) И, как тебе вероятно известно, есть метрики "сложности". Это, например, Cyclomatic Complexity, которая косвенно характеризует количество тестов, необходимых для вылова тех самых ошибок, которые в п.3.
G>>То есть. Очевидно, что 10000 строк кода написать и отдалить дольше, чем эти 100, если не брать маргинальные примеры, конечно. Другими словами, налицо корелляция объема и трудозатрат. Объем — какая это "сложность"? Речь о "трудоемкости", а не "сложности", и не надо их смешивать. Это раз.
IT>А что такое трудоёмкость?
Штука такая, сводится к оценка объема работы в человекочасах. Очевидно, определяется сочетанием задачи и человека. Парадокс? Наверное, только для программистов.
Никто не ждет от школьника на уроке труда, что он сделает табурет за то же время, что и столяр первого разряда, да еще такого, у которого на табуретках рука набита.
IT>Мы её будем мерять в человеках?
Не, не будем.
IT>А может гораздо точнее будет в Васях или Колях?
Очевидно, "гораздо точнее" будет в человекоминутах.
G>>Вот и вся "сложность". Все, как видишь, очень просто.
IT>Даже слишком просто.
Ты слишком много уделил внимания вводной части, в которой просто перечислялись известные объективные метрики, и пропустил часть, в которой была суть.
Ничего сложного в таком прочтении, естественно, нет.
IT>Мало знать, что один код сложнее, чем другой. Сам по себе этот факт с практической точки зрения совершенно не интересен.
Мысль в моем комментарии чуточку посложнее этой банальщины. Но не понял, и ладно.
Здравствуйте, gandjustas, Вы писали:
G>>Если вещи, которые в процессе разработки ПО объективно и точно поддаются измерению. Их, в целом, немного. G>>1) Объем. В строках кода, количестве классов, количестве функций — это не принципиально. Это — объем. G>>2) Время. С этим вопросов нет, не так-ли? G>>3) Количество ошибок. G>>4) И, как тебе вероятно известно, есть метрики "сложности". Это, например, Cyclomatic Complexity, которая косвенно характеризует количество тестов, необходимых для вылова тех самых ошибок, которые в п.3.
G>А как тут учитывается "сложность" связанная с необходимым объемом знания для написания кода.
Она учитывается _взаимосвязью_ элементарных метрик. Более того, вся эта "сложность" будет _наблюдаема_ по совокупности элементарных метрик, дополненных классификатором ошибок.
Объясняю. Если бы ты _вообще_ не совершал ошибок (честно попытайся представить себе такое), ты бы сразу годный исходный текст со скоростью машинистки печатал, и тебе не надо было бы его тестировать. Все время по сути тратится на поиск ошибок и путей их устранения.
Т.е. ошибаться будешь чаще, не имея необходимого знания. Ошибок будешь больше исправлять. Времени в результате больше потратишь. Возможно, сдуру нафигачишь больше кода, чем было бы со знаниями и опытом. И потому — сделаешь еще больше ошибок, и потратишь еще больше времени.
G>Гипотетический пример — написать парсер языка без специальных инструментов. Влоб такая задача решается крайне плохо, используя некоторые теоретически знания — гораздо лучше.
Знание позволяет делать меньше ошибок. А если ошибок совсем не будет, то что? Правильно — со скоростью машинистки.
G>Многие современные языки как раз торгуют объем-время на эту самую сложность понимания.
Это к делу не относится. Что вы все к элементарным метрикам цепляетесь? Сами по себе они ничего не значат, — они наблюдаемы и объективно измеримы, в этом вся их суть. Смысла потаенного в них нет, не надо его искать.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
G>>Вот эти 3 метрики + количество строк кода дают вполне пригодную оценку "качества кода", при минимизации метрик качество растет.
IT>Ну допустим мы получили три числа: 25, 42 и 18. Что с ними дальше делать?
Считать производные метрики, сравнивать с историей по предыдущим проектам, делать выводы, принимать решения.
IT>>>Чего — например, ООП. Можно квантануть до наследования, инкапсуляция, полиморфизм. Какова будет метрика? G>>Связность.
IT>Связность может быть сильная, а может быть слабая. Я вовсе не против этого, но это не количественная метрика.
Это совсем несложно выразить в виде количественной метрики, посчитав количество связей.
IT>>>Разная у всех не только сложность понимания, но ещё и обучаемость и предел алгоритмической сложности. Это всё тоже нужно как-то включать в формальное определение. G>>Субъективные факторы, типа сложности обучения, лучше не учитывать в формальных выкладках.
IT>Ну да. А может лучше сразу не заниматься такой бесполезной фигнёй как формальные выкладки?
Бесполезной фигней являются общие рассуждения о "сложности". Никаких полезных выводов из этого сделать нельзя. You can't control what you can't measure.
T>>>>Это исследование надо проводить, на это я пойтить не могу. IT>>>А зря. G>>Не очень получится, в зависимости от задачи одни метрики могут быть более приоритетные, чем другие.
IT>Включи в свои формулы приоритетность, в чём проблема?
Здравствуйте, IT, Вы писали:
T>>Если возвращаться к теме статьи, то ты не определил количественную меру сложности, поэтому не можешь сформулировать и закона сохранения
IT>Не определил по одной простой причине — её не существует.
По одной простой причине — ты не настолько хорошо понимаешь проблему, чтобы определить количественную меру.
T>>Хотя бы сложность по Колмогорову упомянул, что ли.
IT>Блин, ещё один измеряльщик. Ну тогда сравни мне сложность восприятия безобразно оформленного кода, алгоритмическую сложность кода, объём кода, сложность обучения, необходимую для понимания кода, и сложность понимания поставленной задачи. При этом, желательно, чтобы формула была универсальной для любого программиста.
Техника работы с метриками основана на измерениях, сравнениях, анализе истории и поиске статистических закономерностей, а не "универсальных формулах для любого программиста". Последнее — глупость.
Для твоего случая — время на объем, плюс процентная раскладка времени на каждый этап. Вводи по очереди разные факторы, и проведи статистическое исследование, если тебе интересно. Мне предложенное тобой сравнение кажется лишенным какой-ли практической пользы. Так, абстрактное умствование.
Здравствуйте, Sinclair, Вы писали:
M>>Так бы и продолжалось дальше, но увы, экспоненциальное развитие скорости компьютеров практически закончилось. И просто увеличение количества уровней абстракции (вроде применения более высокоуровневых языков программирования) уже не поможет — железо не потянет. S>И это тоже неправда. Простой пример: запись вида int a = b + c / d — e; находится на совсем другом уровне абстракции, чем набор из mov EAX, .... Тем не менее, производительность программы будет ничуть не хуже.
Более того. На современных суперскалярно-конвейерных процах производительность будет на практике не то что не хуже, а лучше.
Пример про то, как тупенький gcc компилирует два подряд идущих умножения для тупенького MIPS я уже раньше приводил. Одно делается как умножение, второе — на сдвигах-сложениях. Выполняется такое _быстрее_.
Здравствуйте, Gaperton, Вы писали:
G>>>1) Объем. В строках кода, количестве классов, количестве функций — это не принципиально. Это — объем. IT>>А что даёт такая метрика? G>Дает объективную характеристику объема кода.
Был у меня один случай лет пять назад. В Банке Оф Америка. Достался мне в наследство один недавно начатый проект от одного индуса. Объёма кода море, баги, глюки, тормоза, в общем всё как положено. После нескольких недель рефакторинга объём рукописного кода сократился раз в пять, баги, глюки, тормоза куда-то сами собой подевались, а тот же самый объём кода был достигнут только месяца через четыре, когда проект представлял собой уже не просто демку из формочек, а приложение под завяз напичканое функционалом.
С тех пор веру в объём кода как в объективную характеристику я окончательно потерял. Да и в дальнейшем не раз приходилось в этом убеждаться. Сейчас, кстати, работаю над проектом, вротой его версией. Искренне надеюсь, что удастся сократить объём кода раза в два по сравнению с первой версией.
G>А еще — дает неплохие корелляции с количеством ошибок и временем, для каждого отдельно взятого Васи, и Коли.
Количество ошибок безусловно как-то коррелирует с объёмом кода, но гораздо сильнее оно коррелирует с количеством мозгов у ошибающегося.
G>>>2) Время. С этим вопросов нет, не так-ли? IT>>Вопрос. Что даст такая метрика без учёта способностей Васи и Коли? G>Такая метрика объективно даст время решения задачи Васей и Колей. Никакого учета их способностей для измерения времени, которое они на задачу потратят, очевидно, не требуется.
Т.е. это постфактум?
IT>>А что такое трудоёмкость? G>Штука такая, сводится к оценка объема работы в человекочасах. Очевидно, определяется сочетанием задачи и человека. Парадокс? Наверное, только для программистов.
Есть такая штука... точнее была когда-то в СССР, сейчас уже не уверен — сметные нормы на строительные работы, которые всячески пытались учитывать производительность труда. Так вот, правильные командиры и мастера строй-отрядов абсолютно безошибочно выбирали для отряда те виды работ, которые наиболее хорошо оплачивались при минимальных затратах ресурсов, учитывая особенности конкретных бойцов. Неправильные командиры брались за любую работу. В результате при примерно одинаково выполненных объёмах работ и человекочасах зарплата в разных отрядах отличалась в разы. Хотя делалось всё по одним сметным нормам, учитывающим одну и туже производительность труда.
Под ресурсами здесь, кстати, понимается в основном грубая физическая сила имеющихся в наличии индивидуумов. Мы же здесь толкуем о работе мозгами. Если бы мы тогда работали мозгами, то разница была бы не в разы, а на порядки.
Такая вот оценка производительности труда. Над которой, кстати, трудились много учёных и прочих специалистов из разных научных заведений и ведомств.
G>>>Вот и вся "сложность". Все, как видишь, очень просто. IT>>Даже слишком просто. G>Ты слишком много уделил внимания вводной части, в которой просто перечислялись известные объективные метрики, и пропустил часть, в которой была суть.
Ты плохо читал статью. Я тщательно старался избегать любое упоминание о каких бы то ни было метриках. Метрики нужны менеджерам, особенно плохим, им без них никак. Мне метрики не нужны, мне нужно распознать и предотвратить появление проблемных мест в приложении. А для этого мне вполне достаточно вещей вроде "больше"/"меньше".
IT>>Мало знать, что один код сложнее, чем другой. Сам по себе этот факт с практической точки зрения совершенно не интересен. G>Мысль в моем комментарии чуточку посложнее этой банальщины. Но не понял, и ладно.
Сложность твоей мысли из той же серии что и сложность в доставшемся мне проекте, о котором я говорил выше. Если её (мысль) правильно отрефакторить, то возможно она станет простой и понятной не только одному тебе. И возможно, у неё даже будет шанс когда-нибудь стать банальной
Если нам не помогут, то мы тоже никого не пощадим.
IT>А что такое трудоёмкость? Мы её будем мерять в человеках? А может гораздо точнее будет в Васях или Колях?
С Васями и Колями хорошо, когда у тебя есть один Вася и один Коля и ты интуитивно представляешь, что будет за результат если каждый возьмется за работу.
А для случаев более серьезных, придется искать способ численно выразить Васю чрез Колю, потому ты снова приходишь к численным характеристикам.
Здравствуйте, IT, Вы писали:
IT>С тех пор веру в объём кода как в объективную характеристику я окончательно потерял. Да и в дальнейшем не раз приходилось в этом убеждаться. Сейчас, кстати, работаю над проектом, вротой его версией. Искренне надеюсь, что удастся сократить объём кода раза в два по сравнению с первой версией.
А что ты хочешь от такой метрика как количество строк кода ? Сама по себе она почти ничего не значит.
С численными характеристиками одна проблема, их нельзя рассматривать по отдельности.
Нужна оценочная функция, которая у тебя вобщем то уже есть, только ьы пользуешься ею интуитивно.
IT>Количество ошибок безусловно как-то коррелирует с объёмом кода, но гораздо сильнее оно коррелирует с количеством мозгов у ошибающегося.
Если когда нибудь можно будет измерить характеристи мозга, динамику из изменения, то можно будет пользоваться именно этим способом.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, AndrewVK, Вы писали:
AVK>>Маленькое дополнение. То, что ты называешь IQ-сложностью стоит разделить на два вида: AVK>>1) Алгоритмическая сложность. Т.е. сложность логики, алгоритмов. Она, собственно, напрямую определяется той логикой, которая в итоге реализуется программой. AVK>>2) Структурная сложность. Т.е. сложность архитектуры программы, структуры обрабатываемых данных, сложности, количества и противоречивости требований.
IT>Пожалуй это будет тем самым недостающим кирпичиком
Самое большое влияние на алгоритм и его сложность оказывает выбор концепции. При не правильно выбраной концепции сложность может оказаться и бесконечной. Классическая ситуация разбор текста вручную (я называю такое написание программ "в длинну") If-ами или парсером. Пусть даже самодельным. И качество и сложность программы даже трудно сравнивать. В длину вроде проще писать, но результат очень "тупой" и не гибкий. С другой стороны написать парсер.. Не то, что бы проще..Но в опытных руках окажется быстрее. Ну, вообщем понятно.
Здравствуйте, Gaperton, Вы писали:
T>>>Если возвращаться к теме статьи, то ты не определил количественную меру сложности, поэтому не можешь сформулировать и закона сохранения IT>>Не определил по одной простой причине — её не существует. G>По одной простой причине — ты не настолько хорошо понимаешь проблему, чтобы определить количественную меру.
100% не настолько хорошо. Хорошо если хотя бы на 0.5%.
IT>>Блин, ещё один измеряльщик. Ну тогда сравни мне сложность восприятия безобразно оформленного кода, алгоритмическую сложность кода, объём кода, сложность обучения, необходимую для понимания кода, и сложность понимания поставленной задачи. При этом, желательно, чтобы формула была универсальной для любого программиста. G>Техника работы с метриками основана на измерениях, сравнениях, анализе истории и поиске статистических закономерностей, а не "универсальных формулах для любого программиста".
К сожалению, метрики никак не помогают мне при принятии решений, которые я как программист принимаю десятками ежедневно. А из этих решений в конце концов складывается результат, который может быть потом и можно как-то померить.
G>Последнее — глупость.
Глупость — не только последнее, а вообще любое использование метрик.
G>Для твоего случая — время на объем, плюс процентная раскладка времени на каждый этап. Вводи по очереди разные факторы, и проведи статистическое исследование, если тебе интересно. Мне предложенное тобой сравнение кажется лишенным какой-ли практической пользы. Так, абстрактное умствование.
Статистическое исследование подразумевает как минимум необходимость понаблюдать за процессом. Т.е. мы получим какие-то данные после того как уже будет поздно пить боржоми. Какой мне толк от знания того, что на решение задачи X с помощью технологии Y было затрачено Z Васе-Коле-Вите-часов, если в следующий раз я буду решать задачу A, используя технологию B и привлеку для её решения Петю и Ваню?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Ikemefula, Вы писали:
IT>>А что такое трудоёмкость? Мы её будем мерять в человеках? А может гораздо точнее будет в Васях или Колях? I>С Васями и Колями хорошо, когда у тебя есть один Вася и один Коля и ты интуитивно представляешь, что будет за результат если каждый возьмется за работу. I>А для случаев более серьезных, придется искать способ численно выразить Васю чрез Колю, потому ты снова приходишь к численным характеристикам.
Пол сотни программистов, шесть воркстримов на проекте — это достаточно серьёзный случай?
Был у меня лет семь назад такой случай В IBM. Был у нас в команде один индусик. Его вклад в общее дело (в команде с пятью программистами) составлял где-то 5%, а количество его багов в треккере — 80%. После того как его выгнали за неуспеваемость, его код был за неделю переписан и баги исчезли. Как численно выразить этого индуса? Особенно интересно увидеть в формуле зависимость того, что после его увольнения и фактического сокращения поголовья команды, картина через призму багтреккера стала выглядеть в пять раз лучше.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Ikemefula, Вы писали:
I>С численными характеристиками одна проблема, их нельзя рассматривать по отдельности. I>Нужна оценочная функция, которая у тебя вобщем то уже есть, только ьы пользуешься ею интуитивно.
Нет у меня никакой функции. И быть не может. Во-первых, я не менеджер и такие функции меня не интересуют в принципе. Во-вторых, более менее правдоподобные функции можно получить для конкретного типа задач конкретной командой. Я не решая по два раза одни и теже задачи.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Ikemefula, Вы писали:
IT>>>А что такое трудоёмкость? Мы её будем мерять в человеках? А может гораздо точнее будет в Васях или Колях? I>>С Васями и Колями хорошо, когда у тебя есть один Вася и один Коля и ты интуитивно представляешь, что будет за результат если каждый возьмется за работу. I>>А для случаев более серьезных, придется искать способ численно выразить Васю чрез Колю, потому ты снова приходишь к численным характеристикам.
IT>Пол сотни программистов, шесть воркстримов на проекте — это достаточно серьёзный случай?
IT>Был у меня лет семь назад такой случай В IBM. Был у нас в команде один индусик. Его вклад в общее дело (в команде с пятью программистами) составлял где-то 5%, а количество его багов в треккере — 80%. После того как его выгнали за неуспеваемость, его код был за неделю переписан и баги исчезли. Как численно выразить этого индуса? Особенно интересно увидеть в формуле зависимость того, что после его увольнения и фактического сокращения поголовья команды, картина через призму багтреккера стала выглядеть в пять раз лучше.
Я не совсем понимаю, что ты имел сказать. Сначала "Как численно выразить индуса" а потом "в пять раз лучше"
Сто пудов, у тебя есть как минимум интуитивная оценочная функция и надо чуток поработать, что бы можно было сформули ровать внятно, по-человечески.
Т.е. как то ты ухитряешься конвертиорвать васей в колей, но поделиться этим не можешь. Об чем тебе Гапертон и говорит
Здравствуйте, IT, Вы писали: IT>Глупость — не только последнее, а вообще любое использование метрик. IT>Статистическое исследование подразумевает как минимум необходимость понаблюдать за процессом. Т.е. мы получим какие-то данные после того как уже будет поздно пить боржоми. Какой мне толк от знания того, что на решение задачи X с помощью технологии Y было затрачено Z Васе-Коле-Вите-часов, если в следующий раз я буду решать задачу A, используя технологию B и привлеку для её решения Петю и Ваню?
Ну вот это ты зря. Все общественные науки — типа того же менеджмента — занимаются ровно этим.
Берут одни кренделя и делают опросы тим мемберов в командах. Публикуют их, вместе с метриками чего-нибудь высокоабстрактного.
Потом какие-нибудь другие кренделя сводят все эти публикации и пишут монографию типа "мы обследовали семь педеровых компаний в области IT и заметили, что при применении X программисты в среднем в 2.34 раза чаще употребляют слово ".пт", чем аналитики при применении Y употребляют слово ".па". И из этого мы можем сделать вывод о том, что в XXI веке технологии управления проектами Z, W, и U устарели. В нашем быстроменяющемся рынке повысить удовлетворённость потребителей и надои трафика на квадратный байт можно только при помощи новой, альтернативной парадигмы управления, построенной на расширении полномочий и вовлечении работников. Процесс развития делегировния ответственности должен быть длительным, непрерывным, и незаметным, как зарытый в землю шланг". И так далее. Подобная писанина приносит $ на kLOC гораздо больше, чем любое программирование.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, IT, Вы писали:
I>>С численными характеристиками одна проблема, их нельзя рассматривать по отдельности. I>>Нужна оценочная функция, которая у тебя вобщем то уже есть, только ьы пользуешься ею интуитивно.
IT>Нет у меня никакой функции. И быть не может.
Тут я тебе не поверю. Рассказ про индуса категорически свидетельствует о том, что обозначеная функция у тебя есть.
> Во-первых, я не менеджер и такие функции меня не интересуют в принципе.
Собственно по этому у тебя интуитивный подход в этом плане.
>Во-вторых, более менее правдоподобные функции можно получить для конкретного типа задач конкретной командой. Я не решая по два раза одни и теже задачи.
Одни и те же не обязательно. Можно даже похожие. Вообще редко получаются задачи абсолютно уникальные, ты ведь не менял область деятельности радикально ?
Здравствуйте, gandjustas, Вы писали:
G>А как тут учитывается "сложность" связанная с необходимым объемом знания для написания кода.
Это не сложность проекта. Это сложность для HR найти нужного человека.
G>Гипотетический пример — написать парсер языка без специальных инструментов. Влоб такая задача решается крайне плохо, используя некоторые теоретически знания — гораздо лучше.
G>Многие современные языки как раз торгуют объем-время на эту самую сложность понимания.
В каком-то смысле можно считать эту "сложность" именно той сложностью, которая "сложность в отличие от трудоёмкости". Классический пример: выкопать яму объемом десять кубов не сложно, но трудоёмко.
Придумать новый алгоритм сортировки — сложно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
G>>Многие современные языки как раз торгуют объем-время на эту самую сложность понимания.
S>В каком-то смысле можно считать эту "сложность" именно той сложностью, которая "сложность в отличие от трудоёмкости". Классический пример: выкопать яму объемом десять кубов не сложно, но трудоёмко. S>Придумать новый алгоритм сортировки — сложно.
Мне кажется не стоит делить сложность и трудоемкость так, как ты это делаешь.
Грубо говоря, все сводится к уровню мышления, не знаю какой термин подобрать.
Копать яму — это значит, что техника тебе давным давно известна, опробована, отработана и дело только в примнении ранее полученых навыков.
Придумать алгоритм — это вобщем то тоже техника, которая может быть опробована, отработана и дело только в применении ранее полученых навыков.
Разница только в смысловой дистанции. Чем больше эта дистанция, тем "сложнее" задача.
Но это все относительно и субъективно — человек, которы съел собаку на конкретных задачах, будет выдавать просто адские решения и ему это, вполне возможно, будет ни чуть не сложно.
Соответсвенно чем лучше отработана техника, тем бОльшими абстрациями ты можешь оперировать в единицу времени без потери например точности. Т.е., уровень детализации ты можешь менять в достаточно широких пределах.
Здравствуйте, Ikemefula, Вы писали:
I>Сто пудов, у тебя есть как минимум интуитивная оценочная функция и надо чуток поработать, что бы можно было сформули ровать внятно, по-человечески.
Если ты имеешь ввиду оценочную функцию производительности труда, то такой функции у меня нет. Я более двадцати лет пишу код и когда сегодня мне мой начальник задаёт вопрос "сколько это займёт времени", то я однозначно отвечаю — "не знаю". С другой стороны, я могу задать встречный вопрос — "а сколько у меня есть времени", и, в зависимости от его ответа, я могу ответить одно из:
— импосибл,
— только если включить форсаж,
— бу сделано,
— фигня вопрос.
При этом всегда присутствует оговорка, что это всё при отсутствии непредвиденных обстоятельств АКА мистической хреноты.
I>Т.е. как то ты ухитряешься конвертиорвать васей в колей, но поделиться этим не можешь. Об чем тебе Гапертон и говорит
Гапертон вообще говорит о чём-то своём. Он изобрёл метрику, в которой в качестве попугаев используются ошибки. Я несказанно рад за него и ни чуточки не сомневаюсь, что эта метрика замечательно работает в его команде, на его проектах, при используемых им технологиях для оценки его рисков и сроков выполнения его работ. Только, во-первых, это всё его субъективный взгяд на его собственные проблемы, а, во-вторых, статья совсем не об этом. Обрати внимание, говоря о сложности, Гапертон всё время соскакивает на трудоёмкость. Он менеджер, он видит сложность только с этой стороны. В принципе, это нормально. У менеджеров свои задачи, которые они должны решать и за которые они несут ответственность в первую очередь. У программистов свои задачи, немного другие. К сожалению, очень часто эти задачи не совпадают и даже конфликтуют между собой.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, minorlogic, Вы писали:
M>"Трансформирование сложности означает одну простую вещь – устраняя сложность в одном месте, мы всегда добавляем её где-то в другом." M>Очевиднейший бред, дальше читать не стал. И как только такой треш пропускает рецензура...
Надеюсь ты в обморок от переизбытка чувств не упал как князь Мышкин? Ну вот и славно.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Gaperton, Вы писали:
IT>>Ну да. А может лучше сразу не заниматься такой бесполезной фигнёй как формальные выкладки? G>Бесполезной фигней являются общие рассуждения о "сложности". Никаких полезных выводов из этого сделать нельзя. You can't control what you can't measure.
Вынужден с тобой не согласиться. Для меня бесполезной фигнёй являются цифры, которыми измеряются абстрактные человекочасы абстрактного проекта. Общие рассуждения о сложности позволяют мне принять решения на распутье: направо пойдешь коня потеряешь, прямо пойдешь голову потеряешь, налево пойдешь жену потеряешь. В этом во всём понятно только одно — налево лучше не ходить. А куда тогда? И таких решений мне нужно принимать десятки каждый день, а не одно один раз за весь проект, как тебе кажется.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Ikemefula, Вы писали:
I>>Сто пудов, у тебя есть как минимум интуитивная оценочная функция и надо чуток поработать, что бы можно было сформули ровать внятно, по-человечески.
IT>Если ты имеешь ввиду оценочную функцию производительности труда, то такой функции у меня нет. Я более двадцати лет пишу код и когда сегодня мне мой начальник задаёт вопрос "сколько это займёт времени", то я однозначно отвечаю — "не знаю". С другой стороны, я могу задать встречный вопрос — "а сколько у меня есть времени", и, в зависимости от его ответа, я могу ответить одно из:
IT>- импосибл, IT>- только если включить форсаж, IT>- бу сделано, IT>- фигня вопрос.
То есть у тебя таки есть оценка времени выполнения, только ты сам её не говоришь. Для инженеров это нормальное явление так как многие считают что назвав оценку они берут ответственность за риски на себя.
IT>При этом всегда присутствует оговорка, что это всё при отсутствии непредвиденных обстоятельств АКА мистической хреноты.
Это и есть те самые риски
В принципе ты можешь сам называть срок "только если включить форсаж" и "фигня вопрос", как нижнюю и верхнюю границу времени выполнения. С теми же оговорками про риски.
I>>Т.е. как то ты ухитряешься конвертиорвать васей в колей, но поделиться этим не можешь. Об чем тебе Гапертон и говорит
IT>Гапертон вообще говорит о чём-то своём. Он изобрёл метрику, в которой в качестве попугаев используются ошибки. Я несказанно рад за него и ни чуточки не сомневаюсь, что эта метрика замечательно работает в его команде, на его проектах, при используемых им технологиях для оценки его рисков и сроков выполнения его работ. Только, во-первых, это всё его субъективный взгяд на его собственные проблемы, а, во-вторых, статья совсем не об этом. Обрати внимание, говоря о сложности, Гапертон всё время соскакивает на трудоёмкость. Он менеджер, он видит сложность только с этой стороны.
Трудоемкость — функция сложности. Все параметры "сложности" так или иначе выражаются в характеристиках трудоемкости. А при некотором объеме статистики по этим параметрам уже можно выявить закономерности.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Ikemefula, Вы писали:
I>>Сто пудов, у тебя есть как минимум интуитивная оценочная функция и надо чуток поработать, что бы можно было сформули ровать внятно, по-человечески.
IT>Если ты имеешь ввиду оценочную функцию производительности труда, то такой функции у меня нет. Я более двадцати лет пишу код и когда сегодня мне мой начальник задаёт вопрос "сколько это займёт времени", то я однозначно отвечаю — "не знаю".
Ты меня пугаешь. Вроде мы с тобой ровесники, если общие знакомые не врут, 20 лет не совсем представляю откуда берутся
>С другой стороны, я могу задать встречный вопрос — "а сколько у меня есть времени", и, в зависимости от его ответа, я могу ответить одно из:
Я это понимаю. Но это ведь для тех случав, когда работа радикально отличается от тех что были раньше ? Или ты имеешь скзать, что тебя ставят на проекты на которых другие уже провалили всё подряд ?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Gaperton, Вы писали:
IT>>>Ну да. А может лучше сразу не заниматься такой бесполезной фигнёй как формальные выкладки? G>>Бесполезной фигней являются общие рассуждения о "сложности". Никаких полезных выводов из этого сделать нельзя. You can't control what you can't measure.
IT>Вынужден с тобой не согласиться. Для меня бесполезной фигнёй являются цифры, которыми измеряются абстрактные человекочасы абстрактного проекта.
Так же, как и показания спидометра абстрактной машины на абстрактной трассе являются полной фигней. И что? Кто тебя заставляет говорить об абстракциях-то рассуждать?
Конкретные человекочасы конкретного проекта — вовсе не фигня. Ибо в значительной степени определяют его, конкретного проекта, не менее конкретный бюджет. При значительном превышении которого твои рассуждения о видах сложности в этом проекте внезапно перестанут кого-либо интересовать — ибо проект будет закрыт.
IT>Общие рассуждения о сложности позволяют мне принять решения на распутье: направо пойдешь коня потеряешь, прямо пойдешь голову потеряешь, налево пойдешь жену потеряешь. В этом во всём понятно только одно — налево лучше не ходить. А куда тогда? И таких решений мне нужно принимать десятки каждый день, а не одно один раз за весь проект, как тебе кажется.
Точно так же, решение тебе помогают принять не "общие рассуждения", а конкретные рассуждения о конкретной сложности в конкретном проекте.
То, что ты в своих рассуждениях ввел разнообразные факторы — это неплохо. Это лучше, чем просто говорить "сложно". Но непосредственно из этого ничего не следует, ибо с проектным управлением твои рассуждения не стыкуются. Они не уложены в систему. Рассуждать, в результате, ты не можешь — ты можешь только пользоваться "чуйкой".
Здравствуйте, gandjustas, Вы писали:
IT>>С другой стороны, я могу задать встречный вопрос — "а сколько у меня есть времени", и, в зависимости от его ответа, я могу ответить одно из:
IT>>- импосибл, IT>>- только если включить форсаж, IT>>- бу сделано, IT>>- фигня вопрос.
G>То есть у тебя таки есть оценка времени выполнения, только ты сам её не говоришь.
Здравствуйте, IT, Вы писали:
T>>>>Если возвращаться к теме статьи, то ты не определил количественную меру сложности, поэтому не можешь сформулировать и закона сохранения IT>>>Не определил по одной простой причине — её не существует. G>>По одной простой причине — ты не настолько хорошо понимаешь проблему, чтобы определить количественную меру.
IT>100% не настолько хорошо. Хорошо если хотя бы на 0.5%.
Я это сказал только к тому, что очень тяжело доказать не существование чего-либо. Приведенная мной фраза — более честна, штоли.
IT>>>Блин, ещё один измеряльщик. Ну тогда сравни мне сложность восприятия безобразно оформленного кода, алгоритмическую сложность кода, объём кода, сложность обучения, необходимую для понимания кода, и сложность понимания поставленной задачи. При этом, желательно, чтобы формула была универсальной для любого программиста. G>>Техника работы с метриками основана на измерениях, сравнениях, анализе истории и поиске статистических закономерностей, а не "универсальных формулах для любого программиста".
IT>К сожалению, метрики никак не помогают мне при принятии решений, которые я как программист принимаю десятками ежедневно. А из этих решений в конце концов складывается результат, который может быть потом и можно как-то померить.
Метрики — они как спидометр, тахометр, и прочие приборы на доске автомобиля. В них самих по себе особой магии нет, и их наличие не позволяет алгоритмизовать управление автомобилем. Но — при принятии решений они _полезны_.
G>>Последнее — глупость.
IT>Глупость — не только последнее, а вообще любое использование метрик.
Ну, если у тебя есть автомобиль, то ты регулярно используешь метрики . С неработающей приборной доской в автомобиле ты даже не поймешь, что у тебя заканчивается бензин. С работающей — ты поймешь, что тебе надо бы на заправку зарулить, и увидев знак "это единственная заправка на 100 миль" ты туда завернешь.
G>>Для твоего случая — время на объем, плюс процентная раскладка времени на каждый этап. Вводи по очереди разные факторы, и проведи статистическое исследование, если тебе интересно. Мне предложенное тобой сравнение кажется лишенным какой-ли практической пользы. Так, абстрактное умствование.
IT>Статистическое исследование подразумевает как минимум необходимость понаблюдать за процессом.
Вообще говоря — верно. Но в принципе — не обязательно. Много чего можно собрать и постфактум, по уже завершенным проектам.
IT>Т.е. мы получим какие-то данные после того как уже будет поздно пить боржоми.
Нет, конечно. Мы будем использовать метрики, собранные в реальном времени, и сравнивать их с планом. А план составлять с оглядкой на историю.
Простейший пример — так называемый EV-Plan.
Составил план работ. Нарисовал кривую — общее количество (нарастающим итогом) закрытых задач понедельно, на основании плана. И каждую неделю наносишь на этот же график новую точку фактической кривой — с общим количеством фактически закрытых задач.
Вот тебе пример самого простого использования самой незамысловатой метрики. Ты не просто заметишь отставание по этому графику — ты в состоянии увидеть нарастающее отставание. И понять, что в плане систематическая недооценка. И сделать перепланирование, сдвинув сроки, или зарезав функциональность.
Глядя на разного рода гант-чарты — ты этого так просто не увидишь.
IT>Какой мне толк от знания того, что на решение задачи X с помощью технологии Y было затрачено Z Васе-Коле-Вите-часов, если в следующий раз я буду решать задачу A, используя технологию B и привлеку для её решения Петю и Ваню?
Пока не умеешь метриками пользоваться — никакого. Если умеешь — очень большой толк. Сходу этого, естественно, не поймешь — этому учиться надо.
В твоем случае — возьмешь метрики Пети и Вани, делов-то. И не надо рассказывать, что каждая новая задача у тебя на новой неизвестной технологии и языке программирования делается — это не так. Для прогноза берется не время на отдельной задаче, а средний коридор "продуктивности".
Далее, делаешь простую штуку. Планируешь время и объем. Считаешь запланированную продуктивность делением одного на другое, и:
— убеждаешься, что попал в коридор, а не вылетел из него.
— Смотришь на положение значения в коридоре, и следишь, что оно отражает твое представление о сложности.
Если указанное не выполняется — ты где-то ошибся в прогнозе, правь.
Я тебе простейший вариант планирования с учетом метрик дал. Есть другие.
Что до разброса времени на отдельных задачах — это неважно. Также не важно, что по отдельным задачам прогноз не совпадет. Они тебя не интересуют — важна суммарная оценка по проекту. Время решения задачи трактуется как случайная величина. И процентная дисперсия суммы этих величин будет уменьшаться при росте единиц планирования. Означает это одно — погрешности оценок будут взаимоуничтожены, если ты прогнозом попал в матожидание.
Здравствуйте, Sinclair, Вы писали:
>Потом какие-нибудь другие кренделя сводят все эти публикации и пишут монографию типа "мы обследовали семь педеровых компаний в области IT и заметили, что при применении X программисты в среднем в 2.34 раза чаще употребляют слово ".пт", чем аналитики при применении Y употребляют слово ".па". И из этого мы можем сделать вывод о том, что в XXI веке технологии управления проектами Z, W, и U устарели. В нашем быстроменяющемся рынке повысить удовлетворённость потребителей и надои трафика на квадратный байт можно только при помощи новой, альтернативной парадигмы управления, построенной на расширении полномочий и вовлечении работников. Процесс развития делегировния ответственности должен быть длительным, непрерывным, и незаметным, как зарытый в землю шланг". И так далее. Подобная писанина приносит $ на kLOC гораздо больше, чем любое программирование.
Какая милая фантазия о содержимом монографий, которых не читал .
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>А как тут учитывается "сложность" связанная с необходимым объемом знания для написания кода. S>Это не сложность проекта. Это сложность для HR найти нужного человека.
G>>Гипотетический пример — написать парсер языка без специальных инструментов. Влоб такая задача решается крайне плохо, используя некоторые теоретически знания — гораздо лучше.
G>>Многие современные языки как раз торгуют объем-время на эту самую сложность понимания.
S>В каком-то смысле можно считать эту "сложность" именно той сложностью, которая "сложность в отличие от трудоёмкости". Классический пример: выкопать яму объемом десять кубов не сложно, но трудоёмко. S>Придумать новый алгоритм сортировки — сложно.
Все правильно.
Трудоемкость характеризует объем работ. Выкопать яму объемом 20 кубов (при прочих равных — при условии того же грунта, исполнителя, инструментов, и т.п.) вдвое затратнее, чем 10 кубов. Реализовать 20 "одинаковых по сложности" независимых фич — при прочих равных в два раза затратнее, чем 10.
"Сложность" работ характеризует производительность труда, т.н. "продуктивность", которая есть "объем на время".
Т.е. 10 кубов песка выкопать гораздо "проще", чем 10 кубов глины, ибо мы будем копать песок в темпе побыстрее, чем глину.
Так же и с сортировкой. Выдумать и сделать новый алгоритм сортировки вообще говоря _дольше_, чем реализовать существующий, при равном размере кода. Т.е. "показатель строки кода в час" на задаче, где надо что-то выдумывать, будет вообще говоря _меньше_. Если предположить, что задача изолирована, и исключить таким образом влияние других факторов. Фактор внесения изменений в существующий код учитывается цикломатикой и связностью.
Берем _простейшую_ производную метрику — и она количественно характеризует этот подвид "сложности".
Эту "сложность" можно и _запланировать_, сделав, например, не только прогноз срока, но и одновременно прогноз объема.
Основная же ценность системы метрик — в том, что люди понимают взаимосвязь. Это понимание ценно и в том случае, если метрики не применять. Ибо закономерности работают независимо от того, проводишь ты измерения, или нет.
Здравствуйте, minorlogic, Вы писали:
M>"Трансформирование сложности означает одну простую вещь – устраняя сложность в одном месте, мы всегда добавляем её где-то в другом."
M>Очевиднейший бред, дальше читать не стал. И как только такой треш пропускает рецензура...
Один ошибочный вывод не делает бредом всю статью. В конце концов, непрерывно нести бред очень тяжело. Почти так же тяжело, как и все время говорить истину, и только истину . Если предмет статьи содержателен, конечно.
Здравствуйте, IT, Вы писали:
I>>Сто пудов, у тебя есть как минимум интуитивная оценочная функция и надо чуток поработать, что бы можно было сформули ровать внятно, по-человечески.
IT>Если ты имеешь ввиду оценочную функцию производительности труда, то такой функции у меня нет. Я более двадцати лет пишу код и когда сегодня мне мой начальник задаёт вопрос "сколько это займёт времени", то я однозначно отвечаю — "не знаю". С другой стороны, я могу задать встречный вопрос — "а сколько у меня есть времени", и, в зависимости от его ответа, я могу ответить одно из:
IT>- импосибл, IT>- только если включить форсаж, IT>- бу сделано, IT>- фигня вопрос.
Переводится в конкретные цифры методом половинного деления.
IT>При этом всегда присутствует оговорка, что это всё при отсутствии непредвиденных обстоятельств АКА мистической хреноты.
Чтобы учесть "обстоятельства", достаточно дать _два_ прогноза. С обстоятельствами и без них.
Грубо говоря — "раньше не справлюсь" — "точно успею". Разумные люди в прогнозах оперируют вариациями, а не "точными значениями". Но — при этом оперируют цифрами.
I>>Т.е. как то ты ухитряешься конвертиорвать васей в колей, но поделиться этим не можешь. Об чем тебе Гапертон и говорит
IT>Гапертон вообще говорит о чём-то своём. Он изобрёл метрику, в которой в качестве попугаев используются ошибки.
Первым этот подход изобрел Уотс Хамфри. И ошибки, конечно, там не используются в качестве "попугаев". Там вообще все просто, но не тупо.
IT>Я несказанно рад за него и ни чуточки не сомневаюсь, что эта метрика замечательно работает в его команде, на его проектах, при используемых им технологиях для оценки его рисков и сроков выполнения его работ.
Лучше за Хамфри порадуйся . И за студентов Carnegie-Mellon, у которых это в стандартную программу обучения входит.
IT>Только, во-первых, это всё его субъективный взгяд на его собственные проблемы, а, во-вторых, статья совсем не об этом.
Почему субъективный? Метрики-то как раз наблюдаемы объективно. А вот твои рассуждения о сложности — субъективны полностью.
IT>Обрати внимание, говоря о сложности, Гапертон всё время соскакивает на трудоёмкость.
Почему? Не только. Я все факторы учитываю. Про цикломатику, например, я достаточно внятно сказал.
IT>Он менеджер, он видит сложность только с этой стороны. В принципе, это нормально.
Нет, не правильно. Менеджер — это не более чем должность. И почкованием они не размножаются. У меня лет 10 стажа инженерной работы. И я с этой сложностью, как и любой Senior Software Developer (что тоже не более чем должность, а не религия и не образ мысли), знаком не хуже тебя. Все перечисленные тобой виды сложности имеют место быть, и прекрасно учитываются. У тебя просто системы нет в управлении сложностью. Я тебе ее показал. Вот и все.
Здравствуйте, IT, Вы писали:
G>>>>1) Объем. В строках кода, количестве классов, количестве функций — это не принципиально. Это — объем. IT>>>А что даёт такая метрика? G>>Дает объективную характеристику объема кода.
IT>Был у меня один случай лет пять назад. В Банке Оф Америка. Достался мне в наследство один недавно начатый проект от одного индуса. Объёма кода море, баги, глюки, тормоза, в общем всё как положено. После нескольких недель рефакторинга объём рукописного кода сократился раз в пять, баги, глюки, тормоза куда-то сами собой подевались, а тот же самый объём кода был достигнут только месяца через четыре, когда проект представлял собой уже не просто демку из формочек, а приложение под завяз напичканое функционалом.
И что? Одна и та же задача может быть решена в разное количество строк кода. Разные исполнители имею тенденции один и те же задачи укладывать в код, различающийся в размере до двух раз. И это нормально. Отдельные представители могут и вдесятеро больше кода написать.
И что с того? Метрика объема как характеризовала объем кода, так и продолжает его характеризовать. Объективно, ибо считается механически, а не субъективно. Поэтому, мы и можем
IT>С тех пор веру в объём кода как в объективную характеристику я окончательно потерял.
У тебя появились сомнения, что объем кода объективно и точно считается? Однако .
IT>Да и в дальнейшем не раз приходилось в этом убеждаться.
Появились сомнения — а теперь "убеждаться"? У тебя что, тулза измерения SLOC разные результаты выдавала от запуска к запуску на одном файле? Выкинь эту тулзу.
IT> Сейчас, кстати, работаю над проектом, вротой его версией. Искренне надеюсь, что удастся сократить объём кода раза в два по сравнению с первой версией.
Дык, отлично. Из этого факта можно сделать вывод, что подходы к решению во второй версии лучше, чем в первой. И надеятся, что в ней будет меньше ошибок.
Я не понял, ты думаешь, что ты какие-то возражения против элементарных метрик приводишь?
G>>А еще — дает неплохие корелляции с количеством ошибок и временем, для каждого отдельно взятого Васи, и Коли.
IT>Количество ошибок безусловно как-то коррелирует с объёмом кода, но гораздо сильнее оно коррелирует с количеством мозгов у ошибающегося.
Не "как-то", а очень хорошо кореллирует. Так как мозг у ошибающегося находится в относительно стабильном состоянии, количество ошибок дает прекрасные корреляции с тем объемом кода, который он пишет. Корреляции великолепны и очень сильны — гораздо сильнее, чем корреляции время-объем. Производная метрика "плотность ошибок" Defects/KLOC ну очень стабильная для каждого отдельно взятого разработчика.
Померь и убедись сам. Все факты, о которых я говорю, проверяемы. Для проверки этого, правда, придется фиксировать все вносимые тобой ошибки, а не только те, которые находят тестеры.
Ну а тот факт, что метрики персональны, и на других людей, команды, и задачи не переносимы — и так всем известен. Что ни разу не отменяет наличия статистических закономерностей между отдельными метриками.
G>>>>2) Время. С этим вопросов нет, не так-ли? IT>>>Вопрос. Что даст такая метрика без учёта способностей Васи и Коли? G>>Такая метрика объективно даст время решения задачи Васей и Колей. Никакого учета их способностей для измерения времени, которое они на задачу потратят, очевидно, не требуется.
IT>Т.е. это постфактум?
Для законченного проекта — постфактум, для незаконченного — прогноз.
IT>>>А что такое трудоёмкость? G>>Штука такая, сводится к оценка объема работы в человекочасах. Очевидно, определяется сочетанием задачи и человека. Парадокс? Наверное, только для программистов.
IT>Есть такая штука... точнее была когда-то в СССР, сейчас уже не уверен — сметные нормы на строительные работы, которые всячески пытались учитывать производительность труда. Так вот, правильные командиры и мастера строй-отрядов абсолютно безошибочно выбирали для отряда те виды работ, которые наиболее хорошо оплачивались при минимальных затратах ресурсов, учитывая особенности конкретных бойцов. Неправильные командиры брались за любую работу. В результате при примерно одинаково выполненных объёмах работ и человекочасах зарплата в разных отрядах отличалась в разы. Хотя делалось всё по одним сметным нормам, учитывающим одну и туже производительность труда.
Никто не говорит, что надо завязывать оплату на метрики и вообще учитывать их при оценке персонала и труда.
Более того, методики основанные на метриках говорят ровно обратное. Метрики _запрещено_ использовать для оценки "годности" персонала, и более того, например, в TSP менеджер вообще не видит индивидуальных метрик. Только агрегатные метрики по команде. Личные метрики считаются личной, приватной информацией, ее разглашать запрещено. Тулза их прячет.
IT>Под ресурсами здесь, кстати, понимается в основном грубая физическая сила имеющихся в наличии индивидуумов. Мы же здесь толкуем о работе мозгами. Если бы мы тогда работали мозгами, то разница была бы не в разы, а на порядки.
Корреляции элементарных метрик наблюдаемы объективно, в том числе и при работе мозгами.
G>>>>Вот и вся "сложность". Все, как видишь, очень просто. IT>>>Даже слишком просто. G>>Ты слишком много уделил внимания вводной части, в которой просто перечислялись известные объективные метрики, и пропустил часть, в которой была суть.
IT>Ты плохо читал статью. Я тщательно старался избегать любое упоминание о каких бы то ни было метриках.
Почему? Я очень внимательно прочитал статью. Ты тщательно избегал упоминания о метриках, а мне-то это зачем?
IT>Метрики нужны менеджерам, особенно плохим, им без них никак.
О как.
IT>Мне метрики не нужны, мне нужно распознать и предотвратить появление проблемных мест в приложении. А для этого мне вполне достаточно вещей вроде "больше"/"меньше".
Сравнивать на больше-меньше можно только количественные показатели. А не апельсины с бананами, и не вась с петями.
IT>>>Мало знать, что один код сложнее, чем другой. Сам по себе этот факт с практической точки зрения совершенно не интересен. G>>Мысль в моем комментарии чуточку посложнее этой банальщины. Но не понял, и ладно.
IT>Сложность твоей мысли из той же серии что и сложность в доставшемся мне проекте, о котором я говорил выше. Если её (мысль) правильно отрефакторить, то возможно она станет простой и понятной не только одному тебе. И возможно, у неё даже будет шанс когда-нибудь стать банальной
Она и понятна не только мне. Лично тебе она не понятна . Начиная с момента — что называется объективной метрикой. Но я, в общем, не в претензии.
Здравствуйте, gandjustas, Вы писали:
G>В принципе ты можешь сам называть срок "только если включить форсаж" и "фигня вопрос", как нижнюю и верхнюю границу времени выполнения. С теми же оговорками про риски.
Не могу. Включить форсаж означает потеря качества кода. Это приемлемо в редких случаях, но заниматься этим систематически крайне вредно. К тому же предлагая нижнюю и верхнюю границу, я буду иметь ввиду верхнюю, а начальник всегда нижнюю. Какой смысл а таких сроках?
G>Трудоемкость — функция сложности. Все параметры "сложности" так или иначе выражаются в характеристиках трудоемкости. А при некотором объеме статистики по этим параметрам уже можно выявить закономерности.
Трудоёмеость в программировании — это в чистом виде субъективная оценка конкретного индивидуума сроков выполнения его проектов, построенная на его предпочтениях. Можно, конечно, выявлять закономерности, но работать это будет в строго ограниченных рамках. Если бы такие закономерности можно было бы выявить хотя бы приблизительно и распространить на всю индустрию, то это уже давно было бы сделано. Уже давно закончились бы споры C# vs Java vs C++ и в мире рулил бы Немерле Но пока это не так. Потому что в мире есть люди со своими предпочтениями, есть "зи" архитекторы, принимающие дебильные решения, есть менеджеры, не умеющие распределять ресурсы, есть программисты с кривыми конечностями. И наоборот.
G>Странно что ты пытаешься не замечать этого.
Мне это не интересно в рамках данного обсуждения. Я вообще не об этом. Вот смотри, подходит, например, к тебе твой младший товарищ с таким вопросом — "Товарищ, gandjustas, что мне здесь лучше использовать? Visitor pattern, walker, просто набор ifs, заиспользовать F# и его ПМ или вообще забить?". Что ты ему ответишь?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
G>>В принципе ты можешь сам называть срок "только если включить форсаж" и "фигня вопрос", как нижнюю и верхнюю границу времени выполнения. С теми же оговорками про риски.
IT>Не могу. Включить форсаж означает потеря качества кода. Это приемлемо в редких случаях, но заниматься этим систематически крайне вредно. К тому же предлагая нижнюю и верхнюю границу, я буду иметь ввиду верхнюю, а начальник всегда нижнюю. Какой смысл а таких сроках?
Поэтому оценка из двух сроков и дается.
G>>Трудоемкость — функция сложности. Все параметры "сложности" так или иначе выражаются в характеристиках трудоемкости. А при некотором объеме статистики по этим параметрам уже можно выявить закономерности.
IT>Трудоёмеость в программировании — это в чистом виде субъективная оценка конкретного индивидуума сроков выполнения его проектов, построенная на его предпочтениях.
В том то и дело что трудоемкость — чисто объективна, так как легко измеряется.
IT>Можно, конечно, выявлять закономерности, но работать это будет в строго ограниченных рамках. Если бы такие закономерности можно было бы выявить хотя бы приблизительно и распространить на всю индустрию, то это уже давно было бы сделано. Уже давно закончились бы споры C# vs Java vs C++ и в мире рулил бы Немерле Но пока это не так. Потому что в мире есть люди со своими предпочтениями, есть "зи" архитекторы, принимающие дебильные решения, есть менеджеры, не умеющие распределять ресурсы, есть программисты с кривыми конечностями. И наоборот.
Ну это же не повод совсем отказываться от оценок.
G>>Странно что ты пытаешься не замечать этого.
IT>Мне это не интересно в рамках данного обсуждения. Я вообще не об этом. Вот смотри, подходит, например, к тебе твой младший товарищ с таким вопросом — "Товарищ, gandjustas, что мне здесь лучше использовать? Visitor pattern, walker, просто набор ifs, заиспользовать F# и его ПМ или вообще забить?". Что ты ему ответишь?
Используй Силу, юный падаван. (серьезно)
Здравствуйте, gandjustas, Вы писали:
IT>>Трудоёмеость в программировании — это в чистом виде субъективная оценка конкретного индивидуума сроков выполнения его проектов, построенная на его предпочтениях. G>В том то и дело что трудоемкость — чисто объективна, так как легко измеряется.
Постфактум мало интересен. Мне нужно принимать решение здесь и сейчас, а не после разбора полётов.
IT>>Можно, конечно, выявлять закономерности, но работать это будет в строго ограниченных рамках. Если бы такие закономерности можно было бы выявить хотя бы приблизительно и распространить на всю индустрию, то это уже давно было бы сделано. Уже давно закончились бы споры C# vs Java vs C++ и в мире рулил бы Немерле Но пока это не так. Потому что в мире есть люди со своими предпочтениями, есть "зи" архитекторы, принимающие дебильные решения, есть менеджеры, не умеющие распределять ресурсы, есть программисты с кривыми конечностями. И наоборот. G>Ну это же не повод совсем отказываться от оценок.
Да ради бога. Только я ещё раз повторяю, в рамках данной статьи мне эта тема не интересна.
IT>>Мне это не интересно в рамках данного обсуждения. Я вообще не об этом. Вот смотри, подходит, например, к тебе твой младший товарищ с таким вопросом — "Товарищ, gandjustas, что мне здесь лучше использовать? Visitor pattern, walker, просто набор ifs, заиспользовать F# и его ПМ или вообще забить?". Что ты ему ответишь? G>Используй Силу, юный падаван. (серьезно)
А почему не "Используй Трудоёмкость, юный падаван."?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Ikemefula, Вы писали:
>>С другой стороны, я могу задать встречный вопрос — "а сколько у меня есть времени", и, в зависимости от его ответа, я могу ответить одно из: I>Я это понимаю. Но это ведь для тех случав, когда работа радикально отличается от тех что были раньше ? Или ты имеешь скзать, что тебя ставят на проекты на которых другие уже провалили всё подряд ?
Не обязательно радикально отличаться. Может быть просто ситуация приоритетная и надо сделать быстро. А может быть наоборот.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Не могу. Включить форсаж означает потеря качества кода. Это приемлемо в редких случаях, но заниматься этим систематически крайне вредно. К тому же предлагая нижнюю и верхнюю границу, я буду иметь ввиду верхнюю, а начальник всегда нижнюю. Какой смысл а таких сроках?
Твой начальник — идиот? Он не понимает, что ты ему вариацией даешь оценки случайной величины, и чтобы избежать систематической недооценки в плане, надо взять нечто похожее на "матожидание", т.е. как минимум (H-L)/2?
И чтобы успеть к общему сроку — на весь проект заложить "буфер безопасности", накинув как минимум одну сигму сверху, что даст нам примерно 85% вероятность укладывания в срок?
Ну, если он все-таки идиот (в чем я лично сильно сомневаюсь) — то ты говори ему M + S, то есть оценку, стоящую на трех четвертях между вариациями сроков. Тебе-то что мешает?
G>>Странно что ты пытаешься не замечать этого.
IT>Мне это не интересно в рамках данного обсуждения. Я вообще не об этом. Вот смотри, подходит, например, к тебе твой младший товарищ с таким вопросом — "Товарищ, gandjustas, что мне здесь лучше использовать? Visitor pattern, walker, просто набор ifs, заиспользовать F# и его ПМ или вообще забить?". Что ты ему ответишь?
"Полшестого". Ни разу не припомню, что бы кто-то к кому-то приходил с подобным вопросом.
Но вот если я ему предложу правку к его подходу, то аргументом будут объективно наблюдаемые вещи, а не гениальные только мне видные прозрения, подкрепленнные метафизикой.
Например, сокращение объема кода (и соответственно работы), упрощение этого кода (выражающееся в низкой цикломатике), или дешевизна будущих правок, выражающаяся в объеме кода и количестве место при внесении правки.
Здравствуйте, Gaperton, Вы писали:
G>То, что ты в своих рассуждениях ввел разнообразные факторы — это неплохо. Это лучше, чем просто говорить "сложно". Но непосредственно из этого ничего не следует, ибо с проектным управлением твои рассуждения не стыкуются. Они не уложены в систему. Рассуждать, в результате, ты не можешь — ты можешь только пользоваться "чуйкой".
Я могу обосновать правильность выбора того или иного решения в процессе разработки и при этом учесть максимальное количество влияющих на это факторов. А какое решение примешь ты, зная что в прошлом проекте у тебя было 125 багов?
G>Как их уложить в систему — я тебе показал.
Я тут выше по ветке приводил пример с мндусиком, вклад которого в код был 5%, а количество багов в треккере 80%. После его изгнания его код был переписан и количество багов у команды сократилось в 5 раз. Вот и вся твоя система. Меня вообще из IBM провожали со словами "Мужик, мы тебя запомнить как человека, не оставившего следов в баг-треккере". На что ты теперь будешь умножать свою трудоёмкость, на 0?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
IT>>>Трудоёмеость в программировании — это в чистом виде субъективная оценка конкретного индивидуума сроков выполнения его проектов, построенная на его предпочтениях. G>>В том то и дело что трудоемкость — чисто объективна, так как легко измеряется.
IT>Постфактум мало интересен. Мне нужно принимать решение здесь и сейчас, а не после разбора полётов.
И при принятии решения ты учитываешь собственный прогноз трудоемкости. Сознательно, или безсознательно.
IT>>>Можно, конечно, выявлять закономерности, но работать это будет в строго ограниченных рамках. Если бы такие закономерности можно было бы выявить хотя бы приблизительно и распространить на всю индустрию, то это уже давно было бы сделано. Уже давно закончились бы споры C# vs Java vs C++ и в мире рулил бы Немерле Но пока это не так. Потому что в мире есть люди со своими предпочтениями, есть "зи" архитекторы, принимающие дебильные решения, есть менеджеры, не умеющие распределять ресурсы, есть программисты с кривыми конечностями. И наоборот. G>>Ну это же не повод совсем отказываться от оценок.
IT>Да ради бога. Только я ещё раз повторяю, в рамках данной статьи мне эта тема не интересна.
Не интересна — зачем комментируешь? Дай другим обсудить. Вдруг — кому-то еще интересна?
IT>>>Мне это не интересно в рамках данного обсуждения. Я вообще не об этом. Вот смотри, подходит, например, к тебе твой младший товарищ с таким вопросом — "Товарищ, gandjustas, что мне здесь лучше использовать? Visitor pattern, walker, просто набор ifs, заиспользовать F# и его ПМ или вообще забить?". Что ты ему ответишь? G>>Используй Силу, юный падаван. (серьезно)
IT>А почему не "Используй Трудоёмкость, юный падаван."?
Да нивапрос. Используй Трудоемкость, юный падаван . Единственный эффективный способ сделать работу быстрее — не делать лишней работы.
Здравствуйте, IT, Вы писали:
G>>То, что ты в своих рассуждениях ввел разнообразные факторы — это неплохо. Это лучше, чем просто говорить "сложно". Но непосредственно из этого ничего не следует, ибо с проектным управлением твои рассуждения не стыкуются. Они не уложены в систему. Рассуждать, в результате, ты не можешь — ты можешь только пользоваться "чуйкой".
IT>Я могу обосновать правильность выбора того или иного решения в процессе разработки и при этом учесть максимальное количество влияющих на это факторов. А какое решение примешь ты, зная что в прошлом проекте у тебя было 125 багов?
Не зная значения остальных метрик, и других деталей — никакого. Метрики сами по себе, и, тем более, взятые по отдельности — ничего не значат. Они должны интерпретироваться в некотором контексте.
Например, если 120 из 125 багов локализованы в одном модуле, и "плотность ошибок" Defects/KLOC в нем аномально высока, и выходит за обычную вариацию — я буду искать причину этой аномалии, разбираться с ситуацией, и принимать меры. В особенности, если туда будут ожидаться в будущем правки. А какие именно меры — это уже зависит от ситуации.
И в будущем — обязательно проверю, возымели меры эффект, или нет.
G>>Как их уложить в систему — я тебе показал.
IT>Я тут выше по ветке приводил пример с мндусиком, вклад которого в код был 5%, а количество багов в треккере 80%. После его изгнания его код был переписан и количество багов у команды сократилось в 5 раз. Вот и вся твоя система.
Если бы такой индус затесался в команду, которая применяет метрики для мониторинга состояния проекта, его моментально бы вычислили по аномально большому объему закоммиченного кода, который он пишет аномально высокими темпами, задолго до того, как его баги успели бы попасть в трекер. Вылет метрик за три сигмы — не хрен собачий, этого не спрячешь.
И это, разумеется, далеко не вся "моя система". В реальности — он вообще ничего закоммитить не смог бы, по причине наличия код- и дизайн-ревью. И при регулярно зашкаливающем количестве issues на этом ревью (тоже метрика), он бы довольно скоро был вынужден либо включить мозг в положение ON, либо пойти искать себе другую работу.
IT>Меня вообще из IBM провожали со словами "Мужик, мы тебя запомнить как человека, не оставившего следов в баг-треккере". На что ты теперь будешь умножать свою трудоёмкость, на 0?
Из этого следует три возможных вывода — либо ты ничего в IBM не писал, либо — тщательно проектировал и тестировал свой код, либо твоим кодом никто не пользовался и багов не репортил. Проверяется, что именно из тех — элементарно.
Не понял — и зачем мне на что-то умножать свою трудоемкость?
Здравствуйте, Gaperton, Вы писали:
G>Ну, если у тебя есть автомобиль, то ты регулярно используешь метрики . С неработающей приборной доской в автомобиле ты даже не поймешь, что у тебя заканчивается бензин. С работающей — ты поймешь, что тебе надо бы на заправку зарулить, и увидев знак "это единственная заправка на 100 миль" ты туда завернешь.
А принимая решение повернуть налево или направо ты каким прибором пользуешься, спидометром или тахометром?
G>Вот, реально, простейший вариант.
Судя по всему мы с тобой говорим о разных вещах. Ну правда, мне не интересна тема управления проектами в рамках данной статьи. Где-нибудь в другом месте я бы с удовольствием потрепался на эту тему. А здесь мне интересней выяснить, например, почему решения, использующие Visitor pattern в целом сложнее, чем применение pattern-matching.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Gaperton, Вы писали:
G>>Ну, если у тебя есть автомобиль, то ты регулярно используешь метрики . С неработающей приборной доской в автомобиле ты даже не поймешь, что у тебя заканчивается бензин. С работающей — ты поймешь, что тебе надо бы на заправку зарулить, и увидев знак "это единственная заправка на 100 миль" ты туда завернешь.
IT>А принимая решение повернуть налево или направо ты каким прибором пользуешься, спидометром или тахометром?
Выбирая маршрут — наручными часами, показывающими текущее время, и данными по средней скорости потока на карте, которые выдает навигатор в виде цветных линий.
Принимая решение повернуть направо на заправку — указателем бензина в бензобаке.
И разумеется, я, как разумный человек, учитываю значение спидометра, принимая решение о повороте как налево, так и направо. Если по показаниям спидометра будет очевидно, что я при такой скорости не впишусь в поворот, куда я хотел поворачивать, я, как разумный человек, приму решение поворот пропустить.
Даже если указатель бензина будет мне говорить о том, что поворот надо сделать, прикинь?
G>>Вот, реально, простейший вариант.
IT>Судя по всему мы с тобой говорим о разных вещах. Ну правда, мне не интересна тема управления проектами в рамках данной статьи.
Я обсуждаю именно сложность, а не "управление проектами". И говорить о сложности вне связи со временем и объемом, т.е. наблюдаемыми характеристиками работы и ее результата — не интересно уже мне. Ибо сие есть метафизика.
IT>Где-нибудь в другом месте я бы с удовольствием потрепался на эту тему. А здесь мне интересней выяснить, например, почему решения, использующие Visitor pattern в целом сложнее, чем применение pattern-matching.
Потому, что в случае визитора для того, чтобы понять, что написано, и что это именно визитор — тебе надо посмотреть код в нескольких местах, и немного подумать, а в случае паттерн-матчинга — все написано в одном месте, и распознавать ничего не нужно. Меньше дергаться, меньше читать, меньше думать, что хотел сказать автор.
Причина наличия "паттернов" — слабый адхок полиморфизм в ОО модели. Только по одному (неявному) аргументу. В паттерн-матчинге он делается по любому количеству аргументов. Паттерн же раздербанивает тебе "единицу мысли", размазывая ее по нескольким местам, затрудняя reverse engineering, ибо тебе надо из фрагментов все заново сложить, а это уже работа.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
IT>>>Трудоёмеость в программировании — это в чистом виде субъективная оценка конкретного индивидуума сроков выполнения его проектов, построенная на его предпочтениях. G>>В том то и дело что трудоемкость — чисто объективна, так как легко измеряется. IT>Постфактум мало интересен. Мне нужно принимать решение здесь и сейчас, а не после разбора полётов.
Анализ предыдущего опыта (не только своего) помогает принимать решения.
IT>>>Можно, конечно, выявлять закономерности, но работать это будет в строго ограниченных рамках. Если бы такие закономерности можно было бы выявить хотя бы приблизительно и распространить на всю индустрию, то это уже давно было бы сделано. Уже давно закончились бы споры C# vs Java vs C++ и в мире рулил бы Немерле Но пока это не так. Потому что в мире есть люди со своими предпочтениями, есть "зи" архитекторы, принимающие дебильные решения, есть менеджеры, не умеющие распределять ресурсы, есть программисты с кривыми конечностями. И наоборот. G>>Ну это же не повод совсем отказываться от оценок.
IT>Да ради бога. Только я ещё раз повторяю, в рамках данной статьи мне эта тема не интересна.
Тебе — может и неинтересна, а другим вполне. Меня уже давно интересует сложность не сама по себе, а какими последствиями это грозит на проекте. Если я увижу что применение X вместо Y вызывало увеличение плотности багов и уменьшение скорости написания кода, то смогу сделать определенные выводы. А если будут только рассуждения о сложности той или иной функциональности, то мне это ничего не даст.
Здравствуйте, Gaperton, Вы писали:
G>Причина наличия "паттернов" — слабый адхок полиморфизм в ОО модели. Только по одному (неявному) аргументу. В паттерн-матчинге он делается по любому количеству аргументов. Паттерн же раздербанивает тебе "единицу мысли", размазывая ее по нескольким местам, затрудняя reverse engineering, ибо тебе надо из фрагментов все заново сложить, а это уже работа.
То есть, для распознавания случая применения "паттерна", и для внесения сознательной правки, тебе надо удерживать в голове несколько объектов/мест одновременно. Это отвлекает в случае, когда ты знаешь что там паттерн, а вот если ты не знаешь — то тебе еще надо найти эти места, чтобы потом сложить из них "паттерны".
Учитывая, что одна из основных характеристик "хорошего" дизайна, это как раз количество мест + объем логики, которые тебе надо понимать и держать в уме одновременно, для внесения осмысленной правки — код с агрессивным применением "паттернов" таковым является с большой натяжкой.
Особенно учитывая, что "паттерны" не имеют никакого отношения к сути решаемой задачи. Получается, что усилия, которые тратятся на их понимание — непродуктивны, это борьба с низкой выразительностью языка.
Паттернов-исключений, для распознавания которых не требуется складывать в голове головоломку из фрагментов, и которые легко (в один ход) узнаваемы, вышесказанное не касается.
Хороший дизайн подразумевает разбиение кода на набор слабосвязных компонент. Связность бывает "по состоянию" и "функциональная". Связность характеризуется "шириной интерфейса" (количеством разных функций/сообщений — функциональная связность) и сложностью протокола поверх данного интерфейса (связность по состоянию). Последняя характеризуется количеством состояний в протоколе.
Клинический случай сильной связности по состоянию — общие данные.
Так вот, для внесения правки в хороший дизайн тебе надо понимать небольшой фрагмент системы, и ты не сильно рискуешь. Происходит это благодаря связности. Основные свойства системы, характеризующие дизайн (т.е. входные данные для его оценки), можно выразить через объективные количественные метрики, и именно этот факт позволяет тебе оценивать их интуитивно, используя хитрую весовую функцию в голове, которая строится годами на основе твоего опыта.
А вот "весовую функцию" которая выполняет оценку в твоей голове, формализовать на все случаи жизни не просто невозможно, но просто бессмысленно и не нужно. Это есть тот самый уникальный "творческий" компонент. И это основной момент в работе с метриками, который ты почему-то отказываешься понимать. Пойми.
Здравствуйте, IT, Вы писали:
G>>У тебя просто системы нет в управлении сложностью. Я тебе ее показал. Вот и все.
IT>Вообще-то ты показал управление сроками, а не сложностью.
Точно так. К этому "прикладная теория сложности" и сведется.
Вне контекста сроков (трудоемкости) текущих и будущих работ, сложность, взятая сама по себе, ни малейшего интереса не представляет. Нафига нам абстрактная "сложность", никак не влияющая на сроки работ и цену внесения изменений?
Вот у тебя кусок кода. У него "высокая сложность", что означает крайне дорогие правки в этот код, даже если правки сами по себе незначительные. Но! Код отлажен, изолирован за годными интерфейсами, отлично работает, и никаких правок туда в ближайшие 5 лет не ожидается.
Тебя волнует его сложность? Ты будешь тратить время на то, чтобы его "рефакторить", понижая "сложность"?
Здравствуйте, Gaperton, Вы писали:
IT>>С тех пор веру в объём кода как в объективную характеристику я окончательно потерял. G>У тебя появились сомнения, что объем кода объективно и точно считается? Однако . IT>>Да и в дальнейшем не раз приходилось в этом убеждаться. G>Появились сомнения — а теперь "убеждаться"? У тебя что, тулза измерения SLOC разные результаты выдавала от запуска к запуску на одном файле? Выкинь эту тулзу.
О, да! Допустим, у меня в команде объём одного из проектов 50k строк. Как ты думаешь — это сложный проект или не очень? А объём второго — 100k. Какой из них сложнее? А сложнее в чём? А какой быстрее написали? А на сколько быстрее?
IT>>Под ресурсами здесь, кстати, понимается в основном грубая физическая сила имеющихся в наличии индивидуумов. Мы же здесь толкуем о работе мозгами. Если бы мы тогда работали мозгами, то разница была бы не в разы, а на порядки. G>Корреляции элементарных метрик наблюдаемы объективно, в том числе и при работе мозгами.
Здорово. Только я всё не возьму в толк, как мне это поможет выбрать правильный дизайн базы данных? Вот, например, у меня есть форма с гридом, в котором 24 колонки для 24-х месяцев, по 12 на 2 года. Как мне лучше их уложить в базу, как 24 месяца в одну запись или как две записи по 12 месяцев? Какую метрику посоветуешь?
IT>>Ты плохо читал статью. Я тщательно старался избегать любое упоминание о каких бы то ни было метриках. G>Почему? Я очень внимательно прочитал статью. Ты тщательно избегал упоминания о метриках, а мне-то это зачем?
Заметь, статья не о метриках, а о сложности. В основном о сложности выбора между двумя/тремя/... решениями. А не о сроках выполнения проектов.
IT>>Мне метрики не нужны, мне нужно распознать и предотвратить появление проблемных мест в приложении. А для этого мне вполне достаточно вещей вроде "больше"/"меньше". G>Сравнивать на больше-меньше можно только количественные показатели. А не апельсины с бананами, и не вась с петями.
Да ну? Если я буду использовать, например, датасеты в своём приложении, то ускорю его написание на пару дней. А если не буду, то уменьшу баговость процентов на 30%. Сравнивай и, главное, выбирай.
IT>>Сложность твоей мысли из той же серии что и сложность в доставшемся мне проекте, о котором я говорил выше. Если её (мысль) правильно отрефакторить, то возможно она станет простой и понятной не только одному тебе. И возможно, у неё даже будет шанс когда-нибудь стать банальной
G>Она и понятна не только мне. Лично тебе она не понятна . Начиная с момента — что называется объективной метрикой. Но я, в общем, не в претензии.
Лично мне она прежде всего не интересна, потому что абсолютно не в тему.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Gaperton, Вы писали:
IT>>Мне это не интересно в рамках данного обсуждения. Я вообще не об этом. Вот смотри, подходит, например, к тебе твой младший товарищ с таким вопросом — "Товарищ, gandjustas, что мне здесь лучше использовать? Visitor pattern, walker, просто набор ifs, заиспользовать F# и его ПМ или вообще забить?". Что ты ему ответишь?
G>"Полшестого". Ни разу не припомню, что бы кто-то к кому-то приходил с подобным вопросом.
А я ни разу не припомню, чтобы ко мне кто-то приходил и говорил — у тебя в прошлый раз было 5 багов, теперь тебе 2 месяца на решение новой задачи.
G>Но вот если я ему предложу правку к его подходу, то аргументом будут объективно наблюдаемые вещи, а не гениальные только мне видные прозрения, подкрепленнные метафизикой. а не гениальные только мне видные прозрения, подкрепленнные метафизикой.
А в чём гениальность?
G>Например, сокращение объема кода (и соответственно работы), упрощение этого кода (выражающееся в низкой цикломатике), или дешевизна будущих правок, выражающаяся в объеме кода и количестве место при внесении правки.
Т.е. ты ему скажешь, что если пойдёшь налево, то напишешь кода на 1264 строки меньше. Пойдёшь направо — справишься бысрее на 5 часов. Пойдёшь прямо — сделаешь 14 багов. Так? Я тебя правильно понял? А если не так, то чем твоя гениальность отличается от моей, твоя эзотерика от моей метафизики?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Gaperton, Вы писали:
IT>>Постфактум мало интересен. Мне нужно принимать решение здесь и сейчас, а не после разбора полётов. G>И при принятии решения ты учитываешь собственный прогноз трудоемкости. Сознательно, или безсознательно.
Я не только трудоёмкость учитываю, а ещё много чего другого.
IT>>Да ради бога. Только я ещё раз повторяю, в рамках данной статьи мне эта тема не интересна. G>Не интересна — зачем комментируешь? Дай другим обсудить. Вдруг — кому-то еще интересна?
Пожалуйста, сколько угодно.
IT>>>>Мне это не интересно в рамках данного обсуждения. Я вообще не об этом. Вот смотри, подходит, например, к тебе твой младший товарищ с таким вопросом — "Товарищ, gandjustas, что мне здесь лучше использовать? Visitor pattern, walker, просто набор ifs, заиспользовать F# и его ПМ или вообще забить?". Что ты ему ответишь? G>>>Используй Силу, юный падаван. (серьезно)
IT>>А почему не "Используй Трудоёмкость, юный падаван."?
G>Да нивапрос. Используй Трудоемкость, юный падаван . Единственный эффективный способ сделать работу быстрее — не делать лишней работы.
Складывается впечатление, что у тебя ввобще кроме "быстрее" нет больше никаких критериев сложности. Тебе никогда не приходилось работать над проектами или хотя бы слышать о таких, в которых сроки вообще не имели никакого определяющего значения?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>>>Мне это не интересно в рамках данного обсуждения. Я вообще не об этом. Вот смотри, подходит, например, к тебе твой младший товарищ с таким вопросом — "Товарищ, gandjustas, что мне здесь лучше использовать? Visitor pattern, walker, просто набор ifs, заиспользовать F# и его ПМ или вообще забить?". Что ты ему ответишь?
G>>"Полшестого". Ни разу не припомню, что бы кто-то к кому-то приходил с подобным вопросом.
IT>А я ни разу не припомню, чтобы ко мне кто-то приходил и говорил — у тебя в прошлый раз было 5 багов, теперь тебе 2 месяца на решение новой задачи.
И такого я тоже такого не припомню. Зачем кому-то к тебе приходить, и говорить что-то вроде "в огороде бузина, а в Киеве дядька"? Не понимаю.
G>>Но вот если я ему предложу правку к его подходу, то аргументом будут объективно наблюдаемые вещи, а не гениальные только мне видные прозрения, подкрепленнные метафизикой. а не гениальные только мне видные прозрения, подкрепленнные метафизикой.
IT>А в чём гениальность?
В том, что не строя в рассуждении связи с объективно наблюдаемыми характеристиками и фактами, пусть даже наблюдаемыми постфактум, ты не сможешь толком объяснить, почему надо делать именно так, а не иначе. И останется полагаться на свой авторитет и веру в "гениальность".
G>>Например, сокращение объема кода (и соответственно работы), упрощение этого кода (выражающееся в низкой цикломатике), или дешевизна будущих правок, выражающаяся в объеме кода и количестве место при внесении правки.
IT>Т.е. ты ему скажешь, что если пойдёшь налево, то напишешь кода на 1264 строки меньше. Пойдёшь направо — справишься бысрее на 5 часов. Пойдёшь прямо — сделаешь 14 багов. Так? Я тебя правильно понял? А если не так, то чем твоя гениальность отличается от моей, твоя эзотерика от моей метафизики?
Объем-ошибки и объем-время дают корреляции, так что предложенная тобой альтернатива либо-либо-либо невозможна в принципе. Меньше кода — в среднем меньше ошибок, меньше времени. Это в целом и общем. В деталях и в конкретных случаях — возможны варианты.
Мне достаточно будет сказать, почему не сделать вот так — кода будет сильно меньше. И вовсе не обязательно приводить "точное" значение, насколько строк меньше. Есть и другие критерии, за которыми также стоят объективно измеримые вещи. Но значимость их — зависит от ситуации.
Разница в том, что ты отказываешься привязывать свою теорию сложности к объективно измеримым вещам.
Здравствуйте, IT, Вы писали:
IT>>>Постфактум мало интересен. Мне нужно принимать решение здесь и сейчас, а не после разбора полётов. G>>И при принятии решения ты учитываешь собственный прогноз трудоемкости. Сознательно, или безсознательно.
IT>Я не только трудоёмкость учитываю, а ещё много чего другого.
Ты ошибаешься. Не так уж и много.
G>>Да нивапрос. Используй Трудоемкость, юный падаван . Единственный эффективный способ сделать работу быстрее — не делать лишней работы.
IT>Складывается впечатление, что у тебя ввобще кроме "быстрее" нет больше никаких критериев сложности.
"Быстрее" не является критерием сложности.
IT> Тебе никогда не приходилось работать над проектами или хотя бы слышать о таких, в которых сроки вообще не имели никакого определяющего значения?
Вопрос некорректен. В любом _проекте_ сроки имеют значение, ибо проект всегда ограничен временем по определению. Не ограничены временем _программа_ и разгильзяйство. Но программа состоит из проектов. А из чего состоит разгильзяйство — мне не интересно.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Gaperton, Вы писали:
IT>>>С тех пор веру в объём кода как в объективную характеристику я окончательно потерял. G>>У тебя появились сомнения, что объем кода объективно и точно считается? Однако . IT>>>Да и в дальнейшем не раз приходилось в этом убеждаться. G>>Появились сомнения — а теперь "убеждаться"? У тебя что, тулза измерения SLOC разные результаты выдавала от запуска к запуску на одном файле? Выкинь эту тулзу.
IT>О, да! Допустим, у меня в команде объём одного из проектов 50k строк. Как ты думаешь — это сложный проект или не очень?
Никак не думаю. Информации для раздумий ноль. Не задан ни достаточный набор метрик, ни контекст, в котором их надо интерпретировать. Задан только один дурацкий вопрос.
IT> А объём второго — 100k. Какой из них сложнее? А сложнее в чём? А какой быстрее написали? А на сколько быстрее?
Метрика "время". Она элементарна, и поддается прямому измерению. Не понимаю, с какого дуба я должен догадываться о том, что полагается измерять.
IT>>>Под ресурсами здесь, кстати, понимается в основном грубая физическая сила имеющихся в наличии индивидуумов. Мы же здесь толкуем о работе мозгами. Если бы мы тогда работали мозгами, то разница была бы не в разы, а на порядки. G>>Корреляции элементарных метрик наблюдаемы объективно, в том числе и при работе мозгами.
IT>Здорово. Только я всё не возьму в толк, как мне это поможет выбрать правильный дизайн базы данных? Вот, например, у меня есть форма с гридом, в котором 24 колонки для 24-х месяцев, по 12 на 2 года. Как мне лучше их уложить в базу, как 24 месяца в одну запись или как две записи по 12 месяцев? Какую метрику посоветуешь?
Посоветую не морочить людям голову, и перестать выдумывать и писать ерунду.
Здравствуйте, Gaperton, Вы писали:
G>Какая милая фантазия о содержимом монографий, которых не читал .
Как раз по менеджменту я монографии читал.
G>На почитай, что Уотс Хамфри о метриках пишет. Тот самый, который CMMI. Что характерно — более-менее адекватное представление об этом имеет каждый _студент_ Carnegie-Mellon SEI — у них в программу обучения включено. G>http://www.amazon.com/Introduction-Personal-Software-Process-sm/dp/0201548097
Я рад за Хамфри. Тем не менее, всякими software process теория менеджмента не исчерпывается.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Sinclair, Вы писали:
Странное ощущение, что пишущие и чиатющие разговаривают на разных языках.
M>>>Так бы и продолжалось дальше, но увы, экспоненциальное развитие скорости компьютеров практически закончилось.
Практически можно согласиться.
И просто увеличение количества уровней абстракции (вроде применения более высокоуровневых языков программирования) уже не поможет — железо не потянет.
Во первых, конечно, потянет, а во-вторых другого пути просто нет. За исключением распараллеливания.
S>>И это тоже неправда. Простой пример: запись вида int a = b + c / d — e; находится на совсем другом уровне абстракции, чем набор из mov EAX, .... Тем не менее, производительность программы будет ничуть не хуже.
Действительно на другом. И что?
G>Более того. На современных суперскалярно-конвейерных процах производительность будет на практике не то что не хуже, а лучше.
Для того и уровни абстракции, что б иметь возможность эффективней использовать возможности более низкого уровня.
G>Пример про то, как тупенький gcc компилирует два подряд идущих умножения для тупенького MIPS я уже раньше приводил. Одно делается как умножение, второе — на сдвигах-сложениях. Выполняется такое _быстрее_.
И, наконец, какое отношение увеличение/уменьшение производительности имеет к сложности?
S_>-------------- S_>Лучше бы студия отдельно все считала, отдельно циклы, отдельно функции,отдельно if'ы, ... S_>А потом показывала бы красивые картинки, диаграммы. Какие-то диаграммы распределения функций по числу вызовов, по размеру функции, классов по числу членов, по соотношению числа приватных и публичных членов... Эти картинки хоть можно принять к сведению будет, какая то инфа о характере кода. S_>И желательна возможность написания своих скриптов для получения суммарных показателей.
S_> А для связей между классами какие-то картинки где бы была видна кластеризация, и чтобы сотни классов на одной картинке было видно, но это уже сложно.
S_>Еще можно было бы подсчитывать показатель объема повторной используемости функций. Т.е. взять число IL инструкций программы, затем все функции условно подставить(распаковать) в точку вызова, и вычислить на сколько процентов вырастет число инструкций. Когда функция вызывается из одного места, то повторной используемости нет, ее могли выделить только для уменьшения сложности. А когда большая функция вызывается из разных 10 мест, то это уже совсем другое...
S_> При изучении незнакомого кода, например откуда-то скачанного. Полезно сначала посмотреть на метрики, но хотелось бы чего то посерьезнее чем сейчас в студии.
Совершенно согласен. If-ы и циклы имеют разную природу сложности. Их необходимо считать отдельно. И, есть замечание по общей статистике. Есть объективная природа задачи. И выбор концепции решения. От этого объективно будет зависеть результат собраной статистики. Например разбор выражения If-ми или рекурсивно используя грамматику покажут разный уровень сложности. Даже любопытно как их сравнивать по сложности...
Здравствуйте, minorlogic, Вы писали:
M>"Трансформирование сложности означает одну простую вещь – устраняя сложность в одном месте, мы всегда добавляем её где-то в другом."
M>Очевиднейший бред, дальше читать не стал. И как только такой треш пропускает рецензура...
Если точного определения сложности нет, то почему бы не допустить что это так? Тем более дальнейшие рассуждения вполне заслуживают интерес. Относись как к гипотезе.
Здравствуйте, Sinclair, Вы писали:
G>>Какая милая фантазия о содержимом монографий, которых не читал . S>Как раз по менеджменту я монографии читал.
Где вот такая херня написана, как ты привел? Ты их не просто читал, ты их, видимо, тщательно отбирал .
G>>На почитай, что Уотс Хамфри о метриках пишет. Тот самый, который CMMI. Что характерно — более-менее адекватное представление об этом имеет каждый _студент_ Carnegie-Mellon SEI — у них в программу обучения включено. G>>http://www.amazon.com/Introduction-Personal-Software-Process-sm/dp/0201548097 S>Я рад за Хамфри. Тем не менее, всякими software process теория менеджмента не исчерпывается.
Правда? Ну расскажи же мне, что же там еще такого есть, в теории менеджмента, чтоб про софтверные метрики (характеризующие software process по своей природе), но при этом ни в коем случае не про этот самый software process.
Здравствуйте, batu, Вы писали:
B>Самое большое влияние на алгоритм и его сложность оказывает выбор концепции.
Концепции чего?
B> При не правильно выбраной концепции сложность может оказаться и бесконечной. Классическая ситуация разбор текста вручную (я называю такое написание программ "в длинну") If-ами или парсером. Пусть даже самодельным.
И? Что в этой ситуации страшного и почему она классическая?
B> И качество и сложность программы даже трудно сравнивать.
Сравнивать с чем?
B> В длину вроде проще писать,
Проще чем что?
B> но результат очень "тупой"
Что значит "тупой"?
B> и не гибкий.
По сравнению с чем?
B> С другой стороны написать парсер.. Не то, что бы проще..Но в опытных руках окажется быстрее.
Парсер напичать быстрее чем парсер? Что то у тебя с логикой.
B> Ну, вообщем понятно.
Нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, Gaperton, Вы писали:
G>Где вот такая херня написана, как ты привел? Ты их не просто читал, ты их, видимо, тщательно отбирал .
Да через раз. Отбирал их не я — отбирали авторы учебного курса на MBA.
G>Правда? Ну расскажи же мне, что же там еще такого есть, в теории менеджмента, чтоб про софтверные метрики (характеризующие software process по своей природе), но при этом ни в коем случае не про этот самый software process.
Открою тайну: метрики бывают вовсе не софтверные. Теоретики менеджмента применяют что-нибудь типа контрольного списка Армстронга или шкалы справедливости Мурмана. В общем курсе менеджмента про софтверные процессы нет вообще ничего. Управление проектами занимает маахонький уголок.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, batu, Вы писали:
B>>Самое большое влияние на алгоритм и его сложность оказывает выбор концепции.
AVK>Концепции чего?
Концепции решения задачи. Как правило есть выбор метода. И структура данных может здорово повлиять на алгоритм.
B>> При не правильно выбраной концепции сложность может оказаться и бесконечной. Классическая ситуация разбор текста вручную (я называю такое написание программ "в длинну") If-ами или парсером. Пусть даже самодельным.
AVK>И? Что в этой ситуации страшного и почему она классическая?
Например, разбор выражений со скобками. Попробуйте сделать в лоб и с помощью польской записи.
Одна задача, две концепции, один уровень програмиста. Самое то, что нужно для сравнения сложности.
B>> В длину вроде проще писать,
AVK>Проще чем что?
Проще чем подумать, вычленить общности и в новых категориях написать.
B>> но результат очень "тупой"
AVK>Что значит "тупой"?
B>> и не гибкий.
AVK>По сравнению с чем?
B>> С другой стороны написать парсер.. Не то, что бы проще..Но в опытных руках окажется быстрее.
AVK>Парсер написать быстрее чем парсер? Что то у тебя с логикой.
Для приведеной задачи разбора выражений проще самому написать парсер, чем разбирать с помощью if-ов. Хотя я не уверен что проще. Смотря в каком смысле и кому. Собственно в этом и вопрос состоял.
B>> Ну, вообщем понятно.
AVK>Нет.
А сейчас?
Здравствуйте, batu, Вы писали:
AVK>>Концепции чего? B>Концепции решения задачи.
Непонятно.
B> Как правило есть выбор метода. И структура данных может здорово повлиять на алгоритм.
Ну может конечно. Вывод то какой?
AVK>>И? Что в этой ситуации страшного и почему она классическая? B>Например, разбор выражений со скобками. Попробуйте сделать в лоб и с помощью польской записи.
Что "значит" в лоб? Без польской записи пробовал много раз, ужаса не заметил. Более того, с появлением ассоциативности и приоритета операторов польская запись как раз таки обрастает гемороем.
B>Одна задача, две концепции, один уровень програмиста. Самое то, что нужно для сравнения сложности.
Ну так сравни.
B>>> В длину вроде проще писать,
AVK>>Проще чем что?
B>Проще чем подумать, вычленить общности и в новых категориях написать.
В каких таких новых категориях? О каком таком вундеваффе в написании парсера вообще речь?
AVK>>Парсер написать быстрее чем парсер? Что то у тебя с логикой. B>Для приведеной задачи разбора выражений проще самому написать парсер, чем разбирать с помощью if-ов.
Опять непонятно. Большинство практически используемых алгоритмов парсинга это и есть "разбирать с помощью if-ов".
B> Хотя я не уверен что проще.
Прелестно.
AVK>>Нет. B>А сейчас?
Стало еще более непонятным.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, batu, Вы писали:
AVK>>>Концепции чего? B>>Концепции решения задачи.
AVK>Непонятно.
Так ниже предложил два варианта. Неужели не понятно что алгоритм будет другой.
B>> Как правило есть выбор метода. И структура данных может здорово повлиять на алгоритм.
AVK>Ну может конечно. Вывод то какой?
Никакого. Ну, кроме того, что алгоритмы будут разными, что должно как-то отразиться на сложности.
AVK>>>И? Что в этой ситуации страшного и почему она классическая? B>>Например, разбор выражений со скобками. Попробуйте сделать в лоб и с помощью польской записи.
AVK>Что "значит" в лоб? Без польской записи пробовал много раз, ужаса не заметил. Более того, с появлением ассоциативности и приоритета операторов польская запись как раз таки обрастает гемороем.
Ассоциативность то как влияет на разбор написанного? А приоритет просто проверяешь и меняешь местами операции. Какой гемор?
B>>Проще чем подумать, вычленить общности и в новых категориях написать.
AVK>В каких таких новых категориях? О каком таком вундеваффе в написании парсера вообще речь?
слово "вундеваффе" не знакомое. Извини.
AVK>>>Парсер написать быстрее чем парсер? Что то у тебя с логикой. B>>Для приведеной задачи разбора выражений проще самому написать парсер, чем разбирать с помощью if-ов.
AVK>Опять непонятно. Большинство практически используемых алгоритмов парсинга это и есть "разбирать с помощью if-ов".
B>> Хотя я не уверен что проще.
AVK>Прелестно.
AVK>>>Нет. B>>А сейчас?
AVK>Стало еще более непонятным.
Ну, и хрен с ним
Если у тебя в руках молоток, все вокруг кажется гвоздями.
Ты упорно говоришь про что то свое, не про то что в статье. Она вообще не о сроках и трудоемкости.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, batu, Вы писали:
AVK>>Непонятно. B>Так ниже предложил два варианта.
Только один, плохой. Причем непонятно какой. Про хороший опять ни слова.
B> Неужели не понятно что алгоритм будет другой.
Какой?
AVK>>Ну может конечно. Вывод то какой? B>Никакого.
Ясно, пустопорожний треп. Я так и подумал.
AVK>>Что "значит" в лоб? Без польской записи пробовал много раз, ужаса не заметил. Более того, с появлением ассоциативности и приоритета операторов польская запись как раз таки обрастает гемороем. B>Ассоциативность то как влияет на разбор написанного?
Напрямую.
B> А приоритет просто проверяешь и меняешь местами операции.
Вообще то в парсерах, которые не рассчитаны на динамическое управление ассоциативностью и приоритетом (а таких большинство), никто местами операторы не меняет, дерево выражения сразу строится с учетом ассоциативности и приоритета.
B> Какой гемор?
Обходные маневры вроде твоей перестановки операторов местами. В хорошем парсере первичное дерево часто вообще иммутабельное.
AVK>>В каких таких новых категориях? О каком таком вундеваффе в написании парсера вообще речь? B>слово "вундеваффе" не знакомое. Извини.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, batu, Вы писали:
AVK>>>Непонятно. B>>Так ниже предложил два варианта.
AVK>Только один, плохой. Причем непонятно какой. Про хороший опять ни слова.
B>> Неужели не понятно что алгоритм будет другой.
AVK>Какой?
Другой. Там таки два подхода было предложено.
AVK>>>Ну может конечно. Вывод то какой? B>>Никакого.
AVK>Ясно, пустопорожний треп. Я так и подумал.
Ага. Тема для обсуждения. Я не знал что тут без выводов нельзя высказываться.
AVK>>>Что "значит" в лоб? Без польской записи пробовал много раз, ужаса не заметил. Более того, с появлением ассоциативности и приоритета операторов польская запись как раз таки обрастает гемороем. B>>Ассоциативность то как влияет на разбор написанного?
AVK>Напрямую.
B>> А приоритет просто проверяешь и меняешь местами операции.
AVK> Вообще то в парсерах, которые не рассчитаны на динамическое управление ассоциативностью и приоритетом (а таких большинство), никто местами операторы не меняет, дерево выражения сразу строится с учетом ассоциативности и приоритета.
B>> Какой гемор?
AVK>Обходные маневры вроде твоей перестановки операторов местами. В хорошем парсере первичное дерево часто вообще иммутабельное.
Какое дерево? Оно только в теории рисуется. Цепочка текста сразу превращается в польскую форму, и никаких деревьев. Так в польской записи и подается на вычисление. Причем тут ассоциативность? Как выражение написано так и выполняется. Оптимизация? Так какие проблемы? И каким боком тут иммутабельность несуществующего дерева?
AVK>>>В каких таких новых категориях? О каком таком вундеваффе в написании парсера вообще речь? B>>слово "вундеваффе" не знакомое. Извини.
AVK>http://lurkmore.ru/%D0%92%D1%83%D0%BD%D0%B4%D0%B5%D1%80%D0%B2%D0%B0%D1%84%D0%BB%D1%8F
Здравствуйте, batu, Вы писали:
AVK>>Какой? B>Другой.
B> Там таки два подхода было предложено.
Не заметил.
AVK>>Обходные маневры вроде твоей перестановки операторов местами. В хорошем парсере первичное дерево часто вообще иммутабельное. B>Какое дерево?
AST
B> Оно только в теории рисуется.
Силен, ничего не скажешь. Обратная польская запись, а точнее стековая машина, используется для итерпретации/кодогенерации и некоторх видов анализа. А боевые парсеры на выходе выдают AST, в котором никакой польской записи нет.
B> Цепочка текста сразу превращается в польскую форму, и никаких деревьев.
И этот человек еще пытается свой язык реализовать. Бегом читать книжки хотя бы.
B> Так в польской записи и подается на вычисление. Причем тут ассоциативность?
Ассоциативность определяет, каким образом строится дерево выражений. Левоассоциативные операторы на одноприоритетной цепочке формируют дерево вложенных выражений слева, правоассоциативные справа.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, batu, Вы писали:
AVK>>>Какой? B>>Другой.
AVK>
B>> Там таки два подхода было предложено.
AVK>Не заметил.
Бывает.
AVK>>>Обходные маневры вроде твоей перестановки операторов местами. В хорошем парсере первичное дерево часто вообще иммутабельное. B>>Какое дерево?
AVK>AST
B>> Оно только в теории рисуется.
AVK>Силен, ничего не скажешь. Обратная польская запись, а точнее стековая машина, используется для итерпретации/кодогенерации и некоторх видов анализа. А боевые парсеры на выходе выдают AST, в котором никакой польской записи нет.
B>> Цепочка текста сразу превращается в польскую форму, и никаких деревьев.
Я только про выражения.
AVK>И этот человек еще пытается свой язык реализовать. Бегом читать книжки хотя бы.
У меня дерево строится но, малость по другому. В узлах создается объект класса Production с именем понятия определенного грамматикой. Потому на выражения выхожу при разборе сразу, и дальше уже так как написал. А остальное так деревом и идет на выполнение еще одного этапа компиляции на создание объектов- результата трансляции. В частности объектов-инструкций. Процесс создания объектов — результата трансляции задается операторами при описании грамматики. Таким образом, значение свойств создаваемого объекта идет под управлением грамматики, а класс, имя и реализация создается на основе общего синтаксиса. Так и получается конвертируем из объектов в объекты. Лексический разбор идет перед синтаксичекским отдельно. Там разбор линейный и деревья ни к чему потому как LL(R) грамматика.
B>> Так в польской записи и подается на вычисление. Причем тут ассоциативность?
AVK>Ассоциативность определяет, каким образом строится дерево выражений. Левоассоциативные операторы на одноприоритетной цепочке формируют дерево вложенных выражений слева, правоассоциативные справа.
Как уже написал, приоритеты понятно, а ассоциациативность..не въехал в необходимость. Растолкуй.
Здравствуйте, batu, Вы писали:
B>>> Цепочка текста сразу превращается в польскую форму, и никаких деревьев. B>Я только про выражения.
Выражения тоже отображаются в AST. Не строится дерево только в игрушечных интерпретаторах.
AVK>>Ассоциативность определяет, каким образом строится дерево выражений. Левоассоциативные операторы на одноприоритетной цепочке формируют дерево вложенных выражений слева, правоассоциативные справа. B>Как уже написал, приоритеты понятно, а ассоциациативность..не въехал в необходимость. Растолкуй.
Здравствуйте, Gaperton, Вы писали:
G>Простейший пример — так называемый EV-Plan.
G>Составил план работ. Нарисовал кривую — общее количество (нарастающим итогом) закрытых задач понедельно, на основании плана. И каждую неделю наносишь на этот же график новую точку фактической кривой — с общим количеством фактически закрытых задач.
... G>Я тебе простейший вариант планирования с учетом метрик дал. Есть другие.
Планирования чего? Архитекутры приложения, или уровня загруженности конвеера(массива разработчиков), с целью уменьшения простоев и слабых мест.
А если надо определиться в том что использовать WPF или WinForms. Или боле того, надо писать подобную библиотеку. Какую архитектуру выбрать как у WinForms или как WPF. Планирование уровня загруженности разработчиков уже будет недостаточно?
Здравствуйте, minorlogic, Вы писали:
>"Трансформирование сложности означает одну простую вещь – устраняя сложность в одном месте, мы всегда добавляем её где-то в другом."
M>Очевиднейший бред, дальше читать не стал. И как только такой треш пропускает рецензура...
Что именно бред? Ты не сталкивался с "перетягиванием одеяла" в софтостроении? Когда улучшить какой то показатель можно только ухудшив что-то другое.
Так вот, даже в математике есть закон сохранения сложности (ну пусть будет "закон сохранения одеяла"). Хотя не в той математике где теоремы доказывают, а где конкретные прикладные проблемы решают. И перетягивание одеяла там совсем по другому поводу.
Сам факт что существуют методы: аналитические,асимптотические,численные,экспериментальные. Говорит что каждый плох и хорош по своему. Выбрав один что-то выиграешь и что-то проиграешь.
И даже в асимптотических методах присутствует перетягивание одеяла:
(Р.Баранцев)
Асимптотология — искусство обращения с прикладными математическими системами в предельных случаях; наука о синтезе простоты и точности за счёт локализации.
В качестве первого приближения проще всего назвать асимптотическими методами те, что приспособлены для исследования асимптотических явлений. Однако их содержание таким путем еще не раскрывается. Цель асимптотического подхода заключается в упрощении предмета исследования. Это упрощение достигается за счет уменьшения окрестности рассматриваемой особенности. Причем характерно, что вместе с такой локализацией возрастает и точность асимптотических представлений.
Точность и простота обычно встречаются как понятия противоположные, дополнительные. Стремясь к простоте, мы жертвуем точностью; добиваясь точности, не ждем простоты. Однако при локализации эти антиподы сходятся, противоречие разрешается, снимается в синтезе, имя которому — асимптотика [Баранцев].
Итак, суть асимптотических методов состоит в том, что они осуществляют синтез простоты и точности за счет локализации: в окрестности некоторого предельного состояния находится упрощенное решение задачи, которое тем точнее, чем меньше эта окрестность. Как отмечал еще Лаплас, асимптотические методы тем точнее, чем нужнее. Действительно, потребность в них появляется там, где глобальные методы не срабатывают, но именно там, в окрестности особенностей, они и наиболее эффективны.
Согласованное взаимодействие этих трех компонент образует очевидную целостность. Следовательно, триаду точность—локальность—простота можно рассматривать как определение асимптотической методологии .
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, minorlogic, Вы писали:
M>>"Трансформирование сложности означает одну простую вещь – устраняя сложность в одном месте, мы всегда добавляем её где-то в другом." M>>Очевиднейший бред, дальше читать не стал. И как только такой треш пропускает рецензура...
IT>Надеюсь ты в обморок от переизбытка чувств не упал как князь Мышкин? Ну вот и славно.
Я польщен что ты заюотишься о моей личности спасибо.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, minorlogic, Вы писали:
M>>"Трансформирование сложности означает одну простую вещь – устраняя сложность в одном месте, мы всегда добавляем её где-то в другом."
M>>Очевиднейший бред, дальше читать не стал. И как только такой треш пропускает рецензура...
G>Один ошибочный вывод не делает бредом всю статью. В конце концов, непрерывно нести бред очень тяжело. Почти так же тяжело, как и все время говорить истину, и только истину . Если предмет статьи содержателен, конечно.
Конечно нет , но уровень статьи сразу понижает. Может все же Мак Коннелла почитать? без шуток ? Ну уже классика, пока не стареющая.
Здравствуйте, batu, Вы писали:
B>Здравствуйте, minorlogic, Вы писали:
M>>"Трансформирование сложности означает одну простую вещь – устраняя сложность в одном месте, мы всегда добавляем её где-то в другом."
M>>Очевиднейший бред, дальше читать не стал. И как только такой треш пропускает рецензура... B>Если точного определения сложности нет, то почему бы не допустить что это так? Тем более дальнейшие рассуждения вполне заслуживают интерес. Относись как к гипотезе.
Если точного нет , тогда и не стоит спекулировать ? Практично , прагматично , без пафоса.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, batu, Вы писали:
B>>>> Цепочка текста сразу превращается в польскую форму, и никаких деревьев. B>>Я только про выражения.
AVK>Выражения тоже отображаются в AST. Не строится дерево только в игрушечных интерпретаторах.
AVK>>>Ассоциативность определяет, каким образом строится дерево выражений. Левоассоциативные операторы на одноприоритетной цепочке формируют дерево вложенных выражений слева, правоассоциативные справа. B>>Как уже написал, приоритеты понятно, а ассоциациативность..не въехал в необходимость. Растолкуй.
AVK>http://ru.wikipedia.org/wiki/%D0%90%D1%81%D1%81%D0%BE%D1%86%D0%B8%D0%B0%D1%82%D0%B8%D0%B2%D0%BD%D0%BE%D1%81%D1%82%D1%8C
Скажу прямо. Редко встретишь специалиста в этой области. Но и в других тоже. Каждый по своему силен, и уважаем. Но почему надо молится на Ахо, или Алана.. У вас же есть такие же мозги. Почему вы не видите что они предлагают только часть своего пути. Дорога впереди открыта, при всем уважении. Ну, я сделал по другому. Где-то проще. Где-то сложней. Но это продолжение пути. Потому что до сих пор не понимаю чем поможет ассоциативность. Для оптимизации? Соглашусь. Хотя не понял. Но моя фишка не в том. А в том, что грамматику можно и нужно определить (и постороить компилятор) для любых объектов, а не только для букв (которые сейчас и не объекты.. а что-то левое, заданное где-то и кем-то сверху). Мне кажется, что современные требования объектного программирования ставят задачи шире. Да. У меня не все красиво. Но работает. Я бы хотел здесь посоветоваться, а не получать ссылки на столпов. Конечно, читал. Да, у меня по другому. Вот это и давайте обсуждать. Или критиковать. Фух.. Извините. Тема совсем не та.. Прорвало..
Здравствуйте, minorlogic, Вы писали:
M>Почитайте Мак коннелла что ли ? там все просто легко , в описательной форме без пафоса.
Надо наверное дочитать. Но тяжело он читается, я начинал и забросил не доходя до 100 cтр.
Слишком много воды. Вроде текст есть, а вроде как и нету ничего. Создается впечатление что у автора по делу страниц 20 а растянул их на 800. Что-то интересное наверняка должно быть, знать бы только где искать.
Чтобы найти что-то интересное надо в тысячный раз снова узнать что "Объекты могут поддерживать самые разные операции".
Определите объекты реального мира
Первый, и самый популярный, подход к проектированию — «общепринятый* объектно-ориентированный подход — основан на определении объектов реального мира и искусственных объектов.
При проектировании с использованием объектов определите:
— объекты и их атрибуты (методы и данные);
— действия, которые могут быть выполнены над каждым объектом;
— действия, которые каждый объект может выполнять над другими объектами;
— части каждого объекта, видимые другим объектам, т. е. открытые и закрытые
части;
— открытый интерфейс каждого объекта.
Эти часто повторяющиеся действия не обязательно выполнять в указанном по-
рядке. Помните о важности итерации.
Определите объекты и их атрибуты В основе создания программ обычно
лежат сущности реального мира. Например, система расчета повременной опла-
ты может быть основана на таких сущностях, как сотрудники, клиенты, карты учета
времени и счета (рис. 5-6).
Определить атрибуты объектов не сложнее, чем сами объекты. Каждый объект имеет
характеристики, релевантные для компьютерной программы. Скажем, в системе
расчета повременной оплаты объект «сотрудник» обладал бы такими атрибутами,
как имя/фамилия, должность и уровень оплаты. С объектом «счет» были бы свя-
заны такие атрибуты, как сумма, имя/фамилия клиента, дата и т. д.
Объектами системы GUI были бы разнообразные окна, кнопки, шрифты и инст-
рументы рисования. При дальнейшем изучении проблемной области вы можете
прийти к выводу, что установление однозначного соответствия между объектами
программы и объектами реального мира — не самый лучший способ определе-
ния объектов, но для начала он тоже неплох.
Определите действия, которые могут быть выполнены над каждым
объектом. Объекты могут поддерживать самые разные операции. В нашей сис-
теме расчета оплаты объект «сотрудник» мог бы поддерживать изменение долж-
ности или уровня оплаты, объект «клиент» — изменение реквизитов счета и т. д.
Определите действия, которые каждый объект может выполнять над
другими объектами Суть этого этапа ясна из его названия. Двумя универсаль-
ными действиями, которые объекты могут выполнять друг над другом, являются
включение (containment) и наследование. Какие объекты могут включать другие
(какие?) объекты? Какие объекты могут быть унаследованными от других (каких?)
объектов? На рис. 5-6 объект «карта учета времени» может включать объект «со-
трудник» и объект «клиент», а объект «счет» может включать карты учета време-
ни. Кроме того, счет может сообщать, что клиент оплатил услуги, а клиент —
оплачивать указанную в счете сумму. Более сложная система включала бы допол-
нительные взаимодействия.
Здравствуйте, batu, Вы писали:
B>Скажу прямо. Редко встретишь специалиста в этой области. Но и в других тоже. Каждый по своему силен, и уважаем. Но почему надо молится на Ахо, или Алана..
Молиться не надо. Но и велосипеды кривоколесные изобретать тоже не стоит.
B>Потому что до сих пор не понимаю чем поможет ассоциативность.
Что значит поможет? Язык, в котором нет ассоциативности операторов, не нужен никому. А вот если ассоцитативность есть, то сформировать без дерева, сразу из лексем стековую нотацию будет весьма непросто, да и не нужно никому.
B>А в том, что грамматику можно и нужно определить (и постороить компилятор) для любых объектов, а не только для букв
Каких букв? Ну почитай хоть что нибудь про теорию формальных грамматик, что ты с таким упорством какую то пургу сюда пишешь?
B> (которые сейчас и не объекты.. а что-то левое, заданное где-то и кем-то сверху). Мне кажется, что современные требования объектного программирования ставят задачи шире. Да. У меня не все красиво. Но работает. Я бы хотел здесь посоветоваться, а не получать ссылки на столпов. Конечно, читал.
Не заметно. Ну или читал, не понимая что написано.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, Gaperton, Вы писали:
G>Из этого следует три возможных вывода — либо ты ничего в IBM не писал, либо — тщательно проектировал и тестировал свой код, либо твоим кодом никто не пользовался и багов не репортил. Проверяется, что именно из тех — элементарно.
На самом деле я действительно писал не много, потому что серьёзно занимался проектированием и выбором инструментов для своей части. А немногие баги, без которых, конечно же, не обойтись, выявлялись и фиксились не доходя до треккера.
G>Не понял — и зачем мне на что-то умножать свою трудоемкость?
Ну подели. Тоже интересный результат получится
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, Gaperton, Вы писали:
G>>Простейший пример — так называемый EV-Plan.
G>>Составил план работ. Нарисовал кривую — общее количество (нарастающим итогом) закрытых задач понедельно, на основании плана. И каждую неделю наносишь на этот же график новую точку фактической кривой — с общим количеством фактически закрытых задач. S_>... G>>Я тебе простейший вариант планирования с учетом метрик дал. Есть другие.
S_>Планирования чего? Архитекутры приложения, или уровня загруженности конвеера(массива разработчиков), с целью уменьшения простоев и слабых мест. S_>А если надо определиться в том что использовать WPF или WinForms. Или боле того, надо писать подобную библиотеку. Какую архитектуру выбрать как у WinForms или как WPF. Планирование уровня загруженности разработчиков уже будет недостаточно?
Ты откуда планирование загруженности взял?
Давай так. Лично ты на основании чего будешь делать выбор WinForms или WPF?
Здравствуйте, batu, Вы писали:
B>А в том, что грамматику можно и нужно определить (и постороить компилятор) для любых объектов, а не только для букв (которые сейчас и не объекты.. а что-то левое, заданное где-то и кем-то сверху).
Я прочитал много твоих постов. Могу дать одну рекомендацию: когда хочешь написать слово объект, не пиши его, а попробуй заменить на более подходящее слово в этом контексте.
Если что любая грамматика определяется над некоторым алфавитом терминальных и нетерминальных символов. Что есть символы теория не говорит. В принципе это неважно, главное чтобы был способ отличить один от другого.
Здравствуйте, Gaperton, Вы писали:
IT>>А принимая решение повернуть налево или направо ты каким прибором пользуешься, спидометром или тахометром? G>Выбирая маршрут — наручными часами, показывающими текущее время, и данными по средней скорости потока на карте, которые выдает навигатор в виде цветных линий.
Не верю... Хотя почему не верю. Вполне очень даже может быть. Хотя я так не делаю.
Ручными (да вообще никакими) часами для выбора маршрута я не пользуюсь. В точном времени, например, если поеду направо, то приеду в 17:00, а если налево, то в 17:10, для меня ценной информации только то, что если поеду направо, то приеду быстрее. И даже не важно на сколько. С другой стороны даже в этом случае я могу поехать налево, просто потому, что самый быстрый путь не самый удобный, комфортный и дешовый. Направо можно доехать быстрее, но по светофорам, а налево медленнее, но по шоссе. Ещё и бензин можно сэкономить. К тому же налево я буду проезжать через чудесные места и наслаждаться прекрасным видом. А ещё по пути можно заскочить в цветочный магазин и купить жене цветы и 10 минут как-бы потерянного времени, сэкономят мне пол часа взаимных упрёков, которые удасться избежать при наличии букета. Надеюсь, понимаешь к чему вся эта лирика.
Метрики, особенно времени — это хорошо. Особенно, если время самый дефицитный ресурс. Но на самом деле этот ресурс всегда можно выгодно продать или обменять на что-то более полезное.
IT>>Судя по всему мы с тобой говорим о разных вещах. Ну правда, мне не интересна тема управления проектами в рамках данной статьи. G>Я обсуждаю именно сложность, а не "управление проектами". И говорить о сложности вне связи со временем и объемом, т.е. наблюдаемыми характеристиками работы и ее результата — не интересно уже мне. Ибо сие есть метафизика.
Это не матафизика, это объективная реальность. Кроме сроков и человеко часов есть ещё много разных бенефитов. Некоторые из них можно даже свести ко времени, но только это будет другое время. Ну, например, как оторванная неделя от текущего проекта и потраченная на разработку универсального компонента сегодня может помочь сэкономить тебе месяцы работы в будущем. Как можно сравнивать эти времена?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas, Вы писали:
IT>>Постфактум мало интересен. Мне нужно принимать решение здесь и сейчас, а не после разбора полётов. G>Анализ предыдущего опыта (не только своего) помогает принимать решения.
Опыт вообще-то как раз из области метафизика, как говорит уважаемый Гапертон. Да и помогает он только не делать ошибок, которые уже были сделаны ранее, т.е. осечь заведомо плохие варианты. Найти наиболее оптимальное решение в совершенно новой ситуации он не помогает.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Gaperton, Вы писали:
G>Так вот, для внесения правки в хороший дизайн тебе надо понимать небольшой фрагмент системы, и ты не сильно рискуешь. Происходит это благодаря связности. Основные свойства системы, характеризующие дизайн (т.е. входные данные для его оценки), можно выразить через объективные количественные метрики, и именно этот факт позволяет тебе оценивать их интуитивно, используя хитрую весовую функцию в голове, которая строится годами на основе твоего опыта.
G>А вот "весовую функцию" которая выполняет оценку в твоей голове, формализовать на все случаи жизни не просто невозможно, но просто бессмысленно и не нужно. Это есть тот самый уникальный "творческий" компонент. И это основной момент в работе с метриками, который ты почему-то отказываешься понимать. Пойми.
Видишь ли в чём дело. Время для меня хотя и ценный ресурс, но вовсе не дефицитный. Конечно, у нас бывают авралы и бывают проекты, которые внедряются и интенсивно начинают использоваться будучи в готовности лишь на 70% (прямо как здесь), но в целом времени у меня предостаточно. Соответственно это время я могу конвертировать во что-то другое, не менее ценное, а иногда и гораздо более. Например, в качество кода, в поиск более универсальных решений, в гибкость, в быстродействие, в надёжность, в более грамотный дизайн и т.п. Где-то здесь по ветке ты спросил буду ли я переписывать код, если он не очень, но работает как надо и его не планируется никогда менять. Ответ — возможно, если мне приходится в него часто заглядывать, а его сложность восприятия для меня становится геморроем. В данном случае я обменяю своё время на отсутвие не нужного мне геморроя.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Gaperton, Вы писали:
G>Вот у тебя кусок кода. У него "высокая сложность", что означает крайне дорогие правки в этот код, даже если правки сами по себе незначительные. Но! Код отлажен, изолирован за годными интерфейсами, отлично работает, и никаких правок туда в ближайшие 5 лет не ожидается. G>Тебя волнует его сложность? Ты будешь тратить время на то, чтобы его "рефакторить", понижая "сложность"?
О, блин! Только что ответил выше Повторюсь здесь. Да, буду править, если сложность восприятия этого кода будет для меня проблемой. Сразу оговорюсь, буду править не потому, что заглядывая в него я буду тратить лишнее время (ты же всё равно к этому всё сведёшь, правильно ), а потому что я очень расстраиваюсь, когда вижу плохой код и моё хорошее настроение мне дороже любого времени.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Gaperton, Вы писали:
G>Разница в том, что ты отказываешься привязывать свою теорию сложности к объективно измеримым вещам.
Мне интересно прежде всего рассмотреть какова структура сложности, какие виды сложности бывают и как сложность перетекает из одного вида в другой. Где в результате принятия того или иного решения у нас причина, а где следствие. Почему на разных этапах разработки приложения одно и тоже решение перестаёт или начинает работать. Интересно потому, что без этого сложностью не получится управлять и не помогут никакие метрики. Метрики уже потом, давайте сначала разберёмся с тем, что мы хотим измерять.
Ты же как коммерсанты сводят всё в мире к одной мере — деньгам, сводишь всё к срокам и трудоёмкости. С практической точки зрения это совсем не плохо. Но в мире не всё сводится к деньгам, а в программировании не всё сводится к срокам и трудоёмкости.
Кстати, в программировании практически всё сводится к сложности, но не всё к трудоёмкости. Это я к тому, что это не совсем одно и тоже.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Gaperton, Вы писали:
G>Вопрос некорректен. В любом _проекте_ сроки имеют значение, ибо проект всегда ограничен временем по определению. Не ограничены временем _программа_ и разгильзяйство. Но программа состоит из проектов. А из чего состоит разгильзяйство — мне не интересно.
Здравствуйте, Gaperton, Вы писали:
IT>>Здорово. Только я всё не возьму в толк, как мне это поможет выбрать правильный дизайн базы данных? Вот, например, у меня есть форма с гридом, в котором 24 колонки для 24-х месяцев, по 12 на 2 года. Как мне лучше их уложить в базу, как 24 месяца в одну запись или как две записи по 12 месяцев? Какую метрику посоветуешь?
G>Посоветую не морочить людям голову, и перестать выдумывать и писать ерунду. G>Надоело.
Т.е. для этого случая метрики не нашлось. На самом деле, и здесь всё можно свести ко времени, только проблема в том, что это время хрен засечёшь секундомером. Неверный дизайн всегда однозначно приводит к замедлению проекта, только вряд ли это "больше/меньше" можно померять с точностью хотя бы плюс/минус трамвайная остановка.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, batu, Вы писали:
M>>Очевиднейший бред, дальше читать не стал. И как только такой треш пропускает рецензура... B>Если точного определения сложности нет, то почему бы не допустить что это так? Тем более дальнейшие рассуждения вполне заслуживают интерес. Относись как к гипотезе.
Можно даже как к эзотерическому учению Главное, что есть модель, которая работает. Может быть не для всех, может быть не всегда, но в большинстве случаев вполне сносно объясняет суть происходящего. Когда учоные создадут более адекватную модель и опишут сложность универсальными формулами и метриками, то на эту теорию можно будет смело забить. Я сделаю это первый, если доживу
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, batu, Вы писали:
B>>Здравствуйте, minorlogic, Вы писали:
M>>>"Трансформирование сложности означает одну простую вещь – устраняя сложность в одном месте, мы всегда добавляем её где-то в другом."
M>>>Очевиднейший бред, дальше читать не стал. И как только такой треш пропускает рецензура... B>>Если точного определения сложности нет, то почему бы не допустить что это так? Тем более дальнейшие рассуждения вполне заслуживают интерес. Относись как к гипотезе.
M>Если точного нет , тогда и не стоит спекулировать ? Практично , прагматично , без пафоса.
Если практично и прагматично, то да. А так нет
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, batu, Вы писали:
B>>А в том, что грамматику можно и нужно определить (и постороить компилятор) для любых объектов, а не только для букв (которые сейчас и не объекты.. а что-то левое, заданное где-то и кем-то сверху). G>Я прочитал много твоих постов. Могу дать одну рекомендацию: когда хочешь написать слово объект, не пиши его, а попробуй заменить на более подходящее слово в этом контексте.
Были обсуждения по этому поводу. Предлагались фреймы, монады. Не то. Все-таки к объекту это ближе. А сочинять что-то новое тоже не вариант.
G>Если что любая грамматика определяется над некоторым алфавитом терминальных и нетерминальных символов. Что есть символы теория не говорит. В принципе это неважно, главное чтобы был способ отличить один от другого.
Да. Это так. Может я не могу сформулировать. Но ход мысли такой. Я хочу оперировать более высоким уровнем.Что б в анализе участвовали объекты. Что бы пользователю было легче ориентироваться и создавать свои грамматики. Это никак не противоречит теории, если назначить каждому свойству или значению свойства объекта отдельный символ в классической формулировке. Понятия терминальные и нетерминальные символы убрать. Оставить правила (предикаты), имена которых непосредственно определяют лексему и продукцию. Эти имена тогда будут формулироваться в терминах создаваемого языка, что опять таки будет семантически ближе пользователю. Напрямую в общем случае это не получается. Иногда возникает необходимость в промежуточных (вспомогательных) правилах не создающих ни лексему ни продукцию. Ну, и у меня получилось так сделать. Т.е. построение грамматики стало возможно в общей концепции языка. Не надо никаких регекспов и вводить новые понятия. Вот туда я и веду. И с теорией противоречия нет. Фактически те же алгоритмы восходящий для лексики и нисходящий для синтаксиса. Просто другое представление. Я бы сравнил с машиной Тьюринга. Вещь хорошая для доказательств, но для реального создания программ мало подходящая. Так и теорию грамматик. Вещь хорошая, но для широкого использования надо бы формулировать в терминах ООП. Что я и пытаюсь сделать.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, batu, Вы писали:
M>>>Очевиднейший бред, дальше читать не стал. И как только такой треш пропускает рецензура... B>>Если точного определения сложности нет, то почему бы не допустить что это так? Тем более дальнейшие рассуждения вполне заслуживают интерес. Относись как к гипотезе.
IT>Можно даже как к эзотерическому учению Главное, что есть модель, которая работает. Может быть не для всех, может быть не всегда, но в большинстве случаев вполне сносно объясняет суть происходящего. Когда учоные создадут более адекватную модель и опишут сложность универсальными формулами и метриками, то на эту теорию можно будет смело забить. Я сделаю это первый, если доживу
Такова судьба любой теории.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
IT>>>Постфактум мало интересен. Мне нужно принимать решение здесь и сейчас, а не после разбора полётов. G>>Анализ предыдущего опыта (не только своего) помогает принимать решения.
IT>Опыт вообще-то как раз из области метафизика, как говорит уважаемый Гапертон. Да и помогает он только не делать ошибок, которые уже были сделаны ранее, т.е. осечь заведомо плохие варианты. Найти наиболее оптимальное решение в совершенно новой ситуации он не помогает.
Ну так поробуй формализовать понятия "не делать ошибок" и "заведомо плохие варианты", получишь те самые метрики.
Любое планирование будет метафизикой если не использовать метрики.
Здравствуйте, batu, Вы писали:
B>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, batu, Вы писали:
B>>>А в том, что грамматику можно и нужно определить (и постороить компилятор) для любых объектов, а не только для букв (которые сейчас и не объекты.. а что-то левое, заданное где-то и кем-то сверху). G>>Я прочитал много твоих постов. Могу дать одну рекомендацию: когда хочешь написать слово объект, не пиши его, а попробуй заменить на более подходящее слово в этом контексте. B>Были обсуждения по этому поводу. Предлагались фреймы, монады. Не то. Все-таки к объекту это ближе. А сочинять что-то новое тоже не вариант.
Не надо сочинять, почти в любом разговоре ты используешь слово "объект" вместо какого-то устоявшегося понятия, при этом сбивая не только собеседника, но и себя.
G>>Если что любая грамматика определяется над некоторым алфавитом терминальных и нетерминальных символов. Что есть символы теория не говорит. В принципе это неважно, главное чтобы был способ отличить один от другого. B>Да. Это так. Может я не могу сформулировать. Но ход мысли такой. Я хочу оперировать более высоким уровнем.
Более высоким уровнем чего?
B>Что б в анализе участвовали объекты. Что бы пользователю было легче ориентироваться и создавать свои грамматики.
Взаимоисключающие фразы. Называя все объектами ты усложняешь понимание другим людям, которые как минимум понимают что такое формальные грамматики.
B>Понятия терминальные и нетерминальные символы убрать. Оставить правила (предикаты), имена которых непосредственно определяют лексему и продукцию.
Получишь peg.
B>Эти имена тогда будут формулироваться в терминах создаваемого языка, что опять таки будет семантически ближе пользователю. Напрямую в общем случае это не получается. Иногда возникает необходимость в промежуточных (вспомогательных) правилах не создающих ни лексему ни продукцию. Ну, и у меня получилось так сделать. Т.е. построение грамматики стало возможно в общей концепции языка. Не надо никаких регекспов и вводить новые понятия. Вот туда я и веду. И с теорией противоречия нет. Фактически те же алгоритмы восходящий для лексики и нисходящий для синтаксиса. Просто другое представление. Я бы сравнил с машиной Тьюринга. Вещь хорошая для доказательств, но для реального создания программ мало подходящая. Так и теорию грамматик. Вещь хорошая, но для широкого использования надо бы формулировать в терминах ООП. Что я и пытаюсь сделать.
Я вот понимаю слова по отдельности, а общего смысла не понимаю.
Здесь вообще-то другая тема обсуждается. Ты в своей теме про язык приведи работающий пример и докажи формально что он эквивалентен какой-либо грамматике с этими самыми терминальными и нетерминальными символами. Например разбор арифметического выражения с учетом ассоциативности и приоритетов.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, batu, Вы писали:
G>Не надо сочинять, почти в любом разговоре ты используешь слово "объект" вместо какого-то устоявшегося понятия, при этом сбивая не только собеседника, но и себя.
Почему "вместо"? Понимай как понимаешь. Какие проблемы? В С-ях же не путает. И в джаве не путает. Хотя там сообщений нет, как в смолтоке.
G>>>Если что любая грамматика определяется над некоторым алфавитом терминальных и нетерминальных символов. Что есть символы теория не говорит. В принципе это неважно, главное чтобы был способ отличить один от другого. B>>Да. Это так. Может я не могу сформулировать. Но ход мысли такой. Я хочу оперировать более высоким уровнем. G>Более высоким уровнем чего?
Сформулируй вопрос. Я не понял.
B>>Что б в анализе участвовали объекты. Что бы пользователю было легче ориентироваться и создавать свои грамматики. G>Взаимоисключающие фразы. Называя все объектами ты усложняешь понимание другим людям, которые как минимум понимают что такое формальные грамматики.
Нет ничего взаимоисключающего. Как и слово "дифференциал" не усложняет "отношение приращения функции к приращению аргумента". Чем удобней пользоваться?
B>>Понятия терминальные и нетерминальные символы убрать. Оставить правила (предикаты), имена которых непосредственно определяют лексему и продукцию. G>Получишь peg.
Почти.
B>>Эти имена тогда будут формулироваться в терминах создаваемого языка, что опять таки будет семантически ближе пользователю. Напрямую в общем случае это не получается. Иногда возникает необходимость в промежуточных (вспомогательных) правилах не создающих ни лексему ни продукцию. Ну, и у меня получилось так сделать. Т.е. построение грамматики стало возможно в общей концепции языка. Не надо никаких регекспов и вводить новые понятия. Вот туда я и веду. И с теорией противоречия нет. Фактически те же алгоритмы восходящий для лексики и нисходящий для синтаксиса. Просто другое представление. Я бы сравнил с машиной Тьюринга. Вещь хорошая для доказательств, но для реального создания программ мало подходящая. Так и теорию грамматик. Вещь хорошая, но для широкого использования надо бы формулировать в терминах ООП. Что я и пытаюсь сделать. G>Я вот понимаю слова по отдельности, а общего смысла не понимаю.
Вот тут я не знаю чем помочь. Могу повторить.
G>Здесь вообще-то другая тема обсуждается. Ты в своей теме про язык приведи работающий пример и докажи формально что он эквивалентен какой-либо грамматике с этими самыми терминальными и нетерминальными символами.
Формально я это уже показал там, где ты не понял. Свойства и значения заменить оригинальными символами, включить их в алфавит и получим классическую грамматику.
Например разбор арифметического выражения с учетом ассоциативности и приоритетов.
Разбор выражения есть, конечно. С учетом приоритета. А вот насчет ассоциативности мне она не понадобилась. Есть она или нет, моему алгоритму все равно. Покажи как используется ассоциативность при разборе выражений. Интересно.
Здравствуйте, batu, Вы писали:
B>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, batu, Вы писали:
G>>Не надо сочинять, почти в любом разговоре ты используешь слово "объект" вместо какого-то устоявшегося понятия, при этом сбивая не только собеседника, но и себя. B>Почему "вместо"? Понимай как понимаешь. Какие проблемы? В С-ях же не путает. И в джаве не путает. Хотя там сообщений нет, как в смолтоке.
Вызов метода — частный случай отправки сообщения.
G>>>>Если что любая грамматика определяется над некоторым алфавитом терминальных и нетерминальных символов. Что есть символы теория не говорит. В принципе это неважно, главное чтобы был способ отличить один от другого. B>>>Да. Это так. Может я не могу сформулировать. Но ход мысли такой. Я хочу оперировать более высоким уровнем. G>>Более высоким уровнем чего? B>Сформулируй вопрос. Я не понял.
Ты хочешь оперировать более высоким уровнем чего?
B>>>Что б в анализе участвовали объекты. Что бы пользователю было легче ориентироваться и создавать свои грамматики. G>>Взаимоисключающие фразы. Называя все объектами ты усложняешь понимание другим людям, которые как минимум понимают что такое формальные грамматики. B>Нет ничего взаимоисключающего. Как и слово "дифференциал" не усложняет "отношение приращения функции к приращению аргумента". Чем удобней пользоваться?
Еще раз: называя все объектами ты усложняешь понимание. Это хорошо видно в твоей теме с языком.
B> Например разбор арифметического выражения с учетом ассоциативности и приоритетов. B>Разбор выражения есть, конечно. С учетом приоритета. А вот насчет ассоциативности мне она не понадобилась. Есть она или нет, моему алгоритму все равно. Покажи как используется ассоциативность при разборе выражений. Интересно.
Ассоциативность — свойство операторов, а не разбора.
Как разбирать выражение
a / b / c
?
Два варианта:
(a/b) / c
a / (b/c)
Это называется левой и правой ассоциативностью операторов.
Еще могут быть неассоциативные операторы, для которых необходимо явно указывать порядок (скобками или еще как-то).
Все генераторы парсеров учитывают ассоциативность, что в этом случае делает твой?
B>>Разбор выражения есть, конечно. С учетом приоритета. А вот насчет ассоциативности мне она не понадобилась. Есть она или нет, моему алгоритму все равно. Покажи как используется ассоциативность при разборе выражений. Интересно. G>Ассоциативность — свойство операторов, а не разбора.
G>Как разбирать выражение G>
G>a / b / c
G>
G>?
G>Два варианта:
G>
G>(a/b) / c
G>a / (b/c)
G>
G>Это называется левой и правой ассоциативностью операторов.
G>Еще могут быть неассоциативные операторы, для которых необходимо явно указывать порядок (скобками или еще как-то). G>Все генераторы парсеров учитывают ассоциативность, что в этом случае делает твой?
А мой не учитывает. Как написано програмистом, так и разбирает. Даже не думал на эту тему. Но, вопрос даже не в том. Если определять операции пользовательские, то тогда кроме приоритета надо еще и ассоциативность где-то указывать... Практически где это нужно? Сделать то все можно..
Здравствуйте, batu, Вы писали:
B>Здравствуйте, gandjustas, Вы писали:
B>>>Разбор выражения есть, конечно. С учетом приоритета. А вот насчет ассоциативности мне она не понадобилась. Есть она или нет, моему алгоритму все равно. Покажи как используется ассоциативность при разборе выражений. Интересно. G>>Ассоциативность — свойство операторов, а не разбора.
G>>Как разбирать выражение G>>
G>>a / b / c
G>>
G>>?
G>>Два варианта:
G>>
G>>(a/b) / c
G>>a / (b/c)
G>>
G>>Это называется левой и правой ассоциативностью операторов.
G>>Еще могут быть неассоциативные операторы, для которых необходимо явно указывать порядок (скобками или еще как-то). G>>Все генераторы парсеров учитывают ассоциативность, что в этом случае делает твой? B>А мой не учитывает. Как написано програмистом, так и разбирает. Даже не думал на эту тему.
Ну так как он разберет выражение a / b / c? И почему именно так, а не по-другому?
B>Но, вопрос даже не в том. Если определять операции пользовательские, то тогда кроме приоритета надо еще и ассоциативность где-то указывать... Практически где это нужно? Сделать то все можно..
Для в любом языке с выражениями это нужно. Выражение a / b / c является верным для большинства ныне существующих языков, и каждый из них определяет ассоциативность и приоритет операций. А если ты не определяешь, значит где-то схалтурил.
Ты говоришь что что твое описание парсера эквивалентно некоторой формальной грамматике в виде peg или bnf.
Вот и напиши свою грамматику в таком виде, а все твои рассуждения об объектах и новых концепциях никому не нужны.
G>>>Еще могут быть неассоциативные операторы, для которых необходимо явно указывать порядок (скобками или еще как-то). G>>>Все генераторы парсеров учитывают ассоциативность, что в этом случае делает твой? B>>А мой не учитывает. Как написано програмистом, так и разбирает. Даже не думал на эту тему. G>Ну так как он разберет выражение a / b / c? И почему именно так, а не по-другому?
Да так и разберет. Подряд. Как равно приоритетные. А когда нужно по другому?
B>>Но, вопрос даже не в том. Если определять операции пользовательские, то тогда кроме приоритета надо еще и ассоциативность где-то указывать... Практически где это нужно? Сделать то все можно.. G>Для в любом языке с выражениями это нужно. Выражение a / b / c является верным для большинства ныне существующих языков, и каждый из них определяет ассоциативность и приоритет операций. А если ты не определяешь, значит где-то схалтурил.
Да все понятно. Не понятна только практическая необходимость. Вот выражение разбирается так. Если программисту нужна другая последовательность выполнения каких-то специфических правоассоциативных операций, то пусть скобки пишет.
G>Ты говоришь что что твое описание парсера эквивалентно некоторой формальной грамматике в виде peg или bnf. G>Вот и напиши свою грамматику в таком виде, а все твои рассуждения об объектах и новых концепциях никому не нужны.
Разумно.
Здравствуйте, batu, Вы писали:
B>Здравствуйте, gandjustas, Вы писали:
G>>>>Еще могут быть неассоциативные операторы, для которых необходимо явно указывать порядок (скобками или еще как-то). G>>>>Все генераторы парсеров учитывают ассоциативность, что в этом случае делает твой? B>>>А мой не учитывает. Как написано програмистом, так и разбирает. Даже не думал на эту тему. G>>Ну так как он разберет выражение a / b / c? И почему именно так, а не по-другому? B>Да так и разберет. Подряд. Как равно приоритетные. А когда нужно по другому?
Когда есть правоассоциативные операторы, например a=b=c.
B>>>Но, вопрос даже не в том. Если определять операции пользовательские, то тогда кроме приоритета надо еще и ассоциативность где-то указывать... Практически где это нужно? Сделать то все можно.. G>>Для в любом языке с выражениями это нужно. Выражение a / b / c является верным для большинства ныне существующих языков, и каждый из них определяет ассоциативность и приоритет операций. А если ты не определяешь, значит где-то схалтурил. B>Да все понятно. Не понятна только практическая необходимость. Вот выражение разбирается так. Если программисту нужна другая последовательность выполнения каких-то специфических правоассоциативных операций, то пусть скобки пишет.
Ты уже сливаешь. Пора бы признать что твой мега-парсер с объектами таки не все умеет, а ты еще неочень опытен в построении языков.
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, batu, Вы писали:
PC_>Бату, я там задавал вопрос выше на счет компилятора. Есть ?
ТLL есть. Lada нет. Начал писать. Отвлекают всякие дела. Где-то через пару месяцев будет. Да и вот видишь обсуждаем. Тоже нужное дело. А я разве не ответил тогда? У меня этот месяц в трубу ушел.
Здравствуйте, batu, Вы писали:
B>Здравствуйте, PC_2, Вы писали:
PC_>>Здравствуйте, batu, Вы писали:
PC_>>Бату, я там задавал вопрос выше на счет компилятора. Есть ? B>ТLL есть. Lada нет. Начал писать. Отвлекают всякие дела. Где-то через пару месяцев будет. Да и вот видишь обсуждаем. Тоже нужное дело. А я разве не ответил тогда? У меня этот месяц в трубу ушел.
я чего спросил, можно например скооперироваться, могу докрутить твой язык в студию, взамен нужна помощь докрутить нормально визуальный контрол. Подсветка и все такое.
язык С#.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, batu, Вы писали:
B>>>>Но, вопрос даже не в том. Если определять операции пользовательские, то тогда кроме приоритета надо еще и ассоциативность где-то указывать... Практически где это нужно? Сделать то все можно.. G>>>Для в любом языке с выражениями это нужно. Выражение a / b / c является верным для большинства ныне существующих языков, и каждый из них определяет ассоциативность и приоритет операций. А если ты не определяешь, значит где-то схалтурил. B>>Да все понятно. Не понятна только практическая необходимость. Вот выражение разбирается так. Если программисту нужна другая последовательность выполнения каких-то специфических правоассоциативных операций, то пусть скобки пишет. G> G>Ты уже сливаешь. Пора бы признать что твой мега-парсер с объектами таки не все умеет, а ты еще неочень опытен в построении языков.
Как же я солью если есть правоассоциативные операторы, например a=b=c.
Кстати, мега-парсер это не я придумал.. Зачем обзываешься? И еще. Не стыдно не знать. Стыдно не хотеть знать. Так что я по любому благодарен за общение. Я ж не в институте и не на фирме. Сам себе дома работаю. Оппонентов и помошников нет. Только книги и инет.
По операциям еще будет повод пообзываться.. Вот сформулирую и напишу. Вволю поотрываетесь.
PC_>я чего спросил, можно например скооперироваться, могу докрутить твой язык в студию, взамен нужна помощь докрутить нормально визуальный контрол. Подсветка и все такое. PC_>язык С#.
Переведи на русский. Я ж сказал что работаю сам. Потому с терминологией принятой не очень знаком. Иногда угадываю иногда нет. Что такое подсветка? Сотрудничеству всегда рад.
Здравствуйте, batu, Вы писали:
B>Здравствуйте, PC_2, Вы писали:
PC_>>я чего спросил, можно например скооперироваться, могу докрутить твой язык в студию, взамен нужна помощь докрутить нормально визуальный контрол. Подсветка и все такое. PC_>>язык С#. B>Переведи на русский. Я ж сказал что работаю сам. Потому с терминологией принятой не очень знаком. Иногда угадываю иногда нет. Что такое подсветка? Сотрудничеству всегда рад.
Подсветка это выделение ключевых слов и конструкций в твоем языке другим цветом.
Обычно ключевые слова подсвечиваются синеньким, а строки красным. Но зависит в какой студии ты работаешь
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, batu, Вы писали:
B>>Здравствуйте, PC_2, Вы писали:
PC_>>>я чего спросил, можно например скооперироваться, могу докрутить твой язык в студию, взамен нужна помощь докрутить нормально визуальный контрол. Подсветка и все такое. PC_>>>язык С#. B>>Переведи на русский. Я ж сказал что работаю сам. Потому с терминологией принятой не очень знаком. Иногда угадываю иногда нет. Что такое подсветка? Сотрудничеству всегда рад.
PC_>Подсветка это выделение ключевых слов и конструкций в твоем языке другим цветом. PC_>Обычно ключевые слова подсвечиваются синеньким, а строки красным. Но зависит в какой студии ты работаешь
Фигня вопрос. Даже не вопрос. Осталось наладить связь. А ты работаешь где? Или в чем интерес?
У меня с неделю будут проблемы. Переразметил нечаянно винт, с проектом. А он террабайтный. Надо купить новый и восстановить данные. Проверил они целые. Только у меня старый Getback. Там только по одному файлу можно вытаскивать..Надо найти чем восстановить..Там и прога, и документация..Вообщем все..
Здравствуйте, gandjustas, Вы писали: G>Ты откуда планирование загруженности взял?
Там было про график работ, распределение задач, оценку производительности, управление сроками.
А если это все неактуально, а нужно в первую очередь узнать нужно ли вобще такую-то задачу решать, или лучше совсем другую.
Почему LINQ for SQL не оправдал ожиданий MS (судя по всему ожидания были гораздо выше)? Наверно не из-за того что не смогли вовремя индуса вычислить который выпал из среднеквадратического отклонения по числу багов. И не из-за того что неправильно определили сроки. На пути образовался тупик, которого не было сразу видно.
G>Давай так. Лично ты на основании чего будешь делать выбор WinForms или WPF?
Прийдется лезть в детали.Сравнить потребности приложения с возможностями этих WinForms,WPF.
Я тут полезных рецептов не дам, но тут дело не в том сколько ошибок программист выдает на строчку кода. А в самих библиотеках, что они позволяют что нет.
У WPF возможности не безграничны, и недостатков немало. Многие недостатки типичны для frameworks которые много на себя берут — когда надо делать все в жестких рамках, только то для чего оно приспособлено, тогда все как по рельсам гладко. А чуть шаг в сторону попадешь в болто.
Да и еще надо учитывать что WPF на словах это аппаратное ускорение графики, а на деле чаще аппаратное замедление.
Рисует он гораздо медленнее GDI+, но Zoom, и градиенты быстрее делает.
И вобше впрос интересный стоило ли тащить WPF на D3D устройство, увеличило ли это скорость или уменьшило.
D3D ведь тоже не сахар, и не все он делает быстро. 50 микро секунд весь цикл рисования одного маленького обьекта. Cколько за это время нарисуешь обьектов на GDI+ и не сосчитаешь. Зато D3D может обрабатывать объекты пачками, но на эти пачки объектов жесткие ограничения в которых GUI очень тесно. GUI все-таки штука посложнее чем 3D сцены в игрушках.
Пляски с бубном вокруг этого D3D и приводят к тому что сам D3D выполняет работу быстро, а для процессора получается работы еще больше чем в рисовании на GDI+.
в этом месте засада, для тех кто посмотрит спецификации видеокарточки, сколько треугольников в секунду перемалывает, и начнет потирать руки подсчитав как у него шустро должен работать WPF.
Здравствуйте, batu, Вы писали:
B>Фигня вопрос. Даже не вопрос. Осталось наладить связь. А ты работаешь где? Или в чем интерес?
я в Киеве. На .NET работаю.
Интерес развивать идеи Ресерч Студио с отладкой на графах и нужны ребята в проект
Поэтому когда ты допишешь свой компилятор, помогу прикрутить тебе отладку двух типов, разные окошки и профайлеры. Главное чтобы был парсер и компилятор готовый на твой язык.
Взамен нужно будет потихоньку тратить время и на студию, фиксить там баги и дорабатывать все что поможет тебе лучше писать на твоем языке в новой Ресерч Студии.
Связаться можно со мной будет на этом форуме или по почте tuz.vyacheslav@gmail.com
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, batu, Вы писали:
B>>Фигня вопрос. Даже не вопрос. Осталось наладить связь. А ты работаешь где? Или в чем интерес?
PC_>я в Киеве. На .NET работаю. PC_>Интерес развивать идеи Ресерч Студио с отладкой на графах и нужны ребята в проект PC_>Поэтому когда ты допишешь свой компилятор, помогу прикрутить тебе отладку двух типов, разные окошки и профайлеры. Главное чтобы был парсер и компилятор готовый на твой язык. PC_>Взамен нужно будет потихоньку тратить время и на студию, фиксить там баги и дорабатывать все что поможет тебе лучше писать на твоем языке в новой Ресерч Студии.
PC_>Связаться можно со мной будет на этом форуме или по почте tuz.vyacheslav@gmail.com
Извиняюсь, что встреваю, но вот интересно — ты тоже не в курсе, что в природе есть github/bitbucket/google code etc.?
Здравствуйте, Курилка, Вы писали: К>Извиняюсь, что встреваю, но вот интересно — ты тоже не в курсе, что в природе есть github/bitbucket/google code etc.?
ехал сегодня на трамвае, по дороге бигборды пропустил.
Расскажи подробнее
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, batu, Вы писали:
B>>Фигня вопрос. Даже не вопрос. Осталось наладить связь. А ты работаешь где? Или в чем интерес?
PC_>я в Киеве. На .NET работаю. PC_>Интерес развивать идеи Ресерч Студио с отладкой на графах и нужны ребята в проект PC_>Поэтому когда ты допишешь свой компилятор, помогу прикрутить тебе отладку двух типов, разные окошки и профайлеры. Главное чтобы был парсер и компилятор готовый на твой язык. PC_>Взамен нужно будет потихоньку тратить время и на студию, фиксить там баги и дорабатывать все что поможет тебе лучше писать на твоем языке в новой Ресерч Студии.
PC_>Связаться можно со мной будет на этом форуме или по почте tuz.vyacheslav@gmail.com
Что за студия?
Я имею ввиду связь skype или аську. Что б оперативно.
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, batu, Вы писали: B>> Я имею ввиду связь skype или аську. Что б оперативно.
PC_>аська 3411семь52пять9
Давай когда будет компилятор готов,
обсудим фичи студии. Нужно смотреть возможности компилятора, что можно будет сделать для отладки тогда лучше всего обсудить.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, Курилка, Вы писали: К>>Извиняюсь, что встреваю, но вот интересно — ты тоже не в курсе, что в природе есть github/bitbucket/google code etc.?
PC_>ехал сегодня на трамвае, по дороге бигборды пропустил. PC_>Расскажи подробнее
Здравствуйте, gandjustas, Вы писали:
G>Ну так поробуй формализовать понятия "не делать ошибок" и "заведомо плохие варианты", получишь те самые метрики.
Я не знаю как формализуются понятия "не делать ошибок" и "заведомо плохие варианты".
G>Любое планирование будет метафизикой если не использовать метрики.
Вообще-то речь не о планировании, а о выборе наиболее оптимального варианта.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, PC_2, Вы писали:
PC_>>Здравствуйте, Курилка, Вы писали: К>>>Извиняюсь, что встреваю, но вот интересно — ты тоже не в курсе, что в природе есть github/bitbucket/google code etc.?
PC_>>ехал сегодня на трамвае, по дороге бигборды пропустил. PC_>>Расскажи подробнее
К>пинок мамутом batu
Так зачем здесь все это ?
Вообще-то проект студии пока что не опен сорц, будут люди сделаю опен сорц, будем работать.
Пока любые "коллективные" средства не нужны. Бату же написал, что он еще не дописал компилятор. Когда допишет тогда подумаем как расшарить код для работы и с проектом Компилятора на Ладу и с проектом Визуальной Среды Разработки, которая может поддержать новый язык.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, batu, Вы писали: B>> Я имею ввиду связь skype или аську. Что б оперативно.
PC_>аська 3411семь52пять9
У меня пока нет ничего. Я даже аську не ставлю. Работаю с резервного компа. Через неделю восстановлюсь.
Я хочу узнать к чему прикручивать и сколько у тебя время на занятие этим проектом
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, batu, Вы писали: B>> Я имею ввиду связь skype или аську. Что б оперативно.
PC_>аська 3411семь52пять9
Это я к тому, что тема достаточно серьезная потребует времени, и, следовательно, средств. Попутно с чем-то сделать не получится.
Здравствуйте, Silver_s, Вы писали:
S_>Почему LINQ for SQL не оправдал ожиданий MS (судя по всему ожидания были гораздо выше)? Наверно не из-за того что не смогли вовремя индуса вычислить который выпал из среднеквадратического отклонения по числу багов. И не из-за того что неправильно определили сроки. На пути образовался тупик, которого не было сразу видно.
S_>Я тут полезных рецептов не дам, но тут дело не в том сколько ошибок программист выдает на строчку кода. А в самих библиотеках, что они позволяют что нет.
Вообще говоря дело именно в том, сколько ошибок на единицу кода делает основная масса программистов.
Косяки и возможности фреймворков — это уже второстепенное.
Здравствуйте, batu, Вы писали:
B>Здравствуйте, PC_2, Вы писали:
PC_>>Здравствуйте, batu, Вы писали: B>>> Я имею ввиду связь skype или аську. Что б оперативно.
PC_>>аська 3411семь52пять9 B>Это я к тому, что тема достаточно серьезная потребует времени, и, следовательно, средств. Попутно с чем-то сделать не получится.
Ну если ты пишешь серьезный язык программирования и рассчитываешь что кто-то им будет пользоваться, пускай даже в академических целях, то сложно будет пользователей убедить работать в коммандной строке. Поэтому можно прикрутить его в визуальную среду разработки. Тоесть если брать в общем, то рано или поздно тебе тоже прийдется писать свою визуальную среду с отладчиком для языка или как-то интегрироваться к существующим. Вот про это я тебе и говорю. Когда будет компилятор, обсудим что можно сделать.
Моя студия это инновационый проект, о ней можно почитать в соседнем топике "Исследовательский проект"
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, batu, Вы писали:
B>>Здравствуйте, PC_2, Вы писали:
PC_>>>Здравствуйте, batu, Вы писали: B>>>> Я имею ввиду связь skype или аську. Что б оперативно.
PC_>>>аська 3411семь52пять9 B>>Это я к тому, что тема достаточно серьезная потребует времени, и, следовательно, средств. Попутно с чем-то сделать не получится.
PC_>Ну если ты пишешь серьезный язык программирования и рассчитываешь что кто-то им будет пользоваться, пускай даже в академических целях, то сложно будет пользователей убедить работать в коммандной строке. Поэтому можно прикрутить его в визуальную среду разработки. Тоесть если брать в общем, то рано или поздно тебе тоже прийдется писать свою визуальную среду с отладчиком для языка или как-то интегрироваться к существующим. Вот про это я тебе и говорю. Когда будет компилятор, обсудим что можно сделать.
У меня и проектируется среда.
PC_>Моя студия это инновационый проект, о ней можно почитать в соседнем топике "Исследовательский проект"
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, batu, Вы писали:
B>>У меня и проектируется среда.
PC_>с отладчиком ?
Само собой. И еще куча прибамбасов. Типа UML, Дизайнера и т.п.
Здравствуйте, Ikemefula, Вы писали:
I>Вообще говоря дело именно в том, сколько ошибок на единицу кода делает основная масса программистов. I>Косяки и возможности фреймворков — это уже второстепенное.
Неправильный выбор фреймворка или библиотеки, или крупные архитектурные ошибки, это к тем же ошибкам причисляется о которых идет речь? Или механические ошибки-описки имеются ввиду?
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, Ikemefula, Вы писали:
I>>Вообще говоря дело именно в том, сколько ошибок на единицу кода делает основная масса программистов. I>>Косяки и возможности фреймворков — это уже второстепенное.
S_> Неправильный выбор фреймворка или библиотеки, или крупные архитектурные ошибки, это к тем же ошибкам причисляется о которых идет речь? Или механические ошибки-описки имеются ввиду?
хм, ладно тогда подождем резил версию
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, batu, Вы писали:
B>>У меня и проектируется среда.
PC_>с отладчиком ?
Мне не удалось открыть твой документ. Хотя скачал вроде нормально.
Здравствуйте, batu, Вы писали:
B>Здравствуйте, PC_2, Вы писали:
PC_>>Здравствуйте, batu, Вы писали:
B>>>У меня и проектируется среда.
PC_>>с отладчиком ? B>Мне не удалось открыть твой документ. Хотя скачал вроде нормально.
сохранял в формате Word 2000-2003. Офис какой установлен ?
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, batu, Вы писали:
B>>Здравствуйте, PC_2, Вы писали:
PC_>>>Здравствуйте, batu, Вы писали:
B>>>>У меня и проектируется среда.
PC_>>>с отладчиком ? B>>Мне не удалось открыть твой документ. Хотя скачал вроде нормально.
PC_>сохранял в формате Word 2000-2003. Офис какой установлен ?
10-й
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, gandjustas, Вы писали: G>>Ты откуда планирование загруженности взял? S_>Там было про график работ, распределение задач, оценку производительности, управление сроками.
А откуда планирование загруженности взял?
S_>А если это все неактуально, а нужно в первую очередь узнать нужно ли вобще такую-то задачу решать, или лучше совсем другую.
Как это относится к теме разговора?
S_>Почему LINQ for SQL не оправдал ожиданий MS (судя по всему ожидания были гораздо выше)? Наверно не из-за того что не смогли вовремя индуса вычислить который выпал из среднеквадратического отклонения по числу багов. И не из-за того что неправильно определили сроки. На пути образовался тупик, которого не было сразу видно.
Мне кажется что Linq2SQL придумали как proof of concept для IQueryable, и потом забили потому что пытались развивать "взрослый ORM" EF, который в итоге еле дотянул до сугубо практичного Linq2SQL, построенного по принципу 80\20.
G>>Давай так. Лично ты на основании чего будешь делать выбор WinForms или WPF? S_>Прийдется лезть в детали.Сравнить потребности приложения с возможностями этих WinForms,WPF. S_>Я тут полезных рецептов не дам, но тут дело не в том сколько ошибок программист выдает на строчку кода. А в самих библиотеках, что они позволяют что нет.
Ну если X принципиально не позволяет сделать то что надо, а Y позволяет, то выбор довольно простой.
S_>[описание недостатков WPF]
Меня это мало интересует. Меня больше инетресует основываясь на чем ты будешь делать выбор.
Например надо разработать GIS. Простенькую, без кучи слоев. WPF или WinForm и почему?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
G>>Ну так поробуй формализовать понятия "не делать ошибок" и "заведомо плохие варианты", получишь те самые метрики. IT>Я не знаю как формализуются понятия "не делать ошибок" и "заведомо плохие варианты".
Ну если можешь оценить — видимо знаешь.
G>>Любое планирование будет метафизикой если не использовать метрики. IT>Вообще-то речь не о планировании, а о выборе наиболее оптимального варианта.
Что значит "оптимального"? Критерий "оптимальности" приведи.
Здравствуйте, gandjustas, Вы писали:
G>>>Ну так поробуй формализовать понятия "не делать ошибок" и "заведомо плохие варианты", получишь те самые метрики. IT>>Я не знаю как формализуются понятия "не делать ошибок" и "заведомо плохие варианты". G>Ну если можешь оценить — видимо знаешь.
Оценить на больше меньше, наверное, могу. Формализовать, чтобы получить метрики — сомневаюсь.
IT>>Вообще-то речь не о планировании, а о выборе наиболее оптимального варианта. G>Что значит "оптимального"? Критерий "оптимальности" приведи.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
G>>>>Ну так поробуй формализовать понятия "не делать ошибок" и "заведомо плохие варианты", получишь те самые метрики. IT>>>Я не знаю как формализуются понятия "не делать ошибок" и "заведомо плохие варианты". G>>Ну если можешь оценить — видимо знаешь.
IT>Оценить на больше меньше, наверное, могу.
Отлично. Что будешь оценивать на "больше меньше" для понятий "не делать ошибок" и "заведомо плохие варианты".
IT>Формализовать, чтобы получить метрики — сомневаюсь.
Поможем
IT>>>Вообще-то речь не о планировании, а о выборе наиболее оптимального варианта. G>>Что значит "оптимального"? Критерий "оптимальности" приведи.
IT>Наиболее приемлемый, самый благоприятный, наилучший для чего-либо.
Спасибо, КО. А критерий оптимальности варианта в твоем случае.
Здравствуйте, gandjustas, Вы писали:
S_>>Почему LINQ for SQL не оправдал ожиданий MS (судя по всему ожидания были гораздо выше)? Наверно не из-за того что не смогли вовремя индуса вычислить который выпал из среднеквадратического отклонения по числу багов. И не из-за того что неправильно определили сроки. На пути образовался тупик, которого не было сразу видно. G>Мне кажется что Linq2SQL придумали как proof of concept для IQueryable, и потом забили потому что пытались развивать "взрослый ORM" EF, который в итоге еле дотянул до сугубо практичного Linq2SQL, построенного по принципу 80\20.
Дело вобщем не в функционале. Реально основная масса девелоперов кроме как императивно, мыслить не могут, не хотят и сопротивляются.
G>Например надо разработать GIS. Простенькую, без кучи слоев. WPF или WinForm и почему?
У меня, например, простенькая у меня уже есть, я бы взял винформс потому что она уже винформс
Если переписывать заново, буде для этого причины какие то, я бы _попробовал_ ВПФ, тупо потому, что следить за кликами, отрисовкой мелкой, проще на ВПФ.
За исключением ввода и рендеринга разницы почти что нет, разве что асинхронную хрень и разные подлые биндинги лучшед елать на ВПФ но это уже не совсем простенькая
Здравствуйте, Ikemefula, Вы писали:
G>>Например надо разработать GIS. Простенькую, без кучи слоев. WPF или WinForm и почему?
I>Если переписывать заново, буде для этого причины какие то, я бы _попробовал_ ВПФ, тупо потому, что следить за кликами, отрисовкой мелкой, проще на ВПФ.
Что значит "проще"? В чем эта простота выражается?
Здравствуйте, gandjustas, Вы писали:
I>>Если переписывать заново, буде для этого причины какие то, я бы _попробовал_ ВПФ, тупо потому, что следить за кликами, отрисовкой мелкой, проще на ВПФ. G>Что значит "проще"? В чем эта простота выражается?
Проще значит
1. готовый функционал
2. отсутствие побочных эффектов, как например косяки GDI+
3. отсутствие некоторых рисков, например в случае с GDI+ для решения некоторых проблем, как z-bufer, может понадобиться вагон времени
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Если переписывать заново, буде для этого причины какие то, я бы _попробовал_ ВПФ, тупо потому, что следить за кликами, отрисовкой мелкой, проще на ВПФ. G>>Что значит "проще"? В чем эта простота выражается?
I>Проще значит
I>1. готовый функционал I>2. отсутствие побочных эффектов, как например косяки GDI+ I>3. отсутствие некоторых рисков, например в случае с GDI+ для решения некоторых проблем, как z-bufer, может понадобиться вагон времени
Ну вот уже напрашиваются метрики: время выполнения и количество багов. Причем не важны абсолютные цифры, важно что ты можешь подходы упорядочить по этим метрикам.
Здравствуйте, Silver_s, Вы писали:
I>>Вообще говоря дело именно в том, сколько ошибок на единицу кода делает основная масса программистов. I>>Косяки и возможности фреймворков — это уже второстепенное.
S_> Неправильный выбор фреймворка или библиотеки, или крупные архитектурные ошибки, это к тем же ошибкам причисляется о которых идет речь? Или механические ошибки-описки имеются ввиду?
Да вобщем то нет разницы. Разница между этими ошибками всего лишь в цене вопроса. Т.е. все ошибки можно привести к общему знаменателю чз оную цену.
Здравствуйте, gandjustas, Вы писали:
IT>>Оценить на больше меньше, наверное, могу. G>Отлично. Что будешь оценивать на "больше меньше" для понятий "не делать ошибок" и "заведомо плохие варианты".
Буду оценивать предыдущий опыт и анализировать какие из используемых решений приводят к наименьшему количеству проблем.
IT>>Формализовать, чтобы получить метрики — сомневаюсь. G>Поможем
Здравствуйте, gandjustas, Вы писали:
G>Ну вот уже напрашиваются метрики: время выполнения и количество багов. Причем не важны абсолютные цифры, важно что ты можешь подходы упорядочить по этим метрикам.
Как можно упорядочить баги, если один является орфографической ошибкой в строке и требует 2 секунды на фикс, а другой является следствием архитектурной ошибки и требует для фикса переписать 2/3 приложения?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas, Вы писали:
S_>>Там было про график работ, распределение задач, оценку производительности, управление сроками. G>А откуда планирование загруженности взял?
Ничего ниоткуда не брал. Просто все это обозвал (наверное ругательным выражением) планирование и оптимизация загрузки производственного конвеера.
Поскольку вопросы о внутренности приложения практически не затрагиваются. А больше вопросы на тему кто будет делать за сколько дней и сколько будет багов.
S_>>А если это все неактуально, а нужно в первую очередь узнать нужно ли вобще такую-то задачу решать, или лучше совсем другую. G>Как это относится к теме разговора?
К теме о сроках это относится мало. Но к вопросам о сложностях софтостроения это имеет прямое отношение. Если надо реализовать маленькую задачку с четкой спецификацией, ни шагу в сторону. Тогда конечно можно сказать — есть ли смысл в этой задачке или фигня какая-то никому не нужная, это все проблемы заказчика. Раз заказал пусть сам и расхлебывает. Наше дело написать и забыть.
S_>>[описание недостатков WPF] G>Меня это мало интересует. Меня больше инетресует основываясь на чем ты будешь делать выбор.
Выбор лучше делать на основе "описания недостатков WPF", можно еще взять "описание достоинств". Хотя в предыдущем посте у меня было скорее не полное описание недостатков, а просто предположения откуда у WPF тормоза и почему его было сложно сделать без тормозов.
Да что WPF, он уже написан кем-то. А когда сам пишешь, приходится самому и подбирать и оптимизировать эти списки недостатков и достоинств. (от списка недостатков полностью избавиться не получится)
G>Например надо разработать GIS. Простенькую, без кучи слоев. WPF или WinForm и почему?
Если эта GIS с довольно простым GUI, что даже сошел бы и веб интерфейс на j скриптах и html, то можно и на WPF.
Но GIS это на та система, где куча форм которые надо быстро нашлепать. И механизмы data binding, Layouts,XAML много времени врядли сэкономят — уже несколько достоинств WPF не так востребованы в таком приложении.
Если что-то более сложное и с рисованием. Лично для меня(раз там "ты" жирно выделено) к сожалению пока WPF очень непрозрачный. Если риски на мне висят, то не рискнул бы связываться с WPF. Взял бы WinForms+Direct2D(D2D можно добавить если не напрягает ограничение на Windows 7). Работы может это прибавит, но меньше риск попасть в засаду, когда наполовину сделаное отправится в помойку. Может это от недостаточного знания WPF, может от недостатков WPF.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
IT>>>Оценить на больше меньше, наверное, могу. G>>Отлично. Что будешь оценивать на "больше меньше" для понятий "не делать ошибок" и "заведомо плохие варианты".
IT>Буду оценивать предыдущий опыт и анализировать какие из используемых решений приводят к наименьшему количеству проблем.
То есть как минимум минимизировать баги, возможно еще какие-то метрики.
IT>>>Наиболее приемлемый, самый благоприятный, наилучший для чего-либо. G>>Спасибо, КО. А критерий оптимальности варианта в твоем случае. IT>Вариант, который по сумме всех критериев, устраивает меня больше других.
Вот уже лучше. Критерии == метрики.
Что за критерии?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
G>>Ну вот уже напрашиваются метрики: время выполнения и количество багов. Причем не важны абсолютные цифры, важно что ты можешь подходы упорядочить по этим метрикам.
IT>Как можно упорядочить баги, если один является орфографической ошибкой в строке и требует 2 секунды на фикс, а другой является следствием архитектурной ошибки и требует для фикса переписать 2/3 приложения?
Можно считать взвешенную сумму.
Гапертон уже говорил что базовые метрики мало что дают, а вот производные уже позволяют делать выводы.
Кстати орфографическая ошибка это даже не баг. Баги считаются когда их найдут тестеры или пользователи, то что исправляет на месте программист до того как другие увидят результат его работы — не баг.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Gaperton, Вы писали:
G>>Вот у тебя кусок кода. У него "высокая сложность", что означает крайне дорогие правки в этот код, даже если правки сами по себе незначительные. Но! Код отлажен, изолирован за годными интерфейсами, отлично работает, и никаких правок туда в ближайшие 5 лет не ожидается. G>>Тебя волнует его сложность? Ты будешь тратить время на то, чтобы его "рефакторить", понижая "сложность"?
IT>О, блин! Только что ответил выше Повторюсь здесь. Да, буду править, если сложность восприятия этого кода будет для меня проблемой. Сразу оговорюсь, буду править не потому, что заглядывая в него я буду тратить лишнее время (ты же всё равно к этому всё сведёшь, правильно ), а потому что я очень расстраиваюсь, когда вижу плохой код и моё хорошее настроение мне дороже любого времени.
Совать руки в отлаженный работающий механизм, куда не ожидаются правки, внося туда новые баги, просто потому, что случайно заглянул туда не в том настроении?
Здравствуйте, Gaperton, Вы писали:
IT>>О, блин! Только что ответил выше Повторюсь здесь. Да, буду править, если сложность восприятия этого кода будет для меня проблемой. Сразу оговорюсь, буду править не потому, что заглядывая в него я буду тратить лишнее время (ты же всё равно к этому всё сведёшь, правильно ), а потому что я очень расстраиваюсь, когда вижу плохой код и моё хорошее настроение мне дороже любого времени.
G>Совать руки в отлаженный работающий механизм, куда не ожидаются правки, внося туда новые баги, просто потому, что случайно заглянул туда не в том настроении?
Бывает, что время на то, чтобы разобраться в отлаженном работающем механизме требуется больше, чем время чтобы его нормально переписать, отладить, откоментировать и обложить тестами.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Gaperton, Вы писали:
G>Вот у тебя кусок кода. У него "высокая сложность", что означает крайне дорогие правки в этот код, даже если правки сами по себе незначительные. Но! Код отлажен, изолирован за годными интерфейсами, отлично работает, и никаких правок туда в ближайшие 5 лет не ожидается. G>Тебя волнует его сложность? Ты будешь тратить время на то, чтобы его "рефакторить", понижая "сложность"?
Вообще говоря — да.
Код не должен просто работать.
Если в код никто не лазит, то, как правило, его никто и не знает, следовательно, никто не знает ни возможностей, ни особенностей этого кода.
Следовательно, новый функционал с большой вероятностью будет дублировать уже имеющийся.
ПОтому код надо пересматривать регулярно. А если у кода "высокая сложность", то обычно с этого все и начинается.
Как правило, корень проблем, на мой взгляд, это как раз код который работает годами и туда никто не лазит
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>Все генераторы парсеров учитывают ассоциативность, что в этом случае делает твой?
AVK>Генераторы парсеров обычно никакой ассоциативности не учитывают. Ассоциативность задается грамматикой.
А генераторы на вход что получают?
Мы видимо об одном и том же разными словами говорим.
Здравствуйте, Ikemefula, Вы писали:
G>>Вот у тебя кусок кода. У него "высокая сложность", что означает крайне дорогие правки в этот код, даже если правки сами по себе незначительные. Но! Код отлажен, изолирован за годными интерфейсами, отлично работает, и никаких правок туда в ближайшие 5 лет не ожидается. G>>Тебя волнует его сложность? Ты будешь тратить время на то, чтобы его "рефакторить", понижая "сложность"?
I>Вообще говоря — да.
I>Код не должен просто работать.
Код должен просто работать. Когда у тебя возникает _резон_ вносить туда правку, ты можешь рассматривать его рефакторинг.
I>Если в код никто не лазит, то, как правило, его никто и не знает, следовательно, никто не знает ни возможностей, ни особенностей этого кода.
Вообрази ситуацию, что твоему продукту 10 лет, и объем исходников составляет миллион строк кода, и он при этом постоянно развивается. Систему такого объема один человек не в состоянии понимать и удерживать в голове целиком, и ситуация, когда ты знаком и работаешь с ее фрагментом — естественна.
Нет ни необходимости, ни практической возможности лазить в места, которые давно написаны, отлажены, и отлично работают. У тебя на практике не будет на это ни времени, ни возможности — рефакторинг такого кода слишком сложен и затратен, чтобы делать его пробегая мимо. Тому, кто так будет делать, коллеги с тестерами довольно быстро руки вырвут.
I>Следовательно, новый функционал с большой вероятностью будет дублировать уже имеющийся.
Не следует, и не будет. Ни единого резона на то нет. С какого дуба очередь коллцентра должна дублировать хоть что-то из функциональности перевода звонка? У тебя это просто не получится.
Для меня вообще загадка, о каких системах вы думаете, когда говорите подобное.
I>ПОтому код надо пересматривать регулярно. А если у кода "высокая сложность", то обычно с этого все и начинается.
Скорость просмотра незнакомого кода, на которой ты в состоянии более-менее его понять, и найти там какие-то ошибки — 200 строк кода в час. Это измеренный темп кодревью свежего (т.е. довольно неплохого) кода. Переписывание обойдется куда дороже.
Теперь. У тебя миллион строк, из которого активная разработка затрагивает, допустим, 200 тысяч строк. Остальной код — стабилен, и там иногда находят баги.
И у тебя, естественно, полный бэклог багов и фич, на год вперед, и жопа в мыле. Валяй, считай, сколько времени ты готов потратить на "просматривание" остальных 800 тысяч.
Знаешь, от программеров всего ожидать можно, но от тебя не ожидал. Я ведь типовую ситуацию описываю, не какую-нибудь экзотику.
I>Как правило, корень проблем, на мой взгляд, это как раз код который работает годами и туда никто не лазит
Это нормальная ситуация, и ты никуда от нее не денешься — хочешь или не хочешь.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Gaperton, Вы писали:
IT>>>О, блин! Только что ответил выше Повторюсь здесь. Да, буду править, если сложность восприятия этого кода будет для меня проблемой. Сразу оговорюсь, буду править не потому, что заглядывая в него я буду тратить лишнее время (ты же всё равно к этому всё сведёшь, правильно ), а потому что я очень расстраиваюсь, когда вижу плохой код и моё хорошее настроение мне дороже любого времени.
G>>Совать руки в отлаженный работающий механизм, куда не ожидаются правки, внося туда новые баги, просто потому, что случайно заглянул туда не в том настроении?
IT>Бывает, что время на то, чтобы разобраться в отлаженном работающем механизме требуется больше, чем время чтобы его нормально переписать, отладить, откоментировать и обложить тестами.
А бывает и так, что в работающем коде нет повода ни разбираться, ни переписывать. Потому, что работы, которую _можно_ сделать, обычно гораздо больше, чем ты сделать физически в состоянии.
Но это не главное. Главное, что ты, наконец, не уследил за собой, и нечаянно охарактеризовал "сложность" через время и трудозатраты, связанные с внесением правки.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Если у тебя в руках молоток, все вокруг кажется гвоздями.
G>>На себя примерь.
AVK>Не подошло.
Отлично. Теперь личная просьба — тебя не затруднит прекратить делать переходы на личности, вспоминая искрометные поговорки? Тебе ведь не сложно, нет?
AVK>>>Ты упорно говоришь про что то свое, не про то что в статье. Она вообще не о сроках и трудоемкости.
G>>Я говорю про то, что в статье.
AVK>При этом автор тебе говорит о том, что ничего подобного он не писал. Знаешь лучше автора?
Я в курсе, что он ничего подобного не писал. И вообще — не вижу смысла писать то, что автор уже написал. Я дополняю его статью взглядом с другой стороны на ту же проблему.
Здравствуйте, minorlogic, Вы писали:
M>>>"Трансформирование сложности означает одну простую вещь – устраняя сложность в одном месте, мы всегда добавляем её где-то в другом."
M>>>Очевиднейший бред, дальше читать не стал. И как только такой треш пропускает рецензура...
G>>Один ошибочный вывод не делает бредом всю статью. В конце концов, непрерывно нести бред очень тяжело. Почти так же тяжело, как и все время говорить истину, и только истину . Если предмет статьи содержателен, конечно.
M>Конечно нет , но уровень статьи сразу понижает. Может все же Мак Коннелла почитать? без шуток ? Ну уже классика, пока не стареющая.
Да нормальная у IT в целом статья. Не вижу причины, почему бы ему не написать статью о своем видении сложности. Даже если на эту тему уже писал МакКоннел. Что — теперь нельзя, чтоли?
Здравствуйте, Gaperton, Вы писали:
G>Отлично. Теперь личная просьба — тебя не затруднит прекратить делать переходы на личности, вспоминая искрометные поговорки?
Это не переход на личности. Это не имеет отношение к твоей личности, это намек на то, что в твоих сообщениях демонстрируется крайне узкая точка зрения, плохо коррелирующая с тем, что имел в виду автор статьи.
AVK>>При этом автор тебе говорит о том, что ничего подобного он не писал. Знаешь лучше автора?
G>Я в курсе, что он ничего подобного не писал. И вообще — не вижу смысла писать то, что автор уже написал. Я дополняю его статью взглядом с другой стороны на ту же проблему.
Если бы ты только дополнял. Но ты же споришь и опровергаешь. И это при том, что IT тебе ясно написал, что ничего против метрик не имеет, но статья не о том.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, Gaperton, Вы писали:
I>>Вообще говоря — да.
I>>Код не должен просто работать.
G>Код должен просто работать. Когда у тебя возникает _резон_ вносить туда правку, ты можешь рассматривать его рефакторинг.
Работать — это недостаточно, что бы оставлять его в неизменном виде.
I>>Если в код никто не лазит, то, как правило, его никто и не знает, следовательно, никто не знает ни возможностей, ни особенностей этого кода.
G>Вообрази ситуацию, что твоему продукту 10 лет, и объем исходников составляет миллион строк кода, и он при этом постоянно развивается. Систему такого объема один человек не в состоянии понимать и удерживать в голове целиком, и ситуация, когда ты знаком и работаешь с ее фрагментом — естественна.
3 млн строк если тупо строками. Все полностью в голове не нужно держать.
G>Нет ни необходимости, ни практической возможности лазить в места, которые давно написаны, отлажены, и отлично работают.
Если отлично работают, дублирования не дают, с освоением проблем не возникает, фич не планирует, багов нет — это ж как в сказке
G>У тебя на практике не будет на это ни времени, ни возможности — рефакторинг такого кода слишком сложен и затратен, чтобы делать его пробегая мимо. Тому, кто так будет делать, коллеги с тестерами довольно быстро руки вырвут.
Пробегая мимо и не нужно. В бекграунде вполне возможно.
I>>Следовательно, новый функционал с большой вероятностью будет дублировать уже имеющийся.
G>Не следует, и не будет. Ни единого резона на то нет. С какого дуба очередь коллцентра должна дублировать хоть что-то из функциональности перевода звонка? У тебя это просто не получится.
Дублирование не на уровне подсистем конечно. Дублирование можт проявляться на пример в вагонах водопроводного кода или кода для конфигурации.
G>Для меня вообще загадка, о каких системах вы думаете, когда говорите подобное.
Сложно предложить хороший пример, я согласен.
I>>ПОтому код надо пересматривать регулярно. А если у кода "высокая сложность", то обычно с этого все и начинается.
G>Скорость просмотра незнакомого кода, на которой ты в состоянии более-менее его понять, и найти там какие-то ошибки — 200 строк кода в час. Это измеренный темп кодревью свежего (т.е. довольно неплохого) кода. Переписывание обойдется куда дороже.
Ну да, медленно дело идёт. Время на просмотры будет тратиться постоянно, например при фиксах и отладке, отлдадке зависисимого кода коего может быть на порядки больше. В пересчете на всю тиму я бы уже не был так уверен на счет дороговизны переписывания.
G>Теперь. У тебя миллион строк, из которого активная разработка затрагивает, допустим, 200 тысяч строк. Остальной код — стабилен, и там иногда находят баги.
Как то очень абстрактно. Мне надо знать, что там за баги, т.е. не описание, а вся цепочка возникновения. Буде цепочки длинные, не зависимо от severity, это указывает на проблемы.
Даже если в этом остальном коде багов нет, нужно смотреть цепочки возникновения багов в том коде где идет активная разработка.
G>И у тебя, естественно, полный бэклог багов и фич, на год вперед, и жопа в мыле.
Если можно очень четко изолировать эти 200к строк с багами и фичами, то это слишком простой случай.
G>Валяй, считай, сколько времени ты готов потратить на "просматривание" остальных 800 тысяч.
Все 800 тысяч не нужно просматривать. Нужно находить ключевые места в коде и через них преобразоывать код.
Ключевые места это нестабильные, непредсказуемые, находятся например по количеству депенденсов, по количеству фиксов, по кол.ву времени и тд и тд.
Эти ключевые места вобщем то и определеяют состояние всего кода.
По времени оценить сложно, т.к. много неизвестных.
G>Знаешь, от программеров всего ожидать можно, но от тебя не ожидал. Я ведь типовую ситуацию описываю, не какую-нибудь экзотику.
Я 10 лет проработал на длинных и проектах и вобщем говорю про типовые ситуации.
Код начинает тухнуь вобщем то с тех мест которые вроде как стабильны, работают и тд.
I>>Как правило, корень проблем, на мой взгляд, это как раз код который работает годами и туда никто не лазит
G>Это нормальная ситуация, и ты никуда от нее не денешься — хочешь или не хочешь.
Почему же не денешься, просто сразу все зараз переписывать не нужно.
Бывает, менеджеры имеют обыкновение отгонять девелоперов от такого кода, что не есть правильно.
Здравствуйте, AndrewVK, Вы писали:
G>>Я говорю про то, что в статье.
AVK>При этом автор тебе говорит о том, что ничего подобного он не писал. Знаешь лучше автора?
Автор статьи в этом треде не раз и не два прокололся. А иногда возникает ощущение что он под пивом
Здравствуйте, Gaperton, Вы писали:
G>Но это не главное. Главное, что ты, наконец, не уследил за собой, и нечаянно охарактеризовал "сложность" через время и трудозатраты, связанные с внесением правки.
Не совсем так. Говоря обо всём об этом, я имел ввиду конкретный пример из жизни. Так вот в нём дело было даже не во времени, в количестве геморроя. Если интересно могу об этом случае рассказать подробнее.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
I>>Автор статьи в этом треде не раз и не два прокололся. А иногда возникает ощущение что он под пивом
AVK>У меня ощущение, что под пивом или чем то еще в этом требе как раз ты.
На давайте теперь обсудим, кто тут под пивом, а кто под водкой.
Здравствуйте, AndrewVK, Вы писали:
I>>Автор статьи в этом треде не раз и не два прокололся. А иногда возникает ощущение что он под пивом AVK>У меня ощущение, что под пивом или чем то еще в этом требе как раз ты.
Мальчики, не ссорьтесь! Тем более, что сегодня пятница и вам обоим уж точно давно пора быть по пивом
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
I>>Автор статьи в этом треде не раз и не два прокололся. А иногда возникает ощущение что он под пивом
AVK>У меня ощущение, что под пивом или чем то еще в этом требе как раз ты.
Ты сильно погорячился. А проколы автора вобщем то четко обозначены.
Здравствуйте, IT, Вы писали:
G>>Но это не главное. Главное, что ты, наконец, не уследил за собой, и нечаянно охарактеризовал "сложность" через время и трудозатраты, связанные с внесением правки.
IT>Не совсем так. Говоря обо всём об этом, я имел ввиду конкретный пример из жизни. Так вот в нём дело было даже не во времени, в количестве геморроя.
Ты уже в который раз вместо указания конкретных фактов используешь эмоциональную оценку.
"Геморрой" это обычно время, активность и твоя эмоциональная оценка этих затрат.
Попробуй отделить эмоциональную оценку от того, что ты хочешь сказать.
Здравствуйте, Ikemefula, Вы писали:
IT>>Не совсем так. Говоря обо всём об этом, я имел ввиду конкретный пример из жизни. Так вот в нём дело было даже не во времени, в количестве геморроя. I>Ты уже в который раз вместо указания конкретных фактов используешь эмоциональную оценку.
Я уже в который раз пытаюсь кое-кому объяснить, что эмоциональная оценка такие же конкретные факты, как и всё остальное.
I>Под пивом, сдаётся, это не просто
Ты уже? У меня ещё рабочий день не закончился.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
G>>Отлично. Теперь личная просьба — тебя не затруднит прекратить делать переходы на личности, вспоминая искрометные поговорки?
AVK>Это не переход на личности. Это не имеет отношение к твоей личности, это намек на то, что в твоих сообщениях демонстрируется крайне узкая точка зрения, плохо коррелирующая с тем, что имел в виду автор статьи.
А ты, Андрей, не намекай, ты сразу прямо говори. Свои ж люди, давно заочно знакомы.
Отвечаю по существу. Я уверен, что моя точка зрения отлично коррелирует с тем, что хотел сказать автор.
И я готов это доказать. По самым строгим правилам — приведя прямое соответствие между пунктами его статьи, и тем, что сказал в своем первом комменте я.
Я, правда, грешным делом полагал, что это очевидно. Но если нет — то не вопрос.
AVK>>>При этом автор тебе говорит о том, что ничего подобного он не писал. Знаешь лучше автора?
G>>Я в курсе, что он ничего подобного не писал. И вообще — не вижу смысла писать то, что автор уже написал. Я дополняю его статью взглядом с другой стороны на ту же проблему.
AVK>Если бы ты только дополнял. Но ты же споришь и опровергаешь. И это при том, что IT тебе ясно написал, что ничего против метрик не имеет, но статья не о том.
Он спорит, и пытается опровергать очевидное. Но давай это оставим, это не важно. Важно:
1) Статья я знаю, что не о том. Я в своем комменте привязываю контент статьи к метрикам, ибо с моей точки зрения оно о том. Можно, нельзя?
2) Где именно IT это сказал? Не заметил, сцылко, плиз.
Здравствуйте, Ikemefula, Вы писали:
I>>>Автор статьи в этом треде не раз и не два прокололся. А иногда возникает ощущение что он под пивом
AVK>>У меня ощущение, что под пивом или чем то еще в этом требе как раз ты.
I>Ты сильно погорячился. А проколы автора вобщем то четко обозначены.
Не. ты от ответа не уходи. Ты под пивом или под водкой?
Вот у меня лично сложный состав. В основе — Jack Daniels + Сибирская Корона + Хугарден.
Здравствуйте, IT, Вы писали:
G>>Но это не главное. Главное, что ты, наконец, не уследил за собой, и нечаянно охарактеризовал "сложность" через время и трудозатраты, связанные с внесением правки.
IT>Не совсем так. Говоря обо всём об этом, я имел ввиду конкретный пример из жизни. Так вот в нём дело было даже не во времени, в количестве геморроя. Если интересно могу об этом случае рассказать подробнее.
Валяй, расскажи. Не вижу причин, почему нет — на конкретику всегда полезно перейти. Будет интересно.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Ikemefula, Вы писали:
IT>>>Не совсем так. Говоря обо всём об этом, я имел ввиду конкретный пример из жизни. Так вот в нём дело было даже не во времени, в количестве геморроя. I>>Ты уже в который раз вместо указания конкретных фактов используешь эмоциональную оценку.
IT>Я уже в который раз пытаюсь кое-кому объяснить, что эмоциональная оценка такие же конкретные факты, как и всё остальное.
Почитай, что мы, менеджеры, пишем про эмоциональную оценку. Будет интересно. Примерь на себя. http://gaperton.livejournal.com/50685.html
Hint: некоторые из нас, менеджеров, не боятся "грязной работы", и иногда устраивают себе испытание: заставляют себя тряхнуть стариной, и в полный рост кодить. Из принципа, чтобы не отрываться от реальности. Редкость, но бывает, ага. И тогда появляются такие статьи.
I>>Под пивом, сдаётся, это не просто
IT>Ты уже? У меня ещё рабочий день не закончился.
Здравствуйте, IT, Вы писали:
G>>Вопрос некорректен. В любом _проекте_ сроки имеют значение, ибо проект всегда ограничен временем по определению. Не ограничены временем _программа_ и разгильзяйство. Но программа состоит из проектов. А из чего состоит разгильзяйство — мне не интересно.
IT>Думаю, что вот этот никак не ограничен временем.
Ниче не могу сказать. Просто, я ничего не знаю про это проект.
Скажу так. Я рассматриваю коммерческие проекты.
Если проект — исследование, он всегда ограничен временем и бюджетом. Почему? Потому, что цель проекта — получить новое знание, и всегда есть верхняя граница того, сколько готовы за это знание заплатить. По времени, и по деньгам. Это те реалии, с которыми я постоянно сталкиваюсь. А российской классификации, такой проект называется "НИР".
Если же проект имеет цель не получение нового знания, а получение работоспособного изделия/кода (сталкивался и с тем и с другим — я программно-аппаратными комплексами занимаюсь последние 5 лет), то это, пнимаешь-ли, называется ОКР.
И ты знаешь, один хрен он ограничен временем и деньгами.
Все проекты ограничены временем и деньгами, если это не так — то это не проекты — а "программа исследований".
Ты знаешь, я руководил в том числе и программами исследований. Было дело — в ИТМиВТ (институт точной механики и вычислительной техники). Вот, я тебе скажу, — "программа" бьется на серию вполне конкретных исследований (НИР), каждое из которых имеет конкретную цель, и ограничено рамками времени.
Почему? Потому, что даже в прикладной науке нам не нужен результат любой ценой. И если по конкретному направлению не будет результата длительное время (и не будет движухи по "открытым проблемам", то есть, их список не меняется длительное время) — оно будет закрыто.
Здравствуйте, IT, Вы писали:
IT>>>Здорово. Только я всё не возьму в толк, как мне это поможет выбрать правильный дизайн базы данных? Вот, например, у меня есть форма с гридом, в котором 24 колонки для 24-х месяцев, по 12 на 2 года. Как мне лучше их уложить в базу, как 24 месяца в одну запись или как две записи по 12 месяцев? Какую метрику посоветуешь?
G>>Посоветую не морочить людям голову, и перестать выдумывать и писать ерунду. G>>Надоело.
IT>Т.е. для этого случая метрики не нашлось. На самом деле, и здесь всё можно свести ко времени, только проблема в том, что это время хрен засечёшь секундомером. Неверный дизайн всегда однозначно приводит к замедлению проекта, только вряд ли это "больше/меньше" можно померять с точностью хотя бы плюс/минус трамвайная остановка.
Нет. Просто ты в конце концов задолбал прикидываться валенком, Игорь.
Вопрос в очередной раз некорректно поставлен, и я реально задолбался в 7-й раз объяснять, почему.
Хочешь ответ вне контекста (т.е. юзкейсов)? Третья нормальная форма. Устраивает? Метрики здесь, как ты понимаешь, не причем. То есть, ни в красную армию, ни в известную дырку.
Здравствуйте, Sinclair, Вы писали:
G>>Где вот такая херня написана, как ты привел? Ты их не просто читал, ты их, видимо, тщательно отбирал . S>Да через раз. Отбирал их не я — отбирали авторы учебного курса на MBA.
Ссылку хотя бы на одинин источник, пожалуйста.
G>>Правда? Ну расскажи же мне, что же там еще такого есть, в теории менеджмента, чтоб про софтверные метрики (характеризующие software process по своей природе), но при этом ни в коем случае не про этот самый software process. S>Открою тайну: метрики бывают вовсе не софтверные.
Тайну про то, что существуют самые разные числа на совершенно произвольную тему, ты мне открыть опоздал. Это сделала учительница физики в начальных классах средней школы.
А теперь я обращу внимание твое внимание на внезапную и неожиданную вешь, Синклер. Тока ты сядь на всякий случай. А то мало-ли что случится, от неожиданности-то.
Мы в этом форуме о софте говорим. И метрики обуждаем — софтверные. Не горнопрохождческие, станкостроительные, и даже не HR-ные. Не поверишь — но те как на духу говорю — правда. На название форума глянь, если не веришь.
Здравствуйте, AndrewVK, Вы писали:
G>>На давайте теперь обсудим, кто тут под пивом, а кто под водкой.
AVK>Не я первый начал. И на подобные "аргументы" ничего лучше все равно не изобретешь.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Ikemefula, Вы писали:
IT>>>Не совсем так. Говоря обо всём об этом, я имел ввиду конкретный пример из жизни. Так вот в нём дело было даже не во времени, в количестве геморроя. I>>Ты уже в который раз вместо указания конкретных фактов используешь эмоциональную оценку.
IT>Я уже в который раз пытаюсь кое-кому объяснить, что эмоциональная оценка такие же конкретные факты, как и всё остальное.
Здравствуйте, IT, Вы писали:
IT>>>Не совсем так. Говоря обо всём об этом, я имел ввиду конкретный пример из жизни. Так вот в нём дело было даже не во времени, в количестве геморроя. I>>Ты уже в который раз вместо указания конкретных фактов используешь эмоциональную оценку.
IT>Я уже в который раз пытаюсь кое-кому объяснить, что эмоциональная оценка такие же конкретные факты, как и всё остальное.
Это для тебя она конкретный факт. А для других это эмоциональная оценка. Вполне возможно даже, что та активность которую ты назвал геморроем, кому то будет очень даже нравиться.
Здравствуйте, Gaperton, Вы писали:
I>>>>Автор статьи в этом треде не раз и не два прокололся. А иногда возникает ощущение что он под пивом
AVK>>>У меня ощущение, что под пивом или чем то еще в этом требе как раз ты.
I>>Ты сильно погорячился. А проколы автора вобщем то четко обозначены.
G>Не. ты от ответа не уходи. Ты под пивом или под водкой?
В данном топике все мессаги от меня написаны на трезвую голову.
G>Вот у меня лично сложный состав. В основе — Jack Daniels + Сибирская Корона + Хугарден.
Джек Дениэлс считаю, можно пить только в чистом виде без пива и всякой дряни.
Это не ответ на пост, а вопрос как последнему запостившемуся.
Вопрос, мелкий но конкретный.
Если функция должна вернуть 2-3 параметра как лучше сделать, через out, через Tuple, или дополнительно объявить структуру?
В отрыве от контекста, окружающего кода, может и нет приемуществ ни у одного варианта.
Поэтому вопрос скорее такой, какие факторы полияют выбор ? Т.е. что может повлиять на то что один вариант станет предпочтительнее, какие особенности окружающего кода надо учитывать.
Большой ли список факторов получится?
Вопросы о производительности(выделение динамической памяти на tuple) проигнорируем
3 Варианта:
void Func(out Type1 Name1, out Type2 Name2){...
Здравствуйте, Silver_s, Вы писали:
S_>Вопрос, мелкий но конкретный.
Вопрос вобще говоря не мелкий, про такое написаны целые книги
S_>Если функция должна вернуть 2-3 параметра как лучше сделать, через out, через Tuple, или дополнительно объявить структуру?
out требует понимания указателей, что вобщем то странно ожидать от любого
Туплы идея неплохая, но это жОсткое ограничение если встречается в публичном апи
Структура или класс решает вопрос но количество таких структур снова становится жостким ограничением
есть еще вариант, преобразовать функцию в класс, здесь тоже есть нюансы
S_>Большой ли список факторов получится?
Навскидку, вот
1 как именно будут использоваться возвращаемые значения
2 уровень команды
3 кто будет использовать кроме команды
4 уровень тех кто это будет использовать
5 какие языки будут использоваться
а для внутреннего использования
б для внешнего
6 насколько часто будут использоваться подобные функции
Соответственно, если функция в публичном АПИ, к которому имеют доступ самые разные люди, использовать будут самые разные языки как внутри проекта так и вне, то вариантов не остается — решением будет инстанс конкретного класса или функция преобразованая в класс.
Здравствуйте, Ikemefula, Вы писали:
I>Навскидку, вот I>1 как именно будут использоваться возвращаемые значения I>2 уровень команды I>3 кто будет использовать кроме команды I>4 уровень тех кто это будет использовать I>5 какие языки будут использоваться I> а для внутреннего использования I> б для внешнего I>6 насколько часто будут использоваться подобные функции
А если бы мы задались целью в цифрах это оценить. Состряпать алгоритм чтоб выдавал предпочтительность варианта, или хоть что-то хоть немного похожее на правду. Практической пользы от такого алгоритма может бы и не было, но хотя бы посмотреть насколько все запутано (какую-то сложность, читабельность).
Список уже большой, если пункты начать раскрывать еще вложенные списки полезут.
Там всякие мелочи. Например в Tuple безымянные поля, в остальных вариантах именнованые. v.First может быть хуже чем внятное Name1.
Если забудешь что закреплено за первым элементом, прийдется лезть читать коментарии к функции, что она в Tuple возвращает.
А комментарий еще надо написать, если его нет прийдется читать функцию, что гораздо сложнее.
Но если код так организован что область видимости функции очень маленькая, и читая места ее использования все равно и функцию прийдется прочитать. Тогда недостатки от безымянности уменьшаются.
Если структуру создашь, то как минимум еще одна сущность будет глаза мозолить. Глядя на нее может быть непонятно где она используется, только для возврата из одной функции или где-то еще. Кроме того для нее может оказаться сложно придумать название, т.к. по смыслу два возвращаемых параметра не обязательно сильно сцеплены. Читабельность кода может и снизиться когда везде разбросаны всякие небольшие структурки с невнятными названиями, с невнятной областью видимости. Когда реальная область видимости/действия очень маленькая, а кажущаяся чуть ли не весь проект. Чтобы это узнать еще прийдется тулзы запускать для поиска использований. (Например сменишь поле с double на int, если не выскочит ошибка это еще не значит что ее никто не использует в другом месте, и может где-то что-то отвалится)
Здравствуйте, Silver_s, Вы писали:
S_> Список уже большой, если пункты начать раскрывать еще вложенные списки полезут. S_>Там всякие мелочи. Например в Tuple безымянные поля, в остальных вариантах именнованые. v.First может быть хуже чем внятное Name1. S_>Если забудешь что закреплено за первым элементом, прийдется лезть читать коментарии к функции, что она в Tuple возвращает. S_>А комментарий еще надо написать, если его нет прийдется читать функцию, что гораздо сложнее. S_>Но если код так организован что область видимости функции очень маленькая, и читая места ее использования все равно и функцию прийдется прочитать. Тогда недостатки от безымянности уменьшаются.
Тупл без механизмов распаковки (ПМ или хотя бы питоновский sequence unpacking) — чемодан без ручки.
Здравствуйте, Silver_s, Вы писали:
S_> А если бы мы задались целью в цифрах это оценить. Состряпать алгоритм чтоб выдавал предпочтительность варианта, или хоть что-то хоть немного похожее на правду. Практической пользы от такого алгоритма может бы и не было, но хотя бы посмотреть насколько все запутано (какую-то сложность, читабельность).
Для алгоритма нужно снять более менее толковые данные.
Практическая польза такого алгоритма просто адская — это вобщем то получится алгоритм принятия решения
S_> Список уже большой, если пункты начать раскрывать еще вложенные списки полезут.
Разумеется. Я только основные пункты указал. Раскрывать их можно до бесконечности
Здравствуйте, Gaperton, Вы писали:
G>>>Но это не главное. Главное, что ты, наконец, не уследил за собой, и нечаянно охарактеризовал "сложность" через время и трудозатраты, связанные с внесением правки. IT>>Не совсем так. Говоря обо всём об этом, я имел ввиду конкретный пример из жизни. Так вот в нём дело было даже не во времени, в количестве геморроя. Если интересно могу об этом случае рассказать подробнее. G>Валяй, расскажи. Не вижу причин, почему нет — на конкретику всегда полезно перейти. Будет интересно.
Ага. Ну так вот. Есть у нас одно приложение, которое можно охарактеризовать как data driven application. В общем, пользователи заливают в него свои данные, а оно их как-то там процессит, переливает из пустого в порожнее, объединяет, разъединяет, генерирует, группирует, агрегирует и т.д. Алгоритмы и методологии процессинга весьма разнообразны, так же как и разнообразны средства и способы, с помощью которых они реализованы. Есть среди этих средств в том числе и SQL скрипты, наборы сохранённых процедур, которые занимаются тем, что в зависимости от введённых пользователем данных, динамически создают и выполняют наборы SQL комманд.
Эти скрипты работают как надо и давно отлажены. Единственная проблема — иногда приходится разбираться с тем, что они там, как и зачем понагенерировали. Как правило наши пользователи сами в состоянии разобраться со своими данными, но иногда они попадают в затруднительные ситуации и нам приходится им помогать искать концы. Иногда приходится разбираться с производительностью сгенерированного SQL. Нормальные средства отладки в Sybase отсутствуют, самым доступным средством является команда SELECT xxx, да и с ней проблемы, например, DBArtizan обрезает отображаемые строки до 256 символов, а наш результирующий SQL может легко составлять несколько килобайт. Ещё Sybase теряет контекст вызова, если исользовать команду Execute. Т.е. в случае вылета мы не знаем даже какая из сохранённых процедур дала дуба. В общем, каждый раз фан по полной программе.
Сейчас это всё переписано на C# и проблема как-то сама собой исчезла. Разбираться с данными и запросами всё ещё приходится, но теперь это на порядок быстрее. Фактически время тратится только на анализ самой проблемы, а не на получение данных для анализа, как это было раньше.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Gaperton, Вы писали:
IT>>Я уже в который раз пытаюсь кое-кому объяснить, что эмоциональная оценка такие же конкретные факты, как и всё остальное. G>Почитай, что мы, менеджеры, пишем про эмоциональную оценку. Будет интересно. Примерь на себя. G>http://gaperton.livejournal.com/50685.html
Всё правильно. Я бы только ещё добавил категорию задач, которые являются заведомо геморройными и тогда картина будет полной.
G>Hint: некоторые из нас, менеджеров, не боятся "грязной работы", и иногда устраивают себе испытание: заставляют себя тряхнуть стариной, и в полный рост кодить. Из принципа, чтобы не отрываться от реальности. Редкость, но бывает, ага. И тогда появляются такие статьи.
Молодца! Мой босс тоже периодически тренирует польчики, чтобы не забыть как код писать
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas, Вы писали:
IT>>>>Не совсем так. Говоря обо всём об этом, я имел ввиду конкретный пример из жизни. Так вот в нём дело было даже не во времени, в количестве геморроя. I>>>Ты уже в который раз вместо указания конкретных фактов используешь эмоциональную оценку.
IT>>Я уже в который раз пытаюсь кое-кому объяснить, что эмоциональная оценка такие же конкретные факты, как и всё остальное.
G>Сложной от эмоций не зависит.
Если рассматривать отношение метрик объем/время как характеристику сложности, то совершенно объективно — сложность зависит от эмоций. И иногда — очень сильно. http://gaperton.livejournal.com/50685.html
А вот если не рассматривать — то можно вообще что угодно говорить. Метафизика.
Здравствуйте, IT, Вы писали:
IT>>>Я уже в который раз пытаюсь кое-кому объяснить, что эмоциональная оценка такие же конкретные факты, как и всё остальное. G>>Почитай, что мы, менеджеры, пишем про эмоциональную оценку. Будет интересно. Примерь на себя. G>>http://gaperton.livejournal.com/50685.html
IT>Всё правильно. Я бы только ещё добавил категорию задач, которые являются заведомо геморройными и тогда картина будет полной.
Здравствуйте, IT, Вы писали:
G>>Hint: некоторые из нас, менеджеров, не боятся "грязной работы", и иногда устраивают себе испытание: заставляют себя тряхнуть стариной, и в полный рост кодить. Из принципа, чтобы не отрываться от реальности. Редкость, но бывает, ага. И тогда появляются такие статьи.
IT>Молодца! Мой босс тоже периодически тренирует польчики, чтобы не забыть как код писать
Ну, тебе тоже надо иногда руководить . Не менее полезно для познания реальности во всех ее гранях.
А реальность такова, что планирование — это та же самая инженерная работа. Нет в менеджерской работе ничего менеджерского, чуждого инженерам. План — это архитектура/дизайн, растянутые во времени.
Огромный плюс советской конструкторской школы в том, что в ней это никогда не ставилось под сомнение.
Здравствуйте, IT, Вы писали:
G>>>>Но это не главное. Главное, что ты, наконец, не уследил за собой, и нечаянно охарактеризовал "сложность" через время и трудозатраты, связанные с внесением правки. IT>>>Не совсем так. Говоря обо всём об этом, я имел ввиду конкретный пример из жизни. Так вот в нём дело было даже не во времени, в количестве геморроя. Если интересно могу об этом случае рассказать подробнее.
Это оставляем, чтобы не забыть, зачем.
G>>Валяй, расскажи. Не вижу причин, почему нет — на конкретику всегда полезно перейти. Будет интересно.
IT>Ага. Ну так вот. Есть у нас одно приложение, которое можно охарактеризовать как data driven application. В общем, пользователи заливают в него свои данные, а оно их как-то там процессит, переливает из пустого в порожнее, объединяет, разъединяет, генерирует, группирует, агрегирует и т.д. Алгоритмы и методологии процессинга весьма разнообразны, так же как и разнообразны средства и способы, с помощью которых они реализованы. Есть среди этих средств в том числе и SQL скрипты, наборы сохранённых процедур, которые занимаются тем, что в зависимости от введённых пользователем данных, динамически создают и выполняют наборы SQL комманд.
Ясно.
IT>Эти скрипты работают как надо и давно отлажены. Единственная проблема — иногда приходится разбираться с тем, что они там, как и зачем понагенерировали. Как правило наши пользователи сами в состоянии разобраться со своими данными, но иногда они попадают в затруднительные ситуации и нам приходится им помогать искать концы. Иногда приходится разбираться с производительностью сгенерированного SQL. Нормальные средства отладки в Sybase отсутствуют, самым доступным средством является команда SELECT xxx, да и с ней проблемы, например, DBArtizan обрезает отображаемые строки до 256 символов, а наш результирующий SQL может легко составлять несколько килобайт. Ещё Sybase теряет контекст вызова, если исользовать команду Execute. Т.е. в случае вылета мы не знаем даже какая из сохранённых процедур дала дуба. В общем, каждый раз фан по полной программе.
Другими словами, мы как правило имеем в этот в целом прекрасно работающий код дорогую правку. Будь то дефект, или фича.
Но ты говоришь про повышенную цену выполнения сервисных запросов класса "Investigation", которые вовсе не обязательно приводят к правке — разве что если в процессе разбирательств ты дефект найдешь.
Это конечно, уже никакая не правка, но вполне укладывается в "затраты на поддержку и сопровождение". Совсем небольшое обобщение. Спасибо, учту. Я чуть более чем это требуется сузил класс затрат времени, привязав его к внесению правок.
Можно пытаться выделять отдельные статьи трат времени (и связанной с этим сложности), например, reverse engineering (результат деятельности — понимание), и перечислять их. А можно несколько обобщить до "трат времени, связанных с кодом".
В целом, если разобрать основные траты времени, специфичные для существующего кода, их будет не так много:
1) Затраты на диагностику проблем/разбор ситуаций — понимание, почему именно оно так работает в конкретном случае. Это, по сути, восстановление "детального дизайна".
2) Затраты на reverse engineering (понимание, как оно в целом устроено и работает. "дизайн"+"детальный дизайн").
3) Затраты на рефакторинг (изменение без добавления/изменения функциональности, но, возможно, с одновременным исправлением дефектов).
И все. Каждая трата может быть измерена. Это не означает, что ее надо секундомером измерять — но означает:
— что ее легко интуитивно оценить.
— это можно сравнивать.
— разные люди одинаково поймут.
Привязка твоего классификатора сложности к объективно измеримым вещам только выиграет от этого.
"Классификатор ошибок" в этом деле играет фундаментальную роль. Почему. Каждому типу ошибки соответствует определенный класс технических решений, которые ты можешь принять. И в любом решении ты можешь ошибиться — это отличительная характеристика решения. То есть, не может быть технического решения без возможности ошибки, и ошибки без стоящего за ней технического решения.
Описываемая тобой "сложность" может быть объективно наблюдаема (иметь вполне конкретные наблюдаемые последствия) через совокупность данных по ошибкам, времени, и объему. Что, в общем, совсем не плохо, разве нет? Это дополнительный факт, который может (если его не игнорировать) нам много чего дать.
IT>Сейчас это всё переписано на C# и проблема как-то сама собой исчезла. Разбираться с данными и запросами всё ещё приходится, но теперь это на порядок быстрее. Фактически время тратится только на анализ самой проблемы, а не на получение данных для анализа, как это было раньше.
То есть, в результате переписывания, ты уменьшил стоимость сопровождения этого кода. Ну, отлично .
Если бы тебе не приходилось на этот работающий код времени тратить, ты бы не стал его трогать, правильно?
Здравствуйте, Ikemefula, Вы писали:
G>>Не. ты от ответа не уходи. Ты под пивом или под водкой?
I>В данном топике все мессаги от меня написаны на трезвую голову.
То есть, ты будучи в трезвом уме и сознании взялся комментить в "философию программирования"?
G>>Вот у меня лично сложный состав. В основе — Jack Daniels + Сибирская Корона + Хугарден.
I>Джек Дениэлс считаю, можно пить только в чистом виде без пива и всякой дряни.
Вот за что я люблю РСДН. Не забалуешь тут. Зайдешь в философию выпимши — так тебе до кучи еще и объяснят, что ты и пьешь-то неправильно .
Здравствуйте, IT, Вы писали:
G>>Ну вот уже напрашиваются метрики: время выполнения и количество багов. Причем не важны абсолютные цифры, важно что ты можешь подходы упорядочить по этим метрикам.
IT>Как можно упорядочить баги, если один является орфографической ошибкой в строке и требует 2 секунды на фикс, а другой является следствием архитектурной ошибки и требует для фикса переписать 2/3 приложения?
Да так и упорядочивают — по виду технического решения, в котором найдена бага.
0) Требования. Ошибочные предстваления о том, что надо сделать.
1) Архитектурная. Неверный выбор базовых технологий и/или общих принципов построения системы.
2) Дизайн. "Структурная" ошибка. Неверная нарезка функциональности на компоненты.
3) Детальный дизайн. Ошибка в алгоритмах или структурах данных.
4) Кодирование. Здесь понятно.
Понятно также, что чем выше уровнем техническое решение, тем дороже ошибка.
Среднее время фикса, посчитанное для каждого класса (включая все связанные с разработкой фикса затраты), будет убывать по мере продвижения по списку. Это и есть "стоимость ошибки".
Наблюдается также еще одна весьма любопытная статистическая закономерность. В целом, время (затраты) на фикс (включая диагностику ошибки, разработку решения, и вообще все связанные затраты) коррелирует со временем, прошедшим с момента внесения ошибки, до ее обнаружения.
То есть, "старые" ошибки обходятся дороже, чем новые. Исходя из этого, процесс разработки будет недурно построить таким образом, чтобы те же самые ошибки находились пораньше. В этом и состоит смысл внедрения код и дизайн ревью.
Точно так же, если большой проблемы с ценой и количеством ошибок у нас по факту нет (что измеримо) — то нет большого смысла вводить и ревью. Или, скажем, если наши ревью не позволяют находить ошибок — то они в таком виде не сильно-то и нужны.
Здравствуйте, IT, Вы писали:
G>>Ну так поробуй формализовать понятия "не делать ошибок" и "заведомо плохие варианты", получишь те самые метрики.
IT>Я не знаю как формализуются понятия "не делать ошибок" и "заведомо плохие варианты".
"Не делать ошибок" — вносить поменьше ошибок. "Заведомо плохие варианты" — варианты, которые придется в будущем затратно исправлять, и эти проблемы в состоянии определить design review.
G>>Любое планирование будет метафизикой если не использовать метрики.
IT>Вообще-то речь не о планировании, а о выборе наиболее оптимального варианта.
Если выбор твоего варианта определяет дальнейшие действия (как например, архитектурные и "дизайнерские" технические решения), то это и есть по своей сути планирование. Ибо, при выборе ты должен учитывать эти самые дальнейшие действия.
Планирование вообще неразрывно связано с архитектурной работой.
Здравствуйте, Gaperton, Вы писали:
IT>>Вообще-то речь не о планировании, а о выборе наиболее оптимального варианта.
G>Если выбор твоего варианта определяет дальнейшие действия (как например, архитектурные и "дизайнерские" технические решения), то это и есть по своей сути планирование. Ибо, при выборе ты должен учитывать эти самые дальнейшие действия.
G>Планирование вообще неразрывно связано с архитектурной работой.
Вообще, меня не перестает изумлять, до какой степени упорно инженеры, занимаясь планированием каждый день, любят от этого дистанцироваться, называя планирование "менеджерской работой".
Я случай расскажу.
Однажды одному разработчику фокус показал. Сначала, я спросил его прогноз сроков по его проекту. Он сказал — полгода. Потом, я предложил ему обсудить подход в этом проекте, который определяет план. Он ответил, что планы должен составлять менеджер, а подходы — это их, инженеров дело.
Хорошо, сказал я, и попросил его написать список задач в экселе, из которых я сделаю план. Он написал.
Потом, я попросил его оценить сроки каждой задаче в днях. Разработчик сказал, что это невозможно. Тогда, я предложил ему ответить для каждой задачи на пару вопросов — "точно не справлюсь" — "успею с запасом". Он сделал и это.
После этого, я загнал эту сотню задач в MS Project, и ввел туда среднюю оценку. Выполнил шедулинг, и позвал разработчика посмотреть на результат.
— Че мне смотреть, это ж ваше, менеджерское — планы?
— Да все бы ничего, да вот только мне мой менеджерский план показывает, что ты не успеешь за полгода. В лучшем случае — полтора.
— Как это?!
— Вот, смотри. Я ничего не выдумал — взял твои задачи, и твои оценки. Все остальное — MS Project. Ты ведь уверен в своих оценках?
— Уверен.
— Ну вот я тебе говорю — если сейчас не изменить технический подход к решению, то это полтора года. Ты ведь понимаешь, что результат этого проекта ценой в полтора года никому не нужен?
— Конечно.
— Так что будем делать, дружище? Закрывать проект, или вместе подумаем, как изменить подход?
И вы знаете — как-то ВНЕЗАПНО план перестал быть "нашим менеджерским", и оторванным от проектирования и технических решений .
ЗЫ: В этой компании сроки регулярно в 10 раз срывались — обычное дело. Там мне директор задачу поставил при найме — сократить underestimate в группе разработки до двух раз. Лекарство и одну из причин "болезни" вы видите.
Здравствуйте, Silver_s, Вы писали:
G>>Составил план работ. Нарисовал кривую — общее количество (нарастающим итогом) закрытых задач понедельно, на основании плана. И каждую неделю наносишь на этот же график новую точку фактической кривой — с общим количеством фактически закрытых задач. S_>... G>>Я тебе простейший вариант планирования с учетом метрик дал. Есть другие.
S_>Планирования чего? Архитекутры приложения, или уровня загруженности конвеера(массива разработчиков), с целью уменьшения простоев и слабых мест.
В разработке ПО архитектура и прочие высокоуровневые технические решения оказывают определяющее влияние на план работ.
Также, в разработке софта указанный тобой "конвейерный эффект" мизерный, и возникает настолько редко, что этим в большинстве ситуаций можно пренебречь. И пренебрегают.
S_>А если надо определиться в том что использовать WPF или WinForms. Или боле того, надо писать подобную библиотеку. Какую архитектуру выбрать как у WinForms или как WPF. Планирование уровня загруженности разработчиков уже будет недостаточно?
В представленной схеме вопросы "шедулинга" и уровня загруженности разработчиков оставлены за кадром, что, в общем, сложно не заметить.
А вот выбор базовых технологий — имеет настолько серьезные последствия, и настолько сильно повлияет на все планы, что не принимать во внимание влияние на будущее (т.е. планы не только текущих, но и будущих работ), делая этот выбор, будет клиническим идиотизмом.
Почему бывает, что на практике этот выбор и не предоставляют делать кому попало, и настолько часто, насколько этому кому-попало хочется.
Здравствуйте, Silver_s, Вы писали:
G>>Ты откуда планирование загруженности взял? S_>Там было про график работ, распределение задач, оценку производительности, управление сроками.
Там не было про распределение задач и планирование загруженности. Из чего следует, что ты не читал, что там было.
S_>А если это все неактуально, а нужно в первую очередь узнать нужно ли вобще такую-то задачу решать, или лучше совсем другую.
Если "это все" для принимающего решения, имеющие далеко идущие последствия, не актуально, то ему следует поискать другую работу.
Здравствуйте, Silver_s, Вы писали:
I>>Вообще говоря дело именно в том, сколько ошибок на единицу кода делает основная масса программистов. I>>Косяки и возможности фреймворков — это уже второстепенное.
S_> Неправильный выбор фреймворка или библиотеки, или крупные архитектурные ошибки, это к тем же ошибкам причисляется о которых идет речь? Или механические ошибки-описки имеются ввиду?
Разумеется — да. И ошибочное представление о требованиях также причисляется к ошибкам. Или ты думаешь, что в технических решениях ты никогда не ошибаешься, только механические описки допускаешь?
Ошибочный (неоптимальный) выбор фрейморка (базовых технологий) сейчас, может сделать невероятно затратным реализацию ключевых требований потом, или ограничить принципиальные возможности. Повлияв, таким образом, не только на текущий "план", но и на все последующие.
Поэтому, к выбору базовых технологий надо относиться серьезно, обязательно делать это группой, и, для начала, как минимум, согласиться насчет критериев выбора этих самых базовых технологий, что уже веха в плане. Далее — можно рассмотреть несколько кандидатов, отобрать из них парочку наилучших, и их уже пустить в детальную проработку с разработкой "эскизного проекта", PoC прототипов, и — планов дальнейших работ. После чего уже — можно сделать аргументированный выбор.
Заметь, я уже набросал некий план, т.е. подход к проведению организованного исследования. Впрочем, ничего особо не выдумывал — это распространенный "паттерн" планирования в советской конструкторской школе при проведении НИОКР.
План — это что именно и в каком порядке ты собираешься делать, и каким образом проверять, что таки сделал. Качество плана вообще — показывает, насколько осмысленно ты подходишь к своей работе. Если он для тебя — абстрактная хрень, сводящаяся к оптимизации конвейера — ну тут, собственно, "nuff said". Это можно позволить себе работая индивидуально. Но для работы группы с мало-мальски нормальным КПД — требуется согласованность и целенаправленность действий. Для чего и нужен план.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, gandjustas, Вы писали:
IT>>>>>Не совсем так. Говоря обо всём об этом, я имел ввиду конкретный пример из жизни. Так вот в нём дело было даже не во времени, в количестве геморроя. I>>>>Ты уже в который раз вместо указания конкретных фактов используешь эмоциональную оценку.
IT>>>Я уже в который раз пытаюсь кое-кому объяснить, что эмоциональная оценка такие же конкретные факты, как и всё остальное.
G>>Сложной от эмоций не зависит.
G>Если рассматривать отношение метрик объем/время как характеристику сложности, то совершенно объективно — сложность зависит от эмоций. И иногда — очень сильно. G>http://gaperton.livejournal.com/50685.html
G>А вот если не рассматривать — то можно вообще что угодно говорить. Метафизика.
А разве мы еще не договорились считать сложность неким "объективным фактором", а не трудозатратами (которые вообще дофига от чего зависят)?
Здравствуйте, gandjustas, Вы писали:
G>>А вот если не рассматривать — то можно вообще что угодно говорить. Метафизика.
G>А разве мы еще не договорились считать сложность неким "объективным фактором", а не трудозатратами (которые вообще дофига от чего зависят)?
Вобще говоря есть такой момент, многие гроссы, имеется ввиду шахматисты или игроки в настольных играх такого же уровня, очень часто не могут внятно объяснить свое видение позиции в партии.
В книгах, статьях, используют не конкретные проверяемые утверждения, а какой то эмоциональный бред.
Вот, по памяти: "этот ход однозначно вялый. Запомните — вы так никогда играть не будете !".
Про тот же ход "цель этого хода — не дать никакой помощи противнику".
И только редкие игроки того же уровня, их буквально единицы, суровые методисты, про тот же ход пишут достаточно скучкно, приводят варианты, где эмоциональные оценки отсутсвуют, комантарии примерно такие "цель хода — избежать локальной борьбы и форсированых вариантов(варианты указаны)".
Правда и те и другие и третьи во сложных(для них) позициях, используют именно интуитивные оценки "чуть-чуть", "неудобно", "туманно", "слабо".
Кроме того, некоторые в комментариях заходят еще дальше — буквально рассказывают, что происходит в партии, как в анекдоте
"- Где мы находимся, Холмс ?
— В воздушном шаре, Ватсон !"
Кстати, сейчас вспомнил. У этой истории было смешное продолжение. Проект я таки в результате закрыл. А дело было так.
Сначала, поработав над подходом, мы сократили затраты на этот проект втрое. Удалось это сделать благодаря тому, что инженер взял себя в руки, и отказался от "переписывания всего-превсего", и разбиению этого переписывания на итерации, результат каждой из которых фиксируется в репозитории.
Это что-то вроде lazy evaluation. Мы выписываем фичлист, и проектируем минимальную правку, с серией мостов, откладывая "полный рефакторинг" на те моменты, когда в соответствующую подсистему будет реально нужна какая-нить правка.
Так вот, когда я выписывал для этого проекта фичлист, он оказался, к моему удивлению, весьма небольшим. В основном, это было две полезных фичи — поддержка кнопок Hold и Transfer на IP-телефоне.
Ну ладно. И вот, однажды к нам зашли сейлзы, и стали чуть не на коленях умолять — так или иначе дать возможность перевода звонка с терминала в IP-АТС. У них клиент был с DECT-трубками, хотел IP-коллцентр, и отказывался без этих элементарных фич брать продукт.
Наши орлы говорят — нет, грят, низя, дождитесь мегапроекта. Тут я решил вмешаться.
— Парни, — говорю, — так на DECT-телефонах все равно ведь нет кнопок Hold и Transfer.
— Ну? — говорят разработчики.
— Так и на обычных телефонах их тоже нет. Но с обычными-то телефонами у нас все работает! Расскажите, как.
Парни рассказали, что на то в обычных телефонах есть кнопка Flash, но этой кнопки нет в IP-телефонах. Поэтому, в IP-версии данный код тупо выключен.
— Отлично, — говорю, — давайте эмулировать Flash даблкликом звездочки. Сейлзы, вас это устроит?
Сейлзы на все готовы. Да, грят, нам хоть как.
— Скока, — говорю, — времени надо, чтобы это сделать?
— Да дня два, — говорят инженеры.
И мы сделали. После чего я смотрю, и совсем не понимаю, нахрена нам тратить полгода на кнопки Hold и Transfer. Особенно, когда в бэклоге висит ряд других фич, из-за отсутствия которых недавно был проигран тендер Циске.
Как нибудь в другой раз, короче. Так и закрыли нафиг.
Здравствуйте, Gaperton, Вы писали:
G>Почитай, что мы, менеджеры, пишем про эмоциональную оценку. Будет интересно. Примерь на себя. G>http://gaperton.livejournal.com/50685.html G>Hint: некоторые из нас, менеджеров, не боятся "грязной работы", и иногда устраивают себе испытание: заставляют себя тряхнуть стариной, и в полный рост кодить. Из принципа, чтобы не отрываться от реальности. Редкость, но бывает, ага. И тогда появляются такие статьи.
Насчет классификации проблем вот тут http://kapterev.livejournal.com/496630.html есть интересный график
То есть по мнению психологов "интересные проблемы" хорошо вознаграждаются на физиологическом уровне — состоянием потока.
Хорошо..... Кажется, мой поток мыслей на сегодня иссяк. И этому я тоже рад: выходить из потока – полезный навык.
График на ту же тему. Но моя классификация, вообще-то, лучше. Она куда более специфична, информативна, и при этом ощущается человеком непосредственно, без рассуждений (не надо ничего иллюстрировать). И даже через метрики наблюдаема, и имеет прямую связь с техниками риск-менеджмента . То есть, легко интегрируется в работу. Ей легко воспользоваться на практике, этим графиком — нет. А понимание требуется для действия. Ни для чего другого.
FR>То есть по мнению психологов "интересные проблемы" хорошо вознаграждаются на физиологическом уровне — состоянием потока.
Я бы не сказал, что состояние "потока" само по себе является вознаграждением. Это далеко не элементарное состояние, и оно слишком сложное, чтобы непосредственно участвовать в цепочке стимул-реакция.
Вознаграждением является удовлетворение от решения каждой отдельной проблемы и задачи. Для "понятной" проблемы оно слишком слабо, для "принципиальной" — слишком нерегулярно и редко случается, пока его получишь — успеешь отчаяться. И на подпроблемы не всегда удается сходу побить, чтобы словить кайф на них.
Само состояние "потока" — это далеко не элементарный процесс непрерывного получения значимого вознаграждения. То есть, производное, сложное состояние. И оно не является устойчивым состоянием.
И вообще — по употреблению характерных слов вроде "картируется", становится ясно, что по ссылке не психологи, а мимикрирующие под них нлпсты . А это очень большая разница. Бросьте каку.
Читать надо гештальтистов и бихейвиористов. Это гораздо сложнее, но — и "вознаграждение" гораздо больше. Описанием творческой деятельности, озарений, и свободно перетекающего внимания занимается гештальт, стимул-реакциями — бихейвиористика.
Здравствуйте, gandjustas, Вы писали:
G>>Если рассматривать отношение метрик объем/время как характеристику сложности, то совершенно объективно — сложность зависит от эмоций. И иногда — очень сильно. G>>http://gaperton.livejournal.com/50685.html
G>>А вот если не рассматривать — то можно вообще что угодно говорить. Метафизика.
G>А разве мы еще не договорились считать сложность неким "объективным фактором", а не трудозатратами (которые вообще дофига от чего зависят)?
Черт его знает, наверное это без меня было .
"Сложность" — это не фактор, а интуитивная, субъективная интегральная оценка "геморройности". Выделять объективные факторы, которые на эту оценку влияют, можно.
Считать же саму "сложность" объективным фактором, очевидно нельзя. Начать можно с того, что "сложность" не элементарная характеристика, а результат многофакторной оценки. И продолжить тем, что находясь в разном эмоционально-психическом состоянии человек по разному оценивает "сложность" одной и той же задачи, по разному расставляя "веса" в своей формуле. Военным это хорошо знакомо — они учитывают как фактор "боевой дух", и его влияние оценивается некоторыми специалистами чуть ли не как 3:1 ко всем прочим.
Здравствуйте, Gaperton, Вы писали:
G>"Сложность" — это не фактор, а интуитивная, субъективная интегральная оценка "геморройности".
При всем при том, эта самая сложность коррелирует с объективно измеримым отношением "время/объем". Которое называется не "сложностью", а "продуктивностью". И косвенно характеризуется этим соотношением.
Не, ну можно было бы сказать "вы программеры, ничего в сложности не понимаете, мы лучше знаем, что это за слово такое и что оно означает". Но это было бы чепухой. Смысл слова лучше оставить фактический, такой, какой он есть по частоте употребления .
Здравствуйте, Gaperton, Вы писали:
G>График на ту же тему. Но моя классификация, вообще-то, лучше. Она куда более специфична, информативна, и при этом ощущается человеком непосредственно, без рассуждений (не надо ничего иллюстрировать). И даже через метрики наблюдаема, и имеет прямую связь с техниками риск-менеджмента . То есть, легко интегрируется в работу. Ей легко воспользоваться на практике, этим графиком — нет. А понимание требуется для действия. Ни для чего другого.
Угу лучше. Но если переживал поток график вызывает сильный эмоциональный отклик
FR>>То есть по мнению психологов "интересные проблемы" хорошо вознаграждаются на физиологическом уровне — состоянием потока.
G>Я бы не сказал, что состояние "потока" само по себе является вознаграждением. Это далеко не элементарное состояние, и оно слишком сложное, чтобы непосредственно участвовать в цепочке стимул-реакция.
Физиологи практически установили что
Особенность лиц, имевших признаки состояния «потока» состояла в значительно меньшей физиологической цене деятельности.
Так что награда есть и вполне осязаемая, кто испытывал "второе дыхание" сразу поймет
G>Вознаграждением является удовлетворение от решения каждой отдельной проблемы и задачи. Для "понятной" проблемы оно слишком слабо, для "принципиальной" — слишком нерегулярно и редко случается, пока его получишь — успеешь отчаяться. И на подпроблемы не всегда удается сходу побить, чтобы словить кайф на них.
G>Само состояние "потока" — это далеко не элементарный процесс непрерывного получения значимого вознаграждения. То есть, производное, сложное состояние. И оно не является устойчивым состоянием.
Да это конечно комплексное состояние, мне кажется оно сейчас просто позабыто и во многом атрофировалось, но вполне могло играть
гораздо большую роль в ранних стадиях развития человечества.
А так да положится на него особо не получится.
G>И вообще — по употреблению характерных слов вроде "картируется", становится ясно, что по ссылке не психологи, а мимикрирующие под них нлпсты . А это очень большая разница. Бросьте каку.
По моему все психологи немного шаралатаны
G>Читать надо гештальтистов и бихейвиористов. Это гораздо сложнее, но — и "вознаграждение" гораздо больше. Описанием творческой деятельности, озарений, и свободно перетекающего внимания занимается гештальт, стимул-реакциями — бихейвиористика.
Гештальт да вещь хорошая, а бихевиоризм во многом как раз самая кака и есть, ну бестолково такие сложные вещи изучать методом черного ящика,
лучше уж физиологов почитать, к примеру того же Бернштейна у него хоть вполне рабочие модели подкрепленные фактами.
Здравствуйте, Gaperton, Вы писали:
G>Считать же саму "сложность" объективным фактором, очевидно нельзя. Начать можно с того, что "сложность" не элементарная характеристика, а результат многофакторной оценки.
Если из этих факторов убрать эмоциональные что получится?
Здравствуйте, gandjustas, Вы писали:
G>>Считать же саму "сложность" объективным фактором, очевидно нельзя. Начать можно с того, что "сложность" не элементарная характеристика, а результат многофакторной оценки. G>Если из этих факторов убрать эмоциональные что получится?
Зачем их убрать, если они полезны, и их можно учитывать? Для нового кода работает оно примерно так:
Набор объективных фактов -> (логические рассуждения) -> (индивидуальная оценочная функция на базе опыта, "сложность" и эмоции где-то внутри) -> Оценка вариации сроков, объема результата, + эмоциональная оценка "геморройности", которую ты получаешь бесплатно — на халяву. Хочешь ты этого, или нет. Эмоции все равно испытываешь.
Теперь, с предыдущих проектов берешь вариацию время/объем. Эта штука будет колебаться в диапазоне — его, диапазон, ты из истории и берешь.
А далее смотришь — твой запланированный коэффициент время/объем соответствует интуитивной оценке "геморройности", или нет. Если задача кажется тебе "геморройной", а запланированный коэффециент строки кода/час такой, что ты должен колбасить с олимпиадной скоростью (для меня это более 60 строк кода в час), то ты явно где-то в своей оценке ошибся.
И нафига мне такую ценную штуку убирать, которая позволяет технические риски буквально задницей чувствовать?
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, gandjustas, Вы писали:
G>>>Считать же саму "сложность" объективным фактором, очевидно нельзя. Начать можно с того, что "сложность" не элементарная характеристика, а результат многофакторной оценки. G>>Если из этих факторов убрать эмоциональные что получится?
G>Зачем их убрать, если они полезны, и их можно учитывать? Для нового кода работает оно примерно так:
G>Набор объективных фактов -> (логические рассуждения) -> (индивидуальная оценочная функция на базе опыта, "сложность" и эмоции где-то внутри) -> Оценка вариации сроков, объема результата, + эмоциональная оценка "геморройности", которую ты получаешь бесплатно — на халяву. Хочешь ты этого, или нет. Эмоции все равно испытываешь.
G>Теперь, с предыдущих проектов берешь вариацию время/объем. Эта штука будет колебаться в диапазоне — его, диапазон, ты из истории и берешь.
G>А далее смотришь — твой запланированный коэффициент время/объем соответствует интуитивной оценке "геморройности", или нет. Если задача кажется тебе "геморройной", а запланированный коэффециент строки кода/час такой, что ты должен колбасить с олимпиадной скоростью (для меня это более 60 строк кода в час), то ты явно где-то в своей оценке ошибся.
G>И нафига мне такую ценную штуку убирать, которая позволяет технические риски буквально задницей чувствовать?
Это я и так отлично знаю.
Меня интересует другое. "Сложность" существует объективно, вот и хочется понять какие факторы влияют на нее. И как можно бороться с объективной сложностью, чтобы минимизировать итоговые метрики "объем", "время", "плотность ошибок"
Здравствуйте, FR, Вы писали:
FR>Угу лучше. Но если переживал поток график вызывает сильный эмоциональный отклик
Возможно. У меня не вызывает . Хотя закономерность он, безусловно, иллюстрирует наглядно. Ибо график.
FR>>>То есть по мнению психологов "интересные проблемы" хорошо вознаграждаются на физиологическом уровне — состоянием потока.
G>>Я бы не сказал, что состояние "потока" само по себе является вознаграждением. Это далеко не элементарное состояние, и оно слишком сложное, чтобы непосредственно участвовать в цепочке стимул-реакция.
FR>Физиологи практически установили что
FR>
FR>Особенность лиц, имевших признаки состояния «потока» состояла в значительно меньшей физиологической цене деятельности.
Здесь не идет речи о награде. Здесь они нудно описывают наблюдаемые особенности физиологии, не осознаваемые испытуемым, перечисляя установленные ими факты.
Вывод-то вот он:
Причина указанного парадокса прояснилась при изучении ритма и временных характеристик фаз дыхательного цикла. Оказалось, что характер дыхания у выделенной группы лиц имел признаки «связности», вывод о чем можно сделать из значений вариативности дыхательного ритма, которая была более чем в 2 раза ниже, и продолжительности выдоха, которая была на 65–90% выше, при практически прежней частоте дыхания.
Далее, углубившись в анализ ЭЭГ и альфа-ритмов, и накидывая over 9000 умняка, чтобы усыпить бдительность читателя и навести легкий транс, автор статьи ВНЕЗАПНО вдруг говорит:
Таким образом, результаты М. Чиксентмихайи могут быть дополнены еще одним элементом, который может быть использован сознательно для вызывания состояния «потока». Используя терминологию нейро-лингвистического программирования, можно сказать, что связное дыхание служит при этом для «якорения» состояния «потока». Более того, существует реальная возможность создавать физиологические и нейропсихологические предпосылки для вызывания ресурсных, творческих состояний личности – процессы осознанного связного дыхания.
Что представляет собой полный бред, который автор даже не потрудился как-то обосновать. Ибо перед этим он вещал:
Вскоре после этих исследований в русле идей биологической обратной связи были разработаны портативные приборы, осуществляющие стимуляцию мозга через электрические датчики, наушники и светодиоды.
Оказалось возможным навязывание мозгу человека ритмов, характерных для разных состояний сознания. Например, низкий бета-ритм частотой 15 Гц...
G>>Вознаграждением является удовлетворение от решения каждой отдельной проблемы и задачи. Для "понятной" проблемы оно слишком слабо, для "принципиальной" — слишком нерегулярно и редко случается, пока его получишь — успеешь отчаяться. И на подпроблемы не всегда удается сходу побить, чтобы словить кайф на них.
G>>Само состояние "потока" — это далеко не элементарный процесс непрерывного получения значимого вознаграждения. То есть, производное, сложное состояние. И оно не является устойчивым состоянием.
FR>Да это конечно комплексное состояние, мне кажется оно сейчас просто позабыто и во многом атрофировалось, но вполне могло играть FR>гораздо большую роль в ранних стадиях развития человечества. FR>А так да положится на него особо не получится.
Это комплексное состояние, оно неустойчиво, и его нельзя вызвать "якорями" и какими-либо другими заклинаниями. Так же бессмысленно и глупо, как и вызвать ощущение радости от победы.
Вы "полагаетесь" на "ощущение победы", которое дает заряд бодрости и прилив новых сил? Оно "позабыто" и атрофировалось? Может быть, для него нужны сложная психология, и физиологи с аппаратами?
Или для того, чтобы вызвать это ощущение — надо победить, черт бы его побрал?
Так же и для поддержания состояния "потока" нужны не альфа ритмы и особое дыхание. Человек не система веревочек, за которые можно тупо дергать. Нужен набор факторов, поддерживающих спонтанный интерес и свободно перетекающее внимание. Следствием этого являются возбуждение, особенности дыхания, и прочие вещи, которые увлеченно наблюдает автор статьи, делая из бодрый вывод, что "таракан слышит ногами".
"Практика гештальт-терапии", Фриц Перлз, читаем вводные главы, где он про фигуру-фон и основы гештальт-психологии рассказывает. Все понятно будет.
G>>И вообще — по употреблению характерных слов вроде "картируется", становится ясно, что по ссылке не психологи, а мимикрирующие под них нлпсты . А это очень большая разница. Бросьте каку.
FR>По моему все психологи немного шаралатаны
НЛПсты не психологи. Они такие же психологи, как продавцы скрама специалисты по процессам разработки, а продавцы пищевых добавок — фармацевты. НЛП — это инфраструктура по зарабатыванию бабла, а не наука.
G>>Читать надо гештальтистов и бихейвиористов. Это гораздо сложнее, но — и "вознаграждение" гораздо больше. Описанием творческой деятельности, озарений, и свободно перетекающего внимания занимается гештальт, стимул-реакциями — бихейвиористика.
FR>Гештальт да вещь хорошая, а бихевиоризм во многом как раз самая кака и есть, ну бестолково такие сложные вещи изучать методом черного ящика,
С когнитивными психологами бихейвиористов не путаете? Нет у них никакого черного ящика. Методы бихейвиористов основаны на модели психики, в основе которой лежит система условных рефлексов. В частности, "непавловском условном рефлексе". И в своем классе ситуаций бихейвиористика потрясающе эффективна — напоминает магию. НЛПстам не снилось. Собственно, НЛП сдернуло большую часть именно у бихейвиористов, выкинув при этом всю теоретическую базу.
FR>лучше уж физиологов почитать, к примеру того же Бернштейна у него хоть вполне рабочие модели подкрепленные фактами.
Это примерно так же продуктивно, как пытаться реверс-инжинирить оперсистему Windows, копаясь на уровне транзисторов, замера времянок, и спиливания печатной платы по слоям.
Скажем, практический интерес представляет "мышечный панцирь", и, в частности, связь переживания тревожности с неконтроллируемым напряжением диафрагмы. Связь есть, она экспериментально наблюдается, она двухсторонняя, и этим можно пользоваться.
А что там происходит с точки зрения физиологии при переживании тревожности — абсолютно по барабану. Понимание, совершенно лишнее для действия.
Здравствуйте, Gaperton, Вы писали:
IT>>Всё правильно. Я бы только ещё добавил категорию задач, которые являются заведомо геморройными и тогда картина будет полной. G>Как эти задачи отличить от приводимых трех типов?
Отношением к ним.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Gaperton, Вы писали:
IT>>Молодца! Мой босс тоже периодически тренирует польчики, чтобы не забыть как код писать G>Ну, тебе тоже надо иногда руководить . Не менее полезно для познания реальности во всех ее гранях.
Я уже своё отруководил. Лет 6 начальником группы/сектора в одном НИИ, потом 4 года начальником отдела разработки ПО в одной программистской конторе. В целом — не понравилось Руководить людьми не моё.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>>>Всё правильно. Я бы только ещё добавил категорию задач, которые являются заведомо геморройными и тогда картина будет полной. G>>Как эти задачи отличить от приводимых трех типов?
IT>Отношением к ним.
Приведи пожалуйста пример "заведомо геморройной" задачи, не подпадающей ни под один из трех типов.
Здравствуйте, Gaperton, Вы писали:
G>В целом, если разобрать основные траты времени, специфичные для существующего кода, их будет не так много: G>1) Затраты на диагностику проблем/разбор ситуаций — понимание, почему именно оно так работает в конкретном случае. Это, по сути, восстановление "детального дизайна". G>2) Затраты на reverse engineering (понимание, как оно в целом устроено и работает. "дизайн"+"детальный дизайн"). G>3) Затраты на рефакторинг (изменение без добавления/изменения функциональности, но, возможно, с одновременным исправлением дефектов).
Кстати, существует довольно обширный класс ошибок, которые легко фиксятся без понимания как работает система не только в целом, но даже исследуемая её часть.
G>Если бы тебе не приходилось на этот работающий код времени тратить, ты бы не стал его трогать, правильно?
Абсолютно.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Кстати, существует довольно обширный класс ошибок, которые легко фиксятся без понимания как работает система не только в целом, но даже исследуемая её часть.
Бывает. Но вообще говоря — "симптоматическое лечение поциента" — это ай-ай-ай. Иногда, впрочем, бывает, что выхода другого нет.
Насчет фаз — я, помнится, выделял три фазы работы над дефектом.
1) "А что вообще происходит". Завершается, когда ты признал наличие проблемы (либо объяснил, что это не дефект, и тогда ваще все), смог сам воспроизвести ситуацию, и в состоянии работать с ней дальше без тестера. Иногда бывает, что это длительная фаза.
2) "Загон зверя". Завершается, когда ты понял root cause дефекта. То есть, ты в состоянии по шагам показать, как так выходит, что дефект проявляется, и почему. Вовсе не обязательно ты в этот момент знаешь, что тебе делать, и как эту дичь исправлять. На этой фазе добывается понимание, как система работает, необходимое для описания root cause.
3) "Добивание". Собственно, раздумья над фиксом, завершаются его реализацией, и коммитом. Иногда бывает, что это дольше, чем все предыдущее, потому, что понимания для внесения правки требуется куда больше. Здесь ты можешь принять решение провести рефакторинг, если дефектов в найденном месте гнездо.
Дефекты могут быть классифицированы на типы по грубому соотношению времен этих фаз. Не то, штоб для какой-то специальной цели — но надо ж их, зараз, как-то различать, когда на поддержке работаешь? Ну, типо как у эскимосов в языке 20 названий разного снега .
Скажем, по вырожденности фаз, когда время на какой-либо из них близко к нолю. Например, бывает, что фикс совершенно очевиден при окончании фазы 2. Фаза (3) длительна тогда, когда ты оказался в непростой ситуации. Это, в общем, само по себе индикатор того, что с кодом все крайне запущено.
Здравствуйте, Gaperton, Вы писали:
IT>>Отношением к ним. G>Приведи пожалуйста пример "заведомо геморройной" задачи, не подпадающей ни под один из трех типов.
Задача, которую я приводил выше. Да любая задача, требующая ковыряния в коде заведомо низкого качества.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas, Вы писали:
G>Это я и так отлично знаю.
G>Меня интересует другое. "Сложность" существует объективно, вот и хочется понять какие факторы влияют на нее. И как можно бороться с объективной сложностью, чтобы минимизировать итоговые метрики "объем", "время", "плотность ошибок"
Сложность это количество простейших умозаключений + количество простейших механических действий которые необходимо совершить, что бы решить задачу.
Соответсвенно, нужно уменьшать это количество, за счет
1. использования высокоуровневых конструкций
2. использования высокоуровневых инструментов
Здравствуйте, IT, Вы писали:
IT>Я уже своё отруководил. Лет 6 начальником группы/сектора в одном НИИ, потом 4 года начальником отдела разработки ПО в одной программистской конторе. В целом — не понравилось Руководить людьми не моё.
В линкедине у тебя написано вице-президент Морган Стенли, это руководящя должность или где ?
"Пол сотни программистов, шесть воркстримов на проекте " — ты один из этих "пол сотни" или ты руководишь этой кухней ?
Здравствуйте, Ikemefula, Вы писали:
IT>>Я уже своё отруководил. Лет 6 начальником группы/сектора в одном НИИ, потом 4 года начальником отдела разработки ПО в одной программистской конторе. В целом — не понравилось Руководить людьми не моё. I>В линкедине у тебя написано вице-президент Морган Стенли, это руководящя должность или где ?
Это звание, а не должность. Как погоны у военных. Можно иметь много звёзд, но не иметь при этом ни одного человека в прямом подчинении.
I>"Пол сотни программистов, шесть воркстримов на проекте " — ты один из этих "пол сотни" или ты руководишь этой кухней ?
Это был один проект в IBM. Там я был архитектором и руководил в основном диаграммами и схемами
Если нам не помогут, то мы тоже никого не пощадим.
FR>>Так что награда есть и вполне осязаемая, кто испытывал "второе дыхание" сразу поймет
G>Здесь не идет речи о награде. Здесь они нудно описывают наблюдаемые особенности физиологии, не осознаваемые испытуемым, перечисляя установленные ими факты.
Угу, но на своей шкуре в потоке на самом деле не устаешь.
Факты ими установленные с этим совпадают.
G>Далее, углубившись в анализ ЭЭГ и альфа-ритмов, и накидывая over 9000 умняка, чтобы усыпить бдительность читателя и навести легкий транс, автор статьи ВНЕЗАПНО вдруг говорит:
G>
G>Таким образом, результаты М. Чиксентмихайи могут быть дополнены еще одним элементом, который может быть использован сознательно для вызывания состояния «потока». Используя терминологию нейро-лингвистического программирования, можно сказать, что связное дыхание служит при этом для «якорения» состояния «потока». Более того, существует реальная возможность создавать физиологические и нейропсихологические предпосылки для вызывания ресурсных, творческих состояний личности – процессы осознанного связного дыхания.
Это похоже уже второй автор подключился психолого притом из "новых" гуманистических
G>Что представляет собой полный бред, который автор даже не потрудился как-то обосновать. Ибо перед этим он вещал:
Психологам тоже кушать хочется
G>Это комплексное состояние, оно неустойчиво, и его нельзя вызвать "якорями" и какими-либо другими заклинаниями. Так же бессмысленно и глупо, как и вызвать ощущение радости от победы.
Угу.
G>Вы "полагаетесь" на "ощущение победы", которое дает заряд бодрости и прилив новых сил? Оно "позабыто" и атрофировалось? Может быть, для него нужны сложная психология, и физиологи с аппаратами?
G>Или для того, чтобы вызвать это ощущение — надо победить, черт бы его побрал?
Все таки ты сравниваешь мягкое с зеленым
Поток все-таки не такое узкоспециализированное ощущение, да и не ощущение вовсе, это состояние и сравнивать его надо именно с состояниями — сном, бодрствованием, трансом и гипнозом.
G>Так же и для поддержания состояния "потока" нужны не альфа ритмы и особое дыхание. Человек не система веревочек, за которые можно тупо дергать. Нужен набор факторов, поддерживающих спонтанный интерес и свободно перетекающее внимание. Следствием этого являются возбуждение, особенности дыхания, и прочие вещи, которые увлеченно наблюдает автор статьи, делая из бодрый вывод, что "таракан слышит ногами".
Понятно что правильно задышав и подстроив альфа ритмы в поток не войдешь, но и знание о том что поток по сути полезен для здоровья не лишнее.
G>НЛПсты не психологи. Они такие же психологи, как продавцы скрама специалисты по процессам разработки, а продавцы пищевых добавок — фармацевты. НЛП — это инфраструктура по зарабатыванию бабла, а не наука.
НЛПисты да, но это вообще традиционно для (около)психологии те же психоаналитики недалеко от них ушли.
G>С когнитивными психологами бихейвиористов не путаете? Нет у них никакого черного ящика. Методы бихейвиористов основаны на модели психики, в основе которой лежит система условных рефлексов. В частности, "непавловском условном рефлексе". И в своем классе ситуаций бихейвиористика потрясающе эффективна — напоминает магию. НЛПстам не снилось. Собственно, НЛП сдернуло большую часть именно у бихейвиористов, выкинув при этом всю теоретическую базу.
Вроде нет, но возможно слишком много читал советских психологов не особо жалующих бихейвиористов
FR>>лучше уж физиологов почитать, к примеру того же Бернштейна у него хоть вполне рабочие модели подкрепленные фактами.
G>Это примерно так же продуктивно, как пытаться реверс-инжинирить оперсистему Windows, копаясь на уровне транзисторов, замера времянок, и спиливания печатной платы по слоям.
Не это скорее ядро, прерывания и низкоуровневое программирование
G>Скажем, практический интерес представляет "мышечный панцирь", и, в частности, связь переживания тревожности с неконтроллируемым напряжением диафрагмы. Связь есть, она экспериментально наблюдается, она двухсторонняя, и этим можно пользоваться.
G>А что там происходит с точки зрения физиологии при переживании тревожности — абсолютно по барабану. Понимание, совершенно лишнее для действия.
Бернштейн как раз один из основоположников современной биомеханики и психофизиологии и у него много захватывается именно пси притом на достаточно высоком уровне, вплоть до мотивации http://flogiston.ru/library/bernstein
Здравствуйте, Ikemefula, Вы писали:
FR>>Угу, но на своей шкуре в потоке на самом деле не устаешь. FR>>Факты ими установленные с этим совпадают.
I>Вообще говоря в потоке ты устаёшь, только не замечаешь этого.
Да конечно устаешь, но устаешь меньше выполняя более сложную работу чем вне потока.
Здравствуйте, thesz, Вы писали:
S_>>Бывают задачи простые,краткие, с недвусмысленными условиями.Но с очень сложным решением. T>Пример?
Докажите, что для раскраски любой карты на плоскости достаточно четырёх красок.
Докажите, что A^Z+B^Z=C^Z не имеет решения в целых числах для Z>3.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, FR, Вы писали:
G>>Здесь не идет речи о награде. Здесь они нудно описывают наблюдаемые особенности физиологии, не осознаваемые испытуемым, перечисляя установленные ими факты.
FR>Угу, но на своей шкуре в потоке на самом деле не устаешь. FR>Факты ими установленные с этим совпадают.
В потоке не замечаешь, как устаешь, по причине, знакомой каждому, но не наблюдаемой их методами.
По причине постоянной заинтересованности в предмете. Предмет является настолько сильной "фигурой", что ощущения усталости, голода, и пр. находятся в "фоне".
Для гештальт-психологии описание состояния "потока" — одноходовка. По физиологическим критериям — его надежно хрен установишь. И непонятно, зачем это вообще делать.
G>>Или для того, чтобы вызвать это ощущение — надо победить, черт бы его побрал?
FR>Все таки ты сравниваешь мягкое с зеленым FR>Поток все-таки не такое узкоспециализированное ощущение, да и не ощущение вовсе, это состояние и сравнивать его надо именно с состояниями — сном, бодрствованием, трансом и гипнозом.
Не надо. Сон, бодрствование, транс, и гипноз — устойчивые состояния. "Поток" — нет.
FR>Вроде нет, но возможно слишком много читал советских психологов не особо жалующих бихейвиористов
Советсткие психологи не жаловали не только бихейвиористов, — но вообще по большей части всю психологию. По сугубо идеологическим соображениям.
Поэтому, наверное, и не оставили миру значимого наследия, мало-мальски сравнимого с "западными" школами.
G>>Это примерно так же продуктивно, как пытаться реверс-инжинирить оперсистему Windows, копаясь на уровне транзисторов, замера времянок, и спиливания печатной платы по слоям.
FR>Не это скорее ядро, прерывания и низкоуровневое программирование
Физиология — это таки транзисторы и провода . Грубая, но точная аналогия: психология — это софт, психиатрия — хард. "Психиатрические" заболевания обусловлены биохимией, "психологические" же проблемы — с биохимией не связаны и допускают "психокоррекцию". Литий колоть вовсе не обязательно, чтобы приступ купировать. Все. Разница объективно наблюдаема.
Попытки притянуть физиологию к объяснению психологических эффектов идут от непонимания этой разницы — что причина, а что следствие. Физиология — это как протокол транспортного уровня по отношению к прикладному. Хоть голубиной почтой доставляй пакеты — на логику приложения не влияет.
G>>А что там происходит с точки зрения физиологии при переживании тревожности — абсолютно по барабану. Понимание, совершенно лишнее для действия.
FR>Бернштейн как раз один из основоположников современной биомеханики и психофизиологии и у него много захватывается именно пси притом на достаточно высоком уровне, вплоть до мотивации http://flogiston.ru/library/bernstein
Здравствуйте, Gaperton, Вы писали:
G>В потоке не замечаешь, как устаешь, по причине, знакомой каждому, но не наблюдаемой их методами.
G>По причине постоянной заинтересованности в предмете. Предмет является настолько сильной "фигурой", что ощущения усталости, голода, и пр. находятся в "фоне".
G>Для гештальт-психологии описание состояния "потока" — одноходовка. По физиологическим критериям — его надежно хрен установишь. И непонятно, зачем это вообще делать.
Психология все-таки не наука, психологи могут "описать" и "объяснить" любые факты, которые до этого в упор не видели. Это и поток и гипноз и транс.
Ну и по физиологическим параметрам даже сон от бодрствования не всегда однозначно различается.
G>Не надо. Сон, бодрствование, транс, и гипноз — устойчивые состояния. "Поток" — нет.
Зависит от глубины, также как и у остальных состояний. Бывает так затянет что все вокруг исчезает
G>Советсткие психологи не жаловали не только бихейвиористов, — но вообще по большей части всю психологию. По сугубо идеологическим соображениям.
G>Поэтому, наверное, и не оставили миру значимого наследия, мало-мальски сравнимого с "западными" школами.
А зачем сравнивать всю западную где население было чуть не в 10 раз больше и советскую? А так вполне на нормальном уровне была,
идеология конечно ее прилично ограничила, вот тут взгляд из запада http://scepsis.ru/library/id_666.html
FR>>Не это скорее ядро, прерывания и низкоуровневое программирование
G>Физиология — это таки транзисторы и провода . Грубая, но точная аналогия: психология — это софт, психиатрия — хард. "Психиатрические" заболевания обусловлены биохимией, "психологические" же проблемы — с биохимией не связаны и допускают "психокоррекцию". Литий колоть вовсе не обязательно, чтобы приступ купировать. Все. Разница объективно наблюдаема.
Это да, я не вообще про физиологию, разделение правильное, но это не отменяет существование ни психофизиологии ни системных программистов
G>Попытки притянуть физиологию к объяснению психологических эффектов идут от непонимания этой разницы — что причина, а что следствие. Физиология — это как протокол транспортного уровня по отношению к прикладному. Хоть голубиной почтой доставляй пакеты — на логику приложения не влияет.
Это у нас не влияет, у них все гораздо хуже, комп наполовину аналоговый и хард на софт влияет и наоборот тоже.
Здравствуйте, Gaperton, Вы писали:
G>И не говори. Совсем распоясались. Как напьются — так сразу в "философию программирования" буянить.
А я вот скромный, я сдерживаюсь — чивас и сигара, и за вами наблюдать из-за укрытия.. =))
Здравствуйте, IT, Вы писали:
IT>Трудоёмеость в программировании — это в чистом виде субъективная оценка конкретного индивидуума сроков выполнения его проектов, IT>построенная на его предпочтениях. Можно, конечно, выявлять закономерности, но работать это будет в строго ограниченных рамках.
А почему такую статистику нельзя применять with respect to конкретному человеку, к его предпочтениям.
Т.е. например добавил 1-октябра индивидум 1 статический класс, и чекины за следущие две недели показывают что код начинает расти
со скоростью 300 строк в день +-100 , и какие нибудь cyclomatic complexity стабильно низкая и прыгает в примерно таких границах.
А если он 1 декабря индивдум 1 добавил базовый класс для Visitora — то за следущие две недели он код растет то по 100 строчек
в день, то по 1000, то вообще уменьшается, комплексити прыгает как сумасшедшая, классы то добавляются, то убираются, ну и
так далее.
Т.е. в принципе можно, если будет достаточная статистика (по индивидуму) — можно будет вывести заранее к чему приведет то или иное его/ее действие.
Тут конечно много допущений, как то код чекиниться через равные промежутки времени, индивидумы работают не на
пятью совсем разными проектами (что в общем-то нормально для тех кто поддерживает старый код), а более менее
постоянно над одним.
Здравствуйте, Igor Sukhov, Вы писали:
IT>>Трудоёмеость в программировании — это в чистом виде субъективная оценка конкретного индивидуума сроков выполнения его проектов, IT>>построенная на его предпочтениях. Можно, конечно, выявлять закономерности, но работать это будет в строго ограниченных рамках. IS>А почему такую статистику нельзя применять with respect to конкретному человеку, к его предпочтениям.
Попробуй.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>>>Трудоёмеость в программировании — это в чистом виде субъективная оценка конкретного индивидуума сроков выполнения его проектов, IT>>>построенная на его предпочтениях. Можно, конечно, выявлять закономерности, но работать это будет в строго ограниченных рамках. IS>>А почему такую статистику нельзя применять with respect to конкретному человеку, к его предпочтениям.
IT>Попробуй.
вот как будет такая тула — обязательно попробую. интересно — есть что то подобное под TFS & SVN?
Здравствуйте, Igor Sukhov, Вы писали:
IS>>>А почему такую статистику нельзя применять with respect to конкретному человеку, к его предпочтениям. IT>>Попробуй. IS>вот как будет такая тула — обязательно попробую. интересно — есть что то подобное под TFS & SVN?
Тула, считающая строки? Игорь, ты же вроде взрослый человек, даже XBox уже сам себе покупаешь, а всё ещё веришь в строчки кода
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IS>>>>А почему такую статистику нельзя применять with respect to конкретному человеку, к его предпочтениям. IT>>>Попробуй. IS>>вот как будет такая тула — обязательно попробую. интересно — есть что то подобное под TFS & SVN?
IT>Тула, считающая строки? Игорь, ты же вроде взрослый человек, даже XBox уже сам себе покупаешь, а всё ещё веришь в строчки кода
тула которая сможет определить источник проблем в проекте. т.е. где проблемность сконценрирована, откуда она взялась, и что с ней станет через месяц, если не боротся.
дело конечно не в строчках, а в метриках файлов, классов, их связей между друг другом. это конечно не метрики на уровне кода (но такое и сделать сложннее — надо будет парсить код методов) — т.е. таким макаром не определишь качество внутри ф-и (хотя конечно оно и важно), но в большинсве случае если проблемы пошли то они будут видны и на уровне файлов, классов, функций, но хотя бы что-то.
G>Скорее есть закон "минимально необходимой сложности", и он во многом пересекается со статьей, но называется никак не "закон сохранения".
G>А вообще респект за тему — управление сложностью — самое важное в разработке.
Нет и закона о минимально необходимой сложности. Выбор метода и инструментов (имеется в виду не программных) для решения задачи играет решающую роль. Примеры, которые вы привели, правильные но не наглядные. В науке такое тоже было. Одно применение дифференциалов (чисто как форма записи) значительно продвинула математику, хотя вроде бы простая фишка. А изобретение десятичной формы письменности. Задачи то остались, а решение насколько упростилось! Так что главное метод. Новые принципы единственный выход.
Если нам не помогут, то мы тоже никого не пощадим.
Мы уже победили, просто это еще не так заметно...
* thriving in a production environment *
