О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 14.03.06 09:49
Оценка: 79 (10) +1
Существует мнение, будто программирование — это искусство написания хитроумных алгоритмов. Чем более навороченный (хитроумный) алгоритм человек может написать, следовательно тем ближе он к представлению об "идеальном программисте". В некоторых конторах даже проверяют в лучшем случае — умение составить хитроумный алгоритм, в худшем — знание некоторых алгоритмов, которые почему-то называют "базовыми". Например, "пузырьковую" сортировку.

Между тем, постепенно становится ясно, что важно не само по себе умение написать алгоритм (код), а умение написать его именно так, чтобы он был простой и короткий. Ибо так легче сопровождать. А для того, чтобы код получился простой и короткий, нужно разные сущности, которых в реальных задачах полным-полно, правильно сгруппировать. Поэтому в настоящее время выплывает наружу другое умение программиста — это искусство правильных группировок.

К сожалению, очень много программистов знают только один способ борьбы со сложностью — полиморфизм. И применяют его как к месту, так и не к месту. Но есть и другие способы группировки, есть критерии для объединения сущностей в группу, есть и типичные ошибки группирования.

Собственно, об этом рассказывается в этой статье:
http://www.triz-ri.ru/themes/method/creative/creative57.asp
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[10]: О правильных и неправильных классификациях...
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 17.03.06 11:04
Оценка: 45 (6) +2
eao197,

LCR>>Много синтаксического оверхеда. Это не компактный код. Это просто утоптанный код

E>Может вот это подойдет
Автор: Lazy Cjow Rhrr
Дата: 06.12.05
?


Ааааа, нож в самое сердце! Как же не хочется называть этот код утоптанным...

Если серьёзно, то он (код), увы, не очень краткий. Что я называю краткостью? Примерно то же, что и Пол Грэхэм понимает под словом "succinctness" в своей статье Succinctness is Power.

...ваш первый опыт чтения статьи по математике может быть пугающим: чтение одной страницы занимает полчаса. И все же я уверен, что проблема не в нотации, как может показаться на первый взгляд. Статью по математике трудно читать, потому что сложны сами идеи.


Видишь ли, если мы пишем
basicmatrix[elementaryrow][elementarycolumn] = basicmatrix[elementaryrow][elementarycolumn] + 1;

то здесь идей не больше, чем в
m[i ][j] ++;

при условии, что нам известен смысл символов m, i и j.

Обфусцированный ли, скомканный ли, утоптанный ли код — это всё не то. Мы этими действиями просто вынимаем смысл у символов, из которых состоит программа, тем самым делая программу бессмысленной (=трудной для чтения), однако краткость от этого не меняется.

Краткости можно достигнуть необязательно в ущерб чтению.

Приведу пример (qsort на Erlang и C).
sort([Pivot | T]) ->
    sort([ X || X <- T, X < Pivot]) ++
    [Pivot] ++
    sort([ X || X <- T, X >= Pivot]);
sort([]) -> [].

qsort( a, lo, hi ) int a[], hi, lo;
{
  int h, l, p, t;
  if (lo < hi) {
    l = lo;
    h = hi;
    p = a[hi];
    do {
      while ((l < h) && (a[l] <= p)) 
          l = l+1;
      while ((h > l) && (a[h] >= p))
          h = h-1;
      if (l < h) {
          t = a[l];
          a[l] = a[h];
          a[h] = t;
      }
    } while (l < h);
    t = a[l];
    a[l] = a[hi];
    a[hi] = t;
    qsort( a, lo, l-1 );
    qsort( a, l+1, hi );
  }
}

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

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

Попробую дать своё определение: (нестрогое, и вообще не определение)
Краткость — это мера концентрации идей, чем выше концентрация, тем выше краткость. Ну и чем выше краткость, тем лучше.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re: О правильных и неправильных классификациях...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 15.03.06 21:10
Оценка: 42 (3) :))) :))
Здравствуйте, Кирилл Лебедев, Вы писали:

Не, ну чисто революция в наших сердцах, не иначе. Читал — смеялся.

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


И где это такое мнение? О програмировании ровно столько мнений, сколько людей так или иначе задето этим процессом.

КЛ>Между тем, постепенно становится ясно, что важно не само по себе умение написать алгоритм (код), а умение написать его именно так, чтобы он был простой и короткий. Ибо так легче сопровождать. А для того, чтобы код получился простой и короткий, нужно разные сущности, которых в реальных задачах полным-полно, правильно сгруппировать. Поэтому в настоящее время выплывает наружу другое умение программиста — это искусство правильных группировок.


1000 лет назад это явление было названо "дизъюнктивной когерентностью", когда сущность выступает в нескольких ипостасях. Чуть позже переобозвали слабосвязностью.

КЛ>К сожалению, очень много программистов знают только один способ борьбы со сложностью — полиморфизм. И применяют его как к месту, так и не к месту. Но есть и другие способы группировки, есть критерии для объединения сущностей в группу, есть и типичные ошибки группирования.


500 лет назад был обнародован принцип подстановки Лисковой. Фундаментальная вещь, надо сказать. Им обоснуются чуть ли не все паттерны.

КЛ>Собственно, об этом рассказывается в этой статье:

КЛ>http://www.triz-ri.ru/themes/method/creative/creative57.asp

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

Хотя, конечно, без ниспровергания авторитетов ну никак:

Сделаем выводы и сформулируем некоторые отличия от общепринятых трактовок (отличия, впрочем, небольшие):


Ключевой, как я понял, тезис:

Всегда ошибетесь с контекстом, если будете класс "выводить из подсистемы".


Отметим эту глубокую мысль. Например так: (*)

2. Когда Ваш оператор if привязан к объекту, есть вероятность, что данную ошибку Вы совершили.


Мда. "Есть вероятность". Однако, чёткий формальный критерий нарушения LSP, оказывается, "есть вероятность". Сурр-рово. Есть вероятность, что 4 != 5. Давайте, обдумаем это на ближайщем слёте топ-менеджмента?

За вот такие формулировочки:

Но в какой-то момент надо сделать шаг вперед. Есть более удобные, чем "тип", термины: "однородность", "контекстность". Мы будем говорить, что сущности однородны, если они принадлежат одному контексту.


вообще нужно отлучать от кнопок и посылать в библиотеку. Однородность — суть принадлежность к одному роду (некоему множеству, определяемому сходностью характеристик), а не контексту. У меня на столе валяются курительная трубка и мобила. Однородные сущности? Да, но по критерию владельца. Это ещё не тип, поскольку трубка на столе моего соседа по лестничной клетке это тоже объект типа "трубка", но принадлежит
она другому.

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

Буквально, следущий абзац:

Так, во всех перечисленных выше разных примерах допущена одна и та же ошибка, и в этом смысле все эти разные примеры — однородны.


Это уже Дзен. 4=5 и в этом смысле 6=7.

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

Уж лучше сказать... а вот не скажу, как. Сами догадаетесь.

А если мы заведем группу "Разный неструктурированный мусор", то все помещенное в эту группу будем считать однородным с точки зрения данного контекста.


...и с нами случится просветление. Слушайте, где такая трава растёт?

А за тезис:

"Сущности, принадлежащие типу "Разнородные"

автору вообще нужно памятник при жизни ставить. И на памятнике изобразить деление на нуль. Не удивительно, что автор поместил сие откровение в примечании. Это ж насколько нужно путаться в собственных идеях, что без примечаний и не высказать?!

4. Значит, можно трактовать класс не столько как тип и не столько как общий случай нашего частного объекта, сколько как один из контекстов для функций, частный случай группировки функций — место, где функции ("методы") лежат "пачкой".

Эта трактовка совсем уж нарушает общепринятую ООП-традицию, но и не отрицает ее – просто сводит к частному случаю


Ага. Дизъюнктивная когерентность рулит, ну хто бы спорил. Конечно, компилятор, он всё стерпит. Можно трактовать класс как угодно, только такой трактовкой мы разносим вообще всю теорию в пух и прах. А чё нам? Ща на ноль поделим и получим, что 4 = 5, а тип = контекст.

Разумеется, без Нильса Бора не обошлось. А как же? Великий авторитет древних — это руль форевер.

Ну и блистательный полёт мысли (надо же, прилетели таки?!)

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


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

За авторской подписью, случайно, не Бодхидхарма скрывается?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[7]: О правильных и неправильных классификациях...
От: Cyberax Марс  
Дата: 17.03.06 08:33
Оценка: 40 (2) +3 :)))
Кирилл Лебедев wrote:
> Критерии все-таки были. Хороший код — это *компактный* код.
Кхм....
#!/usr/bin/perl

$;="@{'`|;{'^'!.|-'}";$.++;$.++;$.++;$_="(.)?";/((?{$_.=$_}).)+$/;@_='~!@#$%^&*(
)_+`-=[]\\{}|;\':",./<>? '=~/$_/;@_ 
_=$;=~/$_/;$_="(.)*?";/((?{$_.=$_}).)+$/;$Z-=
$Z;"$.$."-$Z;/((?{$_ _[$z]&&!("${_[$x]}"^"${_[$y]}"^"${_ 
_[$z]}"^"$Z")&&($a.=$_[$x
],$b.=$_[$y],$z++);$x++;$y+=!($x%="$.$.");$y%="$.$.";}).)+/;$_="^"^"^";$_ 
_=".>.\
'$_ _ _$b')".".('!\@/\"'^'}.')".']}`';


Все еще уверены, что чем компактнее код — тем он лучше?
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re: О правильных и неправильных классификациях...
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.03.06 10:37
Оценка: 24 (2) :))) :)
Здравствуйте, Кирилл Лебедев, Вы писали:

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


Не в тему, но данное обсуждение напомнило:

<zenspider> singletons are almost always a sign of bad design.
<suryam> but i need it in my design... [...]
<zenspider> "need" is almost always a sign of bad thought.



SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: О правильных и неправильных классификациях...
От: Cyberax Марс  
Дата: 15.03.06 20:32
Оценка: 24 (2) +3
Кирилл Лебедев wrote:
> У подобного отношения могут быть такие обоснования:
> 1) Человек является профи, и ему действительно знакомо все то, о чем
> написано в статье.
> 2) Человек понимает статью лишь частично — улавливает знакомые вещи и не
> улавливает незнакомые. Например, понимает примеры и не понимает выводы.
Нет уж. Пусть лучше читает классиков, в которых процесс декомпозиции
задачи разбирается намного проще.

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

В случае с фигурой стоит отделить данные фигуры от метода ее
отображения. Вообще совсем отделить. Читайте любой пример про мультиметоды.

И я не понимаю зачем нужно делать механизм виртуальных функций вручную с
помощью таблицы функций. Осталось добавить в функции
"void DrawBezierX(CDeviceContext & rDC, const POINT * pPoints)" параметр
"void *pThis" и мы будем иметь хрестоматийный пример "виртуальность
своими руками".

В примере с аллокатором вообще куча ошибок. Например, он НЕ будет
работать с распределением double'ов на Sparc'ах (будет сразу валится по
SIGBUS) из-за проблем с выравниванием. Ну и я уж не говорю, что для
поиска утечек есть Rational Purify и Valgrind (или ElectricFence для
бедных), которые с этой задачей справляются наааааааааааамного лучше.


> Вообще в книжках по ООП и ООД, которые я читал, мало уделяется место

> методикам правильной постановки задач. Можно сказать, что вообще не
> уделяется. Та же книга "банды четырех" содержит перечень паттернов
> (приемов) проектирования. И совершенно не содержит описания ситуаций
> (задач).
В начале паттерна описывается ситуация когда он нужен, а в тексте
описывается чем этот паттерн грозит.

> Конечно, в описаниях самих паттернов приводятся описания и

> ситуаций, когда паттерн может быть использован. Но в этих описаниях *нет
> системы*. Нет сводной таблицы таких описаний, нет общего языка.
:O) Странно, а я вот вижу систему.

> Не уделяет книга "банды четырех" внимания и процессу формулирования

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

> Думаю, если вопросу постановки и классификации задач уделить должное

