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



M>Неспециалисту очень легко понять, что то халтура. У нас заказчики просто оперируют понятиями «неудобно» и «медленно». Все. Этого достаточно

Неудобно — с этим, пожалуй, еще и соглашусь.
А вот "медленно" — очень сильно зависит от того, что делаем. Если время операции доли секунды, то заказчик просто не в состоянии сказать, медленно это или нет. Да и не важно в этом случае. А вот если время операции равно 5 секундам или 5 минутам — это медленно или нет ? Это в зависимости от задачи может быть и очень долго и очень медленно, и никакой заказчик не сможет это определить правильно.

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

0K>Человек спросит, как с помощью Linq проверить упорядоченность массива, к примеру {1, 3, 5, 7, 9}.

Правило большого пальца — если для операции над коллекцией достаточно одного прохода и в алгоритме учавствует только одна коллекция, то Linq чаще только мешает.

Конкретно для этой задачи использовать Linq — не очень ясно зачем надо.

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

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

Решил дописать. Чтобы ясна была моя позиция до конца.

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

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

Резюме — если пользователь недоволен, его мнение важно и существенно при оценке качества за исключением разве что каких-то маргинальных случаев.

А вот если пользователь доволен — это ничего вообще не значит в плане оценки качества. И иной подход очень быстро приведет нас в царство халтуры.

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

Так что если речь идет о негативной оценке — суд профанов принимается. А вот что касается позитивной оценки — принимается только суд специалистов, и хороших специалистов.

M>>Неспециалисту очень легко понять, что то халтура. У нас заказчики просто оперируют понятиями «неудобно» и «медленно». Все. Этого достаточно

PD>Неудобно — с этим, пожалуй, еще и соглашусь.
PD>А вот "медленно" — очень сильно зависит от того, что делаем. Если время операции доли секунды, то заказчик просто не в состоянии сказать, медленно это или нет. Да и не важно в этом случае.

Вот именно Думаю, к этому и клонит gandjustas

PD>А вот если время операции равно 5 секундам или 5 минутам — это медленно или нет ? Это в зависимости от задачи может быть и очень долго и очень медленно, и никакой заказчик не сможет это определить правильно.

Как это заказчик не определит? Задачу же не какой-то Петя с улицы ставит У нас есть задача, например, поиск отелей по заданным критериям поиска. Для сайта приемлемое время отклика — до 5-10 секунд, для внутренней софтины — не более 3-4 секунд. Все, что больше этого времени, для заказачика попадает в категорию «медленно».

PD>Так что если речь идет о негативной оценке — суд профанов принимается. А вот что касается позитивной оценки — принимается только суд специалистов, и хороших специалистов.

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

В случае массового софта хороший софт — это софт, решающий проблемы целевой аудитории.

Если качество продукта будут оценивать специалисты, мы из войн типа «iPhone — гуано» никогда не выберемся

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

M> PD>А вот если время операции равно 5 секундам или 5 минутам — это медленно или нет ? Это в зависимости от задачи может быть и очень долго и очень медленно, и никакой заказчик не сможет это определить правильно.

M> Как это заказчик не определит? Задачу же не какой-то Петя с улицы ставит У нас есть задача, например, поиск отелей по заданным критериям поиска. Для сайта приемлемое время отклика — до 5-10 секунд, для внутренней софтины — не более 3-4 секунд. Все, что больше этого времени, для заказачика попадает в категорию «медленно».

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

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

Кэр>Здравствуйте, 0K, Вы писали:

0K>>Человек спросит, как с помощью Linq проверить упорядоченность массива, к примеру {1, 3, 5, 7, 9}.

Кэр>Правило большого пальца — если для операции над коллекцией достаточно одного прохода и в алгоритме учавствует только одна коллекция, то Linq чаще только мешает.

Да ну?

Сделай Select, SelectMany и Where без Linq.

Если что Linq — единственный способ обрабатывать последовательности (ленивые и потенциально бесконечные). Если ты используешь цикл, то последовательность у тебя как минимум конечная и почти всегда материализованная в виде массива.

Кэр>Конкретно для этой задачи использовать Linq — не очень ясно зачем надо.
Очень ясно. Нормальное определение упорядоченности массива на Linq

seq.PairwiseBy((a,b) => a<b).All()

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

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

F>А может быть стоило бы задуматься о контексте задачи, а потом уже ломать копья про (не)эффективность?

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

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

