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

FR>Спорно, для данного примера, мы просто более декларативно задали данные в коде, и он получился полее простым и понятным, а это важнее. Свертывание и цикл имели бы смысл если бы данные для поиска были внешними а не задавались прямо в коде.

Вынесение данных в надсистему — это следующий шаг.

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

C>>>Методы анализа задачи в ТРИЗе плохо подходят к программированию, к
AVC>>Почему Вы так думаете? (Не спорю, а просто интересуюсь основанием уверенности.)
FR>Я тоже так думаю. А причина по моему такая, что того же уровня формализации который смогли проделать оснаватели триза в изобретательстве и патентной сфере, в программировании добится невозможно,

Постоянно поминаемую книжку патернов смогли же составить.

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

Ограничения, имхо, есть. Накладываются они парадигмой, конкретными языками, средами...

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

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

C>>>>Методы анализа задачи в ТРИЗе плохо подходят к программированию, к
C>>>>сожалению.
AVC>>>Почему Вы так думаете? (Не спорю, а просто интересуюсь основанием уверенности.)
FR>>Я тоже так думаю. А причина по моему такая, что того же уровня формализации который смогли проделать оснаватели триза в изобретательстве и патентной сфере, в программировании добится невозможно, основная причина именно в гибкости, если в изобретательстве все возможные приемы ограничены законами физики и поэтому конечны то в проектировании и програмировании этого нет.

AVC>Я подумаю над этим.
AVC>Все же, мне кажется, что и в программировании есть свои "природные законы".

А мне кажется нет, хотя закономерности могут быть

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

AVC>Мне трудно (пока?) об этом судить.
AVC>Спасибо К.Лебедеву, что дал мне повод задуматься о (возможном) применении ТРИЗ в программировании.
AVC>Предварительно (до основательного обдумывания этого вопроса) я придерживаюсь сдержанного оптимизма.

Когда я впервые услышал о ТРИЗ (и увлекся им), то в каком то журнале (наверно ТМ начала 90-ых) читал что ТРИЗ обещает сделать революцию именно в программировании, так как ничего ни произошло то оптимизма у меня ни осталось

AVC>Основание: ТРИЗ есть частный (но самый эффективный) способ диалектического мышления.

Да самый эффективный в одной узкой области. В других областях ничем ни выдающийся. Хотя его общие положения о развитии систем и идеальной машине мне нравятся

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

А оно есть это основное противоречие? а если его нет?

AVC>Я надеюсь, что применение ТРИЗ облегчит поиск таких принципиальных решений.
AVC>Поэтому я и заинтересовался этой темой.

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

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

ГВ>>

ГВ>>Мысль 5: В идеале созданный мной контекст должен быть таким, чтобы инкапсулированные в нем функции (методы) ничего не знали о том, кого они обслуживают. "Кого надо, того и обслужат". Обслужат любую ("any") сущность.

ГВ>>Ага, всеь огромный поток словоблудия, чтобы перефразировать LSP. Не... Точно — Дзен.

V>+1

Прикольно, что от определения термина "контекст" автор, в конечном итоге, похоже, уклонился. Кстати, по поводу терминологии на сайте ТРИЗ аж 2 года назад была любопытная дискуссия: http://www.triz-ri.ru/forum/mess.asp?cat=0&thr=20852&vtk=18292. Посмотри на досуге.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

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

C>>>>Методы анализа задачи в ТРИЗе плохо подходят к программированию, к
AVC>>>Почему Вы так думаете? (Не спорю, а просто интересуюсь основанием уверенности.)
FR>>Я тоже так думаю. А причина по моему такая, что того же уровня формализации который смогли проделать оснаватели триза в изобретательстве и патентной сфере, в программировании добится невозможно,

ANS>Постоянно поминаемую книжку патернов смогли же составить.

Это на законы никак ни тянет, так просто пожелания
Законы физики невозможно нарушить, а не использовать патерны запросто.

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

ANS>Ограничения, имхо, есть. Накладываются они парадигмой, конкретными языками, средами...

Конечно есть, но их уровень не сравним.

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

LCR>Попробую дать своё определение: (нестрогое, и вообще не определение)
LCR>Краткость — это мера концентрации идей, чем выше концентрация, тем выше краткость. Ну и чем выше краткость, тем лучше.

Из примера с qsort мне показалось, что концентрация сильно зависит от высоты абстракций. Чем выше уровень абстракций, которыми мы можем оперировать на конкретном языке, тем выше оказывается концентрация и, следовательно, больше компактность. Именно поэтому Erlang-овская запись выглядит компактнее, чем C-шная.

