Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, VladD2, Вы писали:
V>Фуу, давненько не пересекались, но ощущения все те же, все те же. Попробуй представить себе ситуацию, что собеседник тебя все-таки прекрасно понимает, и тратит на обдумывание твоих постов гораздо больше времени, чем ты тратишь на посты собеседника (это видно невооруженным взглядом... этот вопиющий факт уже просто на грани оскорбления — настолько по диагонали читать оппонентов 
)
V>В общем, так. Свой первый пост ты предоставил в настолько разжеванном виде, и до того гипертрофированно стоят акценты в нужных местах, что основной посыл поймет даже человек, весьма далекий от программирования как такового. Давай условимся считать, что оппонент понял, просто не согласен, либо же имеет замечания/дополнения.
Казалось бы. Но на сегодня в этой теме уже более 90 сообщений, а по делу только 2-3. Так что может кто-то и читает все нимательно, но понять написанного не всилах даже когда написанное с акцентами и разжевано.
V>Очевидно, настала моя очередь "разжевывать".
Ну, ну...
V> Отвергать преимущество оптимального кода над неоптимальным пока никто не собирается.
Верные слова, но с не верным смыслом. Для меня опимальность не сводится только к скорости. Я могу судить или об оптимальности в некоторой обаласти, или об оптимальности как совокупности факторов многие из кторых отрицательно воздействуют на другие. Но даже говоря об оптимальности производительности я не думаю, об абсолютной потимальности. По этому я и говорю, не об оптимальности, а о достаточности и приемлемости.
V> И даже ты относишься к этому делу всего лишь взвешенно, примерно как и я, как и подавляющее большинство разработчкиков с некоторым опытом. Когда речь идет об усилиях, затрачиваемых на оптимизацию, то мы всего лишь оцениваем отношение объема этих усилий к получаемому положительному эффекту (оговорюсь опять — за исключением случаев, когда на быстродействие и потребляемые ресурсы накладывается ограничение либо непосредственно в ТЗ, либо коссвено, выплывает на стадии анализа через смежные/используемые программные и аппаратные технологии)
Опять же не совсем так. Кроме затрат физических есть еще другие аспекты "оптимальности". Если быстродействие будет требовать от меня использовать кривой С-подобный код примеры которого в изобилии демонстрировались отдельными поборниками производительности, то я скорее предпочту более медленный код, но и более просто читаемый/изменяемый.
V>Так вот, если уж речь идет об отношении затраченных усилий к полученному эффекту, то очевидно, что необходимо минимизировать потраченные усилия, либо отказаться от их траты, если получаемый эффект невелик. Так вот, ОЧЕНЬ ЧАСТО т.н. "оптимизация" ничего не стоит,
Оптимизация ничего не стоит очень редко. Да и говорить о таких случаях как об оптимизации не стоит. Ну, да я уже повторяюсь.
V> никак не портит программу, не усложняет код и не требует полного повторного цикла тестирования. Мы давно пишем свои программы не с 0-ля, не с машинных кодов, а основываясь на весьма мощных платформах весом в миллионы строк исходников. Владение информацией об этом окружении помогает выбрать оптимальный путь решения задачи. Сам выбор оптимального пути уже является оптимизацией, даже если разработчик не потратил ни лишней минуты на это. Назовем это дело по другому: "грамотное инженерное решение".
Снова смотрим мои слова, об том что оптимальность бывает разная.
V>Ты в своем посте красочно обрисовал тонны потраченных усилий, были ярки картины загубленной красоты исходников... Ты ведь "потомству в пример" это все написал, признайся? 
Так вот, потомство должно так же знать, что недостаточное владение инструментом может породить все эти проблемы даже при решении такой несложной задачи как буферизация ввода.
Согласен. Собственно кривой код и тормоза на ровном месте это скорее не отсуствие погони за скоростью или красотой, а отсутсвие опыта или кривой опыт. Ну, возможно еще проблемы с ДНК.
Однако тенденция к отказу от абстракций подчеркнуто демонстрируемая, ну, вы знаете кем, как раз демонстрирует, то что выбор некрасивых и даже совсем кривых решений очень даже может являться следствием неразумной погони за производительностью.
Еще раз повторю, я в те времена намеренно отказался от "буферизации" воода и выбрал работу с "блоками памями". Это бло, можно сказать, дизайнерское решение. Безграмотное? Одназначно! Основанное на умозрительных предположениях? Безспорно. Но все же основанием для него явилось не то, что я не допер до буферизации и т.п. Основанием была погоня за производительностью.
V>Опять же... Требования и еще раз требования... Ну почему мы всегда обсуждаем что-то абстрактно, и как тут можно понять, чьи позиции устойчивее, если контекст не задан? Более-менее воссоздать картину можно попробовать из твоих эмоциональных акцентов. Но где гарантия, что их правильно истолковали? А может быть ты тогда не совсем правильно истолковал внешние условия? Какой был процент "покрытия" этими кеш-драйверами? Предназначалась ли твоя прога и для XT? Даже для тех, у кого 256кБ? (На них эти всякие кеши не ставились принципиально никогда, но тем не менее одно время таких машин было достаточно)
Нда, беда. Мне
ПОХРЕНУ проценты, килобайты, названия функий
И ДАЖЕ причины приведщие к этому. Я
ГОВОРИЛ О НЕВЕРНЫХ ПОСЫЛАХ... неверных стремлениях, неверных действиях.
Что килопроцентов, то исходная версия программы писалась на ХТ и там изумительно вставал Смартдрайв, ведь у них один хрен был метр памяти.
VD>>Посыл явно непонятен, раз ты продолжаешь рассуждать о каких-то там структурах и версиях компиляторов.
V>Ловко, однако не зачтено. 
Ты видимо непонимашь реального положения вещей. Мне не нужно сдавать тебе зачеты.
V>Диктую большими буквами: ЕСЛИ ВАМ И ПРОЕКТУ ЭТО НИЧЕГО НЕ СТОИТ, ТО ВЫБИРАЙТЕ НАИБОЛЕЕ ЭФФЕКТИВНОЕ РЕШЕНИЕ ЗАДАЧ НА ЛЮБЫХ УРОВНЯХ.
Ну, тогда я тоже продиктую
ДУМАЙТЕ НА ДВА ШАГА ВПЕРЕД, МАТЬ ВАШУ. Не думайте о битах и байтах пока в этом не будет крайней нужды.
Вообще я кажется понял. Разница между нами не в подходах к программированию. Разница в том что мое мировозрение испочено кроме программирования еще и экономикой с юриспруденцией. По этому для меня очевидны многие вщеи не очевидные для программистов. Видимо чистый программист принципиально не может в рассуждениях не оперировать битами. Вопрос только в степени зациклинности на них.
V>Ключевая фраза: "ничего не стоит".
Да? Привести тебе примеры кода кого приводишиеся в качестве агрументов битовыжимания, чтобы ты обяснил как они могут ничего не стоить?
V>Но тем не менее, факт остается фактом. Тысячи и тысячи программистов пишут одно и то же, выпускают массу продуктов очень близкой функциональности, все получают немаленькую ЗП, и вопрос минимизации затрат на разработку ПО встает в гораздо более жесткой форме — быть бизнесу или же провалиться с треском. Отсюда все эти веяния. Теперь примерно понятно, почему я там 3 поставил?
Это ты о битовыжимальной агитации? Не, не понятно. Ели бы было понятно, то я пошел бы тоже чё-нить поставил.
V>В своей жизни я уже успел написать несколько учетных систем, массу системных и т.д. и т.п. И очень многие мои коллеги так же. Кое какие продукты используются до сих пор, кое-какие скоро начнут активно использоваться (я очень надеюсь). Однако, я ни на секунду не забываю, что программист (и я в том числе) сейчас используется крайне неэффективно. Процесс раздела рынка ПО сейчас в самом разгаре, и продлиться по прогнозам еще не менее 20 лет, т.е. сейчас рулят правила джунглей. А правила не гласят — "сделай лучше всех", правила гласят: "сделай всех", или еще короче: "выживи". И вот такой вот внешний контекст оказывает весьма серьезное влияние на умы даже опытных разработчиков, да такое, что они в пылу спора уже и не помнят, где причина а где следствие обсуждаемых вещей.
Понятно. У тебя экономические причины. Ты уж извини, но экомические вопросы мне мало интересны. И уж обсуждать я их стал бы не с программистами и не в темах связанных с производительностью ПО.
V>Ну представь хоть на секунду, что в стремлении выпустить, например, новую Тойоту на рынок, с новыми, прямо-таки космическими внешними обводами, фирма Тойота пошла на следующие допущения:
V>- Весит в 2 раза больше, однако, по-прежнему шустро ездит за счет более мощного мотора
V>- Топлива она жрет в 2 раза больше
V>)
Вы хотите поговорить об этом? (с)
Я не буду обяснять почему эта налогия здесь не применима. Иначе прийдется вдаться в очень тонкие проблемы рынков и рыночных ниш. Хватватет того, что доказательство по аналогии является машейничеством.
V>Такое может привидется только в кошмарном сне кокого-нибудь инженера Тойоты. В реальности, каждая следующая модель выходит со все лучшими характеристиками, ос более оптимальным весом, с большим КПД (люди, вы еще помните это слово) двигателя.
Тебе не странно, что когда фирма выпускает вертолет вместо легковушки строит машину весящую болше и жрущую больше ресутсов? А не странно что лимизин представительского класса "Весит в 2 раза больше, однако, по-прежнему шустро ездит за счет более мощного мотора — Топлива она жрет в 2 раза больше"?
Вот и мне не странно, что программа которая предоставляет мне рефактринг, хорошо работающее автодополнение при вводе, контекстную справку на каждый чих, отличный расширяемый редактор и отладчик и т.п. жрет чуть ли не в 10 раз больше времени. Точно так же как не странно, что графический Ворд 2003 с морем фич на два-три порядка более прожерлив чем скажем Лексикон, или Ворд фор ДОС.
Так что кончай увликаться аналогиями, а обрати внимание на свою логику. В своих рассуждениях ты забывашь, что продукты жрущие больше ресурсов и дают больше. А те что
жрут больше не давая ничего в замен по сравнению с продуктами конкурента попросу
теряют потребителя и вымирают.
А слезы по повду расходвания 10 метров из гига — это глупость и ханжество. Не нравится? Старые программы работать не перестали.
V>Но ведь это не удивительно, над новой моделью работаюбт сотни инженеров. А у нас, у программистов, примерно 5-15 человек делают проекты, по информационной сложности мало уступающие проекту той же Тойты.
Ну, что же. Тебе никто не мешает заработать денег, создать свою фирму, нанять сотню инжинеров и сделать продукт который пользователи предпочтут потому другим. Вот только на этом пути ты будешь вынужден научиться зарабатывать деньги и поймушь в чем ты был не прав.
V> Поянтное дело, что для самого факта успешности подобных проектов жизненно необходимо максимально все упрощать и выкидывать все лишнее (и оптимальные пути разумеется тоже). А иначе как? Человеческий мозг — весьма ограниченная в своем объеме штуковина.
А иначе так. Пусть все занимаются своим делом. Пусть успешность продукта на рынке предсказывают маркетологи и сложбы по взаимодействию с клиентами. Пусть проектами управляют люди знающие толк в этом деле. А программируют и проектируют ПО люди проффеисиональные в этом деле. Тогда маркетологи и т.п определять набор требуемых возможностей, менеджеры спланируют их реализацию, а программисты запрограммируют и оттестируют все в нужные сроки с нужным качеством. Тогда успешные продукты автоматически выявят более грамотные команды, а безграмотные развалятся. В общем, через рынок потребитель сам определит что ему надо. А прямое управление как бы оно не казалось заманчивым неизбежно приведет к маразму и деградации. О программистах тут вообще речи вести не стоит. Они тут могут сделать только одно — найти или создать контору палитика и прицыпы работы которой их устроит.
На этом рассуждения о экономике и бизнесе лично я заканчиваю и возвращаться в рамках этой темы не собираюсь.
V>... Хотел еще примеров написать, но вроде и так общий (самый общий) мой посыл должен быть понятен.
Безусловно. Жаль, что не всем.
V>А что касается конкретных выводов для молодого поколения: ребята, исходим из того что есть (собственно, это и есть формула выживания ).
Ага. В рамках поднятых тобой вопросов можно смело посоветовать первый принцип —
занимайтесь тем, в чем являетсесь специалистами и старайтесь стать еще большими специалистами.
V>Я бы не стриг всех под одну гребенку. К счастью, в крайности бросаются не многие.
Вопрос который мы обсуждаем является таким, что в крайности в нем бросаются очень многие. По-моему, тут уже половина народу призналась, что их порой тянет пооптимизировать что-нить без особой на то необходиомости. Так что тут речь не о стрижке, а о выробатывании здорового эмунитета к дурным пристрастиям.
V> А что касается текущего положения дел, то на само понятие "эффективности" молодое поколение просто забило.
Это не так.
V> Влад, даже ты пишешь свои программы более менее эффективно (сужу по публикуемым кускам). Ты по другому не можешь, хоть и озвучиваешь другую точку зрения. (гы-гы, кстати).
Что значит "даже"? Я пишу вмеру разумно. Иногда тоже увлекаюсь оптимизациями, а потом понимаю что валял дурака. От чего и предостерегаю других.
Мои слова предназначены для тех самых
молодых, но
умных людей которые понимают, что учиться нужно по возможности на чужих ошибках и чужом опыте. Видя проста таки пропаганду в коре ошибочного (по-моему) подхода, я и стараюсь противопоставить ей обратную пропаганду. Надеюсь, что мои усили не пропадут даром.
V>В споре рождается истина, только дураки учаться на своих ошибках и т.д.
И я о том же. Но надо еще понимать, что является ошибкой.
V>Как еще молодым научиться оценивать тот хрупкий баланс м/у потраченными усилиями и получаемым эффектом? И еще немаловажно, куда эти усилия тратить. В описанном тобой примере их стоило потратить не на кодирование, а на изучение документации.
Вот, например, это высказывание явная ошибка. Документация тут ну никаким обоком не поможет. Тут время нужно было потратить на поиск наиболее простого решения на проверки своих предполжений. Короче на формирование знания о предмете, а не на попытку решить проблему на основании отрывочных знаний и предположений.
V>Знаешь, когда я писал лексические анализаторы, я тоже не пользовался классами строк, и тоже активно использовал стек. При определенной аккуратности лекго исключаются возможности прохода по стеку. Обяснить как?
Не надо. Ты потратил время зря, если конечно ты не писал его 20 лет назад. Я вот писал парсер на Шарпе и он работает очень и очень шустро. Сам понимашь, ни о каком стеке тут и речи не идет.
V>Т.е., повторю, в отрыве от контекста доказывать свою правоту бесполезно.
О том и речь. Собственно вопрос и был в том, что предположения бросамемые извеснтым товарищем — это как раз вот такие безконтекстные рассуждения. Они могут быть верны и не верны одновременно. Так что не нужно предпологать. Нужно знать и сопоставлять.
V> Лично я поддержал сам факт обсуждения этой темы. Согласен, что Дворкин немного перегибает,
Будем надеяться, что тройка поставленная им за твое сообщение в том числе включает и согласие с этим вот высказыванием.
V>но, может он это делает специально, в ответ полное пренебрежение к этому вопросу у окружающего мира?
Вряд ли. Я вижу за этим именно деструктивное мировозрение усиливаемое его статусом. Хотя возможно тут уже я перегибаю палку.
V>Вообще-то, согласно правилам инженерии, самое общее решение является самым неподходящим для конкретного случая.
Да? Можно источники? Люди всегда стремились к универсальным решениям. Другое дело, что частные решения проще оптимизировать. Но это не одно и то же.
V> Однако, в ПО повторное использование ничего не стоит (т.е. разможение информации и кода ничего не стоит).
К сожалению, стоит. Со временем все меньше и меньше, но этого достаточно чтобы очень многие забивали на него исходя из тех же вопросов производительности. Я, кстатати, каюсь, грешен... тоже забивл и порой продолжаю забивать на повторное решение ради производительсности или чего-то еще. Только я делаю это скрипя сердцем, а очень многие с радостью в душе.
V> И вот мы называем самые общие решения "грамотным дизайном", потому как они повторно применимы. В общем, это совсем другой вопрос — что считать грамотным. Я тоже люблю фреймворки писать.
Нет. Лично я называю грамотными решениями — решения подходящие для задачь по многим параметрам (совокпностью которых и выражается мое мировозрение). Общность решения не является решающим, как и скорость.
Скорее грамотным решением я назову некое обобщенное решение которое в то же время позволяет хорошо адаптироваться к задаче. Ну, например, можно написать общее решение, а можно "общее решение с параметрами". Параметры повзолят настроить решение под конкретные задачи.
V>Добавлю еще насчет грамотного дизайна. Опять все встает с ног на голову. Раньше люди решали путем анализа вполне конкретные программистские задачи. Потом обнаружили их похожесть. Потом дали имена паттернам и использовали так: спроектировал что-либо, максимально удовлетворяющее требованиям, а потом _обяснил_ разработку на языке паттернов. Т.е. язык паттернов — это всего лишь терминологическая база. А молодежь как сейчас что-то проектирует??? Вместо того, чтобы решать поставленную задачу, крутит эти паттерны как кубики Лего, путем полного перебора стараясь подобрать нечто условно отвечающее поставленной задаче. И выходят монстры, один другого страшнее. И _паттэрны_ вроде есть, и неграмотно при этом...
Не, с ног на голову, по-моему, все ставишь как раз ты.
Паттерны — это опыт. Слово "паттерн" появилось в программистском лексиконе очень недавно и я по началу был сильно против него. Но потом я понял, что паттерн — это опыт решения конкретной задачи который описан настолько хорошо, что им можно оперировать как сущьностью. 90% паттернов я применял по наитию и раньше. Я использовал Синглтоны и Фабрикуи классов в КОМ-е и т.п.
Доходил я до этих паттерно одним из двух способов:
1. Решая конкретную задачу натыкался на сложности. Раз за разом преодолевая сложности я накапливал опыт их преодоления.
2. Подсматривая неординарные решенеия (т.е. те до которых сам не допер) у других (например, в АТЛ).
Со временем я запоминал эти решения и начинал их использовать
еще на стадии проектирования (ну, или на стадии принятия решения о том как решать вставшую проблему).
Что же я делаю глупости? Нужно как во времена когда я только учился программировать каждый раз проползать на брюхе все трудные места, и только потом распозновать паттерны и заменять некрасивые решения на них?
Или что же тем кто родился на 10 лет позже тоже нужно обязательно проползти на брюхе все что прополз я?
Эдак человечество остановилось бы в развитии и каждое следующее поколение смогло бы только чуть-чуть поодвигаться впердед и то только если верить в то, что каждое новое поколение в принципе становится умнее.
Это несусветная глупость!
Человечество идет семемильными шагами вперед исключительно благодаря тому что научилось обобщать опыт. Паттерны это и есть обобщенный опыт. Кстати, описанный мной принцип получения программ приемлемых по быстродействию тоже есть обощение опыта. Более того не моего! Это и есть те самые инженерные приципы которыеми тут многие так гордятся, если хотите.
Так что молдые очень правильно делают, что используют паттерны при проектировании ПО. Тем самым они повышают свою производительность.
Ну, а беспокоиться нужно о том, чтобы эти молодые привильно понимали эти паттерны и умели быстро и безошибочно распозновать места где они применими (выбирать нужный паттерн).
Конечно, человек неспособный "проползти на брюхе" то для чего еще нет паттерна — это и есть тот самый ламер! Любой хороший программист обязан уметь пробивать проблемы на одном упорстве. Но только если проблема не имеет готового качественного решения.
VD>>Я бы поверил тебе, что ты так всегда поступашь, если бы не видел твоей "тройки" вот на этом призывеАвтор: Pavel Dvorkin
Дата: 05.10.05
. Возможно ты и его не понял доконца, но тогда вопрос можно ставить об адекватности восприятия тобой и вещей вроде объема крови жертвуемой на оптимизации и необходимостью этих оптимизаций. (ни прими это за оскорбление, плиз)
V>(уффф, чтоб меня так чужие оценки беспокоили...)
Меня не беспокоит сама оценка. Уж кому кому, а не мне чужим оценкам завидывать.
Я считаю оценку выражением согласия и поддержки. И куча положительных оценок на явно, по-моему, деструктивном мнеии меня обижает и пугает. Особенно пугает когда оценки ставят не те ктого я считаю ортодоксами или фанатиками.
V>В этом месте ты уже забыл, что я настаивал на выборе оптимального инженерного решения, и обращал внимание, что сам этот выбор может ничего не стоить. А оценку я поставил за художественную силу и злободневность самой темы. И за то, что не поленился человек такой большой пост откатать, и при этом вовсе не нудный. В общем, по аналогии с фигурным катанием, оценки не только за технику ставим, но еще и за артистичность. 
Я не вижу злободневности. Я вижу деструктивность. Очень жаль, что ее не видешь ты и многие друние.
Ставить же оценки за графоманство, чем собственно и является художественная сила, то же считаю не очень разумно, так как яорум посвящен программированию и оценка будет воспринята как одобрение и поддержка основных посылов сообщения.
Именно по этому меня волнуют оценки на пдообных мениях.
Я рассуждаю просто... Если на этот форум зайдет человек мировозрение которого еще не сформировалось, то он обязательно обратит внимание на то, что множество вроде как разумных и достоиных людей поддерживают мнение о том, что нужно делать все максимально быстрым. Дальше скорее всего начнутся дейсвия которые лет через 20 могут привести к появлению еще одной волны, ну, ты понял чего.
VD>>Ну, любая идея требует критического взгляда. Но хотелось бы чтобы этот взгляд был действительно критическим, а не основанным на непонимании.
V>Мы все тебя прекрасно понимаем, мамой клянусь!
Неуверен. Вернее даже уверен в обратном.
V>Давайте, после артподготовки (обмена любезностями), перейдем к ближнему бою. Выкладывайте у кого что есть из актуальных примеров, когда по чьему-то мнению требвалось принимать волевое решение об затратах на оптимизацию, заодно попытаемся собрать максимум внешних ограничений/требований и оценить адекватность подобных затрат. У меня есть пара весьма актуальных примеров, если народу будет интересно, с удовольствием пообсуждаю.
Незнаю. У меня все просто. Если вижу что что-то работает медленно, то думаю как исправить и исправляю. У меня обратная проблема. Часто стараюсь сделать оптимальнее чем нужно на что убиваю кучу времени.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Если нам не помогут, то мы тоже никого не пощадим.