Кроме того, я все-равно не понимаю чем линковская сортировка с последующим сравнением нагляднее чем цикл. они ж даже по размеру примерно одинаковые.

Дальше. про LINQ. На мой взгляд есть три случая:

1) некая навороченная конструкция, которая на LINQ'е записывается просто и эффектно,а без линка — длинная простыня кода. Разумеется, здесь линк очень к месту.

2) нечто где LINQ нафиг не нужен, но он смотрится естесственней, например, написать someArray.Sum(x=>x) нагляднее чем простой цикл с суммированием, при этом сложность обоих алгоритмов одинакова, они отличаются только формой записи. здесь снова есть смысл использовать LINQ, хотя... см.ниже

3) там где LINQ нафиг не нужен, не подходит и тулить его просто вредительство. типа как в рассматриваемом примере.
заведомо на ровном месте без всякой выгоды вставлять в программу тормоза — вредительство.

Эх, не поленился я. Проверил линковский SUM.

тупое суммирование массива из 30,000,000 doubles.

LINQ Sum: 915 ms
обычный цикл: 134 ms
C++ : 61 ms

так что похоже только в первом из перечисленных случаев есть смысл использовать это новомодное чудо.

        private const int N = 30000000;
        static void Main(string[] args)
        {

            var ba = new double[N];
            for (int i = 0; i < N; i++)
                ba[i] = i*i;

            double sum = 0;
            DateTime t0 = DateTime.Now;
            for (int i = 0; i < N; i++)
                sum += ba[i];
            DateTime t1 = DateTime.Now;
            Console.WriteLine("{0} {1}", sum, t1-t0);

            t0 = DateTime.Now;
            double sum2 = ba.Sum(item => item);
            t1 = DateTime.Now;
            Console.WriteLine("{0} {1}", sum, t1 - t0);
        }

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

PD>А вот если пользователь доволен — это ничего вообще не значит в плане оценки качества.
Это значит все. Пользователь доволен — исполнитель сделал свою работу.


PD>И иной подход очень быстро приведет нас в царство халтуры.
Счего бы?

Ты уже несколько лет приводишь такое утверждение, ни разу не обосновав его. Ты оправдываешься за непродуктивную работу?


PD>Нигде пользователь не решает, является ли продукт качественным.
Только пользователь и решает. Причем не только в ПО, а и во многих других сферах.

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

PD>Так что если речь идет о негативной оценке — суд профанов принимается. А вот что касается позитивной оценки — принимается только суд специалистов, и хороших специалистов.

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

Когда продукт массовый, то надо ориентироваться на мнение этих самых масс, а не маленькой группы "экспертов".

А вот гораздо интереснее вопрос "качества" стоит когда продукт заказной разработки для одного заказчика.

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

0K>>>Человек спросит, как с помощью Linq проверить упорядоченность массива, к примеру {1, 3, 5, 7, 9}.

Кэр>>Правило большого пальца — если для операции над коллекцией достаточно одного прохода и в алгоритме учавствует только одна коллекция, то Linq чаще только мешает.

G>Да ну?
G>Сделай Select, SelectMany и Where без Linq.

Что ну? Здесь порождение новой коллекции. Linq в таких случаях экономит промежуточные/результирующие переменные коллекции — крайне удобно. Для простого перебора это не важно.

G>Если что Linq — единственный способ обрабатывать последовательности (ленивые и потенциально бесконечные). Если ты используешь цикл, то последовательность у тебя как минимум конечная и почти всегда материализованная в виде массива.

Foreach дает перебор ленивой бесконечной коллекции.

G>

G>seq.PairwiseBy((a,b) => a<b).All()
G>

G>По русски читать в обратном порядке: "Все пары последовательных элементов такие что первый элемент меньше второго".

Да-да. И специальную инструкцию к коду, как его правильно читать. Вместо одного простейшего цикла. Для которого нафиг никаких инструкций не надо.

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

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

0K>>>>Человек спросит, как с помощью Linq проверить упорядоченность массива, к примеру {1, 3, 5, 7, 9}.

Кэр>>>Правило большого пальца — если для операции над коллекцией достаточно одного прохода и в алгоритме учавствует только одна коллекция, то Linq чаще только мешает.

G>>Да ну?
G>>Сделай Select, SelectMany и Where без Linq.

Кэр>Что ну? Здесь порождение новой коллекции. Linq в таких случаях экономит промежуточные/результирующие переменные коллекции — крайне удобно. Для простого перебора это не важно.

