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

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

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

Кирилл Лебедев wrote:
> Критерии все-таки были. Хороший код — это *компактный* код.
Кхм....

#!/usr/bin/perl

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

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

Здравствуйте, 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>Все еще уверены, что чем компактнее код — тем он лучше?

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

Кирилл Лебедев wrote:
> C>Первый пример вообще никуда не годится. Имеем стандартный случай с
> C>необходимостью создания функции (тем более, что в реальной жизни у нас
> C>не будет хороших статических массивов из трех строк).
> Первый, как и все остальные примеры, взят из реальной жизни. Это к
> вопросу о *надуманности*.
Тем хуже. Для модельных примеров еще можно простить надуманность, для
реальных — пинать программиста.

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

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

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

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

Или вот такая ситуация:

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

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

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

> 1) отсутствуют способы (модели) постановки задач;
А вам не кажется, что они отсутствуют в принципе?

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

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

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

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

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

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

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

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

Lazy Cjow Rhrr wrote:
> C>Все еще уверены, что чем компактнее код — тем он лучше?
> Много синтаксического оверхеда. Это не компактный код. Это просто
> утоптанный код
Щас на K (начал изучать — классный язык!) попробую что-нибудь написать

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

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

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

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

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

    return pszTemp;
}

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

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

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

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

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

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

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

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

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

Мы повторяемся

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

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

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

ANS>Естественно, нужно учитывать насколько сильно ограничивакт ЯП Начиная с такого:
Это, безусловно, повысит наглядность, но последовательность из 3-х (в пределе — N) вызовов так и останется:

doDmth("Одни данные"):
doDmth("Другие данные"):
doDmth("Третьи данные"):
//...
doDmth("Энные данные"):

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

ANS>А может проще взять регэкспы.
Во всяком случае, эволюционно все к этому и идет.

Кирилл Лебедев wrote:
> Вынося последовательность действий в функцию, мы просто убираем лишний
> код из *поля зрения*.
А чем это хорошо? Теперь при отладке мне придется идти на начало функции
и смотреть что там в массиве находится, чтобы понять почему оно [не]
работает.

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

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

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

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

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

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

Может вот это подойдет

Автор: Lazy Cjow Rhrr
Дата: 06.12.05

?

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

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

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

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

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

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

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

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

ANS>>Естественно, нужно учитывать насколько сильно ограничивакт ЯП Начиная с такого:
КЛ>Это, безусловно, повысит наглядность, но последовательность из 3-х (в пределе — N) вызовов так и останется:
КЛ>

КЛ>doDmth("Одни данные"):
КЛ>doDmth("Другие данные"):
КЛ>doDmth("Третьи данные"):
КЛ>//...
КЛ>doDmth("Энные данные"):
КЛ>

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

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

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

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

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

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

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

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 );
  }
}

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

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

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