Кстати, просто для уточнения твоей точки зрения. Считаешь ли ты, что по компактности записи:

basicmatrix[elementaryrow][elementarycolumn] ++;

и

m[i ][j] ++;

эквивалентны?

Lazy Cjow Rhrr wrote:
> Ты умудрился скачать интерпретатор? Или у Трурля взял?
Пнул KXов. Прислали интерпретатор через 10 минут и пообещали выложить на
сайте

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

Я сразу хочу отметить, что с ТРИЗом знаком поверхностно и защищать его не хочу, хочу грокнуть "так таки да или таки нет". Может пригодится.

FR>>>Я тоже так думаю. А причина по моему такая, что того же уровня формализации который смогли проделать оснаватели триза в изобретательстве и патентной сфере, в программировании добится невозможно,

ANS>>Постоянно поминаемую книжку патернов смогли же составить.

FR>Это на законы никак ни тянет, так просто пожелания

Так это не законы, а категоризированный справочник типовых решений.

FR>Законы физики невозможно нарушить, а не использовать патерны запросто.

Хе-хе. Вот нет в Java оператора "super super" для доступа к методу не родителя, а дедушки и попробуй это нарушить. А вопрос, как это сделать, я видел и в ru.java и на rsdn. Или требование типа "должна отработать быстрее чем за N времени".

Кстати кстати. Просматриваю статью "Objectoriented Encapsulation for Dynamically Typed Languages" и что я вижу?

As an illustration, consider the class Morph, which is the root of the GUI framework in Squeak. Morphs have a hierarchic structure: a Morph contains an instance variable named submorphs, which is a (possibly empty) collection of Morph objects. Morph also implements a few methods such as addMorph:, removeMorph:, and moveMorphToFront:, which add and remove submorphs and change how they are layered. /.../
With class-based encapsulation mechanism, the only way to ensure this is to make the reference to the submorphs secret and never pass it out of the parent morph. Unfortunately, this conflicts (выделение моё) with the need of some of Morph’s clients to use the protocol provided in Collection to enumerate the submorphs.

Что-то мне это напомнило. Ну и дальше есть еще ограничения типа

We seek a mechanism that is expressive, simple, and appropriate for dynamic languages.

первые два — не законы физики, конечно, но там дальше эти ограничения конкретизированы. А последнее требование — очень и очень строгое.
Ы?

eao197,

E>Из примера с qsort мне показалось, что концентрация сильно зависит от высоты абстракций. Чем выше уровень абстракций, которыми мы можем оперировать на конкретном языке, тем выше оказывается концентрация и, следовательно, больше компактность. Именно поэтому Erlang-овская запись выглядит компактнее, чем C-шная.
Да, высота абстракций очень влияет на краткость.

E>Кстати, просто для уточнения твоей точки зрения. Считаешь ли ты, что по компактности записи эквивалентны?:
[сcode]
E>basicmatrix[elementaryrow][elementarycolumn] ++;
E>//vs
E>m[ i ][ j ] ++;
[/сcode]
Не совсем. Набор идей совпадает, но концентрация различна.

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

FR>>>основная причина именно в гибкости, если в изобретательстве все возможные приемы ограничены законами физики и поэтому конечны то в проектировании и програмировании этого нет.
ANS>>Ограничения, имхо, есть. Накладываются они парадигмой, конкретными языками, средами...

FR>Конечно есть, но их уровень не сравним.

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

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

LCR>

E>>basicmatrix[elementaryrow][elementarycolumn] ++; 
E>>//vs
E>>m[ i ][ j ] ++;
LCR>

LCR>Не совсем. Набор идей совпадает, но концентрация различна.

Почему? Неужели длина идентификаторов имеет значение?

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

FR>Законы физики невозможно нарушить, а не использовать патерны запросто.
Законы развития техники тоже можно нарушить. Т.е. физически можно создать техническую систему, которая будет нарушать ЗРТС. Только вот такая техническая система долго не проживет или будет неэффективно работать.

Cyberax,

>> Ты умудрился скачать интерпретатор? Или у Трурля взял?
C>Пнул KXов. Прислали интерпретатор через 10 минут и пообещали выложить на
C>сайте

ps: только что заходил, не выложили однако

Здравствуйте, Andrei N.Sobchuck, Вы писали:

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

ANS>Я сразу хочу отметить, что с ТРИЗом знаком поверхностно и защищать его не хочу, хочу грокнуть "так таки да или таки нет". Может пригодится.

Я думаю полезно для общего развития.

FR>>Это на законы никак ни тянет, так просто пожелания