> внимание, то большинство паттернов можно свернуть в более компактную
> модель и даже открыть другие паттерны. Собственно говоря, к этому мы и
> стремимся.
Я новых паттернов хоть десяток могу левой пяткой накатать. На сайтах
типа theserverside.com их вообще коллекционируют (
http://www.theserverside.com/patterns/index.tss ).

Смылс в том, чтобы выделить какой-то один достаточно репрезентативный
набор паттернов. У GoF это неплохо получилось (хотя паттерн Intepreter я
бы выкинул нафиг).

> Судя по Вашему высказыванию, Вы рассматриваете пользователя, как

> источник хаотичных изменений, которые никак нельзя предусмотреть, и
> потому они разрушают архитектуру. Между тем уже давно известно, что
> системы развиваются не хаотично (под воздействием импульсивных желаний),
> а согласно законам развития (http://www.altshuller.ru/triz/zrts1.asp).
В морг ТРИЗ. Для программирования он неприменим — слишком велика
гибкость програмных систем.

> Эти законы познаваемы, а, следовательно, их вполне можно использовать

> для прогнозирования.
Ага, конечно.

Вот как пример, у меня есть компонент для отображения 3D-профиля плоской
поверхности (полученой с некого измерительного устройства). Угадайте,
что меня попросили добавить в него неделю назад?

> Это утверждение ложно, т.к. все задачи (за исключением задачи про стол)

> взяты из реальной практики. Да и у "стола" тоже были свои прототипы.
Ага, это показывает, что практика у вас плохая.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[4]: О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 15.03.06 19:32
Оценка: 13 (4) +1
Здравствуйте, Краснокутский Василий, Вы писали:

КВ>Преподносится все то же самое, только много, долго и нудно по сравнению с классиками. Ну абсолютно ничего нового... Я бы данный материал не рекомендовал.


Работая над первой статьей (http://www.triz-ri.ru/themes/method/creative/creative50.asp), мы столкнулись с подобным отношением со стороны ряда программистов. Наиболее частый упрек: "Все, что вы пишите, и так известно". Собственно, отсюда и пошло название статьи: "Как вспомнить и "так известное"?".

У подобного отношения могут быть такие обоснования:
1) Человек является профи, и ему действительно знакомо все то, о чем написано в статье.
2) Человек понимает статью лишь частично — улавливает знакомые вещи и не улавливает незнакомые. Например, понимает примеры и не понимает выводы.

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

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

Помимо этих соображений, есть еще и другие. Например, в первой статье поясняется "язык компактной записи сути креативных задач". Те, кто внимательно читал статью, очевидно помнят, что креативную задачу можно записать компактно, сформулировав противоречие. Кроме того, утверждается, что в программировании на текущий момент известны лишь всего 9 (девять!) видов креативных задач — девять видов противоречий. Конечно, самих задач гораздо больше. А вот их видов — всего девять. Думаю, что об этом Вы вряд ли могли где-нибудь прочесть. В этом, собственно говоря, и заключается новизна первой статьи.

Вообще в книжках по ООП и ООД, которые я читал, мало уделяется место методикам правильной постановки задач. Можно сказать, что вообще не уделяется. Та же книга "банды четырех" содержит перечень паттернов (приемов) проектирования. И совершенно не содержит описания ситуаций (задач). Конечно, в описаниях самих паттернов приводятся описания и ситуаций, когда паттерн может быть использован. Но в этих описаниях нет системы. Нет сводной таблицы таких описаний, нет общего языка.

Не уделяет книга "банды четырех" внимания и процессу формулирования (постановки) таких задач. А зря! Классики говаривали, что поставленная задача — это наполовину решенная задача.

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

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


Судя по Вашему высказыванию, Вы рассматриваете пользователя, как источник хаотичных изменений, которые никак нельзя предусмотреть, и потому они разрушают архитектуру. Между тем уже давно известно, что системы развиваются не хаотично (под воздействием импульсивных желаний), а согласно законам развития (http://www.altshuller.ru/triz/zrts1.asp). Эти законы познаваемы, а, следовательно, их вполне можно использовать для прогнозирования.

Конечно, если мыслить подсистемно, то спрогнозировать дальнейшее развитие программы (и отдельных ее частей) просто невозможно. Нужно рассматривать систему не саму по себе, а систему в контексте! См. 9-экранную систему мышления (http://www.altshuller.ru/triz/zrts6.asp).

Собственно, об этом мы и говорили во второй статье (http://www.triz-ri.ru/themes/method/creative/creative57.asp). И похоже, этого Вы как раз и не поняли.

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


Это утверждение ложно, т.к. все задачи (за исключением задачи про стол) взяты из реальной практики. Да и у "стола" тоже были свои прототипы.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[11]: О правильных и неправильных классификациях...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 19.03.06 19:02
Оценка: 47 (4)
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Здравствуйте, Геннадий Васильев,


КЛ>Вы опять читаете невнимательно, из сказанного берете только половину, а половину – упускаете. Над взятой половиной надстраиваете уже свои интерпретации и с ними спорите.


ГВ>> Общепринятый смысл термина "идеальность", это, всё-таки, приближение к некоей идее, в нашем случае — идее решения некоторой задачи.


КЛ>Процитирую еще раз определение идеальности, выделив пропущенные Вами места:


КЛ>Идеальная система – это система, которой нет, а функция ее выполняется.


КЛ>В данном случае функция как раз и есть та идея, к которой, в своем развитии, стремится система. И реализация этой функции (идеи, если Вам близок платонизм) тем ближе к идеалу, чем меньше ресурсов потрачено на ее (идеи) реализацию.


Любопытное высказывание. Любопытно оно своей слишком заметной двусмысленностью. С одной стороны — да, чем меньше затрат на разработку, тем лучше. С другой, разработка состоит по большому счёту из двух стадий — первичной разработки и длительного цикла сопровождения. Затраты на первичную разработку (реализацию) программы — это, "в среднем по больнице" где-то около 10%-40% от затрат на весь её жизненный цикл. То есть, с точки зрения стоимости девелопмента ключевой момент — стоимость сопровождения. А стоимость сопровождения, в немалой степени — функция понятности исходного текста. Понятность — суть характеристика взаимодействия человеческого разума с объектом. То есть, "понятность" невозможно рассматривать в отрыве от сопровождающего программиста.

Что получается? А получается, что неправомерно сводя обобщённую характеристикаму "идеальности" к конкретным свойствам программы можно попасть впросак. Например, можно закопаться в первичной стадии, пытаясь предусмотреть всё на свете, а можно и неоправданно усложнить сопровождение. Никогда не слышали о том, как ругаются програмисты в адрес менеджеров, которые говорят: "Это написано и работает — значит не надо ничего менять". Да, оно работет, но им неудобно пользоваться!

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

ГВ>>Вы противоречите сами себе. Если уж система развивается, а "идеальность" тем выше, чем система меньше, то становится ясно, что система развивается всегда только в одном направлении — к не-идеальности.


КЛ>Это не я противоречу сам себе, а Вы уподобляетесь схоласту, который, имея пару посылок, строит силлогизм и пытается, таким образом, вывести (дедуктивно) законы всего сущего. Или, наоборот, построить чисто формальное опровержение, основываясь на все тех же силлогизмах.


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

КЛ>Но схоластика потерпела фиаско на рубеже 16 – 17 веков. С наиболее аргументированной критикой такого подхода выступил Фрэнсис Бэкон в своей работе «Новый Органон».


КЛ>Оставаясь в рамках формальной логики, Вы вряд ли сможете постигнуть законы развития технических систем, как, собственно говоря, и любые другие законы, например, Закон Всемирного Тяготения или Второй Закон Ньютона, т.к. эти законы формально (при помощи силлогизмов) не выводятся.


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

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


Это более чем известно. Называется "уровнями абстракции". Не всегда разумно исключать воплощение уровня абстракции — это тоже далеко не новость.

КЛ>Еще удобнее рассматривать системы в развитии. Например, современный автомобиль гораздо идеальнее своего первого прототипа, т.к. ездит быстрее, а топливо жрет меньше. Т.е. выполняет функцию лучше, а ресурсов тратит меньше.


Внимание! С какой точки зрения? Только с точки зрения энергозатрат на перемещение! А по такой характеристике как цена/качество это может быть совсем не так.




Вы не совсем верно определяете "идеальность" программы, как функцию от её размера. Как я понимаю, противоречие индуцировано тем, что ТРИЗ, в основном, направлена на механические, "жёсткие" системы. По отношению к программированию это, мягко говоря, не совсем верно. "Механическое" изобретение можно построить на некоторых побочных эффектах, свойственных (имманентно присущих) физическим объектам. Ну как, например, в случае буксира и двух барж. В случае програмирования такой подход допустИм лишь отчасти, поскольку если гидродинамические характеристики баржи, например, будут неизменными ещё 30 лет, то о программах такого сказать обычно с уверенностью нельзя. Следовательно, создание заплатки (та самая приставка между носовыми оконечностями) может оказаться не самым подходящим путём. Уж лучше создать баржу с коэффицентом кратности для ёмкости.

На первое место в программостроении нередко выходит "явность", выраженность тех терминов (функций, модулей...), на базе которых строится новая программа. В известном смысле можно провести аналогию между программой и описанием (да-да, именно описанием!) изобретения из "механической" области. Никто не будет внедрять изобретение, которое построено на базе неизвестных (как минимум, неверифицируемых) эффектов. И в описании изобретения эти эффекты перечисляются тоже явно, то есть, по сути — "деидеализируются".

И в этом смысле идеальная программа вступает в противоречие с "идеальностью" в трактовке ТРИЗ. Даже более того! "Идеальная" ТРИЗ-овская программа подвергнется немедленной "де-идеализации" — проявлению, переработке, развитию, обкладыванию трассировками, логгированием и т.д., и т.п.

Например, с точки зрения ТРИЗ нет ничего предосудительного в том, чтобы воспользоваться каким-то побочным эффектом, скажем, функции быстрой сортировки. Например, количеством обращений к элементам сортируемого набора. Однако, это приведёт к появлению иной раз нежелательной зависимости клиентской части от внутренностей самой функции. Потом мы поменяем quick_sort на, например, bubble_sort и получим какой-то непонятный эффект. Чтобы избежать этого программисты напишут новую функцию, например count_array_by_specific_algorithm, т.е. — деидеализируют имевшееся решение. В чём прагматизм? В том, что в последнем случае в текст программы будет добавлен явно выраженный элемент, отражающий некоторое требование к системе.

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

В завершение скажу ещё раз, что нельзя упускать из виду такую характеристику программы, как её понятность. И далеко не всегда "понятная программа = короткая программа".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: О правильных и неправильных классификациях...
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 15.03.06 10:24
Оценка: 11 (2) +2
Здравствуйте, Prometey_, Вы писали:

P_>Собственно, этот же смысл можно найти и в книгах "вликолепной четверки", только у них об этом сказано гораздо эллегантней, и без лишнего кода. Краткость — сестра таланта.


Я так понимаю, цели то разные. Имхо, в данном случае — привить некий стиль мышления, а там справочник патернов.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[2]: О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 15.03.06 22:43
Оценка: 1 (1) +3
Здравствуйте, Геннадий Васильев,

Оставляю Ваши насмешки и оскорбления в стороне. Отвечаю по существу.

КЛ>>К сожалению, очень много программистов знают только один способ борьбы со сложностью — полиморфизм. И применяют его как к месту, так и не к месту. Но есть и другие способы группировки, есть критерии для объединения сущностей в группу, есть и типичные ошибки группирования.


ГВ>500 лет назад был обнародован принцип подстановки Лисковой. Фундаментальная вещь, надо сказать. Им обоснуются чуть ли не все паттерны.


Да, вещь. Да, фундаментальная. И что? К чему Вы привели это название? Какую связь оно имеет с приведенной цитатой?

ГВ>вообще нужно отлучать от кнопок и посылать в библиотеку. Однородность — суть принадлежность к одному роду (некоему множеству, определяемому сходностью характеристик), а не контексту. У меня на столе валяются курительная трубка и мобила. Однородные сущности? Да, но по критерию владельца. Это ещё не тип, поскольку трубка на столе моего соседа по лестничной клетке это тоже объект типа "трубка", но принадлежит

ГВ>она другому.

ГВ>Вообще говоря, понятие "тип" определяется как набор операций, которые можно произвести над объектом этого типа. Потому мобила и труба — суть разнотипные вещи. Ну или пусть автор вдумчиво курит мобильный телефон. Иррационалисты хреновы.


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

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


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

P.S.: Мне кажется, что избранный Вами тон уместно использовать в предвыборных роликах кандидатов, но никак не на профессиональном форуме. Даже если коллеги допустили ошибку, на профессиональном форуме уместно вежливо поправлять их. Желательно, с указанием точных ссылок и источников, если вопрос касается терминов или приоритетов.

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

Соответственно, дальнейшее обсуждение мне интересно, если оно будет носить профессиональный характер.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[23]: О правильных и неправильных классификациях...
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 21.03.06 06:50
Оценка: 1 (1) +3
Кирилл Лебедев,

КЛ>А я уверен, что действуют. Моя уверенность — против Вашей. С мнением бесполезно спорить. Нужны аргументы. Свои аргументы я привел. А как на счет Ваших?

КЛ>Извините, но проблема понимания — это проблема не только автора, но и читателя. В любом случае, на профессиональном форуме недостаточно просто высказать свое мнение. Мнение еще нужно обосновать.

Простите меня за замечание не относящееся к предмету обсуждения.

Мне думается, что выделять болдом имеет смысл только ключевые слова, их обычно 0-1 на абзац (на то они и ключевые). Если же ключевых слов становится слишком много, то я начинаю их ранжировать по "ключности" и пытаться выделить "самое ключевое" исходя из моих личных соображений. Это моё "самое ключевое" может оказаться совсем не тем, на чём хотел сделать акцент автор.

Если автор заботится о правильной расстановке акцентов, то непонимания обычно не возникает.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[15]: О правильных и неправильных классификациях...
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.03.06 14:12
Оценка: +4
Здравствуйте, Lazy Cjow Rhrr

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

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



SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: О правильных и неправильных классификациях...
От: Краснокутский Василий Россия  
Дата: 15.03.06 11:09
Оценка: 23 (3)
Здравствуйте, Кирилл Лебедев, Вы писали:

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


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

КЛ>На случай такой реакции у нас написана статья "Как вспомнить и "так известное" — http://www.triz-ri.ru/themes/method/creative/creative50.asp. Рекомендую!

Преподносится все то же самое, только много, долго и нудно по сравнению с классиками. Ну абсолютно ничего нового... Я бы данный материал не рекомендовал.

Поясняю:
Если у нас есть задача, то мы можем решить ее 1000 способов (это я про программирование), но при этом конечный результат развития данной реализации все же зависит от того, насколько хорошо нам известна предметная область и какой общий опыт/знания разработки систем данного класса. Дело в том, что нельзя сделать программу универсальной и все равно будут '+' и '-' у каждого подхода — либо в начале, либо в дальнейшем развитии ПО. Вопрос то в сущности не в сложности проектирования, а в том, что мы хотим от конечного кода. Пользователя не волнует как все это в программе реализовано (ну понятно, что для чего то пишем мы код, а не просто из удовольствия) и вопрос в том, что бы найти такой подход, что бы код был сопровождаем и расширяем с точки зрения программиста, но при этом еще и удобен для конечного пользователя. Авторы статьи рассматривают вопрос только с точки зрения кодирования и при этом теряется другая составляющая — потребности конечного пользователя. Я скажу больше — весь стройный код может сломаться от того, что пользователь придумал такое требование, которое в нашу архитектуру без большой переделки не влезает, а переписывать архитектуру каждый раз когда возникнут такие требования это самоубийство. Вот и появляются "сказки" про фиговых проектировщиков и т.п.

Мой вывод: Идеального кода не бывает — бывает код заточенный под определенный спектр изменений. Если потребовалось изменение не попадающее в эти границы, то у нас возникает проблема — либо ломать архитектуру и тратить время (читайте деньги), либо ставить "заплатку". Понятно, что с большей вероятностью будет поставлена заплатка. А то, что пытаются продемонстрировать авторы есть их понимание некой задачи в отрыве от пользователя, что суть совершенно неверно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: О правильных и неправильных классификациях...
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 16.03.06 08:26
Оценка: +2 :)
Здравствуйте, Cyberax, Вы писали:

C>В морг ТРИЗ. Для программирования он неприменим — слишком велика

C>гибкость програмных систем.

не понял связи. Или ты тоже сторонник мнения, что в программировании главное автокомплит, чтобы кода побольше наколотить?
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[9]: О правильных и неправильных классификациях...
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.03.06 09:49
Оценка: :)))
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Много синтаксического оверхеда. Это не компактный код. Это просто утоптанный код


Может вот это подойдет
Автор: Lazy Cjow Rhrr
Дата: 06.12.05
?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: О правильных и неправильных классификациях...
От: AVC Россия  
Дата: 17.03.06 09:48
Оценка: 24 (1) +1
Здравствуйте, Cyberax, Вы писали:

>> C>Вот так и методики ТРИЗа плохо приспособлены к проектированию.

>> Не понимаю почему. Тем более, что "оттуда паттерны и пришли".
C>Методы анализа задачи в ТРИЗе плохо подходят к программированию, к
C>сожалению.

Почему Вы так думаете? (Не спорю, а просто интересуюсь основанием уверенности.)

Тема интересная, жаль сейчас нет времени вникать в детали...
IMHO, обнаружение противоречий (в ТРИЗ-овском смысле) должно быть полезнее на более глубоком уровне.
Например, скорее — на уровне архитектуры, а не на уровне кода.
Попробую пояснить мысль примером. (И заранее прошу прощения, если пример окажется неудачным. Мало времени. )
Пример.
Некоторое время назад на RSDN велись споры об Обероне. (Я не собираюсь их возобновлять, а только хочу проиллюстрировать мысль.)
В адрес Оберона было высказано много (в т.ч. справедливой) критики.
В частности, в Обероне (по крайней мере, классическом) нет отдельных адресных пространств.
Попробуем посмотреть, как это получилось.
Одна из базовых метафор Оберона — программы не пишутся, не строятся, а "растут".
Снизу вверх: система просто дополняется новыми модулями поверх предыдущих.
Поэтому в Обероне нет main ни в какой форме: он ограничивал бы программу сверху, накрывал ее крышкой.
Расширение системы благодаря этому очень просто: написал новый модуль, откомпилировал и вызвал новую команду.
Это — "хорошие новости".
А "плохие" — в том, что при таком подходе мы имеем один связанный граф объектов на Оберон-систему.
В случае ошибки (и даже по запросу пользователя) выгрузить "испорченный" подграф трудно (если возможно).
IMHO, здесь имеется классическое "техническое противоречие" (в терминологии ТРИЗ).
Если найти его решение, то Оберон избавится от крупного недостатка.
Весьма вероятно, что эта проблема может быть решена частичным восстановлением в правах понятия "приложения" (программы, процесса), например, чем-то вроде "сборки".
Пока что, AFAIK, эта ситуация в Обероне не исправлена. (Правда, я могу быть не в курсе.)
На мой взгляд, так и развиваются архитектуры: через выявление и устранение противоречий.
На уровне кода, IMHO, это менее заметно.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[11]: О правильных и неправильных классификациях...
От: Cyberax Марс  
Дата: 17.03.06 09:06
Оценка: 12 (1) :)
Andrei N.Sobchuck wrote:
> Если есть ссылки — буду рад.
Гугл не может нормально искать с русской морфологией, и похоже там
неполные архивы (в RU.TRIZ _точно_ больще 6000 сообщений).

Вот на Яндексе нашел:
http://www.delphikingdom.com/asp/articles_forum.asp?ArticleID=485
(Внимание! На этом сайте замечен Сергей Губанов!)
http://dapissarenko.com/resources/2005_08_23_progTriz/index.html
И т.д.

> C>Вам сильно поможет знание приемов изобразительного искусства или

> архитектуры (оттуда паттерны и пришли, кстати)?
> Изобразительное искусство тут не причем. А архитектура — причем (напр.
> создание красивой и лёгкой напряжённой конструкции из монолитного бетона).
И как вам это поможет?

> C>Вот так и методики ТРИЗа плохо приспособлены к проектированию.

> Не понимаю почему. Тем более, что "оттуда паттерны и пришли".
Методы анализа задачи в ТРИЗе плохо подходят к программированию, к
сожалению.

> Архитектуру не святой же дух приносит. Её придумать нужно. И тут часто

> нет однозначных вариантов.
Да, но это не значит, что рецепты их строительства будут подходить к
программированию.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[5]: О правильных и неправильных классификациях...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 15.03.06 21:18
Оценка: 4 (1) :)
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Работая над первой статьей (http://www.triz-ri.ru/themes/method/creative/creative50.asp), мы столкнулись с подобным отношением со стороны ряда программистов. Наиболее частый упрек: "Все, что вы пишите, и так известно". Собственно, отсюда и пошло название статьи: "Как вспомнить и "так известное"?".


КЛ>У подобного отношения могут быть такие обоснования:

КЛ>1) Человек является профи, и ему действительно знакомо все то, о чем написано в статье.
КЛ>2) Человек понимает статью лишь частично — улавливает знакомые вещи и не улавливает незнакомые. Например, понимает примеры и не понимает выводы.

3) Не постиг сущность хлопка одной ладони.

КЛ>Судя по опыту общения, на мой взгляд, более вероятен вариант 2,


Ясен перец, как говорил Нильс Бор, дураков всегда больше.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[3]: О правильных и неправильных классификациях...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 16.03.06 02:13
Оценка: 4 (1) +1
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>>>К сожалению, очень много программистов знают только один способ борьбы со сложностью — полиморфизм. И применяют его как к месту, так и не к месту. Но есть и другие способы группировки, есть критерии для объединения сущностей в группу, есть и типичные ошибки группирования.

ГВ>>500 лет назад был обнародован принцип подстановки Лисковой. Фундаментальная вещь, надо сказать. Им обоснуются чуть ли не все паттерны.
КЛ>Да, вещь. Да, фундаментальная. И что? К чему Вы привели это название? Какую связь оно имеет с приведенной цитатой?

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

Всё очень просто: если у нас есть какой-нибудь if (тип=тег_типа), то считай, что уже приехали, можно идти и выкусывать ошибки проектирования.

ГВ>>вообще нужно отлучать от кнопок и посылать в библиотеку. Однородность — суть принадлежность к одному роду (некоему множеству, определяемому сходностью характеристик), а не контексту. У меня на столе валяются курительная трубка и мобила. Однородные сущности? Да, но по критерию владельца. Это ещё не тип, поскольку трубка на столе моего соседа по лестничной клетке это тоже объект типа "трубка", но принадлежит

ГВ>>она другому.

ГВ>>Вообще говоря, понятие "тип" определяется как набор операций, которые можно произвести над объектом этого типа. Потому мобила и труба — суть разнотипные вещи. Ну или пусть автор вдумчиво курит мобильный телефон. Иррационалисты хреновы.


КЛ>[...] Похожесть или непохожесть вещей задает контекст.


Можно, я не буду додумывать, кто кого тут задаёт? Переформулируйте тезис.