Так простой перебор и встречается крайне редко, поэтому так много всяких функций в linq.


G>>Если что Linq — единственный способ обрабатывать последовательности (ленивые и потенциально бесконечные). Если ты используешь цикл, то последовательность у тебя как минимум конечная и почти всегда материализованная в виде массива.

Кэр>Foreach дает перебор ленивой бесконечной коллекции.

И что?

G>>

G>>seq.PairwiseBy((a,b) => a<b).All()
G>>

G>>По русски читать в обратном порядке: "Все пары последовательных элементов такие что первый элемент меньше второго".

Кэр>Да-да. И специальную инструкцию к коду, как его правильно читать. Вместо одного простейшего цикла. Для которого нафиг никаких инструкций не надо.

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

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

M>Как это заказчик не определит? Задачу же не какой-то Петя с улицы ставит У нас есть задача, например, поиск отелей по заданным критериям поиска. Для сайта приемлемое время отклика — до 5-10 секунд,

Каким образом заказчик определил, что 5-10 секунд — это приемлемо ? А он знает, что (допустим. я не о вас говорю), что при иной реализации это могло бы занимать 0.1 сек ? Кто ему и как внушил, что 5-10 — это хорошо ?

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

M>Странный подход. Вообще-то, решают заказчики и только заказчики. Потому что хороший софт — это софт, решающий проблемы заказчика в рамках поставленной заказчиком проблемы.

Извини, но я здесь никаких контраргументов не вижу. Вижу только декларативное заявление.

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

<все skipped>

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

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

Кэр>Да-да. И специальную инструкцию к коду, как его правильно читать. Вместо одного простейшего цикла. Для которого нафиг никаких инструкций не надо.

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

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

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

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

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

R>тупое суммирование массива из 30,000,000 doubles.

R>LINQ Sum: 915 ms
R>обычный цикл: 134 ms
R>C++ : 61 ms

R>так что похоже только в первом из перечисленных случаев есть смысл использовать это новомодное чудо.

R>

R>        private const int N = 30000000;
R>        static void Main(string[] args)
R>        {

R>            var ba = new double[N];
R>            for (int i = 0; i < N; i++)
R>                ba[i] = i*i;

R>            double sum = 0;
R>            DateTime t0 = DateTime.Now;
R>            for (int i = 0; i < N; i++)
R>                sum += ba[i];
R>            DateTime t1 = DateTime.Now;
R>            Console.WriteLine("{0} {1}", sum, t1-t0);

R>            t0 = DateTime.Now;
R>            double sum2 = ba.Sum(item => item);
R>            t1 = DateTime.Now;
R>            Console.WriteLine("{0} {1}", sum, t1 - t0);
R>        }

R>

Сразу видно сиплюсплюсника. Кто же в цикле делает проверку i<N делай i<ba.Length

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

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

M>>Как это заказчик не определит? Задачу же не какой-то Петя с улицы ставит У нас есть задача, например, поиск отелей по заданным критериям поиска. Для сайта приемлемое время отклика — до 5-10 секунд,

PD>Каким образом заказчик определил, что 5-10 секунд — это приемлемо ? А он знает, что (допустим. я не о вас говорю), что при иной реализации это могло бы занимать 0.1 сек ? Кто ему и как внушил, что 5-10 — это хорошо ?
Это не вылезает за пределы того что он видит на других сайтах.

Есть же давно известное правило.
До 0.1 секунды для пользователя "моментально", до 1 секунды "быстро", до 10 секунд "приемлемо". Причем касается реакции интерфейса, а не времени выполнения работы. Если интерфейс умудряется фибдбэчить каждую секунду, то и минута покажется пользователю приемлемым временем работы.

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

R>

R>            Console.WriteLine("{0} {1}", sum, t1-t0);
R>            t0 = DateTime.Now;
R>            double sum2 = ba.Sum(item => item);
R>            t1 = DateTime.Now;
R>            Console.WriteLine("{0} {1}", sum, t1 - t0);
R>

И результаты суммирования всегда совпадают... Но это так, к слову.

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

double sum2 = ba.Sum(item => item);

G>Сразу видно сиплюсплюсника. Кто же в цикле делает проверку i<N делай i<ba.Length

Т.е. то, что он вместо Sum() измеряет Select(x => x).Sum() никого кроме меня не рассмешило?