Здравствуйте, Кэр, Вы писали:
Кэр>Мне больше нравится код, где никаких инструкций не нужно.
Мне тоже, но к циклам это отношения не имеет. Они нечитабельны.
Кэр>И в этом конкретном примере — Linq требует дополнительных пояснений, а простейший цикл не требует.
Ну, простейший цикл
forever {}
особых пояснений действительно не требует, вот только он бесполезен. А все полезные требуют, да еще как!
Кэр>Более того, приведенный код с Linq приносит очень много неявного поведения. Что, например, является corner case в коде с pairwiseby и данным конкретным предикатом — пустой массив, массив с одним элементом, двумя, тремя, четырьмя, пятью? Некоторые из них? Все вышеперечисленные? Нужны ли unit тесты для всех этих вариантов, чтобы сохранить жесткость этого кода?
Это были доводы против использования функций и в пользу дублирования кода?
... << 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
Здравствуйте, Pavel Dvorkin, Вы писали:
M>>Нас на самом деле занесло немного в ту степь (что всегда происходит с аналогиями). PD>Тогда вопрос — почему в той степи иные все же (ну согласись же ) законы ? И таких степей очень много, практически все. Помнишь, я про мост писал — та же степь. Про банк — та же. Что-то тут не так...
Да все тут точно так же . Когда мост через ручей в деревне строят никто не просчиывает пределы прочности древесины и воздейсвтие атмосферных явлений — кинут пару бревен и порядок.
Когда строят мост через пролив в 5 километров по которому еще и поезда ходить будут — выкатывают стотыщ требований, которые необходимо соблюсти.
То же самое в точности и в IT. Если заказчику нужна программка для решения небольшой текущей проблемы в небольшом отделе — это одно. Требований будет немного и свобода по реализации очень большая.
Если ему нужна программа для управления деньгами большого числа пользователей — то выкатят вагон требований, в частности по надежности, масштабируемости и безопасности. Да еще и добавят требование предоставления всех исходников программы на code-review отделу информационной безопасности с необходимостью учесть все созданные замечания.
И кстати, требования по маштабируемости не будут выставлять в терминах "надо быстрее и еще-еще быстрее". Выставят предельный график изменения требований к ресурсам при заданном просте числа обрабатываемых данных. И если в этот график программа уложится — все хорошо, и опять же не очень важно как она там реализована технически.
А вот проблемы в коде, ведущие к утечке или повреждению данных, найденные отделом сопровождения и отделом информационной безопасности сразу ставят крест на программе. Потому что это тоже одно из бизнес-требований — 0 процентов выявленных дефектов по (и список угроз, которые должны быть учтены — такие как утечка персональных данных, потеря финансовых данных и т.д. и т.п.)
Это как в том же мороженном — если ты его делаешь не в расчете на диабетиков, то ты можешь туда добавлять сахарозу, а можешь фруктозу или глюкозу или вообще муку — это твои личные проблемы. Но вот добавлять ядовитые вещества — нельзя, поскольку тогда не пройдешь сертификацию (кстати, недавно в РФ отменили обязательную сертификацию продуктов питания, так что теперь добавлять можно, но надо быть уверенным, что тебя не поймают, а то оштрафуют — законодательно имеется ответственность за изготовление и продажу продуктов питания, содержащих ядовитые вещества).
И да — заказчик станет "доволен" именно когда все требования будут соблюдены. Принимающий ПМ, пусть он хоть вообще не шарит в IT, будет нифига не доволен принимать программу, если у него на столе отчет отдела ИБ, что программа в текущем виде черевата большими судебными исками — нахрена ему принимать эту ответственность?
Кстати, раз уж упомянул про закон, запрещающий добавлять яды в продукты питания.
Вот отличный пример, что в IT все точно так же, только область новая, регулировок пока еще меньше — некоторое время назад было законодательно издано требование ко всем организациям, которые так или иначе хранят или обрабатывают персональные данные гражан, привести свои системы хранения/обработки в соответстве с требованиями федерального закона "О персональных данных". А там в том числе требования — и что можно собирать, а что нельзя, и как должно осуществляться шифорование и в целом защита данных, и еще куча аспектов. И теперь, что характерно, ни одна компания не примет IT-систему, храняющую персональные данные, если она не соответствует требованиям закона.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[11]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, vitasR, Вы писали:
R>Здравствуйте, Mamut, Вы писали:
R>>>тупое суммирование массива из 30,000,000 doubles.
R>>>LINQ Sum: 915 ms R>>>обычный цикл: 134 ms R>>>C++ : 61 ms
M>>Как всегда, приводятся какие-то непонятные примеры и выдаются за быстродействие Понятно же, что никому даром не нужно ни такое суммирование, ни такое решение.
R>в качестве оценки эффективности реализации Sum на простых запросах приведенный код (даже несмотря на неточность в выводе результатов) вполне адекватен.
Ниугадал.
У меня получилась разница .Sum и цикла в 2.3 раза, а не в 7, как у тебя. Ты видимо совсем не то померял.
M>>В реальных задачах понадобится от силы пара тысяч чисел, и их суммирование на всех трех языках наверняка уместится в десяток миллисекунд, что человеческому глазу незаметно (ниже исправили код на C# и уже разрыв с обычным циклом составил не 9, а 3 раза). О чем весь сыр-бор?
R>вот не поветите, реальные задачи они разные бывают. И массиви на миллионы и десятки миллионов элементов совсем не редкость.
Конечно не редкость, а вот такая обработка для таких массивов редкость.
Часто с такими сталкиваешься? что за алгоритмы на них работают? Как-то не верится что обычное суммирование хоть где-то будет.
R>Тем более что сыр-бор изначально был из-за того, что люди заменяют O(n) -> O(n*n) и не видят в этом криминала. а подобные вещи приводят к проблемам куда как быстрее.
Не надо черезмерно обобщать вопрос. Выше по теме выяснилось что проверка на упорядоченность — почти бесполезная операция, пусть она хоть экспоненциальную сложность имеет.
Кроме того если вдруг какая-то часть будет тормозить, то её можно оптимизировать. Преждевременно этим заниматься не надо.
Re[12]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, gandjustas, Вы писали:
G>>Ну вот я проснулся.
G>>insertion sort дает O(n) в случае упорядоченного массива.
FR>Угу офигено полезное свойство
Ну когда данные почти упорядочены, то лучше именно его применять.
Вот и совершенно ненужным стал алгоритм проверки упорядоченности.
Re[14]: Помогает ли Linq сделать код понятнее или быстрее?
PD>>Черт его знает. Что-то в этом есть. Но принять не могу. Вот представь себе. Были у фирмы данные размером в N, и некий алгоритм прекрасно работал. Год, два, три. А потом фирма вдруг резко выросла и размер данных стал 10N. И стало все совсем нехорошо. А специалисты свое "фи" сказали бы раньше — мол, пока у вас N, 2N, 3N — все будет нормально, а потом наплачетесь. И это не пузырек, который можно и заменить. Вы, господа разработчики, положили в основу совсем неподходящую модель, а она центральное место в вашей задаче, поэтому надо было с самого начала искать тут решение NlogN, а не уповать, что N^2 сойдет.
M>А вот не надо преждевременно оптимизировать и закладываться на «вдруг» С такими «вдруг» не может никто справиться, если только требования такого не было изначально заложено в систему.
Почему же нет ? Все очень просто. Получили задачу эти горе-разработчики. Проанализировали ее (это им так показалось). Пришли к выводу, что основная модель в варианте 1 будет вполне приемлемо работать . А есть модель 2, но она на порядок сложнее для реализации, потребует больше времени и сил, а выигрыш проявится только при больших N. Вот и решили — денег не так уж много, времени мало, реализуем модель 1. Один, правда, заикнулся в духе : "А что потом скажем, когда данных больше будет ?", но ему привели все твои аргументы и он заткнулся. Реализовали модель 1. Дальше по сценарию, описанному выше.
Вот это и есть халтура.
Взяли Хибернейт. Нужды нет, что он тащит по select половину данных, которые совсем и не нужны, а по update апдейтит то, что менять совсем не надо. Зато просто по сравнению с sproc. Кто-то, правда, заикнулся — а что будет, когда размеры выборок станут большими ? Ему привели все твои аргументы и он заткнулся. Реализовали модель 1. Дальше по сценарию, описанному выше.
Вот это и есть халтура.
With best regards
Pavel Dvorkin
Re[11]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, vitasR, Вы писали:
R>Здравствуйте, Mamut, Вы писали:
R>>>тупое суммирование массива из 30,000,000 doubles.
R>>>LINQ Sum: 915 ms R>>>обычный цикл: 134 ms R>>>C++ : 61 ms
M>>Как всегда, приводятся какие-то непонятные примеры и выдаются за быстродействие Понятно же, что никому даром не нужно ни такое суммирование, ни такое решение.
R>в качестве оценки эффективности реализации Sum на простых запросах приведенный код (даже несмотря на неточность в выводе результатов) вполне адекватен.
Он ничем абсолютно не адекватен.
M>>В реальных задачах понадобится от силы пара тысяч чисел, и их суммирование на всех трех языках наверняка уместится в десяток миллисекунд, что человеческому глазу незаметно (ниже исправили код на C# и уже разрыв с обычным циклом составил не 9, а 3 раза). О чем весь сыр-бор?
R>вот не поветите, реальные задачи они разные бывают. И массиви на миллионы и десятки миллионов элементов совсем не редкость. Тем более что сыр-бор изначально был из-за того, что люди заменяют O(n) -> O(n*n) и не видят в этом криминала. а подобные вещи приводят к проблемам куда как быстрее.
Кажется, тут умные люди, и все понимают, что при работе с миллионами и десятками миллионов элементов не будет использоваться ни один ни другой подход. Когда разница между O(n) и O(n*n) на наборе данных различается в 10ms (а ну-ка, проверьте кто-нить код из примера на 1000 даблов), то смысла разводить сыр-бор нет вообще. Узкое место в программе наверняка окажется совсем не там.
Здравствуйте, fmiracle, Вы писали:
PD>>Можно ли считать мое (именно мое, Dvokin Pavel) весьма положительное мнение о мороженом "Магнат" критерием того, что это качественный продукт ? Да или нет ? Без комментариев, просто да или нет!
F>Но я надеюсь, что и ты сможешь ответить — перестал ли ты избивать студентов на своих занятиях? Без комментариев, просто да или нет!
Подобной софистикой займи студентов. Я ей интересовался именно в студенческом возрасте. Мой же вопрос был вполне определенный, на него можно дать ответ "да" или "нет" в зависимости от точки зрения. Я на свой вопрос отвечаю совершенно определенно — "нет", а ты — как хочешь.
F>Мучает меня, правда, вопрос, будешь ли ты покупать мороженное "Магнат", которое тебе совершенно не нравится на вкус, но которое рекомендовал Союз Мороженников РФ, или будешь ты покупать мороженное "Богдан", которое — для тебя — вкусное, по составу выглядит прилично, но на которое никто не дал рекомендаций? F>(а дипломированные специалисты компании "Магнат" вообще заявили, что Богдан их мороженному в подметки не годится)
Слушай, ну нельзя же так. Прочитать то, что я писал можно же было. Вот тут, к примеру, но я потом еще повторял
PD>Резюме — если пользователь недоволен, его мнение важно и существенно при оценке качества за исключением разве что каких-то маргинальных случаев. PD>Так что если речь идет о негативной оценке — суд профанов принимается. А вот что касается позитивной оценки — принимается только суд специалистов, и хороших специалистов.
PD>>>Черт его знает. Что-то в этом есть. Но принять не могу. Вот представь себе. Были у фирмы данные размером в N, и некий алгоритм прекрасно работал. Год, два, три. А потом фирма вдруг резко выросла и размер данных стал 10N. И стало все совсем нехорошо. А специалисты свое "фи" сказали бы раньше — мол, пока у вас N, 2N, 3N — все будет нормально, а потом наплачетесь. И это не пузырек, который можно и заменить. Вы, господа разработчики, положили в основу совсем неподходящую модель, а она центральное место в вашей задаче, поэтому надо было с самого начала искать тут решение NlogN, а не уповать, что N^2 сойдет.
M>>А вот не надо преждевременно оптимизировать и закладываться на «вдруг» С такими «вдруг» не может никто справиться, если только требования такого не было изначально заложено в систему.
PD>Почему же нет ? Все очень просто. Получили задачу эти горе-разработчики. Проанализировали ее (это им так показалось). Пришли к выводу, что основная модель в варианте 1 будет вполне приемлемо работать . А есть модель 2, но она на порядок сложнее для реализации, потребует больше времени и сил, а выигрыш проявится только при больших N. Вот и решили — денег не так уж много, времени мало, реализуем модель 1. Один, правда, заикнулся в духе : "А что потом скажем, когда данных больше будет ?", но ему привели все твои аргументы и он заткнулся. Реализовали модель 1. Дальше по сценарию, описанному выше.
PD>Вот это и есть халтура.
PD>Взяли Хибернейт. Нужды нет, что он тащит по select половину данных, которые совсем и не нужны, а по update апдейтит то, что менять совсем не надо. Зато просто по сравнению с sproc. Кто-то, правда, заикнулся — а что будет, когда размеры выборок станут большими ? Ему привели все твои аргументы и он заткнулся. Реализовали модель 1. Дальше по сценарию, описанному выше.
PD>Вот это и есть халтура.
Это — халтура с твоей точки зрения. Потому что ты опираешься на некий «вдруг». «Вдруг станет больше данных», «вдруг станут большими запросы» и т.п. Предсказать все «вдруги» нереально. Если их все предсказывать, то ничто никогда написано не будет. То есть вообще ни одного софта вообще никогда в жизни. Именно поэтому в реальной жизни рулят реальные требования. Прогнозирование никто не отменял. Но в таком случае софт, который не выполняет требования согласно прогнозам — плохой софт. Но опять же, не с точки зрения специалиста, а с точки зрения заказчика, который такой прогноз составил.
Здравствуйте, fmiracle, Вы писали:
F>То же самое в точности и в IT. Если заказчику нужна программка для решения небольшой текущей проблемы в небольшом отделе — это одно. Требований будет немного и свобода по реализации очень большая. F>Если ему нужна программа для управления деньгами большого числа пользователей — то выкатят вагон требований, в частности по надежности, масштабируемости и безопасности. Да еще и добавят требование предоставления всех исходников программы на code-review отделу информационной безопасности с необходимостью учесть все созданные замечания.
F>И кстати, требования по маштабируемости не будут выставлять в терминах "надо быстрее и еще-еще быстрее". Выставят предельный график изменения требований к ресурсам при заданном просте числа обрабатываемых данных. И если в этот график программа уложится — все хорошо, и опять же не очень важно как она там реализована технически.
F>А вот проблемы в коде, ведущие к утечке или повреждению данных, найденные отделом сопровождения и отделом информационной безопасности сразу ставят крест на программе. Потому что это тоже одно из бизнес-требований — 0 процентов выявленных дефектов по (и список угроз, которые должны быть учтены — такие как утечка персональных данных, потеря финансовых данных и т.д. и т.п.)
Уф! Так я об этом и говорю. Только специалисты могут оценить качество. Ты сказал о специалистах по безопасности, надежности и т.д. Можно и другие критерии добавить, в зависимости от задачи.
F>И да — заказчик станет "доволен" именно когда все требования будут соблюдены. Принимающий ПМ, пусть он хоть вообще не шарит в IT, будет нифига не доволен принимать программу, если у него на столе отчет отдела ИБ, что программа в текущем виде черевата большими судебными исками — нахрена ему принимать эту ответственность?
Совершенно верно! Положительное решение о качестве могут дать только специалисты!
А вот отрицательное — могут дать и конечные пользователи. Пусть все специалисты дали самое наилучшее заключение, а бухгалтеры ругаются — работать неудобно, то и дело проблемы возникают. И все. Качественной такая программа быть признана не может.
With best regards
Pavel Dvorkin
Re[3]: Помогает ли Linq сделать код понятнее или быстрее?
Здравствуйте, FR, Вы писали:
M>>Некорректная задача, для студента или с собеседования. Правильно: FR>Вполне корректная, упорядоченность может проверятся например по нескольким разным критериям.
В случае нескольких критериев линк будет эффективнее И нагляднее, как я понимаю.
M>>1) либо нам нужно получить на выходе отсортированный массив. Тогда сортировать каждый раз будет быстрее, чем проверять, нужна ли сортировка. FR>Сортировать будет точно намного медленнее, проверка это одиночный линейный проход по массиву, с этим даже radix sort не сравняется
Сортировать придется один раз, сортировка уже отсортированного массива — такой же линейный проход..
Здравствуйте, Mamut, Вы писали:
M>>>А вот не надо преждевременно оптимизировать и закладываться на «вдруг» С такими «вдруг» не может никто справиться, если только требования такого не было изначально заложено в систему.
PD>>Почему же нет ? Все очень просто. Получили задачу эти горе-разработчики. Проанализировали ее (это им так показалось). Пришли к выводу, что основная модель в варианте 1 будет вполне приемлемо работать . А есть модель 2, но она на порядок сложнее для реализации, потребует больше времени и сил, а выигрыш проявится только при больших N. Вот и решили — денег не так уж много, времени мало, реализуем модель 1. Один, правда, заикнулся в духе : "А что потом скажем, когда данных больше будет ?", но ему привели все твои аргументы и он заткнулся. Реализовали модель 1. Дальше по сценарию, описанному выше.
PD>>Вот это и есть халтура.
PD>>Взяли Хибернейт. Нужды нет, что он тащит по select половину данных, которые совсем и не нужны, а по update апдейтит то, что менять совсем не надо. Зато просто по сравнению с sproc. Кто-то, правда, заикнулся — а что будет, когда размеры выборок станут большими ? Ему привели все твои аргументы и он заткнулся. Реализовали модель 1. Дальше по сценарию, описанному выше.
PD>>Вот это и есть халтура.
M>Это — халтура с твоей точки зрения. Потому что ты опираешься на некий «вдруг». «Вдруг станет больше данных», «вдруг станут большими запросы» и т.п.
Где я говорю про вдруг ? Я просто имею в виду, что эти горе-проектировщики не оценили характеристики системы при разных значениях параметров и понадеялись на то, что сойдет и так. И до поры до времени это никто не замечает. А "вдруг" тут никакого нет — можно было вполне предсказать, если подумать.
>Предсказать все «вдруги» нереально. Если их все предсказывать, то ничто никогда написано не будет. То есть вообще ни одного софта вообще никогда в жизни.
Да почему же ? Вот при памяти в 16 Мб и быстродействии в 40 MHz создали некую операционную систему в начале 90-х годов. И принципы, которые были в нее заложены, оказались вполне работоспособными при памяти в 4 Гб и частоте 3 GHz.
Интересно, был ли у авторов Windows NT соблазн сократить виртуальное адресное пространство, скажем, до 512 Мб ? Технически это сделать совсем несложно — сокращено же сейчас АП в x64 до 2^40 вроде бы, хотя исходя из размера адреса там 2^64. Не знаю. По тем временам (начало 90-х) 512 Мб — чудовищно много, таких дисков тогда почти что не было. Можно было и заложить такое ограничение, если бы, допустим, оно какой-то выигрыш давало в тот момент (размер каких-то системных таблиц уменьшало). Но сообразили, что не надо, слава богу.
А вот еще более показательный пример. В 1960-е годы создается система IBM/360. Первые модели выпускают с памятью 64 Кб, 128 Кб, старшая модель — 1 Мб, стоит чуть ли не 1 М$. А в архитектуру заложили 16 Мб. Поэтому система благополучна прожила 60-е, потом 70-е (IBM/370), и лишь в 80-е ее архитектуру как-то изменили.
Здравствуйте, Pavel Dvorkin, Вы писали:
F>>А вот проблемы в коде, ведущие к утечке или повреждению данных, найденные отделом сопровождения и отделом информационной безопасности сразу ставят крест на программе. Потому что это тоже одно из бизнес-требований — 0 процентов выявленных дефектов по (и список угроз, которые должны быть учтены — такие как утечка персональных данных, потеря финансовых данных и т.д. и т.п.)
PD>Уф! Так я об этом и говорю. Только специалисты могут оценить качество. Ты сказал о специалистах по безопасности, надежности и т.д. Можно и другие критерии добавить, в зависимости от задачи.
"специалисты" про которых я говорю — это те же представители заказчика, которые тоже должны быть "довольны" прежде чем программа будет принята. Почему ты под "заказчиком" понимаешь только какого-то далекого от IT человека (и вообще одного единственного человека) — мне сугубо непонятно.
Специалист по ИБ может воощбще не умеет программировать, но он знает, что надо проверить, что программа не падает при, например, попытке загрузкить в нее 4хгигабайтный файл. И если падает, то это минус, т.к. может вызвать простои в работе.
Это мало чем отличается от того, что тетя Маша из бухгалтерии ничего не знает про программирвоание, но знает, что если ctrl+c/ctrl+v не работают, то это плохо, т.к. прямой минус скорости ввода данных (например).
В чем разница невыполнения двух требований — я не понимаю. Ну и что, что один специалист в некоторой области IT, а вторая — нет.
Чем более важная программа — тем просто больше заинтерисованных лиц, которые должны быть опрошены для принятия решения "хорошая" она или нет. И собираются требования всех — и специалистов по IT и специалистов по бизнесу. Причем собираются, вот это важно, не "мнения" по готовой программе, а требования к той программе которая будет разработана, а потом уже — соирается проверка на соответствие сделанной программы представленным требованиям. И вменяемых заказчиков не интересует используется там квадратичная сложность алгоритма в точке Х или линейная — интересует общее соответствие программы требованиям, собранных от всех заинтересованных в данной программе лиц.
Да, отдел ИБ — очень заинтересован во всех программах, за работу которых он потом будет отвечать. А если не будет, то и требований он не прдеставит.
И отдел сопровождения очень заинтересован в "простоте кода" ПО, которое он потом будет дорабатывать. А если поддержку всегда будет осуществлять сторонний исполнитель, то отдел сопровождения свои требования не выставляет.
M>>Это — халтура с твоей точки зрения. Потому что ты опираешься на некий «вдруг». «Вдруг станет больше данных», «вдруг станут большими запросы» и т.п.
PD>Где я говорю про вдруг ? Я просто имею в виду, что эти горе-проектировщики не оценили характеристики системы при разных значениях параметров и понадеялись на то, что сойдет и так. И до поры до времени это никто не замечает. А "вдруг" тут никакого нет — можно было вполне предсказать, если подумать.
Ты зря вырезал все
Прогнозирование никто не отменял. Но в таком случае софт, который не выполняет требования согласно прогнозам — плохой софт. Но опять же, не с точки зрения специалиста, а с точки зрения заказчика, который такой прогноз составил.
>>Предсказать все «вдруги» нереально. Если их все предсказывать, то ничто никогда написано не будет. То есть вообще ни одного софта вообще никогда в жизни.
PD>Да почему же ? Вот при памяти в 16 Мб и быстродействии в 40 MHz создали некую операционную систему в начале 90-х годов. И принципы, которые были в нее заложены, оказались вполне работоспособными при памяти в 4 Гб и частоте 3 GHz.
если это про линукс, то разве там все не переписано по пять раз?
PD>Интересно, был ли у авторов Windows NT соблазн сократить виртуальное адресное пространство, скажем, до 512 Мб ? Технически это сделать совсем несложно — сокращено же сейчас АП в x64 до 2^40 вроде бы, хотя исходя из размера адреса там 2^64. Не знаю. По тем временам (начало 90-х) 512 Мб — чудовищно много, таких дисков тогда почти что не было. Можно было и заложить такое ограничение, если бы, допустим, оно какой-то выигрыш давало в тот момент (размер каких-то системных таблиц уменьшало). Но сообразили, что не надо, слава богу.
PD>А вот еще более показательный пример. В 1960-е годы создается система IBM/360. Первые модели выпускают с памятью 64 Кб, 128 Кб, старшая модель — 1 Мб, стоит чуть ли не 1 М$. А в архитектуру заложили 16 Мб. Поэтому система благополучна прожила 60-е, потом 70-е (IBM/370), и лишь в 80-е ее архитектуру как-то изменили.
правильно, потому что даже в таком случае есть заказчики, пусть этими заказчиками и выступают сами программисты. Они составили прогноз и написали систему согласно прогнозу
Здравствуйте, fmiracle, Вы писали:
F>"специалисты" про которых я говорю — это те же представители заказчика, которые тоже должны быть "довольны" прежде чем программа будет принята. Почему ты под "заказчиком" понимаешь только какого-то далекого от IT человека (и вообще одного единственного человека) — мне сугубо непонятно.
Где я писал про одного человека ?
Впрочем, если в такой формулировке — пожалуйста, соглашусь. Программа является качественной, если специалисты по ... высказались, что она качественная. В качестве многоточия разреши мне подставить что угодно — как тех специалистов, что есть у заказчика, так и тех, что у него нет (независимо от причины). Потому что если у заказчика есть специалисты по безопасности и они признали программу качественной, но нет специалистов по системному проектированию, которые ее качественной не признали бы — я не вижу, почему мнение первых надо учитывать, а вторых — нет.
F>Это мало чем отличается от того, что тетя Маша из бухгалтерии ничего не знает про программирвоание, но знает, что если ctrl+c/ctrl+v не работают, то это плохо, т.к. прямой минус скорости ввода данных (например).
Любой специалист скажет, что это страшный страх и ужасный ужас. И это действительно так. Но в этой системе грамотный оператор за 15 секунд, не больше, моежт найти билет из Стамбула в Петербург с минимум одной пересадкой для человека с ребенком по минимальной цене.
Пусть это и бдет выглядеть, как ATASPB1S1P1C в консоли Потому что это просто отличная программа, и лучше, чем она вряд ли существуют.
Здравствуйте, Mamut, Вы писали:
M>>>Это — халтура с твоей точки зрения. Потому что ты опираешься на некий «вдруг». «Вдруг станет больше данных», «вдруг станут большими запросы» и т.п.
PD>>Где я говорю про вдруг ? Я просто имею в виду, что эти горе-проектировщики не оценили характеристики системы при разных значениях параметров и понадеялись на то, что сойдет и так. И до поры до времени это никто не замечает. А "вдруг" тут никакого нет — можно было вполне предсказать, если подумать.
M>Ты зря вырезал все
M>
M>Прогнозирование никто не отменял. Но в таком случае софт, который не выполняет требования согласно прогнозам — плохой софт. Но опять же, не с точки зрения специалиста, а с точки зрения заказчика, который такой прогноз составил.
Заказчик не всегда в состоянии этот прогноз составить. Тут именно системный аналитик поработать должен. Специалист то есть.
>>>Предсказать все «вдруги» нереально. Если их все предсказывать, то ничто никогда написано не будет. То есть вообще ни одного софта вообще никогда в жизни.
PD>>Да почему же ? Вот при памяти в 16 Мб и быстродействии в 40 MHz создали некую операционную систему в начале 90-х годов. И принципы, которые были в нее заложены, оказались вполне работоспособными при памяти в 4 Гб и частоте 3 GHz.
M>если это про линукс, то разве там все не переписано по пять раз?
Нет, про Windows NT 3.1
PD>>Интересно, был ли у авторов Windows NT соблазн сократить виртуальное адресное пространство, скажем, до 512 Мб ? Технически это сделать совсем несложно — сокращено же сейчас АП в x64 до 2^40 вроде бы, хотя исходя из размера адреса там 2^64. Не знаю. По тем временам (начало 90-х) 512 Мб — чудовищно много, таких дисков тогда почти что не было. Можно было и заложить такое ограничение, если бы, допустим, оно какой-то выигрыш давало в тот момент (размер каких-то системных таблиц уменьшало). Но сообразили, что не надо, слава богу.
PD>>А вот еще более показательный пример. В 1960-е годы создается система IBM/360. Первые модели выпускают с памятью 64 Кб, 128 Кб, старшая модель — 1 Мб, стоит чуть ли не 1 М$. А в архитектуру заложили 16 Мб. Поэтому система благополучна прожила 60-е, потом 70-е (IBM/370), и лишь в 80-е ее архитектуру как-то изменили.
M>правильно, потому что даже в таком случае есть заказчики, пусть этими заказчиками и выступают сами программисты. Они составили прогноз и написали систему согласно прогнозу
Черта с два. Программисты того времени и помыслить о 16 Мб не могли, поскольку и 64 Кб было много, я и в 70-е их не имел. Это просто сама IBM подумала как следует.
M>>Прогнозирование никто не отменял. Но в таком случае софт, который не выполняет требования согласно прогнозам — плохой софт. Но опять же, не с точки зрения специалиста, а с точки зрения заказчика, который такой прогноз составил.
PD>Заказчик не всегда в состоянии этот прогноз составить. Тут именно системный аналитик поработать должен. Специалист то есть.
Системный аналитик с чьей стороны? Если скажешь, что со стороны разработчика, то ошибешься Системный аналитик со стороны заказчика — согласен. Потому что программист имеет к предметной области, в которой он обычно работает, весьма опосредованое отношение. Например, предсказать рост компании (что вызовет рост количества запросов к системе, например), разработчик просто не в состоянии. А городить огород только из-за того, что мне, как разработчику, кажется, что вдруг когда-то на порядок возрастет количество клиентов, — это и есть халтура.
>>>>Предсказать все «вдруги» нереально. Если их все предсказывать, то ничто никогда написано не будет. То есть вообще ни одного софта вообще никогда в жизни.
PD>>>Да почему же ? Вот при памяти в 16 Мб и быстродействии в 40 MHz создали некую операционную систему в начале 90-х годов. И принципы, которые были в нее заложены, оказались вполне работоспособными при памяти в 4 Гб и частоте 3 GHz.
M>>если это про линукс, то разве там все не переписано по пять раз?
PD>Нет, про Windows NT 3.1
Что-то мне подсказывает, что многое там тоже было переписано, пока достигли 4 Гигов и 3 гигагерц
PD>>>Интересно, был ли у авторов Windows NT соблазн сократить виртуальное адресное пространство, скажем, до 512 Мб ? Технически это сделать совсем несложно — сокращено же сейчас АП в x64 до 2^40 вроде бы, хотя исходя из размера адреса там 2^64. Не знаю. По тем временам (начало 90-х) 512 Мб — чудовищно много, таких дисков тогда почти что не было. Можно было и заложить такое ограничение, если бы, допустим, оно какой-то выигрыш давало в тот момент (размер каких-то системных таблиц уменьшало). Но сообразили, что не надо, слава богу.
PD>>>А вот еще более показательный пример. В 1960-е годы создается система IBM/360. Первые модели выпускают с памятью 64 Кб, 128 Кб, старшая модель — 1 Мб, стоит чуть ли не 1 М$. А в архитектуру заложили 16 Мб. Поэтому система благополучна прожила 60-е, потом 70-е (IBM/370), и лишь в 80-е ее архитектуру как-то изменили.
M>>правильно, потому что даже в таком случае есть заказчики, пусть этими заказчиками и выступают сами программисты. Они составили прогноз и написали систему согласно прогнозу
PD>Черта с два. Программисты того времени и помыслить о 16 Мб не могли, поскольку и 64 Кб было много, я и в 70-е их не имел. Это просто сама IBM подумала как следует.
А что такое IBM? Некое сферовакуумное сушество? Кто-то сел, спрогнозировал, спроектировал архитектуру. И да, в данном случае это был программист. Что не делает его менее заказчиком
Здравствуйте, Mamut, Вы писали:
PD>>Заказчик не всегда в состоянии этот прогноз составить. Тут именно системный аналитик поработать должен. Специалист то есть.
M>Системный аналитик с чьей стороны? Если скажешь, что со стороны разработчика, то ошибешься Системный аналитик со стороны заказчика — согласен. Потому что программист имеет к предметной области, в которой он обычно работает, весьма опосредованое отношение. Например, предсказать рост компании (что вызовет рост количества запросов к системе, например), разработчик просто не в состоянии. А городить огород только из-за того, что мне, как разработчику, кажется, что вдруг когда-то на порядок возрастет количество клиентов, — это и есть халтура.
Это можно по разному назвать — перестраховкой, преоптимизацией, но уж никак не халтурой. Если я предусмотрю то, чего не может быть — разве это халтура ?
>>>>>Предсказать все «вдруги» нереально. Если их все предсказывать, то ничто никогда написано не будет. То есть вообще ни одного софта вообще никогда в жизни.
PD>>>>Да почему же ? Вот при памяти в 16 Мб и быстродействии в 40 MHz создали некую операционную систему в начале 90-х годов. И принципы, которые были в нее заложены, оказались вполне работоспособными при памяти в 4 Гб и частоте 3 GHz.
M>>>если это про линукс, то разве там все не переписано по пять раз?
PD>>Нет, про Windows NT 3.1
M>Что-то мне подсказывает, что многое там тоже было переписано, пока достигли 4 Гигов и 3 гигагерц
Не очень. Ядро не сильно изменилось. А принципы заложенные вообще нет.
M>>>правильно, потому что даже в таком случае есть заказчики, пусть этими заказчиками и выступают сами программисты. Они составили прогноз и написали систему согласно прогнозу
PD>>Черта с два. Программисты того времени и помыслить о 16 Мб не могли, поскольку и 64 Кб было много, я и в 70-е их не имел. Это просто сама IBM подумала как следует.
M>А что такое IBM? Некое сферовакуумное сушество? Кто-то сел, спрогнозировал, спроектировал архитектуру. И да, в данном случае это был программист. Что не делает его менее заказчиком
Чуть выше у тебя — системный аналитик со стороны разработчика не может. А тут выясняется, что все же может, но для этого ему нужно в пределах той же компании представить себя заказчиком .
) законы ? И таких степей очень много, практически все. Помнишь, я про мост писал — та же степь. Про банк — та же. Что-то тут не так...
Понятно же, что никому даром не нужно ни такое суммирование, ни такое решение.