КЛ>По умолчанию Вы используете в качестве контекста функциональное назначение вещей. Поэтому и курительная трубка, и мобильный телефон суть разнородные вещи, т.к. выполняют разные функции.


Э... сначала переформулируйте тезис.

КЛ>Однако в завещании или в описи имущества конкретного человека эти вещи однородны, т.к. их функциональное различие в данном контексте не важно, а важно то, что они принадлежат одному владельцу.


Так... настала пора задать ещё один вопрос: что же такое "контекст"? Догадываться сам не буду. Вы — автор, вот сами и рассказывайте. Чем короче определение, тем лучше. И не надо определять его через иллюстрации.

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


КЛ>Про черту — это Ваше замечание, не наше. Мы классифицируем примеры, как порожденные одной и той же ошибкой — подсистемным мышлением.


Именно по наличию существенной черты (следа влияния ПМП) вы их и классифицируете.

КЛ>И в данном случае причина ошибки и выступает в роли контекста для примеров. Именно поэтому далеко не все примеры про иерархии.


Повторюсь: дайте определение понятия "контекст". Дальше поглядим, что получится.

КЛ>P.S.: Мне кажется, что избранный Вами тон уместно использовать в предвыборных роликах кандидатов, но никак не на профессиональном форуме. Даже если коллеги допустили ошибку, на профессиональном форуме уместно вежливо поправлять их. Желательно, с указанием точных ссылок и источников, если вопрос касается терминов или приоритетов.


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

КЛ>На мой взгляд, существует четкий критерий профессионализма. Это манера поведения человека во время обсуждения сложных проблем, задач, вопросов...


Нечёткий это критерий и проблема простая — отсутствие точного определения термина "контекст". Дайте его, дальше будет проще.

КЛ>Если человек беседует уважительно, тщательно аргументирует свои выводы, приводит корректные ссылки, то человек является профессионалом. Если человек занимается "шапкозакидательством", насмехается над собеседником, унижает его, обвиняет, не аргументируя свои обвинения, то такой человек вряд ли профессионал.


А что нужно аргументировать? Что автор должен следить за употребляемыми терминами? Это, в общем-то, не нуждается в дополнительной аргументации.

P.S.: А вот чего нельзя делать, так это пытаться переходить на личности собеседников. Насколько я помню, я никак не пытался определять "уровень профессионализма" автора статьи.

P.P.S.: Полезный источник: Гатэг, Лисков
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[25]: О правильных и неправильных классификациях...
От: FR  
Дата: 21.03.06 12:27
Оценка: 2 (2)
Здравствуйте, Кирилл Лебедев, Вы писали:

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


FR>>Где аргументы, пусть даже не доказывающие, а хотя бы показывающие что эти законы работатют в программных системах?


КЛ>Они есть и в данной дискуссии, и в статьях. Приведу лишь несколько ссылок:


Это не аргументы, а просто иллюстрации.

КЛ>1) Противоречия.

КЛ>http://www.triz-ri.ru/themes/method/creative/creative50.asp

КЛ>2) Системный оператор.

КЛ>http://www.triz-ri.ru/themes/method/creative/creative57.asp
КЛ>http://www.rsdn.ru/Forum/Message.aspx?mid=1780857&amp;only=1
Автор: Кирилл Лебедев
Дата: 14.03.06


абсолютно не обоснованные рассуждения об "очень многих программистах"

КЛ>3) Свертывание.

КЛ>http://www.rsdn.ru/Forum/Message.aspx?mid=1787738&amp;only=1
Автор: Кирилл Лебедев
Дата: 17.03.06


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

КЛ>4) Идеальность.

КЛ>http://www.rsdn.ru/Forum/Message.aspx?mid=1787710&amp;only=1
Автор: Кирилл Лебедев
Дата: 17.03.06

КЛ>http://www.rsdn.ru/Forum/Message.aspx?mid=1790859&amp;only=1
Автор: Кирилл Лебедев
Дата: 19.03.06


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

КЛ>И статьи, и сообщения достаточно развернуты и содержат много примеров.


КЛ>Соответственно, если Вы не согласны с выводами, то квалифицированный ответ строится по следующей схеме:


КЛ>П. 1 неверен, потому что существуют такие-то и такие-то примеры, где это нельзя применить.

КЛ>В п. 2 в примере автор перепутал то-то и то-то и стал исходить из ложных посылок.
КЛ>В п. 3 — аргументы по поводу п. 3.
КЛ>И т.д.


Это тут и без меня расписали, и я ставил оценки там где согласен.

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


КЛ>Именно по этой причине я предлагаю оценивать эффективность методики на конкретных задачах. Именно по этой причине я и предлагаю Вам — как квалифицированному специалисту — привести аргументы своих выводов.


А зачем повторятся?

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


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


К квалификации может отношения и не имеет, но имеет прямое отношение к программированию и проектированию. Это очень хорошо видно потому как разные люди предпочитают совершенно разные языки и парадигмы. Вообще программирование во многом "вынос своего мышления наружу" и поэтому подход к этому занятию только с инженерных позиций будет неполным и однобоким.
Вообще в отрасли уже есть целые малопересекающиеся области, например, функциональное программирование, ООП и обычное процедурное структурное, и представители разных областей часто очень плохо понимают друг друга, и одинаковые задачи решают очень по разному.
Re[14]: О правильных и неправильных классификациях...
От: AVC Россия  
Дата: 17.03.06 10:51
Оценка: 1 (1) +1
Здравствуйте, FR, Вы писали:

C>>>Методы анализа задачи в ТРИЗе плохо подходят к программированию, к

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

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

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


Мне трудно (пока?) об этом судить.
Спасибо К.Лебедеву, что дал мне повод задуматься о (возможном) применении ТРИЗ в программировании.
Предварительно (до основательного обдумывания этого вопроса) я придерживаюсь сдержанного оптимизма.
Основание: ТРИЗ есть частный (но самый эффективный) способ диалектического мышления.
Немного поясню, что я имею в виду, основываясь на предположении, что архитектура программной системы развивается путем выявления и устранения противоречий.
Несомненно, что под давлением недовольства пользователей недостатки и так будут устраняться.
Но здесь важно — как.
Добавлением очередной "заплатки", очередного частного решения (ограничиваясь исправлением отдельных дефектов), усложняющего систему, или решения основного архитектурного противоречия.
Я надеюсь, что применение ТРИЗ облегчит поиск таких принципиальных решений.
Поэтому я и заинтересовался этой темой.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[18]: О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 17.03.06 14:06
Оценка: 1 (1) +1
Здравствуйте, FR, Вы писали:

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

FR>И ничего прекрасно живут
Как раз-таки непрекрасно. Расплата заключается в резком увеличении сложности сопровождения таких программ. Например, я видел несколько программ, за которые ряд аутсорсеров просно не рискнули взяться, т.к. сложность сопровождения была очень высока. А те, что взялись, так и не смогли выполнить пожелания заказчика, т.к. просто не смогли побороть основные баги.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[5]: О правильных и неправильных классификациях...
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.03.06 10:09
Оценка: +2
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Кроме того, утверждается, что в программировании на текущий момент известны лишь всего 9 (девять!) видов креативных задач — девять видов противоречий. Конечно, самих задач гораздо больше. А вот их видов — всего девять.


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

КЛ>Вообще в книжках по ООП и ООД, которые я читал, мало уделяется место методикам правильной постановки задач. Можно сказать, что вообще не уделяется. Та же книга "банды четырех" содержит перечень паттернов (приемов) проектирования. И совершенно не содержит описания ситуаций (задач). Конечно, в описаниях самих паттернов приводятся описания и ситуаций, когда паттерн может быть использован. Но в этих описаниях нет системы. Нет сводной таблицы таких описаний, нет общего языка.


КЛ>Не уделяет книга "банды четырех" внимания и процессу формулирования (постановки) таких задач. А зря! Классики говаривали, что поставленная задача — это наполовину решенная задача.


Прочти предисловие к GoF от авторов. Думаю это многое прояснит. Нельзя объять необъятное.

КЛ>Собственно, об этом мы и говорили во второй статье (http://www.triz-ri.ru/themes/method/creative/creative57.asp). И похоже, этого Вы как раз и не поняли.


Это, кстати, в большей части проблема статьи, а не читателя.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[3]: О правильных и неправильных классификациях...
От: EvilChild Ниоткуда  
Дата: 16.03.06 20:04
Оценка: +1 :)
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>P.S.: Мне кажется, что избранный Вами тон уместно использовать в предвыборных роликах кандидатов, но никак не на профессиональном форуме. Даже если коллеги допустили ошибку, на профессиональном форуме уместно вежливо поправлять их. Желательно, с указанием точных ссылок и источников, если вопрос касается терминов или приоритетов.


КЛ>На мой взгляд, существует четкий критерий профессионализма. Это манера поведения человека во время обсуждения сложных проблем, задач, вопросов... Если человек беседует уважительно, тщательно аргументирует свои выводы, приводит корректные ссылки, то человек является профессионалом. Если человек занимается "шапкозакидательством", насмехается над собеседником, унижает его, обвиняет, не аргументируя свои обвинения, то такой человек вряд ли профессионал.


Золотые слова.
Если бы ими руководствовались при написании сообщений в форум, то не приходилось бы скипать такое количества мусора среди них.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: О правильных и неправильных классификациях...
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 17.03.06 08:44
Оценка: +2
Здравствуйте, Cyberax, Вы писали:

C>Кирилл Лебедев wrote:

>> Критерии все-таки были. Хороший код — это *компактный* код.
C>Кхм....
C>#!/usr/bin/perl

C>$;="@{'`|;{'^'!.|-'}";$.++;$.++;$.++;$_="(.)?";/((?{$_.=$_}).)+$/;@_='~!@#$%^&*(
C>)_+`-=[]\\{}|;\':",./<>? '=~/$_/;@_ 
C>_=$;=~/$_/;$_="(.)*?";/((?{$_.=$_}).)+$/;$Z-=
C>$Z;"$.$."-$Z;/((?{$_ _[$z]&&!("${_[$x]}"^"${_[$y]}"^"${_ 
C>_[$z]}"^"$Z")&&($a.=$_[$x
C>],$b.=$_[$y],$z++);$x++;$y+=!($x%="$.$.");$y%="$.$.";}).)+/;$_="^"^"^";$_ 
C>_=".>.\
C>'$_ _ _$b')".".('!\@/\"'^'}.')".']}`';


C>Все еще уверены, что чем компактнее код — тем он лучше?


Много синтаксического оверхеда. Это не компактный код. Это просто утоптанный код
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[11]: О правильных и неправильных классификациях...
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.03.06 11:58
Оценка: +1 -1
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Попробую дать своё определение: (нестрогое, и вообще не определение)

LCR>Краткость — это мера концентрации идей, чем выше концентрация, тем выше краткость. Ну и чем выше краткость, тем лучше.

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

Кстати, просто для уточнения твоей точки зрения. Считаешь ли ты, что по компактности записи:
basicmatrix[elementaryrow][elementarycolumn] ++;

и
m[i ][j] ++;

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: О правильных и неправильных классификациях...
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 17.03.06 14:07
Оценка: +1 -1
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 и анализировать в непринуждённой обстановке. Как правило такой анализ "с закрытыми глазами" происходит эффективнее.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[20]: О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 18.03.06 15:52
Оценка: 12 (1)
Здравствуйте, FR, Вы писали:

FR>Все это так, но вопрос в том может ли тут помощь ТРИЗ, и эффективнее ли он чем классические методики?


Классическая ТРИЗ включает ряд инструментов различных системных уровней и уровней сложности:

1. Приемы устранения технических противоречий (http://www.altshuller.ru/triz/tools.asp).
2. Систему стандартов (http://www.altshuller.ru/triz/standards0.asp).
3. Алгоритм решения изобретательских задач (http://www.altshuller.ru/triz/ariz.asp).
4. Физические, химические, геометрические эффекты (http://www.altshuller.ru/triz31.asp, http://www.altshuller.ru/triz32.asp).
5. Законы развития технических систем (http://www.altshuller.ru/triz/zrts.asp).
6. Методы борьбы с психологической инерцией (http://www.altshuller.ru/triz36.asp).
7. Курс развития творческого воображения (http://www.altshuller.ru/rtv/).
8. Системный оператор (http://www.altshuller.ru/triz/zrts6.asp).

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

Тем не менее, другие инструменты и понятия ТРИЗ (высокого системного уровня), например, законы развития технических систем, идеальность, системный оператор могут быть использованы для решения сложных "программистских" задач. Собственно, мы это попытались показать в своих статьях. Например, статья "Освобождение узников оператора "IF" (http://www.triz-ri.ru/themes/method/creative/creative57.asp) как раз про системный оператор.

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

Тем не менее, более простые инструменты ТРИЗ, "заточенные" под решение "программистских" задач создать все-таки возможно. Только для этого нужно пользоваться не простым переносом приемов из "железной" ТРИЗ, а созданием и анализом информационного фонда. Собственно, такая работа уже ведется, и опубликованные статьи — лишь "первые ласточки".
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[9]: О правильных и неправильных классификациях...
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.03.06 19:38
Оценка: 10 (1)
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

C>>Все еще уверены, что чем компактнее код — тем он лучше?


LCR>Много синтаксического оверхеда. Это не компактный код. Это просто утоптанный код


Это не синтаксический оверхэд. Это классический пример во что выливается стремление к компактности если при этом упускается из виду абстрагирование и декомпозиция.

Я уже не раз замечал, что менее компактный, но более поддающийся декомпозиции и абстрагированию EBNF воспринимается намного лучше чем более компактные регулярные выражения.

При этом синтаксический оверхэд скорее в EBNF, но при этом читается он намного лучше.

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

Есть три способа повысить компактность:
1. Использовать короткие идентификаторы и символьные сокращения. Это путь регекспов, Перла и многих функциональных языков.
2. Использоват массу умолчаний. Опять же многие ФЯ этим злоупотребляют.
3. Описание задачи с использованием высокоуровневых абстракций с отдельной детализацией абстракций. Этот путь доступен почти в любом современном языке программирования, но к сожалению он требует усилий от программиста, а значит целиком и полностью зависит от его оптыта. Язык может только подталкивать к декомпзиции предоставляя удобные средства для этого. ООП, функции высшего порядка, да и просто процедуры — это все средства декомпозиции.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: О правильных и неправильных классификациях...
От: Cyberax Марс  
Дата: 16.03.06 09:26
Оценка: 1 (1)
Andrei N.Sobchuck wrote:
> C>В морг ТРИЗ. Для программирования он неприменим — слишком велика
> C>гибкость програмных систем.
> не понял связи. Или ты тоже сторонник мнения, что в программировании
> главное автокомплит, чтобы кода побольше наколотить?
Нет, просто я не выношу упоминания ТРИЗа применительно к
программированию. Не видел ни одного реального примера, когда бы он
помог сделать правильное архитектурное решение.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[10]: О правильных и неправильных классификациях...
От: AVC Россия  
Дата: 19.03.06 20:09
Оценка: 1 (1)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Внимание! Ключевое слово — "физические"!


Вряд ли.
AFAIR, в ТРИЗ "физические" противоречия отличаются от "административных" тем, что в них противоречивые требования предъявляются к одному объекту.
Думаю, что "природа" объекта здесь не так важна.

ГВ>Вот теперь догадайтесь, какое из этих правил вы сами и нарушаете.


Геннадий, мне просто интересно: а вот такое высказывание

http://www.rsdn.ru/Forum/Message.aspx?mid=1785096&amp;only=1

ничего не нарушает?

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[13]: О правильных и неправильных классификациях...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 19.03.06 22:21
Оценка: 1 (1)
Здравствуйте, AVC, Вы писали:

ГВ>>"Физический" объект это не совсем то же самое, что и "информационный" объект. Не нужно сводить методологию к метафизике.


AVC>"Физический" объект, действительно, не совсем то же самое, что и "информационный".

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

+1

AVC>"Техническое" противоречие фиксирует отношение между двумя элементами системы (один "улучшаем" — второй "ухудшается").

AVC>Это, так сказать, на поверхности.
AVC>А "физическое" противоречие докапывается — почему не получается исправить первый, не портя второй.
AVC>Суть в том, что где-то мы предъявляем противоположные требования к одному элементу системы.

+1

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

AVC>Терминология, конечно, несет суровый отпечаток первоначальной сферы применения ТРИЗ.


Дык о том-то и речь. Иначе мы просто не можем с легкостью понимать высказывания друг друга. То есть, приходится додумывать: а) что автор имел ввиду исходя из анализа материалов по его области, б) как это проецируется на мою область деятельности, в) в чём противоречие и г) как это противоречие сформулировать на обоюдопонятном языке исходя из специфических искажений семантики терминов. Всё потому, что автор не позаботился об адекватном переносе терминологии.

Собственно, поэтому я так часто и упоминаю Дзен-буддизм. Аналогия напрашивается сама собой: прочесть то, сказано, вроде бы, обычными словами (получить коан), грокнуть, что хотел сказать автор (решить коан), перевести продукт понимания на общий язык ("...горы стали горами"). Ну, или если покороче — то "найти ту траву, которую курил автор".

AVC>Что есть — то есть.

AVC>Но, в принципе, речь идет о системном мышлении. А оно не ограничено одной сферой применения.

Даже это понятно, уж поверь. Только вопрос в том, какой предлагается инструментарий вербализации этого самомго системного мышления.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: О правильных и неправильных классификациях...
От: Mikhail Polykovsky Россия http://glader.ru
Дата: 14.03.06 12:42
Оценка: +1
КЛ>Собственно, об этом рассказывается в этой статье:
КЛ>http://www.triz-ri.ru/themes/method/creative/creative57.asp

Логический вывод паттернов
Re: О правильных и неправильных классификациях...
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 14.03.06 14:39
Оценка: :)
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Собственно, об этом рассказывается в этой статье:

КЛ>http://www.triz-ri.ru/themes/method/creative/creative57.asp

Александр Сергеевич Усов, говорит примерно о том же, но другими словами, и Гради Буча тоже высмеивает (делает ему "взБучку" от "vs.Booch-car").
Re[2]: О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 15.03.06 09:13
Оценка: +1
Здравствуйте, ie, Вы писали:

ie> но сравнение разработчика столов и Буча с датчиками (как впрочем и с окнами) просто неадекватное. Если бы столы составляли иерархию и в следствии этого присутсвовал матчинг по типам, то безусловно такое сравнение должно было быть, а в данном случае оно неуклюже пытается связать ни как не связанные примеры.


Эти примеры одинаковы с той точки зрения, что разработчик мыслит подсистемно, т.е. проектирует от части, а не от целого. В случае со столами — это ножки, в случае с Гради Бучем — это датчики (или даже отдельно взятый датчик температуры).
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[6]: О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 16.03.06 21:11
Оценка: :)
Здравствуйте, Краснокутский Василий, Вы писали:

КВ>На ваше сообщение уже ответил Cyberax и сделал это хорошо.

Похоже, необходимо вернуться к причине дискуссии. В предыдущем сообщении Вы заявили, что статья не содержит ничего нового. В качестве примера нового я Вам привел модели постановки задач (через противоречия). Но Вы это обошли молчанием. Так что будем считать, что новое все-таки было.

Теперь относительно всего остального. Чем дальше я общаюсь с Вами, тем больше склоняюсь к варианту 2. Почему? Сейчас поясню.

КВ>1. Не вижу критериев по которым код оценивает как хороший или плохой.


Критерии все-таки были. Хороший код — это компактный код. В пределе хороша ситуация, когда кода нет, а функция его выполняется. Поэтому идеальный код — это отсутствующий код. Такой код легче всего сопровождать (т.е. вообще сопровождать не надо).

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

С этой точки зрения все приведенные в статье задачи одинаковы. И решения их тоже одинаковы. Вернее, не решения, а принципы (приемы), с помощью которых они получены.

КВ>2. Кстати, не видел общих диаграмм системы, а только кодинг.


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

КВ>3. Статья очень тяжело читается, потому что, во первых много ошибок в коде,

Это утверждение ложно. Привидите примеры ошибок.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[9]: О правильных и неправильных классификациях...
От: FR  
Дата: 17.03.06 08:53
Оценка: +1
Здравствуйте, Кирилл Лебедев, Вы писали:

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


ANS>>Не нужен цикл. Нужна отдельная функция/метод. И дальше, что угодно. А вот куда это метод вынести, это уже вопрос...


КЛ>Пожалуйста, приведите Ваше решение.


Так судя по вашему коду нет проблем с выносом повторяющегося фрагмента в отдельную функцию.
А чтобы требовать решение надо формальную постоновку задачи, может решать ее лучше совсем по другому(например используя регулярные выражения).
Re[12]: О правильных и неправильных классификациях...
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 17.03.06 09:09
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

>> C>Вот так и методики ТРИЗа плохо приспособлены к проектированию.

>> Не понимаю почему. Тем более, что "оттуда паттерны и пришли".
C>Методы анализа задачи в ТРИЗе плохо подходят к программированию, к

Мы повторяемся
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[15]: О правильных и неправильных классификациях...
От: FR  
Дата: 17.03.06 11:28
Оценка: +1
Здравствуйте, Andrei N.Sobchuck, Вы писали:

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


C>>>>Методы анализа задачи в ТРИЗе плохо подходят к программированию, к

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

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


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

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


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


Конечно есть, но их уровень не сравним.
Re[16]: О правильных и неправильных классификациях...
От: Трурль  
Дата: 17.03.06 12:37
Оценка: +1
Здравствуйте, FR, Вы писали:

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

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

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


Ну, вряд ли можно запрограмировать вычисление невычислимой функции.
Re[13]: О правильных и неправильных классификациях...
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.03.06 12:39
Оценка: +1
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

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

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

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[11]: О правильных и неправильных классификациях...
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.03.06 19:38
Оценка: +1
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>В добрый путь. Я попробую на J:

LCR>
LCR>divmod=: <.@% , |~

LCR>anag=: (4 : 0)^:(1: < #@])
LCR>  'q n'=. x. divmod !<:#y.
LCR>  (q{y.) , n anag (q{.y.) , (>:q)}.y.
LCR>)


Ужас. И зачем такими извращениями вообще заниматься?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 18.03.06 21:50
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

C>Все еще уверены, что чем компактнее код — тем он лучше?


То, что Вы продемонстрировали, как раз и называется подсистемным мышлением. Судя по приведенному примеру, Вы предполагаете, что программный код – это набор символов. Но это неправильно! Это все равно, что предполагать, будто дом – набор кирпичей или строительных блоков.

Так же, как письменная речь не сводится к набору букв, так и программный код – нечто большее, чем набор символов. Код имеет иерархическую структуру, и на каждом уровне этой иерархии в качестве элементов выступают разные абстракции:

0. Символы.
1. Слова (операторы, переменные, константы, типы данных).
2. Функции и функциональные блоки.
3. Типы данных, определяемые пользователем.
4. Иерархии, группы связанных классов.
5. Библиотеки.
6. И т.д. – наверняка что-то пропустил.

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

Как я уже писал, для задания критерия качества кода мне привычнее пользоваться понятием идеальность. Это «тризовский» термин, и суть его заключается в следующем:

Идеальная система – эта система, которой нет, а функция ее выполняется.

Применительно к программному коду, это правило будет звучать так:

Идеальный код – это код, которого нет, а функция его выполняется.

Понятно, что в реальной жизни ни идеальных технических систем, ни идеального программного кода не существует. Идеальность – это модельное понятие. Это предел, к которому в своем развитии стремится любая система (самолет или модуль искусственного интеллекта для гоночной игры).

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

Например, для хранения координат и выполнения операций над ними можно использовать встроенные типы данных:
int iOldX;
int iOldY;
int cx;
int cy;
//...
int iNexX = iOldX + cx;
int iNewY = iOldY + cy;

А можно создать свои типы данных и выразить те же самые действия иначе:
CPoint pt;
CSize sz;
//...
CPoint pt1 = pt + sz;

Мы видим, что вторая запись компактнее, а, следовательно, идеальнее. Ее компактность обеспечивается не небольшим количеством символов (системный уровень 0), а небольшим количеством слов – названий переменных и операторов (системный уровень 1).

В данном случае, повышение идеальности на уровне 1 привело к небольшому снижению идеальности на уровнях 2 и 3 – нам пришлось добавить классы CPoint и CSize и определить оператор ‘+’ для этих типов данных. Соответственно, мы можем повысить идеальность на этих уровнях, если будем использовать уже готовую библиотеку, где классы CPoint и CSize определены (например, MFC). В этом случае, правда, ухудшится идеальность на уровне 5. Но если библиотека уже была нами использована для каких-то иных целей, то снижение идеальности не произойдет.

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

О чем это говорит? О том, что любое правило нельзя применять бездумно. Нужно четко видеть различные системные уровни и изменения, которые происходят на них в процессе развития или под воздействием правила. Как было написано в статье, отсутствие системного мышления – типовая ошибка разработчиков и причина «глючного» кода. Подозреваю, что по этой причине просьба Заказчика о внесении изменений в Ваш компонент оказалась неожиданной. Потому что Вы оперируете одной системой, одним компонентом, а не классами подобных систем и не классами подобных компонентов.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[10]: О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 19.03.06 14:15
Оценка: +1
Здравствуйте, Геннадий Васильев,

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

ГВ> Общепринятый смысл термина "идеальность", это, всё-таки, приближение к некоей идее, в нашем случае — идее решения некоторой задачи.


Процитирую еще раз определение идеальности, выделив пропущенные Вами места:

Идеальная система – это система, которой нет, а функция ее выполняется.

В данном случае функция как раз и есть та идея, к которой, в своем развитии, стремится система. И реализация этой функции (идеи, если Вам близок платонизм) тем ближе к идеалу, чем меньше ресурсов потрачено на ее (идеи) реализацию.

ГВ>Вы противоречите сами себе. Если уж система развивается, а "идеальность" тем выше, чем система меньше, то становится ясно, что система развивается всегда только в одном направлении — к не-идеальности.


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

Но схоластика потерпела фиаско на рубеже 16 – 17 веков. С наиболее аргументированной критикой такого подхода выступил Фрэнсис Бэкон в своей работе «Новый Органон».

Оставаясь в рамках формальной логики, Вы вряд ли сможете постигнуть законы развития технических систем, как, собственно говоря, и любые другие законы, например, Закон Всемирного Тяготения или Второй Закон Ньютона, т.к. эти законы формально (при помощи силлогизмов) не выводятся.

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

Еще удобнее рассматривать системы в развитии. Например, современный автомобиль гораздо идеальнее своего первого прототипа, т.к. ездит быстрее, а топливо жрет меньше. Т.е. выполняет функцию лучше, а ресурсов тратит меньше.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[11]: О правильных и неправильных классификациях...
От: Cyberax Марс  
Дата: 19.03.06 15:02
Оценка: :)
AVC wrote:
>> > Качественная архитектура должна быть расширяемой. Это означает, что
>> > разработчик должен спрогнозировать возможные направления развития
>> > системы.
> C>Сразу все возможные направления? Не подскажете, случайно, как это сделать?
> *В принципе* (на деталях не настаиваю) — как в Обероне.
Ррррррррррр.

> В основе минимальный набор основных модулей.

Если честно, то мне плевать на модули. Совсем.

У меня почти все программы "монолитны", то есть сделаны в виде одного
большого изображения. Но тем не менее расширяемы на уровне исходного кода.

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

> Система расширяется добавлением новых модулей поверх предыдущих.

Ничерта не "расширяется". Просто "добавляется".
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[10]: Опечатка
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 19.03.06 20:00
Оценка: :)
Фразу:

ГВ>С вами спорят далеко самые не типичные представители "большинства".


Читать как: С вами спорят далеко не самые типичные представители "большинства".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[12]: Блин, опять опечатка
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 19.03.06 20:44
Оценка: :)
ГВ>...сие высказывание не не нарушает.
Имеется ввиду: "...сие высказывание не нарушает".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[22]: О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 20.03.06 18:10
Оценка: +1
Здравствуйте, FR, Вы писали:

FR>А вот насчет законов развития технических систем, я не уверен что они также действуют в программных системах как и в технических.


А я уверен, что действуют. Моя уверенность — против Вашей. С мнением бесполезно спорить. Нужны аргументы. Свои аргументы я привел. А как на счет Ваших?

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


Это не так. См. дискуссию про идеальность.

FR>Извините пока такой работы не видно. Видна только чистая философия, на ней далеко не уедешь.


Извините, но проблема понимания — это проблема не только автора, но и читателя. В любом случае, на профессиональном форуме недостаточно просто высказать свое мнение. Мнение еще нужно обосновать.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[22]: О правильных и неправильных классификациях...
От: AVC Россия  
Дата: 21.03.06 12:36
Оценка: +1
Здравствуйте, FR, Вы писали:

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


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

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re: О правильных и неправильных классификациях...
От: ie Россия http://ziez.blogspot.com/
Дата: 15.03.06 04:48
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Собственно, об этом рассказывается в этой статье:

КЛ>http://www.triz-ri.ru/themes/method/creative/creative57.asp

Ряд идей предлагаемых в статье, мне видятся хорошими. Непонравилось одно. Хотя и все примеры с вашей точки зрения "однородны" относительно пресловутого IF, но сравнение разработчика столов и Буча с датчиками (как впрочем и с окнами) просто неадекватное. Если бы столы составляли иерархию и в следствии этого присутсвовал матчинг по типам, то безусловно такое сравнение должно было быть, а в данном случае оно неуклюже пытается связать ни как не связанные примеры.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Превратим окружающую нас среду в воскресенье.
Re: О правильных и неправильных классификациях...
От: Краснокутский Василий Россия  
Дата: 15.03.06 08:02
Оценка:
Честно говоря не понял что такого нового можно извлечь из данной стать. Такое ощушение, что авторы статьи пытаются вывести базовые принципы ООП заново. Все изложенное в статьях уже давно классифицировано и разложено по полочкам.

Почитайте статьи Robert C. Martin на www.objectmentor.com
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: О правильных и неправильных классификациях...
От: GlebZ Россия  
Дата: 15.03.06 08:59
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

В данном случае можно говорить о направленности проектирования на наследование, и на сервис-ориентированность. В случае сервис ориентированости таких проблем нет. Это проблема хренового наследования.
Re[2]: О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 15.03.06 09:19
Оценка:
Здравствуйте, Краснокутский Василий, Вы писали:

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

На случай такой реакции у нас написана статья "Как вспомнить и "так известное" — http://www.triz-ri.ru/themes/method/creative/creative50.asp. Рекомендую!
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re: О правильных и неправильных классификациях...
От: Prometey_ Казахстан vingrad.ru
Дата: 15.03.06 10:11
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

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


КЛ>Собственно, об этом рассказывается в этой статье:

КЛ>http://www.triz-ri.ru/themes/method/creative/creative57.asp

Собственно, этот же смысл можно найти и в книгах "вликолепной четверки", только у них об этом сказано гораздо эллегантней, и без лишнего кода. Краткость — сестра таланта.
Re[4]: О правильных и неправильных классификациях...
От: GlebZ Россия  
Дата: 15.03.06 11:55
Оценка:
Здравствуйте, Краснокутский Василий, Вы писали:

А я скажу еще больше. В наше итерационное время требований для следующей итерации вообще не может существовать в природе. Поэтому надо закладывать гибкость изначально. Кое-что будет из заложенного использовано, кое-что никогда не будет. Только закладываться надо, иначе будет значительно больнее. И тут уже во многом играет эвристика.
Так что в некотором виде автор прав. Просто там изначально ошибочные подходы, без какой либо закладки на развитие.
Re[2]: О правильных и неправильных классификациях...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 15.03.06 21:14
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Александр Сергеевич Усов, говорит примерно о том же, но другими словами, и Гради Буча тоже высмеивает (делает ему "взБучку" от "vs.Booch-car").


Буча не высмеивает только ленивый. Ниспровергатели, блин.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: Дополнение про (*)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 15.03.06 21:27
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

А кто мне объяснит, чем "дизайн от подсистемы" отличается от "дизайна от контекста"? Подсистема уже перестала быть контекстом?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: Дополнение про (*)
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 15.03.06 22:13
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>А кто мне объяснит, чем "дизайн от подсистемы" отличается от "дизайна от контекста"? Подсистема уже перестала быть контекстом?


Подсистема является контекстом (надсистемой) для систем, образующих ее. Для системы, в которую она входит, она контекстом не является.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[3]: Дополнение про (*)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 15.03.06 22:24
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

ГВ>>А кто мне объяснит, чем "дизайн от подсистемы" отличается от "дизайна от контекста"? Подсистема уже перестала быть контекстом?


КЛ>Подсистема является контекстом (надсистемой) для систем, образующих ее. Для системы, в которую она входит, она контекстом не является.


Сиречь, речь идёт о реюзинге?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: О правильных и неправильных классификациях...
От: Краснокутский Василий Россия  
Дата: 16.03.06 08:21
Оценка:
Здравствуйте, Кирилл Лебедев,
На ваше сообщение уже ответил Cyberax и сделал это хорошо. От себя добавить могу следующее:
1. Не вижу критериев по которым код оценивает как хороший или плохой. Введите четкие критерии которые можно оценить количественно и продолжим разговор. Если опираетесь на общепринятые критерии, то опишите на какие именно и как Вы их оцениваете. Со своей стороны могу порекомендовать следующие критерии с точки зрения программиста: хрупкость, монолитность, переиспользуемость, расширяемость. С точки зрения пользователя: удобство интерфейса (да да, оно оценивается и достаточно много методик это сделать количественно), скорость работы, функциональное наполнение. Без критериев оценки все ваши утверждения пустой звук. Это как про задачу построить дом. Вы старательно строите дом по всей правде технологий, а вам говорят что он предназначен для семейства жирафов которые любят купаться в болоте...
2. Разбиение на системы зависит во первых от задачи, а во вторых от направления дальнейшего развития выявленного эвристическим путем основываясь на опыте и знании предметной области. Очень интересно ваше утверждение, что Вы мыслите основываясь на общем, а не на частном и при этом действуете в отрыве от тех самых требований которые будут предъявляться к решению Вашей задачи. Кстати, не видел общих диаграмм системы, а только кодинг. Кодинг вещь интересная, все же в процессе разработки она занимает около 20% всего времени. Где разбор прецендентов, анализ требований, модель системы ? Ничего этого я не видел. Статья по сложному вопросу спускает все на уровень кодинга... Если как Вы утверждаете правильно поставленная задача есть половина решения, то при чем здесь кодинг ? У нас что, решением задачи является код или все же продукт ?? Это разные вещи, Вам не кажется ?
3. Статья очень тяжело читается, потому что, во первых много ошибок в коде, а во вторых непонятно где выводы. Т.е. я то понимаю что Вы этим хотите сказать, но все же изложение в таком ключе это плохое изложение. Читайте классиков, вот там изложение такое, что можно вообще не знать языка примеров, но при этом все понять. У Вас же, извините, дебри кода.
4. Утверждение о предсказуемости систем это сильно... Даже спорить не буду с этим утверждением — оно оторвано от реальности.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: О правильных и неправильных классификациях...
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 16.03.06 09:46
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Нет, просто я не выношу упоминания ТРИЗа применительно к

