Здравствуйте, Pavel Dvorkin, Вы писали:
AVK>>Я тоже. И что?
PD>Не знаю. Спроси VladD2. Он же начал меня в непонимании идей ООП обвинять.
Он обвинял тебя в неумении ими пользоваться.
AVK>>То, что ты описал называется оптимизацией. Которая почти всегда ухудшает структуру программы. Но оптимизации делают обычно, когда точно известны узкие места. Делать ее заранее и везде — прямой путь к убийству мало мальски крупного проекта. Именно об этом и пытается тебе сказать Влад.
PD>Я уже на эту тему выступал осенью. Не хочу возвращаться к ней.
То есть признаешь, что приводить подобное в качестве правильного примера в проектировании программ не стоит?
AVK>>1) Предлагая одновременно с абстракциями думать о реализации, ты увеличиваешь количество сущностей на одном уровне.
PD>На разных уровнях. Я об этом писал в письме к Владу — переключение между уровнями.
Чудес не бывает. Человек штука однозадачная.
PD>[Остальная часть этого замечания skipped в связи с этим возражением.]
Класс! Это нифига не замечание было, это был вопрос. Повторю еще раз в краткой форме — как ты предлагаешь бороться с увеличением количества сущностей ввиду того что нужно учитывать аспекты реализации? Или ты считаешь что проектирование с учетом реализации и без такового на одной и той же задаче равноценно по сложности?
>>Теперь собственно вопрос — в какой момент нам следует прекратить думать о реализации нижележащих абстракций?
PD>На том уровне, на котором изменение в реализации перестает влиять на свойства программы (быстродействие, память и т.д.)
Как определить? Где гарантия что, к примеру, твои сики туда и обратно не вступят в конфликт с файловым кешем ОС, и в результате ты получишь более медленное решение вместо ожидаемого более быстрого? Мой опыт доказывает, что зачастую узкие места обнаруживаются там, где их никто предсказать не смог бы. Так что такой способ не годится.
PD> Или когда мы попадаем на уровень, который нам неподвластен. PD> Как только один из этих уровней достигнут — стоп. Дальше думать не о чем — думай не думай, а ничего не изменится.
Ну и что что неподвластен? Вот кеш у процессора нам тоже неподвластен, однако мы же можем его учитывать?
Итого: на оба заданных вопроса я ответа не получил. Исходя из этого задам другие вопросы — насколько сложнее проектирование при постоянном учете реализаций? Во сколько ты оцениваешь стоимость ошибок, вызванных неправильной оценкой эффективности реализации на реальных источниках данных? Насколько оправдано сужение универсальности алгоритма в угоду его производительности? Всегда ли стоит предпочесть более эффективное решение более универсальному? Где золотая середина между скоростью разработки и эффективностью полученного решения? Насколько сильно отразится твой подход на восможности реиспользования и модификации полученного решения?
>>Почему я, при создании сериализации, должен думать о файле, но не должен думать о кластерной структуре ФС?
PD>Потому что ты не выбираешь ФС.
Но я выбираю алгоритмы работы с ней. Например на FAT поиск файла это очень дорого, а на NTFS есть индексы и поиск значительно дешевле. Какое грамотное решение ты видишь в подобной ситуации? Наплевать на то, что в случае NTFS мы получаем оверхед и городить свои индексы? Или сделать решение, тормозящее на FAT?
>>Или должен. Тогда когда не должен? Об абстрактной модели контроллера IDE должен?
PD>Не должен. Ни к к какому улучшению это не приведет.
Я бы не был столь уверен. Современные винты имеют очень непростое firmware, а каждый процент производительности дисковой подсистемы сегодня очень ценен. Как считаешь — стоит учитывать особенности firmware, или сделать универсальное решение, неоптимальное в каждом конкретном случае? Из той же серии — стоит учитывать кеш процессора, если размер и алгоритмы работы на сегодня довольно существенно разнятся для разных процессоров?
PD> А если залача такова, что приведет и можно выбирать — должен.
А как определить что задача такова? И в какой момент это можно сделать? Я лично знаю только один такой способ — произвести замеры на реальном решении или хотя бы прототипе. Но для этого надо архитектуру уже разработать! Замкнутый круг?
PD>(В скобках. А это не демагогия ?
Нет.
PD> При чем тут контроллер ?
Один из уровней абстракции. Если еще не забыл, я пытаюсь узнать критерии глубины погружения от собственных абстракций в чужие.
PD>Чем мне помогут мысли о контроллере, если я никак на его выбор повлиять не могу ? При чем тут ФС, если я ее тоже выбирать не могу! )
Это, кстати, не факт. Я видел и списки рекомендованных контроллеров, и обязательное требование (впрочем как и просто рекомендации) использования NTFS. Так что все возможно, вопрос лишь в цене.
AVK>>Я тебя умоляю — не стоит делать далеко идущие выводы из аналогий. Строительство это далеко не то же самое, что создание программ и тому есть масса причин.
PD>Все аналогии хромают. Эта тоже.
Ну вот тогда и не делай из них выводы. Единственное использование аналогий в споре, не являющееся демагогией, это применение их в качестве иллистраций каких то высказываний. Ты же сделал вывод, опираясь только на аналогию (здание рухнет, если не рассчитать прочность каждого кирпича -> программа рухнет, если не рассчитать прочность каждого кусочка кода).
PD> Дом развалится, это верно. Программа не развалится, просто работать будет в несколько раз медленнее и памяти кушать больше. Что мы и наблюдаем.
Где? Не вижу.
AVK>>Это нормально. Называется рефакторинг. Ничего страшного в нем нет.
PD>Вполне согласен. Я же об этом говорил — откажусь от нее (кстати, если уж на то пошло, в реальной работе я сначала именно ее и попробую, зачем мне лишние сложности ?) и задействую иное.
А зачем учитывать то, что еще не определено? При начале проектирования как правило известно очень мало, причем часть информации принципиально неопределена? Почему, вместо того чтобы напрягать интуицию, не выбрать простейшее решение и построить код таким образом, чтобы его легко было модифицировать?
Небольшой пример — как то пришлось воспользоваться библиотекой редактора графов — NetronGraphLib. Библиотека весьма куцая по функционалу, с ошибками и не очень хорошей реализацией (автор явно плохо знал C# и .NET). Но есть у нее неоспоримое преимущество — она написана так, что ее легко модифицировать. В результате я за сравнительно небольшое время привел ее в соответствие со своими требованиями и ни разу у меня не возникло желания написать все с нуля.
Другой пример — в .NET Framework 1.х отсутствуют нормальные тулбары и менюхи. Вначале в янусе использовали крутую MagikLibrary. Но глюков было столько, что пришлось от нее избавится. Потом была не менее крутая UserControlLibrary (сейчас она как то по другому называется), от нее тоже пришлось избавиться ввиду неудобоваримости. В итоге вплоть до появления 2 версии фреймворка в янусе использовалась простенькая, без супер реализации, зато с качественной моделью (читай с грамотно спроектированными абстракциями) CommandBars.
PD> А другие пытаются ее изо всех сил все же запихнуть, доказывая, что она годится там, где она не годится. В этом все различие.
Я наверное что то не понимаю, но тебе тут о другом говорят. Не о том что надо что то впихнутьт, а о том что абстракции надо делать максимально простыми, не корежа их в угоду своим догадкам о проблемах реализации.
PD>Я — знаю. Не всегда и не везде. Могу ошибиться, с кем не бывает.
Можешь и еще как. Этот топик (да и не только он) — прекрасная тому иллюстрация. Нужно только понять, что это не ты виноват, что частенько ошибаешься и не формат форума тому виной. Я в своей работе регулярно наталкиваюсь на то что, казалось бы, самые очевидные предположения оказываются неверны.
AVK>>Это мелочи. Там проблемы логического плана. Впрочем, попроси об этом рассказать Синклера, у него хорошо получается.
PD>Да я в общем-то как внутри NHibernate устроен, и так разобрался — в небольшой части, конечно, которая меня интересовала. Потрассировал код, посмотрел. Неплохо самодокументировано — понять, что делается, довольно легко.
А как насчет эффективности?
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
PD>с выпадом в мой адрес в самом начале
PD>это не вызвало с твоей стороны (как модератора) никаких замечаний, а поэтому заставило меня ответить.
PD>Если ты считаешь, что высказывание "у тебя в голове каша " есть корректное ведение дискуссии — у тебя очень гибкие принципы.
Демагогия detected: — в качестве оправданий собственного наезда на Синклера используется поведение Влада.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Тебе демагогологический анализ твоих сообщений устроить или сам справишся? Если первое — мне не сложно.
Ввиду того, что мой ответ и продолжение этой дискуссии с тобой не нуждается в том, чтобы это стало всеобщим достоянием, ответ отправлен по e-mail на адрес в твоих "Личных".
Здравствуйте, AndrewVK, Вы писали:
PD>>Не знаю. Спроси VladD2. Он же начал меня в непонимании идей ООП обвинять.
AVK>Он обвинял тебя в неумении ими пользоваться.
О да!
PD>>Я уже на эту тему выступал осенью. Не хочу возвращаться к ней.
AVK>То есть признаешь, что приводить подобное в качестве правильного примера в проектировании программ не стоит?
Нет. Признаю, что повторять два раза одно и то же тем, кто не хочет слышать , дает тот же результат, что и одни раз — не слышат.
PD>>На разных уровнях. Я об этом писал в письме к Владу — переключение между уровнями.
AVK>Чудес не бывает. Человек штука однозадачная.
Бывают и такие. Владельцы единственно правильного мировоззрения. И точно знающие, как правильно нужно делать.
PD>>[Остальная часть этого замечания skipped в связи с этим возражением.]
AVK>Класс! Это нифига не замечание было, это был вопрос.
Да какой там класс. Просто там была формальная логика. Напоминаю
>Предлагая одновременно с абстракциями думать о реализации, ты увеличиваешь количество сущностей на одном уровне.
Так как с этой посылкой я не согласился, то и остально опустил, поскольку решил, что имеет место обычное "если b то", а поскольку b для меня false, то остальная часть оператора не исследуется. Может, зря. Отвечаю.
AVK>Повторю еще раз в краткой форме — как ты предлагаешь бороться с увеличением количества сущностей ввиду того что нужно учитывать аспекты реализации? Или ты считаешь что проектирование с учетом реализации и без такового на одной и той же задаче равноценно по сложности?
Хороший вопрос. Нет, не равноценно. Да, количество сущностей увеличится. Но на разных уровнях.
Рассуждая на уровне верхнем (в действительности их может быть несколько), можно попытаться построить модель, не слишком вдаваясь в детали реализации. На этом уровне надо оценить саму задачу и найти методы ее решения. Идею, так сказать уловить. И допустимые кирпичи.
Но встраивая в систему эти кирпичи, надо тут же вспоминать о свойствах этих кирпичей. Проще говоря, спроектировав пока что воздушный замок из абстрактных блоков, тут же, немедленно переходить к анализу, годятся ли эти блоки для реального замка, который будем строить. Если не годятся — надо тут же, еще пока замок воздушный, приступить к его перепроектированию. Может быть, небольшому, заменить один кирпич на другой, иного сорта,и все дела. А может, такому, что придется весь воздушный замок разрушить и начать стротить его в уме заново. Потому как замечательный он получился, но вот беда — в реальнйо постройке фундамент такое не выдержит. И т.д.
Для архитектора это банальное правило, и тех, кто им не следует, надо не допускать к профессии. Хотя, отмечу, проектирование 30- этажного небоскреба — задача не более простая, чем написание серьезной программы. В машиностроении то же самое — никто не будет начинать делать изделие в металле, не убедившись, что не нарушаются законы сопромата. И т.д.
Только вот некоторые программисты почему-то решили, что можно строить программы, не вдаваясь в свойства материала, из которого строят. Есть кирпичи. Годятся они по размерам ? Да ? Красиво будет ? Да. Все , ясно, кладем здесь эти кирпичи. Прада, потом может выясниться, что они не держат, ну тогда их и заменим.
Вот здесь самое любопытное ИМХО. Пластичность материала дурную шутку сыграла. Кирпичи в настоящем здании -то не заменишь, а рухнет здание — под суд пойдешь. А программистов под суд, слава богу, не отдают, да и кирпичи заменить можно, потратив на это усилия. А можно и не заменять, ведь не рухнет же (в прямом смысле слова), просто качество будет на порядок ниже, так и это не беда , в конце концов убедим себя, что лучше и быть-то не может, да и не надо лучше.
Да, качественный подход потребует более сложного проектирования. Да, при этом число сущностей увеличится (хотя, опять-таки повторяю, на разных уровнях). Может, придется больше работников привлечь. Или специалиста получше а качестве лидера взять. Да, это денег стоит. Да, возможно, их нет, а поэтому придется попроще делать, и качество будет ниже. Все это я понимаю. И не осуждаю, что делать, жизнь такая. Может, мне и самому иногда придется наступать на горло собственной песне и делать не лучшим образом, потому что времени нет или по иной причине. Может (хотя вряд ли) я , сделав так, даже буду потом утверждать, что , дескать, ничего, нормально сделано, все хорошо, и когда заказчик будет меня благодарить, скромно приму эту благодарность и не скажу, что в действительности мог бы сделать это на порядок лучше. Все может быть, жизнь сложная штука, иногда приходится идти на компромиссы.
Но вот одно я делать не буду никогда. Никогда я не стану уверять самого себя, что то, что я сделал, не есть халтуура, а есть именно то, к чему и надо стремиться. Никогда я не стану проповедывать этот халтурный подход в качестве идеала.
AVK>Как определить? Где гарантия что, к примеру, твои сики туда и обратно не вступят в конфликт с файловым кешем ОС, и в результате ты получишь более медленное решение вместо ожидаемого более быстрого? Мой опыт доказывает, что зачастую узкие места обнаруживаются там, где их никто предсказать не смог бы. Так что такой способ не годится.
Ну, в той задаче сики тут не при чем — там об оптимизации вывода по скорости и речи не было. Но вообще — ты прав, конечно.Нет гарантии. Могу ошибиться. Вполне могу. Но ты две вещи смешиваешь.Узкие места обнаруживаются там, где их никто предсказать не смог бы — абсолютно согласен. Но из этого не следует, что надо создавать узкие места там, где вполне очевидно, что они возникнут, если не учитвать свойства (реализацию) материала.
Я в предыдущем письме привел пример с массивом и деревом. Ты на него отвечать не стал. Твое право. Но он как раз и характеризует то, о чем я говорю. Предельно ясно и четко. Может, все же ответишь ? Не возражаю, если в рассмотрение еще и хеш-таблицу введешь.
PD>> Или когда мы попадаем на уровень, который нам неподвластен. PD>> Как только один из этих уровней достигнут — стоп. Дальше думать не о чем — думай не думай, а ничего не изменится.
AVK>Ну и что что неподвластен? Вот кеш у процессора нам тоже неподвластен, однако мы же можем его учитывать?
Я, может, не очень точно выразился. Под словами "неподвластен" я имел в виду, что его поведение не может быть никак учтено, т.е мы не может ничего изменить в программе в зависимости от его поведения. Кэш — можно, поэтому его может быть, и надо учитывать. Хороший пример, кстати. Вот представь, что ты делаешь систему предельно быстрого доступа к данным огромного файла. Можно ли при этом рассуждать только на уровне абстракции "файл" и не принимать во внимание реализацию и кеша, и особенностей ФС ?
Контроллер дисковода — нет, если мы не состоянии как-либо учитывать его поведение. А если в состоянии и это надо — то и его, да. Для драйвера этого контроллера — придется мыслить не только абстракциями "пакет, отсылаемый на устройство", но и думать тут же, наилучшим ли образом этот пакет будет контроллеру передаваться/получаться (если это возможно).
AVK>Итого: на оба заданных вопроса я ответа не получил.
Надеюсь, теперь получил ?
>Исходя из этого задам другие вопросы — насколько сложнее проектирование при постоянном учете реализаций? Во сколько ты оцениваешь стоимость ошибок, вызванных неправильной оценкой эффективности реализации на реальных источниках данных? Насколько оправдано сужение универсальности алгоритма в угоду его производительности? Всегда ли стоит предпочесть более эффективное решение более универсальному? Где золотая середина между скоростью разработки и эффективностью полученного решения? Насколько сильно отразится твой подход на восможности реиспользования и модификации полученного решения?
В общем. я на это уже ответил выше в этом письме. Не на все эти вопросы в деталях, но по сути ответил.
>>>Почему я, при создании сериализации, должен думать о файле, но не должен думать о кластерной структуре ФС?
PD>>Потому что ты не выбираешь ФС.
AVK>Но я выбираю алгоритмы работы с ней. Например на FAT поиск файла это очень дорого, а на NTFS есть индексы и поиск значительно дешевле. Какое грамотное решение ты видишь в подобной ситуации? Наплевать на то, что в случае NTFS мы получаем оверхед и городить свои индексы? Или сделать решение, тормозящее на FAT?
Не знаю. От задачи зависит и от требований. Если это критично и можно потребовать, чтобы FAT не было — это одно. Если придется с FAT мириться — не исключаю даже хранения каталога в ОП в виде своего Б-дерева и отслеживания изменений по ReadDirectoryChanges или на уровне драйвера-фильтра. А может, махнуть рукой — если это не существенно и не критично.
Еще раз — я не обсуждаю решения, пока не ясна задача. Я не верю в универсальные решения. Универсальные решения приводят к неэффективным программам. Я предпочитаю конкретику. Давайте задачу — будем обсуждать.
AVK>Я бы не был столь уверен. Современные винты имеют очень непростое firmware, а каждый процент производительности дисковой подсистемы сегодня очень ценен. Как считаешь — стоит учитывать особенности firmware, или сделать универсальное решение, неоптимальное в каждом конкретном случае? Из той же серии — стоит учитывать кеш процессора, если размер и алгоритмы работы на сегодня довольно существенно разнятся для разных процессоров?
Еще раз — зависит от задачи.
AVK>А как определить что задача такова? И в какой момент это можно сделать? Я лично знаю только один такой способ — произвести замеры на реальном решении или хотя бы прототипе. Но для этого надо архитектуру уже разработать! Замкнутый круг?
Ты ведь , по сути, знаешь, что здесь утверждаешь ? Невозможно априорно оценить качество решения, кроме как соорудив его во плоти и крови и посмотрев, как оно работает. Так получается ?
Если да — ну тогда я просто не знаю, что сказать. Конечно, не всегда можно теоретически рассчитать то, что мы собираемся создать — в любой области. Иногда можно (строительство, машиностроение), иногда сложнее (ядерная физика, химия, поиск веществ с заранее заданными свойствами). Но чтобы уж так прямо утвержать — "только один способ существует, создать да посмотреть, что получилось" — ИМХО ни в одной области человеческой деятельности в Новое время никто такое не декларировал. Все же есть какая-то наука, а не только эмпирика.
Вот тебе тот же пример с деревом/массивом. Я может, в другом месте ошибусь — может. Может там оно медленно работать будет — может. Но означает ли это , что так уж ни о чем и думать не надо, когда массив здесь вставляешь ? Годится он сюда по своим методам/свойствам — годится. Берем. Неужели если я подумаю о том, что вставка в него очень дорогая по времени, а у меня вставок очень много, а время критично — и не откажусь от него еще на этапе абстракций, не написав ни одной еще строчки — неужели это правильно будет ? Я не верю, что ты сам так сделаешь. Или сделаешь все же ?
AVK>Ну вот тогда и не делай из них выводы. Единственное использование аналогий в споре, не являющееся демагогией, это применение их в качестве иллистраций каких то высказываний. Ты же сделал вывод, опираясь только на аналогию (здание рухнет, если не рассчитать прочность каждого кирпича -> программа рухнет, если не рассчитать прочность каждого кусочка кода).
Цитату , пожалуйста! Точную. Где я говорил, что программа рухнет.
PD>> Дом развалится, это верно. Программа не развалится, просто работать будет в несколько раз медленнее и памяти кушать больше. Что мы и наблюдаем.
Вот это я говорил. Передергивать не надо. Некрасиво.
PD>>Да я в общем-то как внутри NHibernate устроен, и так разобрался — в небольшой части, конечно, которая меня интересовала. Потрассировал код, посмотрел. Неплохо самодокументировано — понять, что делается, довольно легко.
AVK>А как насчет эффективности?
Да как... Так себе. Насчет эффективности в плане работы с БД — вроде довел до того состояния, когда лишние данные не запрашиваются и все SELECT и т.д. под контролем. А что касается того, что они там данные из строки БД читают в массив, а потом долго и упорно исследуют мой класс на предмет того, что куда и как из массива загнать — плевался, конечно. Но не властен я был в этой работе от NHibernate отказаться.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Я уже на эту тему выступал осенью. Не хочу возвращаться к ней.
AVK>>То есть признаешь, что приводить подобное в качестве правильного примера в проектировании программ не стоит?
PD>Нет. Признаю, что повторять два раза одно и то же тем, кто не хочет слышать , дает тот же результат, что и одни раз — не слышат.
А ты сам слышишь?
PD>>>На разных уровнях. Я об этом писал в письме к Владу — переключение между уровнями.
AVK>>Чудес не бывает. Человек штука однозадачная.
PD>Бывают и такие. Владельцы единственно правильного мировоззрения. И точно знающие, как правильно нужно делать.
Это ты к чему? Можно попроще свою мысль выразить?
AVK>>Повторю еще раз в краткой форме — как ты предлагаешь бороться с увеличением количества сущностей ввиду того что нужно учитывать аспекты реализации? Или ты считаешь что проектирование с учетом реализации и без такового на одной и той же задаче равноценно по сложности?
PD>Хороший вопрос. Нет, не равноценно. Да, количество сущностей увеличится. Но на разных уровнях.
Так, давай попроще. Имеем некую модель (пота только абсракцию), которая состоит из N уровней. Очевидно что количество различных абстракций на каждом уровне не должно быть большим, иначе человек не сможет с такой архитектурой работать. Путь у нас заселенность уровней близка к оптимуму. Теперь мы начинаем в модели учитывать реализацию — автоматически заселенность уровней увеличится (каких — неважно). Единственный выход привести модель в человекопонимаемое состояние — увеличить количество уровней, так?
PD>Рассуждая на уровне верхнем (в действительности их может быть несколько), можно попытаться построить модель, не слишком вдаваясь в детали реализации.
Ага, ты сам пришел к правильным выводам. Модель надо начинать строить не заморачиваясь особенно конкретикой реализации.
PD>Но встраивая в систему эти кирпичи, надо тут же вспоминать о свойствах этих кирпичей.
Под встраиванием в систему кирпичей ты понимаешь уже создание реализаций?
PD> Проще говоря, спроектировав пока что воздушный замок из абстрактных блоков, тут же, немедленно переходить к анализу, годятся ли эти блоки для реального замка, который будем строить.
Подожди. Очевидно, что реализация тоже будет распределена послойно. Так как правильно — создать верхний слой, затем его реализацию, затем слои пониже, затем их реализацию и так до самого дна, или сразу спроектировать все слои, а потом только заниматься реализацией?
PD> Если не годятся — надо тут же, еще пока замок воздушный, приступить к его перепроектированию.
То есть замок у тебя весь готов на момент реализации?
PD> Может быть, небольшому, заменить один кирпич на другой, иного сорта,и все дела. А может, такому, что придется весь воздушный замок разрушить и начать стротить его в уме заново. Потому как замечательный он получился, но вот беда — в реальнйо постройке фундамент такое не выдержит. И т.д.
Ну вобщем это и называется рефакторинг.
PD>Только вот некоторые программисты почему-то решили, что можно строить программы, не вдаваясь в свойства материала, из которого строят.
Ты, мне кажется, неверно понял собеседников. Никто не предлагает вобще заморачиваться реализацией. Идея другая — мы создаем грубую модель, на основе которой грубо работающий прототип (с простейшей реализацией). Потом смотрим на него и получаем новую информацию — чего не учли, где ошиблись. И начинаем проблемные места перепроектировать и создавать уже боевую реализацию. Потом получаем второй прототип и процесс повторяем. По факту в нашем проекте обычно выстраивается цепочка из 4-5 прототипов, прежде чем начинает писаться код, который останется в релизе.
PD>Вот здесь самое любопытное ИМХО. Пластичность материала дурную шутку сыграла. Кирпичи в настоящем здании -то не заменишь, а рухнет здание — под суд пойдешь. А программистов под суд, слава богу, не отдают, да и кирпичи заменить можно, потратив на это усилия.
И что в этом дурного?
PD> А можно и не заменять, ведь не рухнет же (в прямом смысле слова), просто качество будет на порядок ниже, так и это не беда , в конце концов убедим себя, что лучше и быть-то не может, да и не надо лучше.
Тут уж не подход виноват, это банальная халтура. И она везде плоха, вне зависимости от подхода.
PD>Да, качественный подход потребует более сложного проектирования. Да, при этом число сущностей увеличится (хотя, опять-таки повторяю, на разных уровнях). Может, придется больше работников привлечь. Или специалиста получше а качестве лидера взять. Да, это денег стоит.
Повышение качества при любом подходе стоит денег.
PD>Но вот одно я делать не буду никогда. Никогда я не стану уверять самого себя, что то, что я сделал, не есть халтуура, а есть именно то, к чему и надо стремиться. Никогда я не стану проповедывать этот халтурный подход в качестве идеала.
А что, кто то проповедует халтуру?
PD>Ну, в той задаче сики тут не при чем — там об оптимизации вывода по скорости и речи не было. Но вообще — ты прав, конечно.Нет гарантии. Могу ошибиться. Вполне могу.
Давай примем это за аксиому, ок?
PD> Но ты две вещи смешиваешь.Узкие места обнаруживаются там, где их никто предсказать не смог бы — абсолютно согласен. Но из этого не следует, что надо создавать узкие места там, где вполне очевидно, что они возникнут, если не учитвать свойства (реализацию) материала.
Верно. Но вот какая неприятная зависимость — чем сложнее система, тем труднее предположить где будут узкие места. Отсюда другая зависимость — чем крупнее проект, тем чаще его придется перелывать. Наконец отсюда вывод — чем крупнее проект, тем меньше конкретики нужно в него запихивать на каждом этапе (особенно на начальных этапах, где вероятность ошибки близка к 100%).
Вот поэтому и предлагается не заморачиваться хорошими реализациями в первых прототипах, поскольку велика вероятность, что из-за ошибок проектирования хорошую реализацию в лучшем случае придется сильно переделать, а в худшем она в полном объеме пойдет в корзину. И чем больше и сложнее проект, тем больше эта вероятность.
Это я все не из пальца высосал, это все я постоянно наблюдаю в реальной разработке. Опять же в текущем проекте наиболее качественные куски, которые долго живут без сильных переделок, были переписаны по 3-4 раза. Кода, который был один раз написан в самом начале практически не осталось.
PD>Я в предыдущем письме привел пример с массивом и деревом. Ты на него отвечать не стал. Твое право. Но он как раз и характеризует то, о чем я говорю. Предельно ясно и четко. Может, все же ответишь ? Не возражаю, если в рассмотрение еще и хеш-таблицу введешь.
Все это сильно зависит от платформы. Например в .NET массив это более низкоуровневая абстракция, нежели дерево или словарь. Только я не могу понять — какое это имеет отношение к проектированию?
AVK>>Ну и что что неподвластен? Вот кеш у процессора нам тоже неподвластен, однако мы же можем его учитывать?
PD>Я, может, не очень точно выразился. Под словами "неподвластен" я имел в виду, что его поведение не может быть никак учтено,
Почему нет?
PD> т.е мы не может ничего изменить в программе в зависимости от его поведения.
Могу. Надеюсь доказывать не надо?
PD> Кэш — можно, поэтому его может быть, и надо учитывать. Хороший пример, кстати. Вот представь, что ты делаешь систему предельно быстрого доступа к данным огромного файла. Можно ли при этом рассуждать только на уровне абстракции "файл" и не принимать во внимание реализацию и кеша, и особенностей ФС ?
На первом этапе можно.
AVK>>Итого: на оба заданных вопроса я ответа не получил.
PD>Надеюсь, теперь получил ?
Не на все.
AVK>>Но я выбираю алгоритмы работы с ней. Например на FAT поиск файла это очень дорого, а на NTFS есть индексы и поиск значительно дешевле. Какое грамотное решение ты видишь в подобной ситуации? Наплевать на то, что в случае NTFS мы получаем оверхед и городить свои индексы? Или сделать решение, тормозящее на FAT?
PD>Не знаю.
А кто знает?
PD> От задачи зависит и от требований.
Ну задачу можно придумать. Пусть это будет кеш прокси-сервера.
PD> Если это критично и можно потребовать, чтобы FAT не было — это одно.
Помнится ты в свое время утверждал что эффективность в любом случае критична. Впрочем ладно. На этот вопрос я ответить не могу — может критично, а может и нет, пока не не попробуешь, не узнаешь.
PD>Еще раз — я не обсуждаю решения, пока не ясна задача.
А она не может быть ясна на 100% в начале разработки, это мы чуть выше вроде как уяснили.
PD> Я не верю в универсальные решения. Универсальные решения приводят к неэффективным программам. Я предпочитаю конкретику. Давайте задачу — будем обсуждать.
Ну задачу я тебе дал.
PD>Ты ведь , по сути, знаешь, что здесь утверждаешь ? Невозможно априорно оценить качество решения, кроме как соорудив его во плоти и крови и посмотрев, как оно работает. Так получается ?
Ага.
PD>Если да — ну тогда я просто не знаю, что сказать.
А хотелось бы услышать твое мнение. Что ты будешь в этой ситуации делать? Понадеешься на интуицию?
PD>Но чтобы уж так прямо утвержать — "только один способ существует, создать да посмотреть, что получилось" — ИМХО ни в одной области человеческой деятельности в Новое время никто такое не декларировал. Все же есть какая-то наука, а не только эмпирика.
Очень мало аналитической науки в программировании, исчезающе мало. Аналитическое моделирование СМО затыкается на сверхпримитивных системах. Академического курса теории СМО мне хватило, чтобы понять, что даже процессор с парой-тройкой уровней кеша аналитически практически не описывается. Что же говорить о реальных системах, чье поведение неизмеримо сложнее?
PD> Я может, в другом месте ошибусь — может. Может там оно медленно работать будет — может. Но означает ли это , что так уж ни о чем и думать не надо, когда массив здесь вставляешь ? Годится он сюда по своим методам/свойствам — годится. Берем. Неужели если я подумаю о том, что вставка в него очень дорогая по времени
Она не дорогая, она просто невозможна.
PD>, а у меня вставок очень много, а время критично — и не откажусь от него еще на этапе абстракций, не написав ни одной еще строчки — неужели это правильно будет ? Я не верю, что ты сам так сделаешь. Или сделаешь все же ?
Я делаю очень просто — выбираю минимальную абстракцию (например IList<T> или ICollection<T> или даже IEnumerable<T>). И мне совершенно пофигу сколько стоит вставка — массив в любом случае не должен меняться снаружи напрямую, поскольку отследить внутри это невозможно. Ну а внутри я всегда волен менять массив на что угодно другое, как только он станет неподходящим. Единственное для чего можно использовать в публичном интерфейсе массив напрямую — как контейнер для параметров или возвращаемого значения.
AVK>>Ну вот тогда и не делай из них выводы. Единственное использование аналогий в споре, не являющееся демагогией, это применение их в качестве иллистраций каких то высказываний. Ты же сделал вывод, опираясь только на аналогию (здание рухнет, если не рассчитать прочность каждого кирпича -> программа рухнет, если не рассчитать прочность каждого кусочка кода).
PD>Цитату , пожалуйста! Точную. Где я говорил, что программа рухнет.
Хорошо, Влад, а объясни, в чем я неправ. Я ведь не против того, что нужны эти абстракции. Но почему я не прав, когда все же при этом думаю о свойствах кирпича, из которого эти колонны строить буду. Ведь не воздушный замок же я строю! Почему я должен от свойств материала отрешаться ? Ведь рухнуть же может здание, не выдержат они и будет ЧП. А абстрактно — колонны вещь замечательная. Красиво и приятно. А потом выяснится вдруг — крышу не держат. Примеры напомнить ?
Что ты этим хотел сказать?
PD>>> Дом развалится, это верно. Программа не развалится, просто работать будет в несколько раз медленнее и памяти кушать больше. Что мы и наблюдаем.
PD>Вот это я говорил. Передергивать не надо. Некрасиво.
Все запротоколированно. Можешь открыть свое сообщение и посмотреть.
Здравствуйте, AndrewVK, Вы писали:
AVK>А ты сам слышишь?
Стараюсь .
PD>>Бывают и такие. Владельцы единственно правильного мировоззрения. И точно знающие, как правильно нужно делать.
AVK>Это ты к чему? Можно попроще свою мысль выразить?
Можно, конечно, если это слишком сложно. Люди, которые уверовали в истину в последней инстанции, и уверенно ее продвигают, не считаясь ни с чем.
Или это опять слишком сложно ?
AVK>Так, давай попроще. Имеем некую модель (пота только абсракцию), которая состоит из N уровней. Очевидно что количество различных абстракций на каждом уровне не должно быть большим, иначе человек не сможет с такой архитектурой работать. Путь у нас заселенность уровней близка к оптимуму. Теперь мы начинаем в модели учитывать реализацию — автоматически заселенность уровней увеличится (каких — неважно). Единственный выход привести модель в человекопонимаемое состояние — увеличить количество уровней, так?
Нет. См. ниже.
PD>>Рассуждая на уровне верхнем (в действительности их может быть несколько), можно попытаться построить модель, не слишком вдаваясь в детали реализации.
AVK>Ага, ты сам пришел к правильным выводам. Модель надо начинать строить не заморачиваясь особенно конкретикой реализации.
А ты процитируй до конца.
PD>... Проще говоря, спроектировав пока что воздушный замок из абстрактных блоков, тут же, немедленно переходить к анализу, годятся ли эти блоки для реального замка, который будем строить.
PD>>Но встраивая в систему эти кирпичи, надо тут же вспоминать о свойствах этих кирпичей.
AVK>Под встраиванием в систему кирпичей ты понимаешь уже создание реализаций?
Продумывание. Решение, будет ли она примемлемой. Дом еще не строится. Но думать, выдержат ли кирпичи, стоит уже.
PD>> Проще говоря, спроектировав пока что воздушный замок из абстрактных блоков, тут же, немедленно переходить к анализу, годятся ли эти блоки для реального замка, который будем строить.
AVK>Подожди. Очевидно, что реализация тоже будет распределена послойно. Так как правильно — создать верхний слой, затем его реализацию, затем слои пониже, затем их реализацию и так до самого дна, или сразу спроектировать все слои, а потом только заниматься реализацией?
А не мог бы ты пояснить, что означает создать верхний слой и его реализацию без создания слоев пониже ? Псевдокод написать, что ли ?
PD>> Если не годятся — надо тут же, еще пока замок воздушный, приступить к его перепроектированию.
AVK>То есть замок у тебя весь готов на момент реализации?
Воздушный — готов. Реализация его при этом уже продумана. Код еще не писался.
PD>> Может быть, небольшому, заменить один кирпич на другой, иного сорта,и все дела. А может, такому, что придется весь воздушный замок разрушить и начать стротить его в уме заново. Потому как замечательный он получился, но вот беда — в реальнйо постройке фундамент такое не выдержит. И т.д.
AVK>Ну вобщем это и называется рефакторинг.
Пострефакторинг я бы сказал.
PD>>Только вот некоторые программисты почему-то решили, что можно строить программы, не вдаваясь в свойства материала, из которого строят.
AVK>Ты, мне кажется, неверно понял собеседников. Никто не предлагает вобще заморачиваться реализацией. Идея другая — мы создаем грубую модель, на основе которой грубо работающий прототип (с простейшей реализацией). Потом смотрим на него и получаем новую информацию — чего не учли, где ошиблись. И начинаем проблемные места перепроектировать и создавать уже боевую реализацию. Потом получаем второй прототип и процесс повторяем. По факту в нашем проекте обычно выстраивается цепочка из 4-5 прототипов, прежде чем начинает писаться код, который останется в релизе.
Повторяю — речь идет о том, чтобы на этапе проектирования учитыват свойства материала. Ничего больше я не говорил, и не собирался.
PD>>Вот здесь самое любопытное ИМХО. Пластичность материала дурную шутку сыграла. Кирпичи в настоящем здании -то не заменишь, а рухнет здание — под суд пойдешь. А программистов под суд, слава богу, не отдают, да и кирпичи заменить можно, потратив на это усилия.
AVK>И что в этом дурного?
Да ничего.
AVK>Повышение качества при любом подходе стоит денег.
Не спорю.
PD>>Но вот одно я делать не буду никогда. Никогда я не стану уверять самого себя, что то, что я сделал, не есть халтуура, а есть именно то, к чему и надо стремиться. Никогда я не стану проповедывать этот халтурный подход в качестве идеала.
AVK>А что, кто то проповедует халтуру?
Увы, да.
PD>>Ну, в той задаче сики тут не при чем — там об оптимизации вывода по скорости и речи не было. Но вообще — ты прав, конечно.Нет гарантии. Могу ошибиться. Вполне могу.
AVK>Давай примем это за аксиому, ок?
OK.
PD>> Но ты две вещи смешиваешь.Узкие места обнаруживаются там, где их никто предсказать не смог бы — абсолютно согласен. Но из этого не следует, что надо создавать узкие места там, где вполне очевидно, что они возникнут, если не учитвать свойства (реализацию) материала.
PD>>Я в предыдущем письме привел пример с массивом и деревом. Ты на него отвечать не стал. Твое право. Но он как раз и характеризует то, о чем я говорю. Предельно ясно и четко. Может, все же ответишь ? Не возражаю, если в рассмотрение еще и хеш-таблицу введешь.
AVK>Все это сильно зависит от платформы. Например в .NET массив это более низкоуровневая абстракция, нежели дерево или словарь. Только я не могу понять — какое это имеет отношение к проектированию?
Сейчас поясню.
Платформа та или другая — массив есть структура данных. В смысле, допустим, известной книги Вирта. Просто структура данных — набор последовательно расположенных элементов одинакового типа. Хочешь — оставь ее голой, как в С или Фортране. Хочешь — окружи классом, как в С++ или C#. Неважно. Выскокоуровневая или нет — мне не важно. Это просто структура данных.
И как стуктура данных, она определяет свое поведение в смысле зависимости времени операции от размера. O(?), проще говоря. Поиск в линейном неупорядоченном массиве — O(N), в упорядоченном — O(log(N)). Доступ по индексу — O(1). Вставка в произвольное место — O(N). И т.д.
Это, так сказать, свойства кирпича.
Массив, действительно, является самой низкоуровнвой структурой, потому что память тоже линейна (она тоже массив). Другие структуры (список, стек, дерево) непосредственно на память не укладываются и должны быть реализованы на базе чего-то. Список на основе массива. Список на основе связанных ссылок. Дерево на основе массива или на основе связанных ссылок И т.д. Все это изучается в курсе "Структуры данных", там же рассматриваются различные реализации и их временные характеристики.Например, список на основе массива с непрерывным хранениме потребует O(N) для вставки, а с ссылочным — O(1) для вставки, но если нужен поиск, то опять O(N). И т.д.
Так вот, вопрос простой. Есть необходимость хранить некие данные. Для того, чтобы программа работала эффективно, надо учесть свойства материала. Применяя ту или иную структуру данных (абстракцию), надо это учесть. Дерево, к примеру, позволит мне иметь O(log(N) для вставки, удаления и поиска. Линейный список — не позволит. Массив тоже. Хеш-таблица — о ней особо.
А учитывать это надо в зависимости от задачи. Данных немного, поиск часто, вставки редкие — годится массив, к примеру. Вставки частые, данных много — не годится массив, хотя он чудо как хорошо в абстрактные постройки укладывается. Там как раз к элементам по смыслу задачи надо по индексу обращаться. Пронумерованы они самим характером задачи.
А я все же предлагаю подумать, не приведет ли это к тому, что доступ к данным будет просто и логичен, а скорость — никуда не годна. И подумаю. И выкину массив, поняв, что он не годится (из-за того, что нет у него нужной мне реализации). И введу туда дерево. И потеряю доступ по индексу, который мне чудо как нравится. И придется мне по ключу поиск элемента вести в дереве поиска. Неудобно это и не укладывается в абстракцию. Зато я знаю, что не будет у меня O(N), а будет O(Log(N)).
Впрочем нет, не будет. Дерево-то дерево, а не выйдет ли оно вырожденным ? Так ведь я могу зря все сделать. Опять к задаче обращаться придется. Как там ключи в дерево добавляются/удаляются ? Есть риск плохой балансировки ? Если нет — ну что же, в среднем случае я всего в 1.3 раза рискую проиграть. Может, тм пренебречь можно. А может, мне и в 1.1 раза нельзя — т задачи зависит. А если есть такой риск — будем АВЛ дерево строить.
И т.д. И т.п.
Думаю, все тебе это известно.
А теперь вопрос.
Предположим, у тебя именно такая ситуация возникла. Что будешь делать ?
1. Вставишь массив, доведешь код до рабочего состояния, убуедишься в том. что нужные характеристики не получаются
или
2. Все же проведешь тот анализ, о котором я написал и решишь, что лучше
Вот тебе конкретная ситуация. Выбирай.
Сорри, но время 20:24. Пора домой идти. На остальную часть отвечу в понедельник, если время будет.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Можно, конечно, если это слишком сложно. Люди, которые уверовали в истину в последней инстанции, и уверенно ее продвигают, не считаясь ни с чем.
PD>Или это опять слишком сложно ?
Сложно, поскольку я до сих пор не вник — какая связь между твоим высказыванием и неспособностью обычного человека думать сразу о нескольких вещах в один момент времени.
AVK>>Под встраиванием в систему кирпичей ты понимаешь уже создание реализаций?
PD>Продумывание. Решение, будет ли она примемлемой. Дом еще не строится. Но думать, выдержат ли кирпичи, стоит уже.
А как ты это делаешь? Пусть у тебя 10000 кирпичей. Запомнить их все нереально. Ты их на бумажке записываешь? Или как то еще?
AVK>>Подожди. Очевидно, что реализация тоже будет распределена послойно. Так как правильно — создать верхний слой, затем его реализацию, затем слои пониже, затем их реализацию и так до самого дна, или сразу спроектировать все слои, а потом только заниматься реализацией?
PD>А не мог бы ты пояснить, что означает создать верхний слой и его реализацию без создания слоев пониже ? Псевдокод написать, что ли ?
А что тут сложного? Реализуешь самый верхний слой, а в детализации вставляешь либо константный вывод без вычисления, либо выкидывание исключения о том, что метод не реализован.
AVK>>То есть замок у тебя весь готов на момент реализации?
PD>Воздушный — готов. Реализация его при этом уже продумана.
А как оно зафиксировано? Только в памяти?
PD> Код еще не писался.
Но уже весь продуман?
AVK>>Ну вобщем это и называется рефакторинг.
PD>Пострефакторинг я бы сказал.
Нет никакого пререфакторинга и пострефакторинга. Рефакторинг может проводится в любой момент.
PD>Повторяю — речь идет о том, чтобы на этапе проектирования учитыват свойства материала.
А я тебя спросил — до какой степени и как справится с резким усложнением дизайна за счет увеличения объема информации, которую надо учитывать.
AVK>>Повышение качества при любом подходе стоит денег.
PD>Не спорю.
А о чем ты тогда споришь?
AVK>>А что, кто то проповедует халтуру?
PD>Увы, да.
Можно показать пальцем?
PD>Так вот, вопрос простой. Есть необходимость хранить некие данные. Для того, чтобы программа работала эффективно, надо учесть свойства материала. Применяя ту или иную структуру данных (абстракцию), надо это учесть.
Почему? До сих пор ты говорил не об абстракциях, а о реализациях. И список на массивах, и массив, и связанный список это IList. Вот IList — абстракция. А вот кто сколько и что делает — характеристики реализации. Хеш же и дерево — это вобще другие структуры, как их можно сравнивать со списком мне неясно.
PD>А я все же предлагаю подумать, не приведет ли это к тому, что доступ к данным будет просто и логичен, а скорость — никуда не годна. И подумаю.
На этапе проектирования? Зачем? Почему просто не указать IList? Ну или свой интерфейс, в котором будут указаны нужные операции. Или ты хочешь конкретные реализации списков выставлять в публичный интерфейс?
PD>Предположим, у тебя именно такая ситуация возникла. Что будешь делать ?
PD>1. Вставишь массив, доведешь код до рабочего состояния, убуедишься в том. что нужные характеристики не получаются PD>или PD>2. Все же проведешь тот анализ, о котором я написал и решишь, что лучше
PD>Вот тебе конкретная ситуация. Выбирай.
Спроектирую не конкретизируя какую реализацию буду использовать вплоть до того, как начну писать код. В публичном интерфейсе укажу IList или собственный интерфейс.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Со всем согласен, кроме последнего. Не в рекламе тут дело. Боюсь, все серьезнее. Формируется некое мировоззрение, в котором нормой явялется не думать о реализации или по крайней мере не считать это главным. Отчасти это понятно — мы пришли к модульному, компонентному программированию, т.е построению не из кирпичей, а из крупных блоков. Беда в том. что эти блоки ставят и там где надо, и там где не надо, а о том, как они устроены (как выглядят) — в последнюю очередь думают.
Ничего ты не понял из того что тебе тут говорили.
Люди с которыми ты спорил думают от реализации. Вот только они используют совершенно иные принципы при проектировании программ.
Причем проводить аналогии вобще и со строительством в частности не корректно. Однако я тебе таки приведу одну аналогию.
Написании программ гораздо больше похоже на создание проекта дома чем на строительство дома. Дом потом построит компилятор и ему всеравно что строить главное что у него есть план строительства, а вот править уже готовый бинарник очень тяжело также как и что-то перестроить в уже построеном доме.
Причем когда проектируют дом сначала делают эскиз: внешний вид, расположение окон, лесниц, лифтов... На этом этапе вобще не думают о каких бы то нибыло инженерных деталях. Далие определяются с технологией строительства ибо скажем кирпичный дом и дом на основе монолитного железобетонного каркаса строят совершенно по разному. Далие начинают рассчитывать где и какой толщины поставить несущие стены/колонны, сколько и какого утеплителя использовать... на этом этапе могут вносится коррективы (рефакторинг) в проект ибо что-то не учли или заказчик захотел что-то еще. Далие когда проект готов все еще раз проверяют(тестирование).
И только потом отдают строителям.(компилятору)
Нам с одной стороны проще ибо строительство программы ничего не стоит и мы можем посмотреть что получилось, а с другой стороны труднее ибо сложность подавляющего числа программ на порядки превосходит сложность любого здания.
Так вот народу не понравилось то что ты еще во время рисования карандашом на бумаге концепт арта внешнего вида дома пытаешься просчитать нагрузку на каждую несущею коллону.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не пойдет. "форма с которой легко манипулировать" — слишком неконкретно.
От это она и есть — абстракция.
PD> Для меня массив — форма с которой достаточно легко манипулировать. Поэтому выкладывание графа в массив есть перевод его именно в такую форму. Но это не сериализация.
Почему же? Очень даже сериализация. Просто массив несколько менее общая абстракция. Хотя и его можно воспримать как просто последоватльную форму... набор байтов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
VD>>Предлагаю следсвтенный эксперемент. Делашь тест сохраняющий данные в файл твоим способом и с использованием промежуточного MemoryStream. Затем сравниваем результаты и делаем выводы.
PD>А что сравнивать-то будем ?
Скорость. А ты что подумал?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
PD>> Для меня массив — форма с которой достаточно легко манипулировать. Поэтому выкладывание графа в массив есть перевод его именно в такую форму. Но это не сериализация.
VD>Почему же? Очень даже сериализация.
Я имел в виду реализацию графа на базе массива (матрицу смежности)
>Просто массив несколько менее общая абстракция. Хотя и его можно воспримать как просто последоватльную форму... набор байтов.
Ну так можно все под сериализацию подвести. Все у нас в конце концов набор байтов.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Pavel Dvorkin, Вы писали:
VD>>>Предлагаю следсвтенный эксперемент. Делашь тест сохраняющий данные в файл твоим способом и с использованием промежуточного MemoryStream. Затем сравниваем результаты и делаем выводы.
PD>>А что сравнивать-то будем ?
VD>Скорость. А ты что подумал?
Нет, в условиях, когда используется доп. память, я принципиально скорости не сравниваю. Даже если при этом лишние действия делаются. Только при равных условиях по памяти.
Продолжаю. То, на что уже ответил — выпущено.
AVK>>>Но я выбираю алгоритмы работы с ней. Например на FAT поиск файла это очень дорого, а на NTFS есть индексы и поиск значительно дешевле. Какое грамотное решение ты видишь в подобной ситуации? Наплевать на то, что в случае NTFS мы получаем оверхед и городить свои индексы? Или сделать решение, тормозящее на FAT?
PD>>Не знаю.
AVK>А кто знает?
PD>> От задачи зависит и от требований.
AVK>Ну задачу можно придумать. Пусть это будет кеш прокси-сервера.
Ничего себе заявление!. Я говорю — От задачи зависит и от требований. Мне в ответ — ну вот тебе задача. Без указания требований к железу, без указания требованйи к софту, без подробной спецификации — на тебе задачу, иди и скажи, как решать будешь. У Вас что, принятно так техзадания выдавать? Сделайте мне прокси-сервер — и радостный девелопер отправляется его делать, не поинтересовавшись даже, для каких целей он нужен, не говоря уж о прочем. М-да...
Вот когда подробные спецификации будут — тогда и поговорим. Может, и FAT сгодится. Может, только NTFS. А может, я вообще просто один файл заведу и в нем свою собственную псевдо-ФС сделаю. Как, к примеру, kerio proxy 4.2 делает (с более поздними версиями не работал, не знаю как там). Потому что FAT — поиск последовательный,а это существенно, NTFS — оверхед на журналирование. Думать надо.
PD>> Если это критично и можно потребовать, чтобы FAT не было — это одно.
AVK>Помнится ты в свое время утверждал что эффективность в любом случае критична. Впрочем ладно. На этот вопрос я ответить не могу — может критично, а может и нет, пока не не попробуешь, не узнаешь.
Узнаешь. Вполне узнаешь. Мне по крайней мере это удавалось.
PD>>Еще раз — я не обсуждаю решения, пока не ясна задача.
AVK>А она не может быть ясна на 100% в начале разработки, это мы чуть выше вроде как уяснили.
На 100% — не может. Но это не означает, что нельзя оценить то, что можно.
Кстати, вот тебе вопрос как раз по твоему примеру, прокси. Ты мне тут много и упорно доказывал, что думать о реализации означает плодить сущности, а мозг человека не в состоянии охватить слишком многое. Вполне разумная мысль, не могу не согласиться. Только вот вопрос — а почему мозг одного человека ? И если все же одного — почему нельзя это по времени растянуть.
Как ты будешь прокси-сервер делать, и что там еще будет — опустим. Но вот есть подзадача — хранить получаемые файлы на диске, стирать их там периодически и т.д. Естественно, я полагаю, что спецификации разработаны, а значит, можно уже сейчас оценить предполагаемое количество файлов общее, в единицу времени, и т.д.
Так вот, вчера и позавчера я думал о прокси-сервере как таковом. На уровне самых высоких абстракций. А сегодня я запрещаю себе о нем думать. Сегодня задача такова — надо файлы хранить. Эффективно. Требования такие -то . Как делать будем ?
Или другому это поручи. Неплохо будет, если он FAT/NTFS хорошо знает, и вообще на этих делах собачку съел..
Он, кстати, даже и не обязан точно знать, зачем это нужно. Впрочем, лучше, если все же знает — две головы все же лучше.
Sinclair мне тут как-то популярно объяснял, что такое декомпозиция. Ликбез, так сказать, устроил. Вот я тебе эту декомпозицию и пересылаю. Декомпозируй (в данном случае подзадача выделяется элементарно) и отдай другому. Пусть продумает. Не только абстракцию "хранилище файлов", а и реализацию этого хранилища.
PD>> Я не верю в универсальные решения. Универсальные решения приводят к неэффективным программам. Я предпочитаю конкретику. Давайте задачу — будем обсуждать.
AVK>Ну задачу я тебе дал.
Я тебе тоже могу задачу дать. Напиши текстовый редактор. К завтрашнему дню. Берешься ?
PD>>Ты ведь , по сути, знаешь, что здесь утверждаешь ? Невозможно априорно оценить качество решения, кроме как соорудив его во плоти и крови и посмотрев, как оно работает. Так получается ?
AVK>Ага.
PD>>Если да — ну тогда я просто не знаю, что сказать.
AVK>А хотелось бы услышать твое мнение. Что ты будешь в этой ситуации делать? Понадеешься на интуицию?
Интуиция — дело не такое уж плохое. В сущности, интуиция — это просто подсознательно оформленный предыдущий опыт. Я в самолетостроении ничего не понимаю, а поэтому никакой интуиции в этой области у меня нет. А когда я программное решение обдумываю — предыдущий опыт может вполне помочь, даже если в точности такую задачу я и не решал. Чувствую, что здесь будет узкое место. Потому как были уже. Может, и не помню, где были, но чувствую, что и здесь может быть. Подумать здесь хорошенько надо, прежде чем код писать.
Но вообще на вопрос — что буду делать — ответ простой. Я просто не согласен с исходной посылкой "Невозможно априорно оценить качество решения, кроме как соорудив его во плоти и крови и посмотрев, как оно работает.". Ты согласен, я — нет. Так что я ничего в этой ситуации делать не должен.
PD>>Но чтобы уж так прямо утвержать — "только один способ существует, создать да посмотреть, что получилось" — ИМХО ни в одной области человеческой деятельности в Новое время никто такое не декларировал. Все же есть какая-то наука, а не только эмпирика.
AVK>Очень мало аналитической науки в программировании, исчезающе мало. Аналитическое моделирование СМО затыкается на сверхпримитивных системах. Академического курса теории СМО мне хватило, чтобы понять, что даже процессор с парой-тройкой уровней кеша аналитически практически не описывается. Что же говорить о реальных системах, чье поведение неизмеримо сложнее?
Серьезное заявление. В общем-то, не отмахнешься просто так. Ну что же...
Системы бывают сильно и слабосвязанные, как тебе известно, конечно. Если система очень сильно связанная, то да, трудно сказать, где что может возникнуть. Но далеко не всегда это так. И твой пример с прокси-сервером — как раз этому подтверждение. В конце концов, прокси — сервер или тестовая программа будет эти файлы генерировать — не все ли равно ? Подсистема почти автономна. И решалась эта задача не один раз — не ты же первый хранилище файлов создаешь при таких-то требованиях ? Так что оценить здесь можно, в крайнем случае тесты сделать — на их создание двух дней за глаза хватит. Продумать все, как следует. А не писать сразу первое, что вголову придет.
Вот, кстати, зачем в kerio они свой файл для прокси-кэша сделали ? Большая же работа — свою ФС (или что-то такое) внутри этого файла городить ? А все же сделали...
И хорошо ли будет, если по твоему пути пойти ? Сделаем проект, посмотрим как работает, если нужно будет — будем улучшать. Я правильно твою идею излагаю, не передергиваю ?
Ну вот и сделали. Файлы в каталоге диска храним. Прокси-сервер как таковой разрабатываем. Наконец готово в первом приближении. Тестируем — с сетью все OK, с файлами медленно, узкое звено оказалось здесь. Предлагаем FAT убрать(допустим, из-за нее проблемы) — заказчик не соглсаен. Что делать ?
И вот теперь приходим к выводу, что надо свою псевдо-ФС на отдельном файле делать. Положение — хуже губернаторского, до дедлайна две недели, все, в общем, готово, но из-за этого узкого звена новый огромный кусок появился, и его за 2 недели никак не сделать (допустим).
А что, нельзя было об этом за 3 месяца до срока узнать ? Подумать немного, интуицию привлечь да парочку тестов соорудить. И знали бы об этой проблеме, и решали бы ее параллельно...
PD>> Я может, в другом месте ошибусь — может. Может там оно медленно работать будет — может. Но означает ли это , что так уж ни о чем и думать не надо, когда массив здесь вставляешь ? Годится он сюда по своим методам/свойствам — годится. Берем. Неужели если я подумаю о том, что вставка в него очень дорогая по времени
AVK>Она не дорогая, она просто невозможна.
Почему невозможна ? Вполне возможна ? Создаем новый массив длины L+1, копируем в него элементы до нужной позиции, потом этот элемент, потом оставшиеся, исходный массив уничтожаем.
Более того, ты сейчас услышишь от меня (адепта эффективности) странное утверждение. Вполне возможно, что в определенной ситуации я именно это решение и выберу. При всей его неэффективности как будто. Потому что знаю — элементов в массиве две сотни, вставки производятся раз в 5 минут, доступ по индексу — 100000 раз в секунду. Начни я что-то иное придумывать — намного дороже обойдется.
AVK>Я делаю очень просто — выбираю минимальную абстракцию (например IList<T> или ICollection<T> или даже IEnumerable<T>). И мне совершенно пофигу сколько стоит вставка — массив в любом случае не должен меняться снаружи напрямую, поскольку отследить внутри это невозможно. Ну а внутри я всегда волен менять массив на что угодно другое, как только он станет неподходящим. Единственное для чего можно использовать в публичном интерфейсе массив напрямую — как контейнер для параметров или возвращаемого значения.
Хм... Ну а если в итоге окажется, что ни одной имплементации IList нет с нужным быстродействием ? К примеру, выяснится, что лучше всего для хранения HashTable использовать, это все же (условно) O(1) на вставку и на поиск, а там — не получается. Или дерево двоичное (допустим, IList не поддерживает). Тогда как , все переделывать ?
AVK>>>Ну вот тогда и не делай из них выводы. Единственное использование аналогий в споре, не являющееся демагогией, это применение их в качестве иллистраций каких то высказываний. Ты же сделал вывод, опираясь только на аналогию (здание рухнет, если не рассчитать прочность каждого кирпича -> программа рухнет, если не рассчитать прочность каждого кусочка кода).
PD>>Цитату , пожалуйста! Точную. Где я говорил, что программа рухнет.
AVK>
Хорошо, Влад, а объясни, в чем я неправ. Я ведь не против того, что нужны эти абстракции. Но почему я не прав, когда все же при этом думаю о свойствах кирпича, из которого эти колонны строить буду. Ведь не воздушный замок же я строю! Почему я должен от свойств материала отрешаться ? Ведь рухнуть же может здание, не выдержат они и будет ЧП. А абстрактно — колонны вещь замечательная. Красиво и приятно. А потом выяснится вдруг — крышу не держат. Примеры напомнить ?
AVK>Что ты этим хотел сказать?
Да то, что и в других места, когда говорил, что здание может рухнуть. Таких мест несколько. Про здание я говорил. А не про программу. Ясно же сказал в письме к тебе
PD>>>> Дом развалится, это верно. Программа не развалится, просто работать будет в несколько раз медленнее и памяти кушать больше. Что мы и наблюдаем.
PD>>Вот это я говорил. Передергивать не надо. Некрасиво.
AVK>Все запротоколированно. Можешь открыть свое сообщение и посмотреть.
Именно. Прочти то, что я выделил жирным и не передергивай.
PD>Вот, кстати, зачем в kerio они свой файл для прокси-кэша сделали ? Большая же работа — свою ФС (или что-то такое) внутри этого файла городить ? А все же сделали... PD>И хорошо ли будет, если по твоему пути пойти ? Сделаем проект, посмотрим как работает, если нужно будет — будем улучшать. Я правильно твою идею излагаю, не передергиваю ? PD>Ну вот и сделали. Файлы в каталоге диска храним. Прокси-сервер как таковой разрабатываем. Наконец готово в первом приближении. Тестируем — с сетью все OK, с файлами медленно, узкое звено оказалось здесь. Предлагаем FAT убрать(допустим, из-за нее проблемы) — заказчик не соглсаен. Что делать ? PD>И вот теперь приходим к выводу, что надо свою псевдо-ФС на отдельном файле делать. Положение — хуже губернаторского, до дедлайна две недели, все, в общем, готово, но из-за этого узкого звена новый огромный кусок появился, и его за 2 недели никак не сделать (допустим). PD>А что, нельзя было об этом за 3 месяца до срока узнать ? Подумать немного, интуицию привлечь да парочку тестов соорудить. И знали бы об этой проблеме, и решали бы ее параллельно...
Вот конкретно это место мне совершенно непонятно. Отказавшись от своей ФС мы очень значительно сократили расходы. Поэтому я не вижу причины, по которой мы встрянем с производительностью за две недели до дедлайна. Получается, что если бы мы сразу стали делать собственную реализацию ФС, то она была бы готова на (три месяца — две недели) после дедлайна. А про решать параллельно — это сказки. Потому как ресурсы из воздуха не берутся. У нас там что, какой-то разработчик три месяца без дела болтался? Нет.
Да, если бы мы сразу заложили свою ФС, то скорее всего дедлайн автоматически был перенесен на три месяца, в команду был бы привлечен временный специалист по страничной организации файлового стораджа, етк, етк. А так мы рискуем напугать заказчика излишне оптимистичными заявлениями. Ну, это на самом деле камень в огород архитектора и ПМа. Потому, что в настоящем проджект плане есть такая секция "Risk Management". И если архитектор не идентифицировал вовремя риск того, что файлуха окажется недостаточно производительна, то ему и линейкой по пальцам. А если идентифицировал, но ПМ никакой mitigation туда не записал, то надо отправить ПМа на пару лет учить уставы (как известно, командир взвода — наиболее близкая специальность к "менеджеру среднего звена" в бывшем СССР, и выгодно отличается от новомодных курсов хорошей проработанностью программы).
Если проект развивается управляемым способом, то производительность ФС будет протестирована очень задолго до дедлайна. Потому что это почти ничего не стоит. И никто не станет вкладывать заранее деньги в оптимизацию того, что не было доказано в качестве узкого места. Слишком велик риск получить за две недели до дедлайна узкое место где-то еще. После того, как весь бюджет оптимизации съеден подчистую.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ничего себе заявление!. Я говорю — От задачи зависит и от требований. Мне в ответ — ну вот тебе задача.
Что тебе не нравится? Вполне реальная задача.
PD> Без указания требований к железу,
Среднестатистический писюк на сегодня.
PD> без указания требованйи к софту
Какие требования к софту тебе нужны?
PD>, без подробной спецификации
Подробную спецификацию это кодерам выдают и то не всегда. А ты, коль уж архитектор, работаешь не в тепличных, а вреальных условиях. Ты сам эту спецификацию создать должен.
PD> — на тебе задачу, иди и скажи, как решать будешь. У Вас что, принятно так техзадания выдавать?
Это не у нас, это везде. Кто тебе эту спецификацию писать будет? Есть рынок, есть реальное железо — welcome to real world.
PD> Сделайте мне прокси-сервер — и радостный девелопер отправляется его делать, не поинтересовавшись даже, для каких целей он нужен,
Для целей кеширования трафика интернета рядового пользователя.
PD>Вот когда подробные спецификации будут — тогда и поговорим.
Мда, плохой из тебя архитектор выходит.
PD>Узнаешь. Вполне узнаешь. Мне по крайней мере это удавалось.
Судя по тем преджположениям, что ты делал в форуме позволю себе не поверить.
AVK>>А она не может быть ясна на 100% в начале разработки, это мы чуть выше вроде как уяснили.
PD>На 100% — не может. Но это не означает, что нельзя оценить то, что можно.
Помнишь я тебе вопросы задавал? Ты на большую часть не ответил. Попробуй, соотносясь с этим утверждением вопросы прочитать еще раз.
PD>Кстати, вот тебе вопрос как раз по твоему примеру, прокси. Ты мне тут много и упорно доказывал, что думать о реализации означает плодить сущности, а мозг человека не в состоянии охватить слишком многое. Вполне разумная мысль, не могу не согласиться. Только вот вопрос — а почему мозг одного человека ?
Потому что до сих пор не существует технологий, позволяющих проектировать систему на верхних уровнях, учитывая только часть архитектурыю
PD> И если все же одного — почему нельзя это по времени растянуть.
Потому что рынок.
PD>Как ты будешь прокси-сервер делать, и что там еще будет — опустим. Но вот есть подзадача — хранить получаемые файлы на диске, стирать их там периодически и т.д. Естественно, я полагаю, что спецификации разработаны, а значит, можно уже сейчас оценить предполагаемое количество файлов общее, в единицу времени, и т.д.
Оцени.
PD>Или другому это поручи. Неплохо будет, если он FAT/NTFS хорошо знает, и вообще на этих делах собачку съел..
Но мне то что делать? Я ведь должен архитектуру дальше делать. Я не могу оставить неспроектированным кусок целиком. Мне нужно ввести абстракцию, изолирующую меня от специфики хранения. Но, пользуясь твоей методикой, я этого сделать не могу, потому что она должна быть согласована с реализацией, а реализацию я не могу никак определить.
PD>Sinclair мне тут как-то популярно объяснял, что такое декомпозиция. Ликбез, так сказать, устроил. Вот я тебе эту декомпозицию и пересылаю. Декомпозируй (в данном случае подзадача выделяется элементарно) и отдай другому.
При декомпозиции обычно учитывают только входные данные и структуру. Как делать декомпозицию с обязательным учетом реализации я не знаю.
AVK>>Ну задачу я тебе дал.
PD>Я тебе тоже могу задачу дать. Напиши текстовый редактор. К завтрашнему дню. Берешься ?
Это называется передергивание.
PD>Но вообще на вопрос — что буду делать — ответ простой. Я просто не согласен с исходной посылкой "Невозможно априорно оценить качество решения, кроме как соорудив его во плоти и крови и посмотрев, как оно работает.". Ты согласен, я — нет. Так что я ничего в этой ситуации делать не должен.
Ну вот теперь самое время вернуться к той зависимости, о которой я писал — чем крупнее и сложнее система, тем сложнее предсказать ее поведение и реальные характеристики. Дальше думай сам.
PD>Системы бывают сильно и слабосвязанные, как тебе известно, конечно. Если система очень сильно связанная, то да, трудно сказать, где что может возникнуть. Но далеко не всегда это так.
Я тебе больше скажу — если система сильно связанная это явный косяк в архитектуре. Вот только чем меньше связность системы, тем выше оверхед на взаимодействие между ее кусками. Оверхед как раз из-за того, что ты тут стараешься представить как неверный подход — слишком куцые абстракции не позволяют сильно оптимизировать под конкретику.
Вот мы и пришли к моменту, который ты упорно пытаешься игнорировать — жесткая привязка абстракций к реализации ведет к сильносвязным системам, что, в свою очередь резко уменьшает предсказуемость такой системы и резко же усложняет ее дальнейшую модификацию. Переход к слабосвязным системам снимает структурные проблемы, но ведет к снижению эфективности на стыках. Найти золотую середину — одна из сверхзадач проектирования архитектуры. Говорить сейчас о конкретном ее значении без конкретики конечно бессмысленно, но одно очевидно — чем больше у нас ресурсов, тем сильнее золотая середина смещается к слабосвязным решениям.
Что же касается того, как эту середину выбрать, то ответ тоже уже был дан. Нужно проектировать максимально слабосвязное решение, а потом, по мере необходимости, мигрировать в узких местах к решениям более связным. Здесь, опять же, замечу, что с увеличением количества ресурсов узкие места совсем не обязательно остануться там же, где и были. Т.е., перефразируя, оптимизации по потреблению ресурсов сильно зависят от конкретного количества и соотношения этих ресурсовю
PD> И твой пример с прокси-сервером — как раз этому подтверждение. В конце концов, прокси — сервер или тестовая программа будет эти файлы генерировать — не все ли равно ? Подсистема почти автономна. И решалась эта задача не один раз — не ты же первый хранилище файлов создаешь при таких-то требованиях ? Так что оценить здесь можно, в крайнем случае тесты сделать — на их создание двух дней за глаза хватит. Продумать все, как следует. А не писать сразу первое, что вголову придет.
А зачем делать тесты, если можно сразу начать проектировать систему? Если, как ты утверждаешь, у тебя очень хорошая интуиция, то и переделывать потом ничего не придется.
PD>Вот, кстати, зачем в kerio они свой файл для прокси-кэша сделали ? Большая же работа — свою ФС (или что-то такое) внутри этого файла городить ? А все же сделали...
А оно там было с первых версий?
PD>И вот теперь приходим к выводу, что надо свою псевдо-ФС на отдельном файле делать. Положение — хуже губернаторского, до дедлайна две недели, все, в общем, готово, но из-за этого узкого звена новый огромный кусок появился, и его за 2 недели никак не сделать (допустим).
Устанавливать жесткие дедлайны до того, как будет получен работающий прототип — признак недалекого ума РМов.
PD>А что, нельзя было об этом за 3 месяца до срока узнать ? Подумать немного, интуицию привлечь да парочку тестов соорудить.
Еще раз — чем тесты лучше прототипа?
AVK>>Она не дорогая, она просто невозможна.
PD>Почему невозможна ?
Потому.
PD> Вполне возможна ? Создаем новый массив длины L+1, копируем в него элементы до нужной позиции, потом этот элемент, потом оставшиеся, исходный массив уничтожаем.
Массив сам такое не умеет. То, что ты написал называется список на массивах. И это тоже не абстракция. Речь же идет о выборе абстракций.
PD>Хм... Ну а если в итоге окажется, что ни одной имплементации IList нет с нужным быстродействием ?
Блин, реализации.
PD> К примеру, выяснится, что лучше всего для хранения HashTable использовать, это все же (условно) O(1) на вставку и на поиск, а там — не получается.
Я тебе уже кажется говорил — хеш-таблица и список это разные вещи, они не взаимозаменяемы.
PD> Или дерево двоичное (допустим, IList не поддерживает). Тогда как , все переделывать ?
Писать свою реализацию IList. А в чем проблема?
PD>Да то, что и в других места, когда говорил, что здание может рухнуть. Таких мест несколько. Про здание я говорил. А не про программу. Ясно же сказал в письме к тебе
Офигеть. Так у нас тут форум по строительству зданий оказывается. А я то думал ... Ну тогда как нибудь без меня, я в кирпичах не специалист, за всю свою жизнь только один дом и построил.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А я и не создавал. Код, который я писал, вполне успешно работает на сотнях компьютеров, и до сих пор никто не жаловался.
Умение писать работоспособный код — это вопрос минимального профессионального соответствия. Та самая планка, ниже которой стоит слово "уволить немедленно". Настоящего квалифицированного программиста отличает умение писать не только работоспособный, но и легко читаемый, поддерживаемый, расширяемый код. Поэтому не надо рассказывать нам, что твои программы работают. Лучше расскажи, какое количество профессиональных программистов занимается/занималось поддержкой твоего кода. Неплохо бы также узнать их мнение о твоем коде.
1.1.4 stable rev. 510