ANS>Так это не законы, а категоризированный справочник типовых решений.

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

FR>>Законы физики невозможно нарушить, а не использовать патерны запросто.

ANS>Хе-хе. Вот нет в Java оператора "super super" для доступа к методу не родителя, а дедушки и попробуй это нарушить. А вопрос, как это сделать, я видел и в ru.java и на rsdn. Или требование типа "должна отработать быстрее чем за N времени".

Я в java не разбераюсь, но в C++ почти все что запрещено можно обойти хаком

ANS>Что-то мне это напомнило. Ну и дальше есть еще ограничения типа
ANS>

We seek a mechanism that is expressive, simple, and appropriate for dynamic languages.

первые два — не законы физики, конечно, но там дальше эти ограничения конкретизированы. А последнее требование — очень и очень строгое.
ANS>Ы?

Дак я и не спорю, ограничения конечно есть, но они очень слабые, по сравнению с физикой

Кроме того нет такой же базы на которой основывается ТРИЗ — патентов, в которых жестко формализовано зафиксированы почти все возможные технические решения. Вообще порадокс программирование вроде само средство формализации и при этом само поддается этой самой формализации с большим трудом

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

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

FR>>Законы физики невозможно нарушить, а не использовать патерны запросто.
КЛ>Законы развития техники тоже можно нарушить. Т.е. физически можно создать техническую систему, которая будет нарушать ЗРТС. Только вот такая техническая система долго не проживет или будет неэффективно работать.

Похоже очень большая часть программ как раз и нарушает любые законы развития — и кривые и неэффективные
И ничего прекрасно живут

Может дело в том что в IT время жизни очень большого числа приложений меньше чем время за которое они могут эволюционировать до плато и при том цена создания (и копирования!) систем намного меньше чем в технике.

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

C>http://dapissarenko.com/resources/2005_08_23_progTriz/index.html

Прикол, блин. Почти всё на английском

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

FR>Похоже очень большая часть программ как раз и нарушает любые законы развития — и кривые и неэффективные
FR>И ничего прекрасно живут
Как раз-таки непрекрасно. Расплата заключается в резком увеличении сложности сопровождения таких программ. Например, я видел несколько программ, за которые ряд аутсорсеров просно не рискнули взяться, т.к. сложность сопровождения была очень высока. А те, что взялись, так и не смогли выполнить пожелания заказчика, т.к. просто не смогли побороть основные баги.

eao197,

LCR>>

E>>>basicmatrix[elementaryrow][elementarycolumn] ++; 
E>>>//vs
E>>>m[ i ][ j ] ++;
LCR>>

LCR>>Не совсем. Набор идей совпадает, но концентрация различна.

E>Почему? Неужели длина идентификаторов имеет значение?

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

Более того, чаще всего "мысленный экран" меньше визуального буфера (впрочем это тренируется). А про визуальный буфер (=визуальную память) можно добавить следующее.

Если текст вылазит за экран, то его приходится прокручивать и крындец — визуальный буфер не работает, включается только кратковременная память.

Возможности же кратковременной памяти гораздо ниже, чем визуальной памяти. (например, для визуальной памяти нет ограничения 5..9 и она быстрее).

Пример (люблю примеры)

min([H|T]) -> min(T, H).

min([H|T], Min) when H < Min -> min(T, H);
min([_|T], Min)              -> min(T, Min);
min([],    Min)              -> Min.

minimum([Head|Tail]) -> minimum(Tail, Head).

minimum([Head|Tail], Minimum) when Head < Minimum -> minimum(Tail, Head);
minimum([_|Tail],    Minimum)                     -> minimum(Tail, Minimum);
minimum([],          Minimum)                     -> Minimum.

Первый кусок находится как бы "на острие взгляда". Второй же кусок требует некоторого блуждания глазами. Различие между этими случаями становятся больше, когда пойдут нетривиальные функции.

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

И последний, очень нехилый плюс. Краткую запись можно запомнить as-is и анализировать в непринуждённой обстановке. Как правило такой анализ "с закрытыми глазами" происходит эффективнее.

Здравствуйте, Lazy Cjow Rhrr

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

Но это уже проблемы моего (либо твоего) воспитания. Поэтому субъективны и обсуждению не подлежат

eao197,

E>Чесно говоря, со всем изложенным не согласен абсолютно. Видимо, сказывается то, что хороший стиль программирования мне прививали на Паскале и длинные идентификаторы для меня более удобны чем короткие.
E>Но это уже проблемы моего (либо твоего) воспитания. Поэтому субъективны и обсуждению не подлежат
E>

Ну хорошо.