C>программированию. Не видел ни одного реального примера, когда бы он
C>помог сделать правильное архитектурное решение.

А что мешает то? Может просто никто не пытался приложить его к программированию? Если я всё правильно понимаю, то "справочники патернов" aka аналоги решений широко применяются в ТРИЗ, прочтение GoF не отменяет необходимость думать, программирование — инженерная специальность, знанение техник ТРИЗ-а не отменяет необходимость знания технологий программирования. То биш противопоказаний пока не вижу.

ЗЫ. А организация виртуальности ручками — это конечно глупость
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[6]: О правильных и неправильных классификациях...
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 16.03.06 09:46
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


Кстати, afair это ты рассказывал о том как для поиска утучек в Жабе, в конструкторе объекта запоминался стек-трейс, а в финализаторе он печатался в лог.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[7]: О правильных и неправильных классификациях...
От: FR  
Дата: 16.03.06 09:48
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

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


C>>В морг ТРИЗ. Для программирования он неприменим — слишком велика

C>>гибкость програмных систем.

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


А какое отношение ТРИЗ имеет к автокомплиту?

Вообще конечно интересно посмотреть на прикрутку ТРИЗ к программированию и проектированию, но мне кажется не будет он в нашей области эффективно работать.
Re[9]: О правильных и неправильных классификациях...
От: Cyberax Марс  
Дата: 16.03.06 10:02
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>А что мешает то? Может просто никто не пытался приложить его к программированию?

Пытались, на моей памяти в FIDO были ссылки на несколько таких попыток.

ANS>Если я всё правильно понимаю, то "справочники патернов" aka аналоги решений широко применяются в ТРИЗ, прочтение GoF не отменяет необходимость думать, программирование — инженерная специальность, знанение техник ТРИЗ-а не отменяет необходимость знания технологий программирования. То биш противопоказаний пока не вижу.

Вам сильно поможет знание приемов изобразительного искусства или архитектуры (оттуда паттерны и пришли, кстати)? Вот так и методики ТРИЗа плохо приспособлены к проектированию.

ANS>ЗЫ. А организация виртуальности ручками — это конечно глупость

Sapienti sat!
Re[7]: О правильных и неправильных классификациях...
От: Cyberax Марс  
Дата: 16.03.06 10:05
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

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

ANS>Кстати, afair это ты рассказывал о том как для поиска утучек в Жабе, в конструкторе объекта запоминался стек-трейс, а в финализаторе он печатался в лог.
Ага. Только дело в том, что я это использовал для сравнительно небольшого количества нативных ресурсов. И цель была не найти утечки, а найти неправильное использование. Valgrind тут бы мало чем помог.
Sapienti sat!
Re[10]: О правильных и неправильных классификациях...
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 16.03.06 11:05
Оценка:
Здравствуйте, Cyberax, Вы писали:

ANS>>А что мешает то? Может просто никто не пытался приложить его к программированию?

C>Пытались, на моей памяти в FIDO были ссылки на несколько таких попыток.

Не нашол. Если есть ссылки — буду рад.

ANS>>Если я всё правильно понимаю, то "справочники патернов" aka аналоги решений широко применяются в ТРИЗ, прочтение GoF не отменяет необходимость думать, программирование — инженерная специальность, знанение техник ТРИЗ-а не отменяет необходимость знания технологий программирования. То биш противопоказаний пока не вижу.

C>Вам сильно поможет знание приемов изобразительного искусства или архитектуры (оттуда паттерны и пришли, кстати)?

Изобразительное искусство тут не причем. А архитектура — причем (напр. создание красивой и лёгкой напряжённой конструкции из монолитного бетона).

C>Вот так и методики ТРИЗа плохо приспособлены к проектированию.


Не понимаю почему. Тем более, что "оттуда паттерны и пришли". Архитектуру не святой же дух приносит. Её придумать нужно. И тут часто нет однозначных вариантов.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[6]: О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 16.03.06 21:38
Оценка:
Здравствуйте, Cyberax,

Оставляю Ваши оценочные высказывания в стороне. Отвечаю только по сути.

C>Первый пример вообще никуда не годится. Имеем стандартный случай с

C>необходимостью создания функции (тем более, что в реальной жизни у нас
C>не будет хороших статических массивов из трех строк).

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

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

C>И я не понимаю зачем нужно делать механизм виртуальных функций вручную с

C>помощью таблицы функций. Осталось добавить в функции
C>"void DrawBezierX(CDeviceContext & rDC, const POINT * pPoints)" параметр
C>"void *pThis" и мы будем иметь хрестоматийный пример "виртуальность
C>своими руками".

Там же четко написано зачем. Представьте, что у Вас имеется ряд классов, которые отличаются друг от друга только количеством однотипных элементов, например, точек:
— в первом классе 3 точки;
— во втором — 4;
— в 3-ем — 5;
— и т.д.

Чтобы не плодить N однотипных классов, их лучше свернуть в один класс. В этом случае мы выполняем свертывание по данным. Но нужно еще и выполнить свертывание по функциям. Если не удается написать единый алгоритм растеризации для фигур из 3, 4, N точек, то мы вынуждены писать уникальные функции, а сами функции — скомпоновать в массив. Если же мы можем выполнить свертывание и по функциям, то все эти N функций мы свертываем в единый алгоритм.

C>В примере с аллокатором вообще куча ошибок. Например, он НЕ будет

C>работать с распределением double'ов на Sparc'ах (будет сразу валится по
C>SIGBUS) из-за проблем с выравниванием. Ну и я уж не говорю, что для
C>поиска утечек есть Rational Purify и Valgrind (или ElectricFence для
C>бедных), которые с этой задачей справляются наааааааааааамного лучше.

Вы опять-таки обратили внимание не на те аспекты, которые относятся к сути задачи. Суть третьей задачи состояла не в том, чтобы описать способ нахождения утечки памяти, а в том, как сократить область поиска. Проблема была в том, что для нахождения места утечки нужно было перебрать массу операторов new. Но это нежелательно, т.к. слишком трудоемко.

C>В начале паттерна описывается ситуация когда он нужен, а в тексте

C>описывается чем этот паттерн грозит.

Да, но:

1) отсутствуют способы (модели) постановки задач;
2) отсутствует сводная таблица с описанием типовых проблем и ссылками на паттерны, которые эти проблемы решают (разработчику приходится перелистывать каталог паттернов, когда проще пользоваться сводной таблицей).
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[7]: О правильных и неправильных классификациях...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 16.03.06 22:52
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

КВ>>2. Кстати, не видел общих диаграмм системы, а только кодинг.


КЛ>Диаграмма, код, противоречие, описание на естественном языке — суть разные модели представления одной и той же задачи. В приведенных задачах диаграммы НЕ нужны, потому что противоречия описывают задачи наиболее компактно.


Какие конкретно противоречия? Любые? Или только те, которые возникают в требованиях, предъявляемых к решению? Если последнее, то они по определению не могут возникнуть вне контекста исходной постановки задачи.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: О правильных и неправильных классификациях...
От: vdimas Россия  
Дата: 17.03.06 01:14
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>А за тезис:

"Сущности, принадлежащие типу "Разнородные"

автору вообще нужно памятник при жизни ставить. И на памятнике изобразить деление на нуль.



плакаль


ГВ>

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


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


+1
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: О правильных и неправильных классификациях...
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 17.03.06 07:50
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

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


КЛ>Тестировал ряд кандидатов при приеме на работу на этой задаче. Если функциям передаются одинаковые данные (т.е. нужно сделать одноходовку), то практически все получают решение. Если же нужно выполнить двухходовку (т.е. действия свернуть в цикл, а данные — в массив), то народ стопорится...


Не нужен цикл. Нужна отдельная функция/метод. И дальше, что угодно. А вот куда это метод вынести, это уже вопрос...
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[7]: О правильных и неправильных классификациях...
От: Краснокутский Василий Россия  
Дата: 17.03.06 08:12
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

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


КВ>>На ваше сообщение уже ответил Cyberax и сделал это хорошо.

КЛ>Похоже, необходимо вернуться к причине дискуссии. В предыдущем сообщении Вы заявили, что статья не содержит ничего нового. В качестве примера нового я Вам привел модели постановки задач (через противоречия). Но Вы это обошли молчанием. Так что будем считать, что новое все-таки было.
Угу, все хорошо кроме того, что противоречия есть в разрешении противоречий и это в посте Cyberax продемонстрировано — не буду дублировать. Давайте определимся что Вы в статье пытаетесь продемонстрировать ?? Подход к решению задачи, подход к постановке задачи или решение задачи ??

КЛ>Теперь относительно всего остального. Чем дальше я общаюсь с Вами, тем больше склоняюсь к варианту 2. Почему? Сейчас поясню.


Мне все равно к какому варианту Вы склоняетесь Я боюсь критериев для оценки моего профессионализма Вы не знаете...

КВ>>1. Не вижу критериев по которым код оценивает как хороший или плохой.


КЛ>Критерии все-таки были. Хороший код — это компактный код. В пределе хороша ситуация, когда кода нет, а функция его выполняется. Поэтому идеальный код — это отсутствующий код. Такой код легче всего сопровождать (т.е. вообще сопровождать не надо).

Отсутствие кода есть решение задачи ?? Получается, что отсутствующий код решает любую задачу ????
Позволю себе поспорить с вашим критерием — он оторван от реальности. Давайте будем реалистами — хороший код не есть компактный. Хороший код это тот код которые наиболее точно отвечает требованиям задачи и при этом остается понятным. Не понимаю при чем здесь компактность и как ее оценить. Какие оценки компактности Вы применяете ?

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

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

КЛ>С этой точки зрения все приведенные в статье задачи одинаковы. И решения их тоже одинаковы. Вернее, не решения, а принципы (приемы), с помощью которых они получены.

Повторюсь еще раз — принципы описанные в вашей статье уже сформулированы. Это Open Closed Principle, Liskov Substitution Principle и Dependency Inversion Principle. Поясните мне что нового есть в вашей статье не укладывающегося в Ваши принципы ?

КВ>>2. Кстати, не видел общих диаграмм системы, а только кодинг.


КЛ>Диаграмма, код, противоречие, описание на естественном языке — суть разные модели представления одной и той же задачи. В приведенных задачах диаграммы НЕ нужны, потому что противоречия описывают задачи наиболее компактно.

Ничего себе утверждение — код и диаграммы суть разные вещи, т.к. диаграмма поясняет подход, а код есть реализация подхода. Противоречие = постановка задачи я так понимаю ?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 17.03.06 08:23
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Не нужен цикл. Нужна отдельная функция/метод. И дальше, что угодно. А вот куда это метод вынести, это уже вопрос...


Пожалуйста, приведите Ваше решение.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[7]: О правильных и неправильных классификациях...
От: Cyberax Марс  
Дата: 17.03.06 08:50
Оценка:
Кирилл Лебедев wrote:
> C>Первый пример вообще никуда не годится. Имеем стандартный случай с
> C>необходимостью создания функции (тем более, что в реальной жизни у нас
> C>не будет хороших статических массивов из трех строк).
> Первый, как и все остальные примеры, взят из реальной жизни. Это к
> вопросу о *надуманности*.
Тем хуже. Для модельных примеров еще можно простить надуманность, для
реальных — пинать программиста.

> Теперь по существу задачи. Основная проблема заключалась, конечно же не

> в том, как вынести то или иное действие в функцию, а как из
> *последовательности* почти одинаковых действий сделать *цикл*. Трудность
> заключалась в том, что для каждого действия использовались *свои* данные.
А зачем было выносить действия в цикл? Проще было создать функцию и
вызвать ее три раза с разными параметрами.

> Чтобы *не плодить* N однотипных классов, их лучше *свернуть* в один

> класс.
А почему "лучше"? С чего вы взяли, что поддержка 20 функций будет проще,
чем 20 классов?

У вас все равно семантически получился тот же самый пример с
виртуальностью. Только виртуальность уже делается руками, и без контроля
компилятора. То есть различие чисто синтаксическое.

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

Или вот такая ситуация:
не_помню_названия_типа *func[]=
{
    &DrawFunc1,
    &DrawFunc2,
    &DrawFunc3,
    &DrawFunc4,
    &DrawFunc4,
    &DrawFunc5,
    &DrawFunc6,
    &DrawFunc7
};


Ну и ваш пример будет работать всегда медленнее механизма виртуальных
функций компилятора. Так как нет никаких шансов заинлайнить вызов.

> Вы опять-таки обратили внимание не на те аспекты, которые относятся к

> сути задачи. Суть третьей задачи состояла не в том, чтобы описать способ
> нахождения утечки памяти, а в том, как *сократить* область поиска.
Valgrind/Purify это делает намного лучше — будет даже stacktrace до
места выделения. Заодно будут пойманы обращения к удаленной памяти.

> 1) отсутствуют способы (модели) постановки задач;

А вам не кажется, что они отсутствуют в принципе?

> 2) отсутствует сводная таблица с описанием типовых проблем и ссылками на

> паттерны, которые эти проблемы решают (разработчику приходится
> перелистывать каталог паттернов, когда проще пользоваться сводной таблицей).
У меня такая таблица на стене висела — от Борланда плакат пришел. Чем
она поможет — непонятно.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[8]: О правильных и неправильных классификациях...
От: Left2 Украина  
Дата: 17.03.06 08:51
Оценка:
ANS>Не нужен цикл. Нужна отдельная функция/метод. И дальше, что угодно. А вот куда это метод вынести, это уже вопрос...

В целом согласен, но всё же цикл — это хорошее "ленивое" решение — удобно если алгоритм внутри требует большого количества входных параметров (к тому же, если код всё ещё модифицируется, в случае с функцией изменять её входные параметры в обьявлении и всех вызовах всё же тяжеловато). Сам постоянно использую решение с циклом и другим рекомендую
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[9]: О правильных и неправильных классификациях...
От: Cyberax Марс  
Дата: 17.03.06 08:57
Оценка:
Lazy Cjow Rhrr wrote:
> C>Все еще уверены, что чем компактнее код — тем он лучше?
> Много синтаксического оверхеда. Это не компактный код. Это просто
> утоптанный код
Щас на K (начал изучать — классный язык!) попробую что-нибудь написать
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[9]: О правильных и неправильных классификациях...
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 17.03.06 08:59
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

ANS>>Не нужен цикл. Нужна отдельная функция/метод. И дальше, что угодно. А вот куда это метод вынести, это уже вопрос...


КЛ>Пожалуйста, приведите Ваше решение.


Естественно, нужно учитывать насколько сильно ограничивакт ЯП Начиная с такого:
char* doSmth(char * pszBuff, DWORD dwSize, char* find, char in, char out) {
    // Ищем строку
    // Ищем открывающий символ
    // Ищем закрывающий символ
    // Сохраняем значение

    return pszTemp;
}


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

А может проще взять регэкспы.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[9]: О правильных и неправильных классификациях...
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 17.03.06 09:06
Оценка:
Здравствуйте, Left2, Вы писали:

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


Сей "патерн" слишком "языкозависим". Статья же должна, при возможности, детализировать не больше, чем нужно.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[10]: О правильных и неправильных классификациях...
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 17.03.06 09:44
Оценка:
Cyberax,

>> C>Все еще уверены, что чем компактнее код — тем он лучше?

>> Много синтаксического оверхеда. Это не компактный код. Это просто
>> утоптанный код
C>Щас на K (начал изучать — классный язык!) попробую что-нибудь написать

В добрый путь. Я попробую на J:
divmod=: <.@% , |~

