Здравствуйте, VladD2, Вы писали:
VD>Верные слова, но с не верным смыслом. Для меня опимальность не сводится только к скорости. Я могу судить или об оптимальности в некоторой обаласти, или об оптимальности как совокупности факторов многие из кторых отрицательно воздействуют на другие. Но даже говоря об оптимальности производительности я не думаю, об абсолютной потимальности. По этому я и говорю, не об оптимальности, а о достаточности и приемлемости.
Тут ты уже съезжаешь с темы. Понятие "оптимальность" (лучше я буду использовать в дальнейшем "эффективность" как более подходящий термин, несмотря на то, что процесс повышения эффективности называется оптимизацией), так вот, понятие "эффективность" нельзя трактовать вольно и свободно, произвольно награждая его различными критериями. Тем более, что
эти критерии могут быть прямо противоположны. Например, критерий эффективности самого ПО относительно потребляемых ресурсов и критерий эффективности процесса разработки ПО. Смешивая эти критерии в одну кучу легко получить две противоположные спорящие стороны, каждая из которых по-своему права.
Я не зря стал поднимать экономическую сторону вопроса производства ПО, ибо твой набор критериев (эффективность процесса разработки) имеет под собой именно экономическую базу, но никак не техническую.
VD>Опять же не совсем так. Кроме затрат физических есть еще другие аспекты "оптимальности". Если быстродействие будет требовать от меня использовать кривой С-подобный код примеры которого в изобилии демонстрировались отдельными поборниками производительности, то я скорее предпочту более медленный код, но и более просто читаемый/изменяемый.
Как я заметил выше относительно противоположных по характеру критериев эффективности, без расставления реальных весовых коэффициентов этим критериям для каждого конкретного случая подобные примеры и замечания не имеют цены.
Например, большинство программного кода по обработке сигналов действительно плохо читаемы/изменяемы (write only), независимо от используемого ЯП, длины и осмысленности идентификаторов. Т.е. не всегда код пишется в расчете на дальнейшее переписывание. По моему субъективному мнению (исход из собственного опыта) подобный код, гарантированно требующий сопровождения и дальнейшей модификации, обычно находится на самом верхнем прикладном уровне. И именно этот уровень в большинстве случаев оказывает наименьшее влияние на эффективность системы в целом. На мой взгляд, основа эффективности системы в большей степени зависит от общих архитектурных решений и далее от качества реализации библиотечного уровня (фреймворка), в основном тех мест, которые имеют дело с приличными объемами данных либо сложными вычислениями.
Опять же, общее архитектурное решение, разработанное с целью увеличения эффективности системы, может понизить эффективность разработки (сделать API более сложным или более чуствительным к "правильной" последовательности применения функциональности этого API)
Т.е., я настаиваю на том выводе, что баланс м/у эффективностью разработки и эффективностью целевой системы должен определяться требованиями. Возникающие ситуации, типа: "вот сделали, а вышло неэффективно, стали оптимизировать — код вышел макаронообразный" — говорит лишь о недостаточном сборе/анализе требований или отсутствии моделирования/прототипирования на начальных этапах проработки архитектуры.
VD>Оптимизация ничего не стоит очень редко. Да и говорить о таких случаях как об оптимизации не стоит.
В твоем примере она могла ничего не стоить, по сравнению со стоимостью разработки. Мы ведь этот пример обсуждали?
V>>Ты в своем посте красочно обрисовал тонны потраченных усилий, были ярки картины загубленной красоты исходников... Ты ведь "потомству в пример" это все написал, признайся? 
Так вот, потомство должно так же знать, что недостаточное владение инструментом может породить все эти проблемы даже при решении такой несложной задачи как буферизация ввода.
VD>Согласен. Собственно кривой код и тормоза на ровном месте это скорее не отсуствие погони за скоростью или красотой, а отсутсвие опыта или кривой опыт. Ну, возможно еще проблемы с ДНК.
Интересный модный термин, насчет проблем с ДНК. Считаю, что каждый должен заниматься своим делом. К сожалению, дефицит программистов привел в эту отрасль массу народа, для которых это занятие явно не рекомендуется. Это не говорит о "проблемной ДНК", просто люди заняты не своим делом. Возможно, в чем-то другом они дали бы всем нам фору.
VD>Однако тенденция к отказу от абстракций подчеркнуто демонстрируемая, ну, вы знаете кем, как раз демонстрирует, то что выбор некрасивых и даже совсем кривых решений очень даже может являться следствием неразумной погони за производительностью.
Согласен, что порой некоторые могут "лепить отмазки" насчет кривизны кода, пытаясь оправдать это погоней за производительностью. Более чем уверен, что реальные замеры в подобных случаях ничего не покажут.
Т.е. см. предыдущий абзац.
Оптимизация — это выбор эффективного алгоритма/протокола. И даже если он потребует в 1.5-2 раза больше кода на конкретном участке, совсем не факт, что этот код должен быть кривым и нечитаемым. Твой упор именно на кривости "неразумной оптимизации" я бы переформулировал в "невладение предметом". Такой программист с очень большой вероятностью налепит кривизны не только в обсуждаемых участках кода. Однако, для подобных случаев и существует разделение труда и иерархия технического руководства. Тим-лидер вполне может в приказном порядке назначать новичкам конкретные алгоритмы или разрабатывать API/протоколы. Т.е. при желании, все это поддается контролю (сужу по своей команде).
VD>Еще раз повторю, я в те времена намеренно отказался от "буферизации" воода и выбрал работу с "блоками памями". Это бло, можно сказать, дизайнерское решение. Безграмотное? Одназначно! Основанное на умозрительных предположениях? Безспорно. Но все же основанием для него явилось не то, что я не допер до буферизации и т.п. Основанием была погоня за производительностью.
Наглядный пример той самой "отмазки". Это просто случайность, что для конкретного твоего случая и именно почти одновременно стал широко использоваться дисковый кеш. Иначе твоя т.н. "погоня за производительностью" прямиком бы пошла в требования (те самые требования относительно конфигураций предполагаемого железа).
V>>Опять же... Требования и еще раз требования... Ну почему мы всегда обсуждаем что-то абстрактно, и как тут можно понять, чьи позиции устойчивее, если контекст не задан? Более-менее воссоздать картину можно попробовать из твоих эмоциональных акцентов. Но где гарантия, что их правильно истолковали? А может быть ты тогда не совсем правильно истолковал внешние условия? Какой был процент "покрытия" этими кеш-драйверами? Предназначалась ли твоя прога и для XT? Даже для тех, у кого 256кБ? (На них эти всякие кеши не ставились принципиально никогда, но тем не менее одно время таких машин было достаточно)
VD>Нда, беда. Мне ПОХРЕНУ проценты, килобайты, названия функий И ДАЖЕ причины приведщие к этому. Я ГОВОРИЛ О НЕВЕРНЫХ ПОСЫЛАХ... неверных стремлениях, неверных действиях.
Угу, а я о неверных выводах, которые ты тогда сделал. В твоем случае эта "неверность посылов" была лишь элементом случайности. В моей практике подобной "халявы", к сожалению, не встречалось. С буферизацией ввода/вывода я разобрался еще на 2-м курсе, а остальные проблемы были только вычислительного плана. Но в этом вопросе "халява" приходит с опозданием на пару лет или еще позднее. И то, в последние 2 года остановились на 3+ GHz. То-то стали снова подниматься подобные вопросы.
А посылы очень даже верные. Просто "техника в руках дикаря..." ну и далее по тексту. Тебе следовало сделать совсем другой вывод, а именно: "на оптимизацию стоит затрачивать усилия только в том случае, если полностью владеешь предметной областью". Потому как оптимизация — это суть выбор пути решения. Надо суметь найти как можно больше таких путей для сравнительного анализа.
Собственно, на этом можно было и закончить. Дальнейшие ответы — уточнение незначительных мелочей.
--------------------------
VD>Что килопроцентов, то исходная версия программы писалась на ХТ и там изумительно вставал Смартдрайв, ведь у них один хрен был метр памяти.
На ХТ стояли 256k, 384к, 512к, 640к (самый популярный и долгодержавшийся размер). 1M крайне редко, стал популярен начиная с AT, и действительно, неиспользуемые 384к стали отдавать под всякие смарт-драйвы и просто RAM-диски.
V>>Ловко, однако не зачтено. 
VD>Ты видимо непонимашь реального положения вещей. Мне не нужно сдавать тебе зачеты.
Жаль, что я не модератор...
V>>Диктую большими буквами: ЕСЛИ ВАМ И ПРОЕКТУ ЭТО НИЧЕГО НЕ СТОИТ, ТО ВЫБИРАЙТЕ НАИБОЛЕЕ ЭФФЕКТИВНОЕ РЕШЕНИЕ ЗАДАЧ НА ЛЮБЫХ УРОВНЯХ.
VD>Ну, тогда я тоже продиктую ДУМАЙТЕ НА ДВА ШАГА ВПЕРЕД, МАТЬ ВАШУ. Не думайте о битах и байтах пока в этом не будет крайней нужды.
А тебе вообще приходилось сдавать зачеты по IT?
Когда настает крайняя нужда, то уже банально поздно. Преподаваемый в наших ВУЗах "системный подход" (и 19xx — ГОСТы как их основа) вполне точно определяли, на каком этапе выяснялась эта "крайняя нужда". Сейчас процесс RUP мне кажется весьма подходящим.
VD>Вообще я кажется понял. Разница между нами не в подходах к программированию. Разница в том что мое мировозрение испочено кроме программирования еще и экономикой с юриспруденцией. По этому для меня очевидны многие вщеи не очевидные для программистов. Видимо чистый программист принципиально не может в рассуждениях не оперировать битами. Вопрос только в степени зациклинности на них.
Ну никак не удается спустить себя с высоты твоей ораторской трибуны на землю и втолковать, что эффективность системы и эффективность разработки — это разные вещи, почти всегда диаметральные друг-другу (жаль, что не ортогональные), и нечего их смешивать в одну кучу. В предыдущем посте я сделал акцент на том, что без конкретных требований никто не в силах сделать оптимальный баланс для конкретной разработки. Но тут прилетает Влад с юридическим образованием и не напрягаясь раздает универсальные советы "космического масштаба ..." и далее как обычно по тексту. Надеюсь, что те, кто прочитал этот твой пост и что-то уже решил для себя, все-таки заглянут и сюда, несмотря на опоздание ответа.
V>>Ключевая фраза: "ничего не стоит".
VD>Да? Привести тебе примеры кода кого приводишиеся в качестве агрументов битовыжимания, чтобы ты обяснил как они могут ничего не стоить?
А зачем ты фразу от предложения отодрал? А насчет "отмазок" по поводу кривизны кода и причин этого — см. мое мнение выше.
V>>Но тем не менее, факт остается фактом. Тысячи и тысячи программистов пишут одно и то же, выпускают массу продуктов очень близкой функциональности, все получают немаленькую ЗП, и вопрос минимизации затрат на разработку ПО встает в гораздо более жесткой форме — быть бизнесу или же провалиться с треском. Отсюда все эти веяния. Теперь примерно понятно, почему я там 3 поставил?
VD>Это ты о битовыжимальной агитации? Не, не понятно. Ели бы было понятно, то я пошел бы тоже чё-нить поставил.
Это я вообще-то о смещении акцентов и причинах такого смещения. А теперь понятно?
V>>В своей жизни я уже успел написать несколько учетных систем, массу системных и т.д. и т.п. И очень многие мои коллеги так же. Кое какие продукты используются до сих пор, кое-какие скоро начнут активно использоваться (я очень надеюсь). Однако, я ни на секунду не забываю, что программист (и я в том числе) сейчас используется крайне неэффективно. Процесс раздела рынка ПО сейчас в самом разгаре, и продлиться по прогнозам еще не менее 20 лет, т.е. сейчас рулят правила джунглей. А правила не гласят — "сделай лучше всех", правила гласят: "сделай всех", или еще короче: "выживи". И вот такой вот внешний контекст оказывает весьма серьезное влияние на умы даже опытных разработчиков, да такое, что они в пылу спора уже и не помнят, где причина а где следствие обсуждаемых вещей.
VD>Понятно. У тебя экономические причины. Ты уж извини, но экомические вопросы мне мало интересны. И уж обсуждать я их стал бы не с программистами и не в темах связанных с производительностью ПО.
Эффективность разработки, на которую все время напираешь ты — это чистейший экономический/рыночный критерий. И обсуждать его надо действительно не с программистами, а с менеджерами. Ну так что... начинаем обсуждение?
VD>Вы хотите поговорить об этом? (с)
VD>Я не буду обяснять почему эта налогия здесь не применима. Иначе прийдется вдаться в очень тонкие проблемы рынков и рыночных ниш. Хватватет того, что доказательство по аналогии является машейничеством.
Законы инженерии одинаковы. Рыночная ситуация может отличаться, законы — нет. Так что, аналогия считается весьма близкой. Если бы я привел тебе пример из теории бальных танцев — согласился бы на мошенничество.
V>>Такое может привидется только в кошмарном сне кокого-нибудь инженера Тойоты. В реальности, каждая следующая модель выходит со все лучшими характеристиками, ос более оптимальным весом, с большим КПД (люди, вы еще помните это слово) двигателя.
VD>Тебе не странно, что когда фирма выпускает вертолет вместо легковушки строит машину весящую болше и жрущую больше ресутсов? А не странно что лимизин представительского класса "Весит в 2 раза больше, однако, по-прежнему шустро ездит за счет более мощного мотора — Топлива она жрет в 2 раза больше"?
Нет, не странно. Странно, когда лимузин жрет в 10000 раз больше. (прикинь-ка относительные производительности современных процессоров к обсуждаемым в твоем посте). В моем примере речь шла о выпуске продуктов одного и того же класса. Сравнивать продукты разных классов бесполезно. Я УЖЕ видел достаточно самописных бух/складских систем на .Net, которые по функциональности не дотягивают даже до 1С 6.х версий, а требуют НА ПОРЯДОК больше ресурсов.
VD>Вот и мне не странно, что программа которая предоставляет мне рефактринг, хорошо работающее автодополнение при вводе, контекстную справку на каждый чих, отличный расширяемый редактор и отладчик и т.п. жрет чуть ли не в 10 раз больше времени.
Странно. Мне показалось, что для среды разработки VС++ 6.х ничего принципиально не изменилось в VC2003 (кроме компилятора, который более стандартный и более быстрый). А жрет в 3 раза больше памяти и работает заметно тормознутее.
Да кстати, почему-то Express C# жрет меньше памяти и работает заметно быстрее, чем VS2003... Может, дело было все-таки в чем-то другом?
VD>Так что кончай увликаться аналогиями, а обрати внимание на свою логику. В своих рассуждениях ты забывашь, что продукты жрущие больше ресурсов и дают больше. А те что жрут больше не давая ничего в замен по сравнению с продуктами конкурента попросу теряют потребителя и вымирают.
Если бы было именно так, то мир был бы идеален. Реально же, нехватка программистов означает лишь одно — спрос на ПО (заказное в большей степени). На заказное ПО действуют немного другие рыночные законы, к тому же сильно перекошенные его дефицитом. Поэтому ничего не вымирает, а "пропихивается" с кривостью, с потрясающими требованиями к железу и т.д.. Могу порекомендовать
www.sql.ru, и в нем форумы, посвященные БД. Как раз там хватает обсуждений насчет требований к железкам, их адекватности задачам и вообще, у кого и как сейчас руки растут.
VD>А слезы по повду расходвания 10 метров из гига — это глупость и ханжество. Не нравится? Старые программы работать не перестали.
1. Не 10 а 30.
2. Лишние 30 на каждую прогу в пямяти — это уже ого.
3. Механизм маппинга области кода DLL на разные процессы не работает в управляемых средах. В среднем +1М на каждую DLL. Грубо плюс еще 5-10М.
В общем, пока вопросов больше чем ответов. Когда приличную часть вопросов закроют, тогда и понравится.
V>>Но ведь это не удивительно, над новой моделью работаюбт сотни инженеров. А у нас, у программистов, примерно 5-15 человек делают проекты, по информационной сложности мало уступающие проекту той же Тойты.
VD>Ну, что же. Тебе никто не мешает заработать денег, создать свою фирму, нанять сотню инжинеров и сделать продукт который пользователи предпочтут потому другим. Вот только на этом пути ты будешь вынужден научиться зарабатывать деньги и поймушь в чем ты был не прав.
Посмешил, спасибо.
Ты прямо как в воду глядел. Фирма создана (довольно давно), набрал не сотню, а гораздо меньше... Подчиняюсь законам рынка, ессно, однако критерии эффективности проработал еще на этапе разработки архитектуры. Противоречие в чем? И почему до сих пор не понял, где был не прав?
V>> Поянтное дело, что для самого факта успешности подобных проектов жизненно необходимо максимально все упрощать и выкидывать все лишнее (и оптимальные пути разумеется тоже). А иначе как? Человеческий мозг — весьма ограниченная в своем объеме штуковина.
VD>А иначе так. Пусть все занимаются своим делом. Пусть успешность продукта на рынке предсказывают маркетологи и сложбы по взаимодействию с клиентами. Пусть проектами управляют люди знающие толк в этом деле. А программируют и проектируют ПО люди проффеисиональные в этом деле. Тогда маркетологи и т.п определять набор требуемых возможностей, менеджеры спланируют их реализацию, а программисты запрограммируют и оттестируют все в нужные сроки с нужным качеством. Тогда успешные продукты автоматически выявят более грамотные команды, а безграмотные развалятся. В общем, через рынок потребитель сам определит что ему надо.
Замечание насчет рынка и его характера сделал выше.
Мы, например, разрабатываем продукт на рынок, а не заказной. Соответственно, вопросы эффективности системы (т.е. требований к целевым железкам) у нас стоят так же остро как вопросы эффективности разработки. Скажу сразу к чему пришли: сервер на .Net, агенты на С++. И код на .Net, поверь, тоже написан не "от балды".
V>>... Хотел еще примеров написать, но вроде и так общий (самый общий) мой посыл должен быть понятен.
VD>Безусловно. Жаль, что не всем.
И я даже его знаю
VD>Вопрос который мы обсуждаем является таким, что в крайности в нем бросаются очень многие. По-моему, тут уже половина народу призналась, что их порой тянет пооптимизировать что-нить без особой на то необходиомости. Так что тут речь не о стрижке, а о выробатывании здорового эмунитета к дурным пристрастиям.
А может их тянет "пооптимизировать" ввиду потребности "зарядки для ума". А кого-то тянет в DOOMы погонять на работе. Пусть уж лучше в качестве отдыха от "кодирования" расслабляются первым способом.
Вполне представляю себе некое API, состоящее из многих аспектов и конкретных методов в нем. Оптимизация некоего одного метода в такой системе (особенно если он так и напрашивается на оптимизацию, т.к. был выполнен "по-быстрому") ничего не изменит в такой системе в худшую сторону. Другое дело, что на месте программиста, которому захотелось "поразмяться" я бы обращался к тим-лидеру с вопросом, указать "узкие" места для той самой разминки. Поверь, их хватает в каждой разработке, и адекватный тим-лидер, обладающий чуть-большей информацией о проекте, с удовольствием обсудит вопросы оптимизации требуемых мест в системе. Если в результате мы получим не хаотический, а упорядоченный по приоритетам процесс оптимизации — то я "за" двумя руками. Особенно, если программист, которому в качестве отдыха захотелось "поупражняться", доводит дело до конца.
V>> А что касается текущего положения дел, то на само понятие "эффективности" молодое поколение просто забило.
VD>Это не так.
Это из разребаемых лично куч "кода" на предыдущем месте работы. Это так.
VD>Что значит "даже"? Я пишу вмеру разумно. Иногда тоже увлекаюсь оптимизациями, а потом понимаю что валял дурака. От чего и предостерегаю других.
Что бы это не было "валянием дурака", заранее планируй и расставляй приоритеты. Пользы больше будет. Мне вообще плохо понятно, как ты упорядочиваешь свои разработки. Как-то тебя кидает из стороны в сторону, от задачи к задаче.
Приятный образ жизни, согласен. Жаль, что не могу позволить себе такого.
VD>И я о том же. Но надо еще понимать, что является ошибкой.
ИМХО, далекоидущие выводы, сделаные без анализа внешних условий, будут ошибочны с большей вероятностью.
VD>Не надо. Ты потратил время зря, если конечно ты не писал его 20 лет назад. Я вот писал парсер на Шарпе и он работает очень и очень шустро. Сам понимашь, ни о каком стеке тут и речи не идет.
10 лет назад писал. И неужели потратил время зря???
Сейчас тоже написал на шарпе, и конечно уже совсем не так. Прямо при инициализации у меня строится минимальный ДКА для моего лексера из набора лексем и регулярных выражений (парсер всевозможных форматов Date/Time).
Q. Почему бы не использовать стндартные регулярные выражения?
А. Для наших задач не подходит быстродействие.
Q.
Почему на сохранил в бинарнике в ресурсах свой ДКА, а строишь каждый раз динамически при старте?
A.
1. Руки не дошли, да и спорный момент, потому как:
2. Из ресурсов всегда читается с блокировкой.
3. Бинарная ДЕ-сериализация не такая уж быстрая, как хотелось бы.
4. Цена вопроса — пара десятков ms при старте, ибо алфавит лексера небольшой у нашей задачи.
5. В результате — пока от этого никакого выигрыша.
Q. Если алфавит будет большой в будущих разработках/применениях лексера?
A.
1. Сама структура лексера будет немного изменена, дабы было удобно загружать/выгружать таблицу переходов. Сейчас состояние — это объект.
2. Либо таблица переходов будет выполнена в виде единого однотипного массива, либо сама загрузка/выгрузка будет написана вручную, без использования ср-в сериализации .Net, если решим оставить состояние в виде объекта (наиболее вероятно).
Q. Текущий приоритет задачи?
А. Крайне низкий.
Еще вопросы?
В общем, не надо держать всех за "маньяков".
V>> Лично я поддержал сам факт обсуждения этой темы. Согласен, что Дворкин немного перегибает,
VD>Будем надеяться, что тройка поставленная им за твое сообщение в том числе включает и согласие с этим вот высказыванием.
Что означает моя оценка я уже обяснил. Поддержку и раскрытие самой темы. Оценки привлекают читателей, не правда ли?
VD>Вряд ли. Я вижу за этим именно деструктивное мировозрение усиливаемое его статусом. Хотя возможно тут уже я перегибаю палку. 
V>> Однако, в ПО повторное использование ничего не стоит (т.е. разможение информации и кода ничего не стоит).
VD>К сожалению, стоит. Со временем все меньше и меньше, но этого достаточно чтобы очень многие забивали на него исходя из тех же вопросов производительности. Я, кстатати, каюсь, грешен... тоже забивл и порой продолжаю забивать на повторное решение ради производительсности или чего-то еще. Только я делаю это скрипя сердцем, а очень многие с радостью в душе.
VD>Скорее грамотным решением я назову некое обобщенное решение которое в то же время позволяет хорошо адаптироваться к задаче. Ну, например, можно написать общее решение, а можно "общее решение с параметрами". Параметры повзолят настроить решение под конкретные задачи.
Параметры и пр. настраиваемость тоже чего-то стоят в плане времени. Я предпочитаю такие решения, которые в будущем без поломки архитектуры позволяют добавлять настраиваемость по мере надобности, которые потом позволят настроить под конкретное решение и т.д.
(в общем, дом, который построил Джек)
Т.е. "оптимизация" архитектуры — это лишь разновидность оптимизации, которая точно так же должна быть оправдана требованиями. Например, требованием повторной применимости.
V>>Добавлю еще насчет грамотного дизайна. Опять все встает с ног на голову. Раньше люди решали путем анализа вполне конкретные программистские задачи. Потом обнаружили их похожесть. Потом дали имена паттернам и использовали так: спроектировал что-либо, максимально удовлетворяющее требованиям, а потом _обяснил_ разработку на языке паттернов. Т.е. язык паттернов — это всего лишь терминологическая база. А молодежь как сейчас что-то проектирует??? Вместо того, чтобы решать поставленную задачу, крутит эти паттерны как кубики Лего, путем полного перебора стараясь подобрать нечто условно отвечающее поставленной задаче. И выходят монстры, один другого страшнее. И _паттэрны_ вроде есть, и неграмотно при этом...
VD>Паттерны — это опыт. Слово "паттерн" появилось в программистском лексиконе очень недавно и я по началу был сильно против него. Но потом я понял, что паттерн — это опыт решения конкретной задачи который описан настолько хорошо, что им можно оперировать как сущьностью. 90% паттернов я применял по наитию и раньше. Я использовал Синглтоны и Фабрикуи классов в КОМ-е и т.п.
А так же все фасадные, бриджевые в т.ч., разумеется. Прокси и их сочетание с фасадными/бриждевыми — итераторы, как следствие и т.д. (многие паттерны описываются другими паттернами и на мой взгляд идут как следствие).
На любой стадии программирования люди используют понимание, чтобы находить и предлагать паттерны. Картостроители стремятся получить общее понимание ситуации, применяя известные паттерны там, где они применимы, и создавая новые там, где их нет.
Среди паттернов может быть, например, и такой: «Не ставь телегу впереди лошади».
Надеюсь, источник указывать не требуется?
VD>Что же я делаю глупости? Нужно как во времена когда я только учился программировать каждый раз проползать на брюхе все трудные места, и только потом распозновать паттерны и заменять некрасивые решения на них?
Где-то я уже говорил, что многие паттерны просто не нужны в языках с динамической типизацией, напр. JavaScript/VBA/SmallTalk.
Большинство из них растет из способа реализации ООП в Java/С++ (и пр. подобного направления, в Дельфи в т.ч.), где имеется требование бинарной совместимости внешних интерфейсов объектов или же основаны на тонкостях создания/защиты объектов, т.е. являются следствием этих требований. Этими ограничениями надо владеть ДО изучения паттернов, тогда-то большая часть из них и покажется "старыми знакомыми", и просто приобретут свои именна и займут место на полке классификации.
VD>Или что же тем кто родился на 10 лет позже тоже нужно обязательно проползти на брюхе все что прополз я? Эдак человечество остановилось бы в развитии и каждое следующее поколение смогло бы только чуть-чуть поодвигаться впердед и то только если верить в то, что каждое новое поколение в принципе становится умнее.
А что прополз, если не секрет?
Основные дисциплины никуда не двигаются уже давно. Справочник по вышке у меня был хрен его знает какого года. По теории компиляторов, БД, дискретке, обработке сигналов тоже и т.д.
ООП — сравнительно "новое" направление. Однако, к счастью, не содержит той информационной емкости или сложности, и является логическим продолжением структурного подхода (зиждется на нем). Всевозможные споры даже неплохих специалистов в вопросах ООП анализа (например, споры насчет иерархии квадрат<=>прямоугольник), показывает тот факт, что эта область, к тому же, слабо детерминирована.
В общем, специалист должен проползти на брюхе гораздо больше, чем перечень паттернов.
VD>Человечество идет семемильными шагами вперед исключительно благодаря тому что научилось обобщать опыт. Паттерны это и есть обобщенный опыт. Кстати, описанный мной принцип получения программ приемлемых по быстродействию тоже есть обощение опыта. Более того не моего! Это и есть те самые инженерные приципы которыеми тут многие так гордятся, если хотите.
Я чего-то не увидел формулировки принципа получания программ, приемлимых по быстродействию. Мне кажется, что лучше руководствоваться более общим принципом: сбор, анализ и воплощение требований. Другие принципы приведут или к неполной реализации требований (и плане быстродействия и требований к ресурсам аппаратуры в т.ч.), либо к реализации лишних требований (опять же, и плане быстродействия и требований к ресурсам аппаратуры в т.ч.). Вот и все.
VD>Так что молдые очень правильно делают, что используют паттерны при проектировании ПО. Тем самым они повышают свою производительность.
Люди, использующие знания в работе, всегда повышают свою производительность. Речь шла о том, как именно эти знания применять, и является ли зазубренный список паттернов знанием сам по себе в отрыве от остальных знаний.
VD>Ну, а беспокоиться нужно о том, чтобы эти молодые привильно понимали эти паттерны и умели быстро и безошибочно распозновать места где они применими (выбирать нужный паттерн).
VD>Меня не беспокоит сама оценка. Уж кому кому, а не мне чужим оценкам завидывать.
VD>Я считаю оценку выражением согласия и поддержки. И куча положительных оценок на явно, по-моему, деструктивном мнеии меня обижает и пугает. Особенно пугает когда оценки ставят не те ктого я считаю ортодоксами или фанатиками.
Не бойся и не пугайся. Пообсуждали вопрос "зачем?", давно пора было перейти к обсуждению "как?".
V>>В этом месте ты уже забыл, что я настаивал на выборе оптимального инженерного решения, и обращал внимание, что сам этот выбор может ничего не стоить. А оценку я поставил за художественную силу и злободневность самой темы. И за то, что не поленился человек такой большой пост откатать, и при этом вовсе не нудный. В общем, по аналогии с фигурным катанием, оценки не только за технику ставим, но еще и за артистичность.
VD>Я не вижу злободневности. Я вижу деструктивность. Очень жаль, что ее не видешь ты и многие друние.
Есть злободневность. Не стоит, ИМХО, обощать свой собственный опыт на всех. А то я начну спрашивать, в каких командах и с кем ты работал и перейдем на замеры длины мобильников... Пока что я считаю, что лично ты работаешь ммм... немного в нестандартных условиях.
VD>Ставить же оценки за графоманство, чем собственно и является художественная сила, то же считаю не очень разумно, так как яорум посвящен программированию и оценка будет воспринята как одобрение и поддержка основных посылов сообщения.
VD>Именно по этому меня волнуют оценки на пдообных мениях.
А если тебе заявят, что ты собираешь большинство своих оценок аналогично? ИМХО, не обязательно отзываться таким образом о постах оппонентов.
VD>Я рассуждаю просто... Если на этот форум зайдет человек мировозрение которого еще не сформировалось, то он обязательно обратит внимание на то, что множество вроде как разумных и достоиных людей поддерживают мнение о том, что нужно делать все максимально быстрым. Дальше скорее всего начнутся дейсвия которые лет через 20 могут привести к появлению еще одной волны, ну, ты понял чего.
Спасибо за заботу, что еще можно сказать на подобное проявление альтруизма... А мне с этими людьми работать, так что, я тоже гну свое
VD>Незнаю. У меня все просто. Если вижу что что-то работает медленно, то думаю как исправить и исправляю.
VD>У меня обратная проблема. Часто стараюсь сделать оптимальнее чем нужно на что убиваю кучу времени.
Так у кого проблемы, я так и не понял?
Если нам не помогут, то мы тоже никого не пощадим.
