Здравствуйте, FR, Вы писали:
FR>А вот насчет законов развития технических систем, я не уверен что они также действуют в программных системах как и в технических.
А я уверен, что действуют. Моя уверенность — против Вашей. С мнением бесполезно спорить. Нужны аргументы. Свои аргументы я привел. А как на счет Ваших?
FR>Мне кажется вы пытаетесь законы выведенные для более простых систем перенести в более сложные, по моему ничего путного из этого не выйдет.
Это не так. См. дискуссию про идеальность.
FR>Извините пока такой работы не видно. Видна только чистая философия, на ней далеко не уедешь.
Извините, но проблема понимания — это проблема не только автора, но и читателя. В любом случае, на профессиональном форуме недостаточно просто высказать свое мнение. Мнение еще нужно обосновать.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, FR, Вы писали:
FR>>А вот насчет законов развития технических систем, я не уверен что они также действуют в программных системах как и в технических.
КЛ>А я уверен, что действуют. Моя уверенность — против Вашей. С мнением бесполезно спорить. Нужны аргументы. Свои аргументы я привел. А как на счет Ваших?
Где аргументы, пусть даже не доказывающие, а хотя бы показывающие что эти законы работатют в программных системах?
Аргументов нет ни с моей ни с вашей стороны, есть только мнения.
FR>>Мне кажется вы пытаетесь законы выведенные для более простых систем перенести в более сложные, по моему ничего путного из этого не выйдет.
КЛ>Это не так. См. дискуссию про идеальность.
Как раз из этой дискуссии по моему вытекает моя точка зрения
FR>>Извините пока такой работы не видно. Видна только чистая философия, на ней далеко не уедешь.
КЛ>Извините, но проблема понимания — это проблема не только автора, но и читателя. В любом случае, на профессиональном форуме недостаточно просто высказать свое мнение. Мнение еще нужно обосновать.
Обосновать можно любую даже очень неэфективную методику, для этого нужна квалификация не программиста — проектировщика а хорошо подвешенный язык и склоность к философии
Проектирование и программирование это занятие на стыке инжинерии, психологии и философии, поэтому существут много методик, которые эффективны для авторов и некоторого количества людей близких к авторам по психотипу. Так что не стоит говорит о непонимании и неявно принижатть квалификацию оппонентов только из-за того что у них и у вас не совпадают психотипы.
Re[23]: О правильных и неправильных классификациях...
Кирилл Лебедев,
КЛ>А я уверен, что действуют. Моя уверенность — против Вашей. С мнением бесполезно спорить. Нужны аргументы. Свои аргументы я привел. А как на счет Ваших? КЛ>Извините, но проблема понимания — это проблема не только автора, но и читателя. В любом случае, на профессиональном форуме недостаточно просто высказать свое мнение. Мнение еще нужно обосновать.
Простите меня за замечание не относящееся к предмету обсуждения.
Мне думается, что выделять болдом имеет смысл только ключевые слова, их обычно 0-1 на абзац (на то они и ключевые). Если же ключевых слов становится слишком много, то я начинаю их ранжировать по "ключности" и пытаться выделить "самое ключевое" исходя из моих личных соображений. Это моё "самое ключевое" может оказаться совсем не тем, на чём хотел сделать акцент автор.
Если автор заботится о правильной расстановке акцентов, то непонимания обычно не возникает.
И статьи, и сообщения достаточно развернуты и содержат много примеров.
Соответственно, если Вы не согласны с выводами, то квалифицированный ответ строится по следующей схеме:
П. 1 неверен, потому что существуют такие-то и такие-то примеры, где это нельзя применить.
В п. 2 в примере автор перепутал то-то и то-то и стал исходить из ложных посылок.
В п. 3 — аргументы по поводу п. 3.
И т.д.
FR>Обосновать можно любую даже очень неэфективную методику, для этого нужна квалификация не программиста — проектировщика а хорошо подвешенный язык и склоность к философии
Именно по этой причине я предлагаю оценивать эффективность методики на конкретных задачах. Именно по этой причине я и предлагаю Вам — как квалифицированному специалисту — привести аргументы своих выводов.
FR>Проектирование и программирование это занятие на стыке инжинерии, психологии и философии, поэтому существут много методик, которые эффективны для авторов и некоторого количества людей близких к авторам по психотипу. Так что не стоит говорит о непонимании и неявно принижатть квалификацию оппонентов только из-за того что у них и у вас не совпадают психотипы.
Простите, но психотип не имеет никакого отношения к квалификации. Квалификацию (и эффективность) определяет количество решенных практических задач, качество решений и, соответственно, качество аргументации. Все остальное — разговоры о политике, женщинах, психотипах, общие рассуждения о философии и психологии — конечно, занимательны, но являются замещением квалифицированной деятельности.
Здравствуйте, FR, Вы писали:
AVC>>Я хочу сказать, что применение вполне "тризовских" методов может иметь место и без лейбла "ТРИЗ". FR>Если любую диалектику обозвать тризом то можно
Что значит 'любая диалектика'?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[25]: О правильных и неправильных классификациях...
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, FR, Вы писали:
FR>>Где аргументы, пусть даже не доказывающие, а хотя бы показывающие что эти законы работатют в программных системах?
КЛ>Они есть и в данной дискуссии, и в статьях. Приведу лишь несколько ссылок:
Первый пример плохой, тут многие уже указали что вынос в функцию, во многих отношениях лучше. И вообще такой код может написать или начинающий или нормальный программист в стресс условиях (нехватка времени или усталость), и такой код у нормального специалиста проживет не больше первой ревизии.
Про стол пример согласен с Cyberax абсолютно надуманный, из серии сам себе придумаю (идиотские) проблемы и с блеском их разрешу.
Пример про кривые решен типичным патерном.
Пример про утечки тоже надуман, ваше решение не единственное и не идиальное, а реальной работе такие проблемы решаются инструментальными средствами.
КЛ>4) Идеальность. КЛ>http://www.rsdn.ru/Forum/Message.aspx?mid=1787710&only=1
Ваше определение идеального кода очень спорно. Есть несколько точек зрения (уже высказаных тут) на то какой код считать идеальным. И даже хуже того, мнение конкретного человека о идеальности меняется в зависимости от того что он в данный момент делает, если работает на большой программой то идеальный код это легко сопровождаемый и расширяемый, если над утилиткой написал и выбросил, то идеальный код компактный и простой, если над программой жестко ограниченной аппаратными ресурсами то идеальный код это оптимизированный на максимально эффективное использование этих ресурсов.
КЛ>И статьи, и сообщения достаточно развернуты и содержат много примеров.
КЛ>Соответственно, если Вы не согласны с выводами, то квалифицированный ответ строится по следующей схеме:
КЛ>П. 1 неверен, потому что существуют такие-то и такие-то примеры, где это нельзя применить. КЛ>В п. 2 в примере автор перепутал то-то и то-то и стал исходить из ложных посылок. КЛ>В п. 3 — аргументы по поводу п. 3. КЛ>И т.д.
Это тут и без меня расписали, и я ставил оценки там где согласен.
FR>>Обосновать можно любую даже очень неэфективную методику, для этого нужна квалификация не программиста — проектировщика а хорошо подвешенный язык и склоность к философии
КЛ>Именно по этой причине я предлагаю оценивать эффективность методики на конкретных задачах. Именно по этой причине я и предлагаю Вам — как квалифицированному специалисту — привести аргументы своих выводов.
А зачем повторятся?
FR>>Проектирование и программирование это занятие на стыке инжинерии, психологии и философии, поэтому существут много методик, которые эффективны для авторов и некоторого количества людей близких к авторам по психотипу. Так что не стоит говорит о непонимании и неявно принижатть квалификацию оппонентов только из-за того что у них и у вас не совпадают психотипы.
КЛ>Простите, но психотип не имеет никакого отношения к квалификации. Квалификацию (и эффективность) определяет количество решенных практических задач, качество решений и, соответственно, качество аргументации. Все остальное — разговоры о политике, женщинах, психотипах, общие рассуждения о философии и психологии — конечно, занимательны, но являются замещением квалифицированной деятельности.
К квалификации может отношения и не имеет, но имеет прямое отношение к программированию и проектированию. Это очень хорошо видно потому как разные люди предпочитают совершенно разные языки и парадигмы. Вообще программирование во многом "вынос своего мышления наружу" и поэтому подход к этому занятию только с инженерных позиций будет неполным и однобоким.
Вообще в отрасли уже есть целые малопересекающиеся области, например, функциональное программирование, ООП и обычное процедурное структурное, и представители разных областей часто очень плохо понимают друг друга, и одинаковые задачи решают очень по разному.
Re[19]: О правильных и неправильных классификациях...
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, FR, Вы писали:
AVC>>>Я хочу сказать, что применение вполне "тризовских" методов может иметь место и без лейбла "ТРИЗ". FR>>Если любую диалектику обозвать тризом то можно
AVC>Что значит 'любая диалектика'?
Извини забыл что существует только одно единственное верное и потому всесильное учение
Re[22]: О правильных и неправильных классификациях...
Здравствуйте, FR, Вы писали:
FR>В программировании квалификация ни только в том чтобы уметь применять сложные наворосенные методолгии, но и в том чтобы уметь не стрелять из пушки по воробьям.
IMHO, в этой реплике есть здравое зерно.
Поэтому мне и кажется пока, что скорее имеет смысл применять ТРИЗ для решения архитектурных проблем (когда мы уперлись в системное противоречие), чем при ежедневном кодировании.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[20]: О правильных и неправильных классификациях...
Здравствуйте, FR, Вы писали:
AVC>>Что значит 'любая диалектика'?
FR>Извини забыл что существует только одно единственное верное и потому всесильное учение
Я не имел этого в виду.
Просто хотел узнать, что понимается под диалектикой в данном случае.
IMHO, есть два типа диалектики: 'негативная' и 'позитивная'.
В первом случае противоречием кончают (Зенон, Кант), во втором — с него начинают (Гегель, ТРИЗ).
Конечно, это чрезмерное упрощение и сугубое IMHO.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[21]: О правильных и неправильных классификациях...
AVC> AVC>Я не имел этого в виду. AVC>Просто хотел узнать, что понимается под диалектикой в данном случае. AVC>IMHO, есть два типа диалектики: 'негативная' и 'позитивная'. AVC>В первом случае противоречием кончают (Зенон, Кант), во втором — с него начинают (Гегель, ТРИЗ). AVC>Конечно, это чрезмерное упрощение и сугубое IMHO.
Я имел в виду вообще единство и борьбу противоположностей, то есть противоречия. Не только ТРИЗ занимается их разрешением
Re[22]: О правильных и неправильных классификациях...
Здравствуйте, FR, Вы писали:
FR>Я имел в виду вообще единство и борьбу противоположностей, то есть противоречия. Не только ТРИЗ занимается их разрешением
Боюсь, что мы отходим от темы, но мое любопытство слишком сильно.
Какой еще подход связан с разрешением противоречий?
Мне известно только про ТРИЗ и диамат.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[23]: О правильных и неправильных классификациях...
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, FR, Вы писали:
FR>>Я имел в виду вообще единство и борьбу противоположностей, то есть противоречия. Не только ТРИЗ занимается их разрешением
AVC>Боюсь, что мы отходим от темы, но мое любопытство слишком сильно. AVC>Какой еще подход связан с разрешением противоречий? AVC>Мне известно только про ТРИЗ и диамат.
Мне кажется что любая современная итерационная методология разработки по сути это поиск и разрешение противоречий, просто терминология для этого применяется не такая как в диамате и тризе
Re[24]: О правильных и неправильных классификациях...
Здравствуйте, FR, Вы писали:
FR>Мне кажется что любая современная итерационная методология разработки по сути это поиск и разрешение противоречий, просто терминология для этого применяется не такая как в диамате и тризе
Возможно.
Некоторые принципы проектирования, например Open-Closed Principle (OCP, в изложении хотя бы Мартина, ), очень похожи на 'тризовские'. Тот же Мартин пишет, что требования, сочетающиеся в OCP, выглядят противоречащими друг другу.
Согласен, что не надо стрелять из пушек по воробьям.
В таком случае можно обойтись и рогаткой.
Но иногда (не так часто) имеет смысл сознательно прибегнуть к методу выявлению и устранению противоречий.
Повторюсь, мне кажется, это скорее всего приложимо к архитектурным проблемам.
Поэтому тема о применении ТРИЗ в программировании все же заслуживает внимания.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