anag=: (4 : 0)^:(1: < #@])
  'q n'=. x. divmod !<:#y.
  (q{y.) , n anag (q{.y.) , (>:q)}.y.
)


999999-я перестановка строки '0123456789':

  999999 anag '0123456789'
2783915460


Ты умудрился скачать интерпретатор? Или у Трурля взял?
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[10]: О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 17.03.06 09:45
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Естественно, нужно учитывать насколько сильно ограничивакт ЯП Начиная с такого:

Это, безусловно, повысит наглядность, но последовательность из 3-х (в пределе — N) вызовов так и останется:
doDmth("Одни данные"):
doDmth("Другие данные"):
doDmth("Третьи данные"):
//...
doDmth("Энные данные"):

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

ANS>А может проще взять регэкспы.

Во всяком случае, эволюционно все к этому и идет.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[11]: О правильных и неправильных классификациях...
От: Cyberax Марс  
Дата: 17.03.06 09:47
Оценка:
Кирилл Лебедев wrote:
> Вынося последовательность действий в функцию, мы просто убираем лишний
> код из *поля зрения*.
А чем это хорошо? Теперь при отладке мне придется идти на начало функции
и смотреть что там в массиве находится, чтобы понять почему оно [не]
работает.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[13]: О правильных и неправильных классификациях...
От: FR  
Дата: 17.03.06 10:09
Оценка:
Здравствуйте, AVC, Вы писали:

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


>>> C>Вот так и методики ТРИЗа плохо приспособлены к проектированию.

>>> Не понимаю почему. Тем более, что "оттуда паттерны и пришли".
C>>Методы анализа задачи в ТРИЗе плохо подходят к программированию, к
C>>сожалению.

AVC>Почему Вы так думаете? (Не спорю, а просто интересуюсь основанием уверенности.)


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

А по примеру с обероном, я не спорю что триз может помощь увидеть противоречия и принципы развития во многоих областях, но к сожалению в не родных областях он не дает хоть сколько-либо эффективных методов решения проблем.
Re[11]: О правильных и неправильных классификациях...
От: FR  
Дата: 17.03.06 10:20
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

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


ANS>>Естественно, нужно учитывать насколько сильно ограничивакт ЯП Начиная с такого:

КЛ>Это, безусловно, повысит наглядность, но последовательность из 3-х (в пределе — N) вызовов так и останется:
КЛ>
КЛ>doDmth("Одни данные"):
КЛ>doDmth("Другие данные"):
КЛ>doDmth("Третьи данные"):
КЛ>//...
КЛ>doDmth("Энные данные"):
КЛ>

КЛ>Вынося последовательность действий в функцию, мы просто убираем лишний код из поля зрения. Свертывая данные в массив, а последовательность действий — в цикл, мы, ко всему прочему, еще и избегаем повторений.

Спорно, для данного примера, мы просто более декларативно задали данные в коде, и он получился полее простым и понятным, а это важнее. Свертывание и цикл имели бы смысл если бы данные для поиска были внешними а не задавались прямо в коде.
Re[12]: О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 17.03.06 11:09
Оценка:
Здравствуйте, FR, Вы писали:

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


Вынесение данных в надсистему — это следующий шаг.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[14]: О правильных и неправильных классификациях...
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 17.03.06 11:16
Оценка:
Здравствуйте, FR, Вы писали:

C>>>Методы анализа задачи в ТРИЗе плохо подходят к программированию, к

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

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

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


Ограничения, имхо, есть. Накладываются они парадигмой, конкретными языками, средами...
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[15]: О правильных и неправильных классификациях...
От: FR  
Дата: 17.03.06 11:18
Оценка:
Здравствуйте, AVC, Вы писали:

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


C>>>>Методы анализа задачи в ТРИЗе плохо подходят к программированию, к

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

AVC>Я подумаю над этим.

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

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

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


AVC>Мне трудно (пока?) об этом судить.

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

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

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


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

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

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

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

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

AVC>Поэтому я и заинтересовался этой темой.

мне тоже интерсно, но пока ничего нового в статьях не почерпнул (да и примеры похоже расчитанны на не очень опытных программистов, например я сразу видел как их разрешить, и при этом решение совпало с авторским только в одном случае, это по моему тоже пример что идеальных решений в проектировании и программировании может и не быть, в отличии от классической области применения триз)
Re[3]: О правильных и неправильных классификациях...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 17.03.06 11:25
Оценка:
Здравствуйте, vdimas, Вы писали:

ГВ>>

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


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


V>+1


Прикольно, что от определения термина "контекст" автор, в конечном итоге, похоже, уклонился. Кстати, по поводу терминологии на сайте ТРИЗ аж 2 года назад была любопытная дискуссия: http://www.triz-ri.ru/forum/mess.asp?cat=0&amp;thr=20852&amp;vtk=18292. Посмотри на досуге.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[11]: О правильных и неправильных классификациях...
От: Cyberax Марс  
Дата: 17.03.06 12:20
Оценка:
Lazy Cjow Rhrr wrote:
> Ты умудрился скачать интерпретатор? Или у Трурля взял?
Пнул KXов. Прислали интерпретатор через 10 минут и пообещали выложить на
сайте
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[16]: О правильных и неправильных классификациях...
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 17.03.06 12:22
Оценка:
Здравствуйте, 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.

первые два — не законы физики, конечно, но там дальше эти ограничения конкретизированы. А последнее требование — очень и очень строгое.
Ы?
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[12]: О правильных и неправильных классификациях...
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 17.03.06 12:35
Оценка:
eao197,

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

Да, высота абстракций очень влияет на краткость.

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

[сcode]
E>basicmatrix[elementaryrow][elementarycolumn] ++;
E>//vs
E>m[ i ][ j ] ++;
[/сcode]
Не совсем. Набор идей совпадает, но концентрация различна.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[16]: О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 17.03.06 12:44
Оценка:
Здравствуйте, FR, Вы писали:

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

Законы развития техники тоже можно нарушить. Т.е. физически можно создать техническую систему, которая будет нарушать ЗРТС. Только вот такая техническая система долго не проживет или будет неэффективно работать.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[12]: О правильных и неправильных классификациях...
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 17.03.06 12:47
Оценка:
Cyberax,

>> Ты умудрился скачать интерпретатор? Или у Трурля взял?

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

ps: только что заходил, не выложили однако
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[17]: О правильных и неправильных классификациях...
От: FR  
Дата: 17.03.06 13:45
Оценка:
Здравствуйте, 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>Ы?

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

Кроме того нет такой же базы на которой основывается ТРИЗ — патентов, в которых жестко формализовано зафиксированы почти все возможные технические решения. Вообще порадокс программирование вроде само средство формализации и при этом само поддается этой самой формализации с большим трудом
Re[17]: О правильных и неправильных классификациях...
От: FR  
Дата: 17.03.06 13:46
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

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


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

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

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

Может дело в том что в IT время жизни очень большого числа приложений меньше чем время за которое они могут эволюционировать до плато и при том цена создания (и копирования!) систем намного меньше чем в технике.
Re[12]: О правильных и неправильных классификациях...
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 17.03.06 13:54
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


Прикол, блин. Почти всё на английском
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[16]: О правильных и неправильных классификациях...
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 17.03.06 14:19
Оценка:
eao197,

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

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

Ну хорошо.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[19]: О правильных и неправильных классификациях...
От: FR  
Дата: 17.03.06 15:53
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

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


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

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

Все это так, но вопрос в том может ли тут помощь ТРИЗ, и эффективнее ли он чем классические методики?
По моему эффективность ТРИЗ для решения задач проектирования и программирования под большим вопросом.
Re[11]: О правильных и неправильных классификациях...
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.03.06 19:38
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Краткости можно достигнуть необязательно в ущерб чтению.


LCR>Приведу пример (qsort на Erlang и C).

LCR>
LCR>sort([Pivot | T]) ->
LCR>    sort([ X || X <- T, X < Pivot]) ++
LCR>    [Pivot] ++
LCR>    sort([ X || X <- T, X >= Pivot]);
LCR>sort([]) -> [].
LCR>

LCR>
LCR>qsort( a, lo, hi ) int a[], hi, lo;
LCR>{
LCR>  int h, l, p, t;
LCR>  if (lo < hi) {
LCR>    l = lo;
LCR>    h = hi;
LCR>    p = a[hi];
LCR>    do {
LCR>      while ((l < h) && (a[l] <= p)) 
LCR>          l = l+1;
LCR>      while ((h > l) && (a[h] >= p))
LCR>          h = h-1;
LCR>      if (l < h) {
LCR>          t = a[l];
LCR>          a[l] = a[h];
LCR>          a[h] = t;
LCR>      }
LCR>    } while (l < h);
LCR>    t = a[l];
LCR>    a[l] = a[hi];
LCR>    a[hi] = t;
LCR>    qsort( a, lo, l-1 );
LCR>    qsort( a, l+1, hi );
LCR>  }
LCR>}
LCR>

LCR>Легко видеть, что краткость в первом случае выше (я так же отдаю себе отчёт в том, что во втором случае быстродействие круче, но сейчас это неважно).

Дело не в скорости. Дело в том, что это совершенно разные алгоритмы. Плюс в первом алгоритме применяются очень высокоуровневые операторы которые делают кучу работы за кадром.

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

Вот как это могло бы выглядеть:
List Sort(List list)
{
    Elem pivot = GetFirst(list);
    return Concat(GetGreater(list, pivot), pivot, GetSmallerOrEq(list, pivot));
}

И что этот код на С сильно сложнее примера на разных КулХаскелях или Эрлэнгах?

Да, нисколичко! Он даже понятнее.

Так что дело в абстракцийях, а не магии языков. Просто некоторые языки подталкивают к абстрагированию, а другие нет. Плюс конечно наличие мощьных языковых конструкций вроде листкоприехеншона позволяют скрять часть сложности алгоритма.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: О правильных и неправильных классификациях...
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 18.03.06 08:39
Оценка:
VladD2,

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


Да, конечно, абстракции имеют важное значение. (Видел плюсик к посту Евгения?)

Но кроме абстракций есть ещё клей (допустимые способы взаимодействия абстракций) и синтаксический сахар (оптимизированное отображение абстракций на язык, наиболее удобное для человека). А эти вещи уже зависят от используемой нотации.

Возьмём C. Что можно сделать с функцией (абстрактным действием)?
1. Вызвать функцию из другой функции.
2. Взять у функции указатель и вызвать через указатель.
Всё.

Языки типа Java/C# добавляют сюда ещё виды клея (пока то, что в голову пришло, возможно не всё):
3. Генерация функций в рантайме.
4. Логическая классификация функций и привязка функций к данным.
Cахар:
5. Расширенные возможности для записи функций. (ex: проперти в C#)

Вот и получается, что зачастую то, что делается легко и непринуждённо в Java, на C идёт тяжело.

Так что для достижения краткости магия имеет значение. Последний пример:
    ord =: /:@:/:
    ord 6 4 5 10
2 0 1 3

(результат — вектор ординалов, а использовано лишь 2 кирпича "/:"). Здесь применён вид клея, вообще отсутствующий в C-подобных языках — называется "fork" и сахар, также отсутствующий в C-подобных языках, называется "tacit form".
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re: О правильных и неправильных классификациях...
От: AVC Россия  
Дата: 18.03.06 13:28
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>К сожалению, очень много программистов знают только один способ борьбы со сложностью — полиморфизм. И применяют его как к месту, так и не к месту. Но есть и другие способы группировки, есть критерии для объединения сущностей в группу, есть и типичные ошибки группирования.


Вот еще один заслуживающий внимания способ решать подобные задачи, основанный на нахождении инварианта:
http://www.embedded.com/story/OEG20010725S0103

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[16]: О правильных и неправильных классификациях...
От: AVC Россия  
Дата: 18.03.06 13:50
Оценка:
Здравствуйте, FR, Вы писали:

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


Насчет других областей — не уверен.
В свое время меня удивил факт, насколько близок ТРИЗ к классической диалектике.
То, что писал о мышлении, например, философ Ильенков, в самом главном — почти один в один согласуется с ТРИЗ.
А ведь Ильенков — не "технарь", а философ (и даже марксист ), о ТРИЗ, скорее всего, не знал.
В качестве примера подобного мышления он приводил решение Марксом проблемы прибавочной стоимости.
Описание проблемы выглядело примерно так: капиталист покупает товар по его стоимости, продает по его стоимости, а получает прибыль.
Я хочу сказать, что применение вполне "тризовских" методов может иметь место и без лейбла "ТРИЗ".
Но ТРИЗ привел их в систему, что очень хорошо.

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


Ах, где бы взять такую архитектуру — без противоречий...

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[17]: О правильных и неправильных классификациях...
От: Кодт Россия  
Дата: 18.03.06 20:20
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

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


Извините, что влезаю с полу-оффтопиком.
Сама постановка вопроса: таки-да или таки-нет — это как раз дуальность, и к ТРИЗу имеет прямое отношение

Можем даже переформулировать. В терминах ТРИЗ.

Проблема 1:
— хочется представлять задачи как можно проще (например, прозревать в них единственный паттерн "противоречие")
— хочется представлять задачи как можно гибче и детальнее (прозревая разные паттерны, наиболее подходящие по месту)

Проблема 2:
— хочется грокнуть ТРИЗ
— не хочется тратить время на гроканье ненужных вещей

Из этого следует, что паттерн "противоречие" (а значит, и методология работы с ним) никуда из природы не девается, и ему есть ненулевое место. Какое именно?

А вот какое. У творческой ситуации есть три стороны:
— проблема (текущее положение дел)
— цель
Концентрация на проблеме — представление её в тех или иных моделях (ТРИЗовой, GoFовой и т.д.). Концентрация на цели — разные методологии.
Как вы понимаете, сами по себе, в отрыве друг от друга, они не приносят плоды.
Механическая состыковка возможна в достаточно узком круге случаев.
Собственно, опять дуальность.

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

В общем, мораль такая. Грокнуть нужно чуть-чуть в учебных целях. А когда/если пригодится — тогда уже грокать на всю катушку.
Перекуём баги на фичи!
Re[7]: О правильных и неправильных классификациях...
От: Кодт Россия  
Дата: 18.03.06 21:09
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

C>>Первый пример вообще никуда не годится. Имеем стандартный случай с

C>>необходимостью создания функции (тем более, что в реальной жизни у нас
C>>не будет хороших статических массивов из трех строк).

КЛ>Первый, как и все остальные примеры, взят из реальной жизни. Это к вопросу о надуманности.


Знаете, в чём тут фокус. Вы оба закапываетесь внутрь системы, которая называется "проектирование".
Введите компонент "проектировщик" и посмотрите на его качества.

У проектировщика есть опыт, одна из важных составляющих которого — способность распознавать шаблоны.
ТРИЗовец натаскан на один набор шаблонов, ГОФовец — на другой, индусский тапёр вообще не натаскан и играет как умеет.

Модели, естественно, взаимно проникают и пересекаются.
Поэтому в случае с обработкой строки мы можем увидеть и классическое противоречие, и посылку для рефакторинга "выделение функции", и посылку для готовых инструментов обработки строк.
В случае иерархией классов (Безье, сонм датчиков и т.д.) — можно разглядеть сразу посылку для некоторых структурных и функциональных паттернов: например, Посетитель и Адаптер / Прокси.

Чем богаче арсенал разработчика, и чем менее он обусловлен любимыми (или навязанными) инструментами, тем ему проще.
Буч, как отец-основатель иерархий классов, попался с датчиками. Кирилл, как приверженец ТРИЗ, пошёл трудным путём с кривыми Безье (переоткрыв ГОФ-паттерны).



Эти две тризовские статьи немного лукавят, предлагая читателю не отвлекаться на известные ему решения в других парадигмах ("объясните школьнику"). С целью обучения конкретной парадигме — это справедливо. В других целях — это разовьёт догматизм.

Теперь, чтобы вернуть в природу равновесие, нужно написать такой же вводный учебный курс по ГОФ



Да, кстати, насчёт отладки утечек. Ещё одно лукавство мелкого плана: а именно, время-деньги.

Тотальное журналирование new/delete находит все полюсы проблемы за единственный запуск программы.
Выборочное журналирование находит некоторые полюсы за логарифмическое количество запусков.

Вот и выбираем асимптотики — O(1) со зверским коэффициентом при инструментировании против O(log n) с относительно дешёвым инструментированием и неизвестно каким коэффициентом при запуске.

Например, сервер или встроенный софт так тестировать точно нельзя. Эту булочку мы уже проходили
Перекуём баги на фичи!
Re[9]: О правильных и неправильных классификациях...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 19.03.06 04:31
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

C>>Все еще уверены, что чем компактнее код — тем он лучше?


КЛ>То, что Вы продемонстрировали, как раз и называется подсистемным мышлением. Судя по приведенному примеру, Вы предполагаете, что программный код – это набор символов. Но это неправильно! Это все равно, что предполагать, будто дом – набор кирпичей или строительных блоков.


КЛ>Так же, как письменная речь не сводится к набору букв, так и программный код – нечто большее, чем набор символов. Код имеет иерархическую структуру, и на каждом уровне этой иерархии в качестве элементов выступают разные абстракции:


КЛ>0. Символы.

КЛ>1. Слова (операторы, переменные, константы, типы данных).
КЛ>2. Функции и функциональные блоки.
КЛ>3. Типы данных, определяемые пользователем.
КЛ>4. Иерархии, группы связанных классов.
КЛ>5. Библиотеки.
КЛ>6. И т.д. – наверняка что-то пропустил.

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


На самом деле, эта "игра уровнями" проявляется где-то начиная с 2-го по вашей классификации.

КЛ>Как я уже писал, для задания критерия качества кода мне привычнее пользоваться понятием идеальность. Это «тризовский» термин, и суть его заключается в следующем:


КЛ>Идеальная система – эта система, которой нет, а функция ее выполняется.


КЛ>Применительно к программному коду, это правило будет звучать так:


КЛ>Идеальный код – это код, которого нет, а функция его выполняется.


Блин, забавно. Вводится термин, означающий 0 и "бесконечность" одновременно. Я же говорил — Дзенский коан!

Здесь разумнее было бы ввести термин "ТРИЗ-идеальность", а не цеплять общепринятую семантику термина "идеальность". А то так можно договориться до того, что "идеализм"="компактизм", но понимать друг друга сможет только ограниченное количество людей. Общепринятый смысл термина "идеальность", это, всё-таки, приближение к некоей идее, в нашем случае — идее решения некоторой задачи.

КЛ>Понятно, что в реальной жизни ни идеальных технических систем, ни идеального программного кода не существует. Идеальность – это модельное понятие. Это предел, к которому в своем развитии стремится любая система (самолет или модуль искусственного интеллекта для гоночной игры).


Вы противоречите сами себе. Если уж система развивается, а "идеальность" тем выше, чем система меньше, то становится ясно, что система развивается всегда только в одном направлении — к не-идеальности. Возможно вы имеете ввиду, что любая система стремится к бесконечному росту (и это так и есть), но тогда получается, что у вас бесконечноcть и нуль — однои то же. А это абсурд чистой воды!

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


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

Зачастую всё обстоит наборот: компактный, но слабоструктурированный код — это ужас во плоти. А в несколько раз большее по объёму, но при том сильно структурированое решение — вполне себе поддаётся сопровождение и развитию.

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

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

Но вернёмся к нашим компактно-идеальным баранам. Собственно, вместо употребляемого вами термина "идеальность", инверсного к существованию, для отражения той же меры вещей есть нормальное программистское понятие: метрика программы. Начиная от простейшей — объём в килобайтах и заканчивая навороченными, которые рассчитываются по весьма непростым формулам на основании довольно сложного анализа. И здесь сразу обнаруживается, что сами по себе метрики — очень спорная вещь. Что лишний раз подтверждает спорность предложенного вами критерия "идеальности".

КЛ>Например, для хранения координат и выполнения операций над ними можно использовать встроенные типы данных:

КЛ>
КЛ>int iOldX;
КЛ>int iOldY;
КЛ>int cx;
КЛ>int cy;
КЛ>//...
КЛ>int iNexX = iOldX + cx;
КЛ>int iNewY = iOldY + cy;
КЛ>

КЛ>А можно создать свои типы данных и выразить те же самые действия иначе:
КЛ>
КЛ>CPoint pt;
КЛ>CSize sz;
КЛ>//...
КЛ>CPoint pt1 = pt + sz;
КЛ>

КЛ>Мы видим, что вторая запись компактнее, а, следовательно, идеальнее. Ее компактность обеспечивается не небольшим количеством символов (системный уровень 0), а небольшим количеством слов – названий переменных и операторов (системный уровень 1).

Да-да, здесь понятийная модель программы подводится к модели понятий геометрии, где мы оперируем такими терминами, как "точка", "размер", "расстояние" и т.п. Кстати, подводится довольно спорно: что получится от сложения точки с размером? Квадрат? Круг? Новая точка? Ну да ладно уж.

КЛ>В данном случае, повышение идеальности на уровне 1 привело к небольшому снижению идеальности на уровнях 2 и 3 – нам пришлось добавить классы CPoint и CSize и определить оператор ‘+’ для этих типов данных. Соответственно, мы можем повысить идеальность на этих уровнях, если будем использовать уже готовую библиотеку, где классы CPoint и CSize определены (например, MFC). В этом случае, правда, ухудшится идеальность на уровне 5. Но если библиотека уже была нами использована для каких-то иных целей, то снижение идеальности не произойдет.


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

КЛ>Возвращаясь к приведенному Вами коду, можно сказать, что он некомпактен и уж, тем более, не идеален. Не смотря на то, что количество символов небольшое, количество разных сущностей велико.


И снова — нехорошо смешивать калий с водой, бабахнуть может. Зачем здесь упоминать про "идеальность"?

КЛ>О чем это говорит? О том, что любое правило нельзя применять бездумно. Нужно четко видеть различные системные уровни и изменения, которые происходят на них в процессе развития или под воздействием правила. Как было написано в статье, отсутствие системного мышления – типовая ошибка разработчиков и причина «глючного» кода. Подозреваю, что по этой причине просьба Заказчика о внесении изменений в Ваш компонент оказалась неожиданной. Потому что Вы оперируете одной системой, одним компонентом, а не классами подобных систем и не классами подобных компонентов.


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

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

А вообще ваша позиция, будучи выражена терминами, инверсными по отношению к существованию, по сути — совершенно бесспорна. Ну разме можно спорить с абсолютом? А с бесконечностью? А с нулём?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[18]: О правильных и неправильных классификациях...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 19.03.06 04:46
Оценка:
Здравствуйте, Кодт, Вы писали:

К>Проблема 1:

К>- хочется представлять задачи как можно проще (например, прозревать в них единственный паттерн "противоречие")

Двойка тебе, Кодт. Будь я тризовцем — разнёс бы тебя только за попытку сопоставить прямую и инверсную интерпретацию задачи. Паттерн — существует сам по себе. Противоречие — возможно только между чем-то и чем-то, т.е., с паттерном не может даже и сопоставляться. Ну, блин, представь себе хлопок одной ладони!

Ну, или ещё проще — задача vs. решение.

К>- хочется представлять задачи как можно гибче и детальнее (прозревая разные паттерны, наиболее подходящие по месту)


К>Проблема 2:

К>- хочется грокнуть ТРИЗ

Сутра 14-го патриарха тут поможет.

К>- не хочется тратить время на гроканье ненужных вещей


К>Из этого следует, что паттерн "противоречие" (а значит, и методология работы с ним) никуда из природы не девается, и ему есть ненулевое место. Какое именно?


Вот-вот. Это и есть место хлопка одной ладони.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[9]: О правильных и неправильных классификациях...
От: Cyberax Марс  
Дата: 19.03.06 10:57
Оценка:
Кирилл Лебедев wrote:
> То, что Вы продемонстрировали, как раз и называется *подсистемным
> мышлением*. Судя по приведенному примеру, Вы предполагаете, что
> программный код – это *набор символов*.
Да. Програмный код — это набор символов. Если спуститься на уровень ниже
— это набор байт.

Если подняться выше, то программный код — это запись AST данного языка.
Во внутренностях компилятора код — это запись T-SSA (Single Static
Assignment Tree). И т.п.

> Но это неправильно!

Почему?

> Это все равно, что предполагать, будто дом – *набор кирпичей* или *строительных

> блоков*.
А у нас дома из воздуха строятся? Я почему-то всегда думал, что из
кирпича/бетона/...

> Код имеет иерархическую

> структуру, и на каждом уровне этой иерархии в качестве элементов
> выступают разные абстракции:
Ничего код не имеет. Это мы можем _интерпретировать_ код как
иерархическую систему.

В общем, "hierarchy is in the eye of the beholder"

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

> Соответственно, когда я пишу, что хороший код – это *компактный код*, я

> отнюдь не имею в виду минимальное количество символов. Ибо хорошо
> понимаю, что код – это *нечто большее*, чем просто набор символов, и
> вижу различные системные уровни.
Прекрасно. Что лучше: "v~=s/aa/bb/g;" или
std::string res;
for(std::string::const_iterator f=str.begin();f!=str.end();++f)
{
    if (str.compare("aa",f,2)==0)
    {
        res+="bb";
        f+=2;
    }
    else
        res+=*f;
}

?

> /Идеальная система – эта система, которой нет, а функция ее выполняется./

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

"Компактный код" (в смысле размера или концентрации идей на квадратный
килобайт) может быть абсолютно непригодным к использованию по причине
нерасширяемости и/или неподдерживаемости в ряде случаев.

Так что думайте дальше над формулировкой идеальности.

> Мы видим, что вторая запись *компактнее*, а, следовательно, *идеальнее*.

> Ее компактность обеспечивается не небольшим количеством символов
> (системный уровень 0), а небольшим количеством слов – названий
> переменных и операторов (системный уровень 1).
Не пойдет.

> Возвращаясь к приведенному Вами коду, можно сказать, что он некомпактен

> и уж, тем более, не идеален. Не смотря на то, что количество символов
> небольшое, количество разных сущностей велико.
Попробуйте лучше переписать. Приведенный код является победителем
International Obfuscated Perl Contest, а значит очень близок к идеалу
этого конкурса — абсолютно непонятная программа на языке Perl, но
делающая интересные осмысленые действия.

Их идеал не совпадает с вашим? Что же, очень жаль....
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[17]: О правильных и неправильных классификациях...
От: Cyberax Марс  
Дата: 19.03.06 11:48
Оценка:
Andrei N.Sobchuck wrote:
> Хе-хе. Вот нет в Java оператора "super super" для доступа к методу не
> родителя, а дедушки и попробуй это нарушить. А вопрос, как это сделать,
> я видел и в ru.java и на rsdn.
Просто решили не делать, так как нечасто требуется. Никаких
фундаментальных запретов для super.super нет.

> Или требование типа "должна отработать быстрее чем за N времени".

На какой машине?

> 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.
Вопрос такой: а зачем нужно реализовывать протокол коллекций?

> первые два — не законы физики, конечно, но там дальше эти ограничения

> конкретизированы. А последнее требование — очень и очень строгое.
> Ы?
Обычная ситуация — противоречие показывает, что у нас неправильная
архитектура (требуется доступ к приватным данным) или на недостаточность
архитектуры.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[8]: О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 19.03.06 14:10
Оценка:
Здравствуйте, Кодт,

1. Умение использовать для постановки и решения задач различные модели, разумеется, благо. И паттерны – хорошая модель, потому что она проста. Эта модель доступна даже студенту. Или, скажем так, она гораздо доступнее, чем системное мышление или идеальность. Это – как приемы в ТРИЗ, которые всем доступны и всем понятны. Поэтому большинство людей и пользуются ими.

2. Казалось бы, раз приемы (паттерны) доступнее и понятнее, то нужно выявить как можно больше приемов, и, благодаря этому, получить возможность решать все новые и новые классы задач. Однако практика показалась тупиковость такого подхода. Скажем так, существует ограничения на качественный уровень задач, которые можно решить при помощи приемов. Поэтому в ТРИЗ и появились другие инструменты: стандарты, физические противоречия, физэффекты и т.п. Соответственно, и в нашем случае основная цель – это не переоткрыть паттерны, а создать инструментарий более высокого класса, который бы позволял решать более сложные и менее очевидные задачи.

3. Разумеется, более сложный инструментарий предъявляет и более высокие требования к квалификации того, кто им будет пользоваться. Конечно, проблему с датчиками можно устранить паттерном “Visitor” или двойной диспетчеризацией. Но лучше вообще так не проектировать. В ряде случаев паттерны выступают в роли «заплатки», которая закрывает архитектурные «глюки».

Соответственно, выгоднее не нашивать «заплатки», а проектировать качественно и безглючно с самого начала. А это требует повышенной квалификации, т.к. нужно думать и напрягаться.

Качественная архитектура должна быть расширяемой. Это означает, что разработчик должен спрогнозировать возможные направления развития системы. Для этого он должен не смотреть на систему в одиночестве (саму по себе), а желательно посмотреть на систему в контексте. Т.е. должен видеть и систему, и надсистему, и отдельные подсистемы. Желательно, еще и в развитии. Здесь мы вплотную подступаем к системному мышлению. А это – не такая уж простая штука, и простым набором паттернов здесь не обойдешься.

4. Все выше изложенное свидетельствует о том, что дискуссия вызвана не только и не столько разницей инструментария (паттерны, ТРИЗ), но и разницей в квалификациях. Можно, например, до посинения спорить, что трубка курительная и «трубка» телефонная суть разные вещи, и не понимать, что данное различие обусловлено избранным критерием – функцией системы или технологическими «наворотами». Те же самые предметы, но в иной системе отсчета, могут быть однородными, т.к. функциональные или технологические различия в ней не важны. В качестве примера такой системы я уже приводил опись имущества, принадлежащего конкретному человеку.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[9]: О правильных и неправильных классификациях...
От: Cyberax Марс  
Дата: 19.03.06 14:41
Оценка:
Кирилл Лебедев wrote:
> 1. Умение использовать для постановки и решения задач *различные
> модели*, разумеется, *благо*. И паттерны – хорошая модель, потому что
> она *проста*. Эта модель доступна даже студенту. Или, скажем так, она
> гораздо доступнее, чем *системное мышление* или *идеальность*.
Идеальности в программировании нет. Точнее, она относительная.

> 2. Казалось бы, раз приемы (паттерны) доступнее и понятнее, то нужно

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

> Качественная архитектура должна быть расширяемой. Это означает, что

> разработчик должен спрогнозировать возможные направления развития
> системы.
Сразу все возможные направления? Не подскажете, случайно, как это сделать?
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[11]: О правильных и неправильных классификациях...
От: Cyberax Марс  
Дата: 19.03.06 14:46
Оценка:
Кирилл Лебедев wrote:
> Это не я противоречу сам себе, а Вы уподобляетесь схоласту, который,
> имея пару посылок, строит силлогизм и пытается, таким образом, вывести
> (дедуктивно) законы всего сущего. Или, наоборот, построить чисто
> формальное опровержение, основываясь на все тех же силлогизмах.
Вам показали на противоречие в ваших собственных высказываниях.
Силлогизмы просто его упрощают для понимая.

С вашей стороны идет софистика.

> Соответственно, для того чтобы понять, как происходит идеализация

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

> Еще удобнее рассматривать системы в развитии. Например, современный

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

По соотношению цена/качество новые (более совершенные технически) машины
тоже могут проигрывать подержаным.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[10]: О правильных и неправильных классификациях...
От: AVC Россия  
Дата: 19.03.06 14:58
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> Качественная архитектура должна быть расширяемой. Это означает, что

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

В принципе (на деталях не настаиваю) — как в Обероне.
В основе минимальный набор основных модулей.
Система расширяется добавлением новых модулей поверх предыдущих.
Возможна критика обероновского подхода в деталях, но сама идея, IMHO, превосходна.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[12]: О правильных и неправильных классификациях...
От: AVC Россия  
Дата: 19.03.06 15:48
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> *В принципе* (на деталях не настаиваю) — как в Обероне.

C>Ррррррррррр.


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

>> В основе минимальный набор основных модулей.

C>Если честно, то мне плевать на модули. Совсем.
C>У меня почти все программы "монолитны", то есть сделаны в виде одного
C>большого изображения. Но тем не менее расширяемы на уровне исходного кода.
C>И вот как организовать архитектуру, чтобы ее можно было расширять — это
C>мне гораздо интереснее сомнительной возможности загружать модули в рантайме.

OK.
Интересы бывают разные.
Меня, напротив, привлекает легкость и безболезненность компонентного программирования.

>> Система расширяется добавлением новых модулей поверх предыдущих.

C>Ничерта не "расширяется". Просто "добавляется".

Хм... в чем разница?
Разве расширяемость не то же самое, что:
1) возможность добавления новой функциональности
2) без внесения изменений в другие модули (или иные программные единицы — для других языков)?

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[13]: О правильных и неправильных классификациях...
От: AVC Россия  
Дата: 19.03.06 15:53
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Разве расширяемость не то же самое, что:

AVC>1) возможность добавления новой функциональности
AVC>2) без внесения изменений в другие модули (или иные программные единицы — для других языков)?

BTW, это вполне можно понимать в ТРИЗовском смысле — как удовлетворение противоречащим друг другу требованиям.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[11]: Притча
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 19.03.06 17:11
Оценка:
Здравствуйте, Кирилл Лебедев,

Прежде чем человек изу­чил дзен, горы для него были горами и воды водами. Потом, когда он взглянул в истину дзен, горы не стали горами и воды водами. Но когда он действительно достиг обители покоя (муд­рости), горы снова стали горами и воды водами.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[11]: Ещё об автомобилях
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 19.03.06 19:09
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Еще удобнее рассматривать системы в развитии. Например, современный автомобиль гораздо идеальнее своего первого прототипа, т.к. ездит быстрее, а топливо жрет меньше. Т.е. выполняет функцию лучше, а ресурсов тратит меньше.


Кроме того, что современные автомобили тратят меньше горючего на перемещение и ездят быстрее, они очень сильно потеряли в сопровождаемости. То есть, в той самой понятности. Хотя у них высокая надёжность, но много ли вы знаете способов отремонтировать компьютерное управление зажиганием в полевых условиях?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[9]: О правильных и неправильных классификациях...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 19.03.06 19:57
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>1. Умение использовать для постановки и решения задач различные модели, разумеется, благо. И паттерны – хорошая модель, потому что она проста. Эта модель доступна даже студенту. Или, скажем так, она гораздо доступнее, чем системное мышление или идеальность. Это – как приемы в ТРИЗ, которые всем доступны и всем понятны. Поэтому большинство людей и пользуются ими.


Поверьте на слово. С вами спорят далеко самые не типичные представители "большинства".

КЛ>2. Казалось бы, раз приемы (паттерны) доступнее и понятнее, то нужно выявить как можно больше приемов, и, благодаря этому, получить возможность решать все новые и новые классы задач. Однако практика показалась тупиковость такого подхода. Скажем так, существует ограничения на качественный уровень задач, которые можно решить при помощи приемов. Поэтому в ТРИЗ и появились другие инструменты: стандарты, физические противоречия, физэффекты и т.п. Соответственно, и в нашем случае основная цель – это не переоткрыть паттерны, а создать инструментарий более высокого класса, который бы позволял решать более сложные и менее очевидные задачи.


Внимание! Ключевое слово — "физические"!

КЛ>3. Разумеется, более сложный инструментарий предъявляет и более высокие требования к квалификации того, кто им будет пользоваться. Конечно, проблему с датчиками можно устранить паттерном “Visitor” или двойной диспетчеризацией. Но лучше вообще так не проектировать. В ряде случаев паттерны выступают в роли «заплатки», которая закрывает архитектурные «глюки».


В точку.

КЛ>Соответственно, выгоднее не нашивать «заплатки», а проектировать качественно и безглючно с самого начала. А это требует повышенной квалификации, т.к. нужно думать и напрягаться.


Угу, ППКС! Только теперь давайте подумаем не об абстрактных "думать" и "напрягаться", а об их конкретных воплощениях.

КЛ>Качественная архитектура должна быть расширяемой. Это означает, что разработчик должен спрогнозировать возможные направления развития системы. Для этого он должен не смотреть на систему в одиночестве (саму по себе), а желательно посмотреть на систему в контексте. Т.е. должен видеть и систему, и надсистему, и отдельные подсистемы. Желательно, еще и в развитии. Здесь мы вплотную подступаем к системному мышлению. А это – не такая уж простая штука, и простым набором паттернов здесь не обойдешься.


И это правильно. Скажу больше — паттерны нередко только замусоривают мышление.

КЛ>4. Все выше изложенное свидетельствует о том, что дискуссия вызвана не только и не столько разницей инструментария (паттерны, ТРИЗ), но и разницей в квалификациях.


Вот смотрите. Сейчас вы отталкиваете от себя тех, кто уверен в своей квалификации, поскольку апеллируете к тому, что часть ваших оппонентов — неквалифицированные специалисты. А что, если поставить вопрос о критериях определения квалификации? Знаете, сколько тут копий поломано?! Потому-то люди и пришли, в частности, к двум очень простым вещам:

— Апелляции к личности (квалификации, возрасту, национальности) некорректны в споре, если мы, конечно, не пенисометрией заняты;
— Плохо, когда учёный не может выразить свою теорию ясно.

