Здравствуйте, Mamut, Вы писали:
M>Странный подход. Вообще-то, решают заказчики и только заказчики. Потому что хороший софт — это софт, решающий проблемы заказчика в рамках поставленной заказчиком проблемы.
Софт написанный студентами левой ногой на подпорках тоже может решать проблемы заказчика. Вот только хорошим его назвать трудно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Софт написанный студентами левой ногой на подпорках тоже может решать проблемы заказчика. Вот только хорошим его назвать трудно.
Это почему вдруг? Была проблема, посл появления софта проблема исчезла? Софт решает проблему, это хороший софт с точки зрения решаемой задачи.
Если вдруг понадобилось обновлять софт, но он написан абы как, и за его модификацию надо много платить — это плохой софт с точки зрения поддержки.
Можно продолжить.
Оценка она всегда многогранная, ты как программист оценишь программу по одним критериям, Шеридан как сисадмин по другим, тетя Маша-бухгалтер по третим, а дядя Вася-гендир — по четвертым.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Re[25]: Помогает ли Linq сделать код понятнее или быстрее?
M>>Как это заказчик не определит? Задачу же не какой-то Петя с улицы ставит У нас есть задача, например, поиск отелей по заданным критериям поиска. Для сайта приемлемое время отклика — до 5-10 секунд,
PD>Каким образом заказчик определил, что 5-10 секунд — это приемлемо ? А он знает, что (допустим. я не о вас говорю), что при иной реализации это могло бы занимать 0.1 сек ? Кто ему и как внушил, что 5-10 — это хорошо ?
Никто не внушал. Это то время, на которое он, как заказчик, согласен. Не мы это время ему внушали Если будет 0.1 сек — он только будет рад.
M>>Странный подход. Вообще-то, решают заказчики и только заказчики. Потому что хороший софт — это софт, решающий проблемы заказчика в рамках поставленной заказчиком проблемы. CC>Софт написанный студентами левой ногой на подпорках тоже может решать проблемы заказчика. Вот только хорошим его назвать трудно.
По каким критериям?
С точки зрения специалиста: сортировка пузырьком — это плохо, в студенческой левопяточной программе она есть, программа плохая.
С точки зрения заказчика: программа работает в пределах требуемых 0.5 секунд и обрабатывает данные так, как надо. Программа хорошая.
Так вот, программа хорошая, так как она выполняет поставленные перед ней задачи. то, что она реализована с помощью сортировки пузырьком не делает ее плохой, а просто открывает возможности по оптимизации.
M>>Странный подход. Вообще-то, решают заказчики и только заказчики. Потому что хороший софт — это софт, решающий проблемы заказчика в рамках поставленной заказчиком проблемы.
PD>Извини, но я здесь никаких контраргументов не вижу. Вижу только декларативное заявление.
Ну так у тебя точно такие же заявления про то, что заказчик не может решать про качественность продукта
Здравствуйте, Cadet, Вы писали: C>Если вдруг понадобилось обновлять софт, но он написан абы как, и за его модификацию надо много платить — это плохой софт с точки зрения поддержки.
А за поддержку кто платить будет? Заказчик. Значит в таком случае это плохая программа с точки зрения заказчика.
Re[11]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, gandjustas, Вы писали:
K>
K>double sum2 = ba.Sum(item => item);
K>
G>>Сразу видно сиплюсплюсника. Кто же в цикле делает проверку i<N делай i<ba.Length
K>Т.е. то, что он вместо Sum() измеряет Select(x => x).Sum() никого кроме меня не рассмешило?
Кстати да, в у меня по пучилось 156 и 393 мс для цикла и .Sum() соответственно.
Re[25]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Каким образом заказчик определил, что 5-10 секунд — это приемлемо ? А он знает, что (допустим. я не о вас говорю), что при иной реализации это могло бы занимать 0.1 сек ? Кто ему и как внушил, что 5-10 — это хорошо ?
Бизнес-требования.
Для внутренней софтины это потеря времени оператора (критично или нет потеря 3х секунд перемноженная на сколько-он там запросов делает).
Для внешней — если скорость работы вызывает дискомфорт (5-10 сек уже начинают вызывать, дольше — больше) это шанс потери пользователей. То есть, если есть сайт с той же функциональностью, но быстрее работающий, или если есть сайт с несколько меньшей функциональностью, но гораздо более быстро работающий, то такие сайты могут перетянуть на себя пользователей. Нет конкурентов — нет и бизнест-требования по производительности, никуда пользователи не денутся
Далее, если видно, что текущая система не удовлетворяет бизнес-требованиям, то надо искать другого подтрядчика, который сделает качественнее.
Если найти в рамках имеющегося бюджета подрядчика, который сделает быстрее при сохранении фунциональности не получается — то придется признать — хотя бы на время — что скорость работы обусловлена именно сложностью задачи.
При этом критерий времени отклика — он гораздо понятнее и при этом легко проверяем, чем абстрактные рассуждения некоего специалиста о "халтуре" конкурентов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[5]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, Klapaucius, Вы писали:
K>Если возникают сложности как в примерах выше — это просто признак того, что в библиотеке нет какого-то комбинатора. В данном случае функции, работающей с соседними элементами в последовательности. В таких случаях и следует написать недостающий комбинатор, который потом еще и не раз пригодится.
Угу, который может пригодится, а может и не пригодится
Здравствуйте, gandjustas, Вы писали:
G>Если что Linq — единственный способ обрабатывать последовательности (ленивые и потенциально бесконечные). Если ты используешь цикл, то последовательность у тебя как минимум конечная и почти всегда материализованная в виде массива.
a, b = 1, 1
while True:
process(a, b)
a, b = b, a + b
if is_exit():
break
Re[25]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Каким образом заказчик определил, что 5-10 секунд — это приемлемо ? А он знает, что (допустим. я не о вас говорю), что при иной реализации это могло бы занимать 0.1 сек ? Кто ему и как внушил, что 5-10 — это хорошо ?
Тут большое значение имеют и трудозатраты на получение этих 0.1 секунд. Если это стоит в 10 или 100 раз дороже любой заказчик трижды подумает надо ли оно ему.
Re[10]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, FR, Вы писали:
FR>Угу, который может пригодится, а может и не пригодится
Тут надо ориентироваться по обстоятельствам. К примеру, если на горизонте видно грибовидное облако атомного взрыва, то повторно использовать код, вероятнее всего, не удастся.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[5]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, Klapaucius, Вы писали:
Кэр>>Да-да. И специальную инструкцию к коду, как его правильно читать. Вместо одного простейшего цикла. Для которого нафиг никаких инструкций не надо.
K>А инструкция и будет. Пододите курсор к вызову одной библиотечной функции — всплывает подсказка. Подводите к другой — и тут подсказка. Да и названия функций, если удачно подобраны — уже подсказка. К невнятным манипуляциям в цикле никаких подсказок нет, если только к каждому циклу они не будут написаны самим программистом. Ну и на практике он они написаны не будут. K>В том числе и поэтому (но не только) и нужно использовать библиотечные функции, которые делают известные изучившему библиотеку действия, комбинировать их и выражать таким образом явно, что код делает, а не городить рыхлые нагромождения из элементарных действий в циклах, которые по отдельности понятны, но только этих деталей уже не 3, как в примере выше, а десятки.
Мне больше нравится код, где никаких инструкций не нужно. И в этом конкретном примере — Linq требует дополнительных пояснений, а простейший цикл не требует.
Более того, приведенный код с Linq приносит очень много неявного поведения. Что, например, является corner case в коде с pairwiseby и данным конкретным предикатом — пустой массив, массив с одним элементом, двумя, тремя, четырьмя, пятью? Некоторые из них? Все вышеперечисленные? Нужны ли unit тесты для всех этих вариантов, чтобы сохранить жесткость этого кода?
Почему для простейшего алгоритма вы начали требовать знания библиотечных функций, тем более не самых популярных? Я, конечно, понимаю, что синдром студента "я выучил, значит все должны выучить!" и принцип "краткость — сестра нашего брата!" — это одни из самых мощных мотиваторов в нашей профессии. Но во всем надо знать меру.
Re[6]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, Кэр, Вы писали:
Кэр>Здравствуйте, Klapaucius, Вы писали:
Кэр>>>Да-да. И специальную инструкцию к коду, как его правильно читать. Вместо одного простейшего цикла. Для которого нафиг никаких инструкций не надо.
K>>А инструкция и будет. Пододите курсор к вызову одной библиотечной функции — всплывает подсказка. Подводите к другой — и тут подсказка. Да и названия функций, если удачно подобраны — уже подсказка. К невнятным манипуляциям в цикле никаких подсказок нет, если только к каждому циклу они не будут написаны самим программистом. Ну и на практике он они написаны не будут. K>>В том числе и поэтому (но не только) и нужно использовать библиотечные функции, которые делают известные изучившему библиотеку действия, комбинировать их и выражать таким образом явно, что код делает, а не городить рыхлые нагромождения из элементарных действий в циклах, которые по отдельности понятны, но только этих деталей уже не 3, как в примере выше, а десятки.
Кэр>Мне больше нравится код, где никаких инструкций не нужно. И в этом конкретном примере — Linq требует дополнительных пояснений, а простейший цикл не требует.
Это потому что ты Linq не понимаешь, а циклы понимаешь.
Для человека, который одинаково понимает (не понимает) и то и другое, linq будет проще.
Кэр>Более того, приведенный код с Linq приносит очень много неявного поведения. Что, например, является corner case в коде с pairwiseby и данным конкретным предикатом — пустой массив, массив с одним элементом, двумя, тремя, четырьмя, пятью? Некоторые из них? Все вышеперечисленные? Нужны ли unit тесты для всех этих вариантов, чтобы сохранить жесткость этого кода?
Цикл требует того же самого.
Ты сначала для себя определи будет ли упорядоченным пустой массив и из одного элемента.
Кэр>Почему для простейшего алгоритма вы начали требовать знания библиотечных функций, тем более не самых популярных? Я, конечно, понимаю, что синдром студента "я выучил, значит все должны выучить!" и принцип "краткость — сестра нашего брата!" — это одни из самых мощных мотиваторов в нашей профессии. Но во всем надо знать меру.
А чего ты пытаешься требовать знание как пишется for и думать с чего начинается индексация массива, и как вообще получить длину массива, а если там не массив, а IEnumerable<T>?
Re[7]: Помогает ли Linq сделать код понятнее или быстрее?
K>Тут надо ориентироваться по обстоятельствам. К примеру, если на горизонте видно грибовидное облако атомного взрыва, то повторно использовать код, вероятнее всего, не удастся.
Здравствуйте, 0K, Вы писали:
0K>Здравствуйте, vitasR, Вы писали:
R>>его вариант на самом деле лучший, самый понятный и самых быстрых (только проверку на пустой массив надо приделать).
0K>Кстати, философский вопрос. При передаче пустого массива нужно вернуть true или false?
Упорядоченный массив — это массив, в котором все элементы расположены по порядку. Очевидно, что для пустого массива это выполняется.
Re[5]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, 0K, Вы писали:
0K>Здравствуйте, gandjustas, Вы писали:
G>>Это ты где такую шутку прочитал? G>>99% данных обычно программа получает извне.
0K>Ну да, и записывает их в ОЗУ. А раз в ОЗУ, то лучше массив.
Здравствуйте, 24, Вы писали:
24>А за поддержку кто платить будет? Заказчик. Значит в таком случае это плохая программа с точки зрения заказчика.
А разве это противоречит точу что я написал? С другой стороны если в этой программе тетя Маша-бухгалтер строит отчеты для налоговой за минуту и гендир смог сэкономить на найме второго буха в помощь первому — тут надо оценивать, что было бы затратнее. А безапеляционно заявить "фу, на яве писана! прога говно!", или "ааа, пузырек внутри, что за говнокодер наклепал!", или "полсекунды работает запрос, писал бы я на плюсах — в десятую долю секунды бы уложился, прога отстой" — это знаешь ли минимум смешно. Как сказать "Камаз отстой, я на хундае быстрее доеду".
У нас есть задача, например, поиск отелей по заданным критериям поиска. Для сайта приемлемое время отклика — до 5-10 секунд, 
Если будет 0.1 сек — он только будет рад.