Вот теперь догадайтесь, какое из этих правил вы сами и нарушаете.

КЛ>Можно, например, до посинения спорить, что трубка курительная и «трубка» телефонная суть разные вещи, и не понимать, что данное различие обусловлено избранным критерием – функцией системы или технологическими «наворотами». Те же самые предметы, но в иной системе отсчета, могут быть однородными, т.к. функциональные или технологические различия в ней не важны. В качестве примера такой системы я уже приводил опись имущества, принадлежащего конкретному человеку.


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

Возвращаясь к трубкам и телефонам, по критерию владельца они действительно однородны, но при этом становятся не "трубкой" и "телефоном", а "объектами собственности". Да, объекты собственности — однородны как объекты собственности. Таким образом мы вводим термин, однозначно определяющий контекст критерии однородности. Неразумно употреблять выражение "однородные объекты в смысле владения", когда его можно заменить на "объекты собственности". И короче, и понятнее, и к абсурду сводить нечего.

Кстати, как раз в программировании в случае необходимости оперирования "объектами собственности" сделают не объекты ТТрубка и ТТелефон, а ограничатся каким-нибудь ТОбъектСобственности. И рассуждать будут уже только о харатеристиках объектов собственности!

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


Вас потому и трудно воспринимать (не говоря уже о том, чтобы восприниимать серьёзно), что вы апеллируете к зауженным значениям достаточно общих терминов, которые (значения) потом обратно же и обобщаете. Была тут недавно перепалка по поводу "модульных систем", там были вполне ясно высказаны претензии к формулировкам. Прочтите, не поленитесь.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[11]: О правильных и неправильных классификациях...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 19.03.06 20:34
Оценка:
Здравствуйте, AVC, Вы писали:

ГВ>>Внимание! Ключевое слово — "физические"!


AVC>Вряд ли.

AVC>AFAIR, в ТРИЗ "физические" противоречия отличаются от "административных" тем, что в них противоречивые требования предъявляются к одному объекту.
AVC>Думаю, что "природа" объекта здесь не так важна.

"Физический" объект это не совсем то же самое, что и "информационный" объект. Не нужно сводить методологию к метафизике.

ГВ>>Вот теперь догадайтесь, какое из этих правил вы сами и нарушаете.


AVC>Геннадий, мне просто интересно: а вот такое высказывание

AVC>http://www.rsdn.ru/Forum/Message.aspx?mid=1785096&amp;only=1
AVC>ничего не нарушает?

Ох, грешен, грешен. Только вот ни одно из упомянутых мной правил сие высказывание не не нарушает. Я же там не теорию излагаю, а банально ругаюсь.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[12]: О правильных и неправильных классификациях...
От: AVC Россия  
Дата: 19.03.06 20:59
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Внимание! Ключевое слово — "физические"!


AVC>>Вряд ли.

AVC>>AFAIR, в ТРИЗ "физические" противоречия отличаются от "административных" тем, что в них противоречивые требования предъявляются к одному объекту.
AVC>>Думаю, что "природа" объекта здесь не так важна.

ГВ>"Физический" объект это не совсем то же самое, что и "информационный" объект. Не нужно сводить методологию к метафизике.


"Физический" объект, действительно, не совсем то же самое, что и "информационный".
Но ведь "физик", как и программист, мыслит все же головой, а не руками, например.
В методах мышления вполне может быть много общего.
"Техническое" противоречие фиксирует отношение между двумя элементами системы (один "улучшаем" — второй "ухудшается").
Это, так сказать, на поверхности.
А "физическое" противоречие докапывается — почему не получается исправить первый, не портя второй.
Суть в том, что где-то мы предъявляем противоположные требования к одному элементу системы.
Терминология, конечно, несет суровый отпечаток первоначальной сферы применения ТРИЗ.
Что есть — то есть.
Но, в принципе, речь идет о системном мышлении. А оно не ограничено одной сферой применения.

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


А-а... Это меняет дело.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[10]: О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 19.03.06 21:46
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Возвращаясь к трубкам и телефонам, по критерию владельца они действительно однородны, но при этом становятся не "трубкой" и "телефоном", а "объектами собственности".


Заметьте, становятся только после того, как выбран соответствующий критерий. А это говорит нам о том, что термины подсистемны к контексту (выбранному критерию), который для них является надсистемой.

ГВ>Кстати, как раз в программировании в случае необходимости оперирования "объектами собственности" сделают не объекты ТТрубка и ТТелефон, а ограничатся каким-нибудь ТОбъектСобственности. И рассуждать будут уже только о харатеристиках объектов собственности!


Разумеется, так и произойдет. Но для начала курительные трубки и "трубки" телефонные нужно поместить в надлежащий контекст.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[11]: О правильных и неправильных классификациях...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 19.03.06 23:24
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

ГВ>>Возвращаясь к трубкам и телефонам, по критерию владельца они действительно однородны, но при этом становятся не "трубкой" и "телефоном", а "объектами собственности".


КЛ>Заметьте, становятся только после того, как выбран соответствующий критерий. А это говорит нам о том, что термины подсистемны к контексту (выбранному критерию), который для них является надсистемой.


Вопрос, как всегда, в словах. Не более того.

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

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

Потом вы упускаете из виду разнесённые по времени действия: а) определение критериев, по которым предметы вводятся в некую систему и б) классификация предметов в этой системе в силу того, что они этим заданным критериям удовлетворяют.

Я подобрал нестрогое выражение для "превращения" трубок в позиции документа. Трубки только упоминаются в документе. Сами по себе они частью документа не становятся.

ГВ>>Кстати, как раз в программировании в случае необходимости оперирования "объектами собственности" сделают не объекты ТТрубка и ТТелефон, а ограничатся каким-нибудь ТОбъектСобственности. И рассуждать будут уже только о харатеристиках объектов собственности!


КЛ>Разумеется, так и произойдет. Но для начала курительные трубки и "трубки" телефонные нужно поместить в надлежащий контекст.


Возвращаемся к вопросу, на который я так ещё и не получил ответа. Что такое "контекст"?

Я, например, когда говорю контекст то имею ввиду сугубо некоторое высказывание или цельный блок текста. Это общечеловеческое понимание термина "контекст". Есть ещё и программистские — контекст пользователя (совокупность данных, соотнесённых с пользователем), контекст защиты (то же, но для системы ограничения доступа), контекст запроса (снова совокупность данных).

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

А что имеете ввиду вы?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[18]: О правильных и неправильных классификациях...
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 20.03.06 08:28
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> Хе-хе. Вот нет в Java оператора "super super" для доступа к методу не

>> родителя, а дедушки и попробуй это нарушить. А вопрос, как это сделать,
>> я видел и в ru.java и на rsdn.
C>Просто решили не делать, так как нечасто требуется. Никаких
C>фундаментальных запретов для super.super нет.

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

>> the need of some of Morph’s clients to use the protocol provided in

>> Collection to enumerate the submorphs.
C>Вопрос такой: а зачем нужно реализовывать протокол коллекций?

Под протоколом коллекций имеются ввиду внутренние итераторы. Собственно там дальше приводятся 3 альтернативы. Персонально я, при прочих равных, сейчас бы делал "fat interface". Две другие — возвращать просто копию коллекции, и некую обёртку (например, ReadStream, который есть внешний итератор).

>> Ы?

C>Обычная ситуация — противоречие показывает, что у нас неправильная
C>архитектура (требуется доступ к приватным данным) или на недостаточность
C>архитектуры.

Ну, блин, это банальность.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[11]: Опечатка
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 20.03.06 09:23
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>С вами спорят далеко самые не типичные представители "большинства".


ГВ>Читать как: С вами спорят далеко не самые типичные представители "большинства".


Занятно. Так и прочитал. Что написано по другому — обратил внимание только сейчас.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[10]: О правильных и неправильных классификациях...
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 20.03.06 09:33
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>А с чего вы взяли, что идеальный код — это код, которого нет


Я думаю это очевидно. Код которого нет не может содержать ошибок. Вот на счет сопровождения не знаю, легче ли сопровождать то чего нет, чем то что есть — вопрос для меня открытый
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[21]: О правильных и неправильных классификациях...
От: FR  
Дата: 20.03.06 11:07
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:


КЛ>Тем не менее, другие инструменты и понятия ТРИЗ (высокого системного уровня), например, законы развития технических систем, идеальность, системный оператор могут быть использованы для решения сложных "программистских" задач. Собственно, мы это попытались показать в своих статьях. Например, статья "Освобождение узников оператора "IF" (http://www.triz-ri.ru/themes/method/creative/creative57.asp) как раз про системный оператор.


А вот насчет законов развития технических систем, я не уверен что они также действуют в программных системах как и в технических.
И я согласен с Геннадием абсолютной идеальности в программных системах нет, а есть идеальности с разных точек зрения.
Мне кажется вы пытаетесь законы выведенные для более простых систем перенести в более сложные, по моему ничего путного из этого не выйдет.

КЛ>К сожалению, сложные инструменты ТРИЗ (законы, идеальность, системный оператор) предъявляют высокие требования к квалификации человека, который их применяет. Опыт показал, что большинство людей, использующих ТРИЗ, применяют приемы. Кропотливый разбор задачи по АРИЗ или постановка задачи при помощи системного оператора дается, увы, не многим. Аналогичная ситуация складывается и в программировании — большинству людей удобнее применять паттерны (аналог приемов) и рефакторинг, чем качественно и кропотливо ставить задачу, рассматривать вещь не саму по себе, а в контексте, в группе. Честно Вам скажу, разнесение сущностей по разным системным уровням (выделение подсистемы, системы и надсистемы) — еще та задачка. (Здесь я, конечно же, не имею в виду совсем тривиальные вещи типа колеса, автомобиля и автотранспорта, где системные уровни всех трех сущностей очевидны.)


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

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


Извините пока такой работы не видно. Видна только чистая философия, на ней далеко не уедешь.
Re[17]: О правильных и неправильных классификациях...
От: FR  
Дата: 20.03.06 11:08
Оценка:
Здравствуйте, AVC, Вы писали:


AVC>Я хочу сказать, что применение вполне "тризовских" методов может иметь место и без лейбла "ТРИЗ".


Если любую диалектику обозвать тризом то можно
Re[23]: О правильных и неправильных классификациях...
От: FR  
Дата: 21.03.06 05:45
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

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


FR>>А вот насчет законов развития технических систем, я не уверен что они также действуют в программных системах как и в технических.


КЛ>А я уверен, что действуют. Моя уверенность — против Вашей. С мнением бесполезно спорить. Нужны аргументы. Свои аргументы я привел. А как на счет Ваших?


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

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


КЛ>Это не так. См. дискуссию про идеальность.


Как раз из этой дискуссии по моему вытекает моя точка зрения

FR>>Извините пока такой работы не видно. Видна только чистая философия, на ней далеко не уедешь.


КЛ>Извините, но проблема понимания — это проблема не только автора, но и читателя. В любом случае, на профессиональном форуме недостаточно просто высказать свое мнение. Мнение еще нужно обосновать.


Обосновать можно любую даже очень неэфективную методику, для этого нужна квалификация не программиста — проектировщика а хорошо подвешенный язык и склоность к философии
Проектирование и программирование это занятие на стыке инжинерии, психологии и философии, поэтому существут много методик, которые эффективны для авторов и некоторого количества людей близких к авторам по психотипу. Так что не стоит говорит о непонимании и неявно принижатть квалификацию оппонентов только из-за того что у них и у вас не совпадают психотипы.
Re[24]: О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 21.03.06 10:35
Оценка:
Здравствуйте, FR, Вы писали:

FR>Где аргументы, пусть даже не доказывающие, а хотя бы показывающие что эти законы работатют в программных системах?


Они есть и в данной дискуссии, и в статьях. Приведу лишь несколько ссылок:

1) Противоречия.
http://www.triz-ri.ru/themes/method/creative/creative50.asp

2) Системный оператор.
http://www.triz-ri.ru/themes/method/creative/creative57.asp
http://www.rsdn.ru/Forum/Message.aspx?mid=1780857&amp;only=1
Автор: Кирилл Лебедев
Дата: 14.03.06


3) Свертывание.
http://www.rsdn.ru/Forum/Message.aspx?mid=1787738&amp;only=1
Автор: Кирилл Лебедев
Дата: 17.03.06


4) Идеальность.
http://www.rsdn.ru/Forum/Message.aspx?mid=1787710&amp;only=1
Автор: Кирилл Лебедев
Дата: 17.03.06

http://www.rsdn.ru/Forum/Message.aspx?mid=1790859&amp;only=1
Автор: Кирилл Лебедев
Дата: 19.03.06


И статьи, и сообщения достаточно развернуты и содержат много примеров.

Соответственно, если Вы не согласны с выводами, то квалифицированный ответ строится по следующей схеме:

П. 1 неверен, потому что существуют такие-то и такие-то примеры, где это нельзя применить.
В п. 2 в примере автор перепутал то-то и то-то и стал исходить из ложных посылок.
В п. 3 — аргументы по поводу п. 3.
И т.д.


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


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

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


Простите, но психотип не имеет никакого отношения к квалификации. Квалификацию (и эффективность) определяет количество решенных практических задач, качество решений и, соответственно, качество аргументации. Все остальное — разговоры о политике, женщинах, психотипах, общие рассуждения о философии и психологии — конечно, занимательны, но являются замещением квалифицированной деятельности.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[18]: О правильных и неправильных классификациях...
От: AVC Россия  
Дата: 21.03.06 12:20
Оценка:
Здравствуйте, FR, Вы писали:

AVC>>Я хочу сказать, что применение вполне "тризовских" методов может иметь место и без лейбла "ТРИЗ".

FR>Если любую диалектику обозвать тризом то можно

Что значит 'любая диалектика'?

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[19]: О правильных и неправильных классификациях...
От: FR  
Дата: 21.03.06 12:35
Оценка:
Здравствуйте, AVC, Вы писали:

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


AVC>>>Я хочу сказать, что применение вполне "тризовских" методов может иметь место и без лейбла "ТРИЗ".

FR>>Если любую диалектику обозвать тризом то можно

AVC>Что значит 'любая диалектика'?


Извини забыл что существует только одно единственное верное и потому всесильное учение
Re[20]: О правильных и неправильных классификациях...
От: AVC Россия  
Дата: 21.03.06 12:48
Оценка:
Здравствуйте, FR, Вы писали:

AVC>>Что значит 'любая диалектика'?


FR>Извини забыл что существует только одно единственное верное и потому всесильное учение



Я не имел этого в виду.
Просто хотел узнать, что понимается под диалектикой в данном случае.
IMHO, есть два типа диалектики: 'негативная' и 'позитивная'.
В первом случае противоречием кончают (Зенон, Кант), во втором — с него начинают (Гегель, ТРИЗ).
Конечно, это чрезмерное упрощение и сугубое IMHO.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[21]: О правильных и неправильных классификациях...
От: FR  
Дата: 21.03.06 13:02
Оценка:
Здравствуйте, AVC, Вы писали:


AVC>

AVC>Я не имел этого в виду.
AVC>Просто хотел узнать, что понимается под диалектикой в данном случае.
AVC>IMHO, есть два типа диалектики: 'негативная' и 'позитивная'.
AVC>В первом случае противоречием кончают (Зенон, Кант), во втором — с него начинают (Гегель, ТРИЗ).
AVC>Конечно, это чрезмерное упрощение и сугубое IMHO.

Я имел в виду вообще единство и борьбу противоположностей, то есть противоречия. Не только ТРИЗ занимается их разрешением
Re[22]: О правильных и неправильных классификациях...
От: AVC Россия  
Дата: 21.03.06 14:05
Оценка:
Здравствуйте, FR, Вы писали:

FR>Я имел в виду вообще единство и борьбу противоположностей, то есть противоречия. Не только ТРИЗ занимается их разрешением


Боюсь, что мы отходим от темы, но мое любопытство слишком сильно.
Какой еще подход связан с разрешением противоречий?
Мне известно только про ТРИЗ и диамат.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[23]: О правильных и неправильных классификациях...
От: FR  
Дата: 21.03.06 14:52
Оценка:
Здравствуйте, AVC, Вы писали:

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


FR>>Я имел в виду вообще единство и борьбу противоположностей, то есть противоречия. Не только ТРИЗ занимается их разрешением


AVC>Боюсь, что мы отходим от темы, но мое любопытство слишком сильно.

AVC>Какой еще подход связан с разрешением противоречий?
AVC>Мне известно только про ТРИЗ и диамат.

Мне кажется что любая современная итерационная методология разработки по сути это поиск и разрешение противоречий, просто терминология для этого применяется не такая как в диамате и тризе
Re[24]: О правильных и неправильных классификациях...
От: AVC Россия  
Дата: 21.03.06 17:13
Оценка:
Здравствуйте, FR, Вы писали:

FR>Мне кажется что любая современная итерационная методология разработки по сути это поиск и разрешение противоречий, просто терминология для этого применяется не такая как в диамате и тризе


Возможно.
Некоторые принципы проектирования, например Open-Closed Principle (OCP, в изложении хотя бы Мартина, ), очень похожи на 'тризовские'. Тот же Мартин пишет, что требования, сочетающиеся в OCP, выглядят противоречащими друг другу.
Согласен, что не надо стрелять из пушек по воробьям.
В таком случае можно обойтись и рогаткой.
Но иногда (не так часто) имеет смысл сознательно прибегнуть к методу выявлению и устранению противоречий.
Повторюсь, мне кажется, это скорее всего приложимо к архитектурным проблемам.
Поэтому тема о применении ТРИЗ в программировании все же заслуживает внимания.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.