ускорение с 1 часа, до 3 мин ничего не меняет, но усложняет поддержку и понимание

Не все так однозначно. Когда есть какие-то ошибки в этом «простом» коде, то на воспроизведение ситуации может уходить до часа времени. Тогда как с 3 мин можно быстрее воспроизвести и понять в чем проблема.

Да, если ошибки воспроизводятся на полном сете данных. В остальные случаях можно написать тест

код нормально комментировать и документировать просто надо. а всем это делать лень. некоторым доки писать - вообще как серпом по яйцам. вот и пытаются делать вариант «программа хорошо документирована на языке программирования c++»

Насколько у вас развито ощущение того, что код нужно писать правильно и эффективно просто потому что код нужно писать правильно и эффективно?

На 9 из 10. Но критерий «правильности и эффективности» варьируется.

От задачи же зависит.

Если это поделие на коленке/что то тошнотворное, вызывающие омерзение/жуткий цейтнот - то работаешь в стиле «сделал и забыл», там не до красивостей.

Если это произведение искусства, «для себя» - то конечно ищешь оптимальное решение не считаясь с затратами времени на поиск. Тут важен процесс, а не результат;-)

Ни насколько.

Для начала нужно написать правильно, но совершенно необязательно эффективно. Конечно, явных глупостев тоже лучше не делать, но зачастую обычный вектор будет лучше всяких КЧ-деревьев.

Затем, если будут тормоза, можно переписать какие-то места эффективно, но совершенно необязательно правильно. Заменить один массив на КЧ-дерево, остальные не трогать.

Это бизнес, детка. Если ты работаешь на НИИ или университет, пишешь софт для ресерчеров, то конечно, алгоритмы надо юзать на 100%, а если пылишься в подвале у ОАО, где менеджеры по продажам срубают зарплату в 15 раз превышающую твою, то сиди, пиши как будет быстрее, компилируй и продавай.

Печально, но факт.

Возможно они говорят верно. Оптимизированный код обычно труднее модифицировать.

А на собеседованиях-то и в резуме обычно «Advanced algorithms understanding is an advantage». А потом сидишь и пишешь фабрики фабрик.

Насколько у вас развито ощущение того, что код нужно писать правильно и эффективно просто потому что код нужно писать правильно и эффективно?

Наверное, надо убить в себе перфекциониста.

Вспомнилось. Надо было вытащить данные из кучи html'ок. За час написался скрипт с использованием BeautifulSoup, четыре часа заняла вся обработка. Итого пять часов. Как ни крути, это оказался самый быстрый вариант, несмотря на python и однопоточность.

индексы пугают людей, ибо написаны вручную, а максимум что дозволено - интегрировать какой-то фреймворк

Доверия нет? А фреймворк — это «надёжно».

может это?

http://programmers.stackexchange.com/questions/163185/torvalds-quote-about-go...

Всё верно говорят.

Нужна взаимозаменяемость мартышек.

А иногда по мере модификации оптимизация приводит к лишним тормозам.

Эта цитата очень хороша для того, чтобы отмазаться за быдлокод.

Потому что ты эстетствуешь, а они деньги зарабатывают.

доводы:

код имеет мало практической пользы без данных и ценности с т.з. потребителя т.е. конечного пользователя

отмазаться можно другими путями...

Если быстродействие некритично, то прозрачность кода всегда имеет приоритет.

код имеет мало практической пользы без данных и ценности с т.з. потребителя т.е. конечного пользователя

И что? Более-менее сложные данные без кода тупо бесполезны.

отмазаться можно другими путями...

Я и не говорил, что это единственный.

Читаемость кода не нужна.

Запускается? Шикарно. Делает то, что нужно? Просто чудесно!

Аргументы следующие: алгоритм запускается раз в неделю и ускорение с 1 часа, до 3 мин ничего не меняет, но усложняет поддержку и понимание.

А вот срочно подоткнуть в работающий ворксшейшен 32 гига оперативки уже малость проблематично.

вот и пытаются делать вариант «программа хорошо документирована на языке программирования c++»

Тут еще всплывает такая область для холивара «эффективные алгоритмы на скриптовых языках vs тупые алгоритмы на с++/java»

это пост о здравом смысле

Насколько у вас развито ощущение того, что код нужно писать правильно и эффективно просто потому что код нужно писать правильно и эффективно?

Нужно писать поддерживаемый и масштабируемый код, а любая оптимизация требует обоснования.

При таком раскладе, я бы не трогал..

в клинических случаях это не помогает, т.к. крайне редко получаются масштабируемые приложиния - обычно bottle neck перемежаются с алгоритмическими жопами, там можно хоть задобавляться

Совсем не факт что читабельный и неоптимизированный код легче масштабировать. Например такой код вполне может оказаться однопоточным by design или очень прожорливым в плане оперативки.

в этом же и есть мастерство - создавать программу с такими свойствами, с какими нужно.

с другой стороны, механизм всегда можно спрятать под интерфейс, а интерфейс сделать понятным... типа sort, сразу понятно что делает, а как он это делает на понимания общей картины не влияет.

Например вместо глупого перебора среди нескольких ГБ данных использование специализированых структур данных вызывает бурю негодования.

сделай интерфейс find и меняй как знаешь.

В таких случаях я стараюсь писать простой код с возможностью замены и оптимизации в будущем. Собственно программирование - это постоянный поиск баланса между разными решениями, где скорость работы кода - не всегда главный критерий.

Есть общее правило: выигрывая в малом, обычно проигрываем в большом, и наоборот. Поэтому не всегда стоит заморачиваться на тех оптимизациях, которые не дадут большого выигрыша в целом.

Совсем не факт что читабельный и неоптимизированный код легче масштабировать

Я указал, что код должен быть масштабируемым - это предполагает наличие какой-никакой архитектуры.

Например такой код вполне может оказаться однопоточным by design

Если это небольшой по объему код - переписать его легко, а для большого кода с вероятностью 99% придется писать свою систему распараллеливания, если не подходят какие-то стандартные юзкейсы - типа там clojure, mpi итд.

или очень прожорливым в плане оперативки.

Современный декларативный код практически всегда таким будет. Поэтому изначально прописываю ТЗ «с запасом», и предполагают отступные варианты - т.е. как например в случае большого потребления ресурсов из няшного но тормознутого кода, не переписывая все нафиг, получить быстрый императивный код желательно на том же высокоуровневом языке.

Если это произведение искусства, «для себя» - то конечно ищешь оптимальное решение не считаясь с затратами времени на поиск. Тут важен процесс, а не результат;-)

Ага, правда потом вместо короткого коммента с названием классического алгоритма нужно каждому обьяснять подробно что он делает.

За час написался скрипт с использованием BeautifulSoup, четыре часа заняла вся обработка. Итого пять часов. Как ни крути, это оказался самый быстрый вариант, несмотря на python и однопоточность.

А регекс в grep?

Доверия нет? А фреймворк — это «надёжно».

Надебагался я уже этих надежных вреймворков.

Потому что ты эстетствуешь, а они деньги зарабатывают.

Деньги зарабатывают другие люди, а они программисты и я с ними работаем за зп

А отвращение к коду? Потом мне надоест писать говнокод, я свалю и бизнес пострадает на денежку для поиска нового человека

Да, у меня тут недавно dict из Python обогнал красно-черное дерево на C. Просто потому что хеш-мапа вместо сбалансированого дерева и хешу везло

Для меня еще самая естественная структура данных - часто залог корректности. Другое дело что многим нужно краткую лекцию прочитать о этой структуре данных

Если это небольшой по объему код - переписать его легко, а для большого кода с вероятностью 99% придется писать свою систему распараллеливания, если не подходят какие-то стандартные юзкейсы - типа там clojure, mpi итд.

Серьезные алгоритмисты обычно не сильно полагаются на распаралеливание, Скиенна об этом прямо говорит. Идеально паралельный алгоритм ускоряется в два раза при покупке второй машины. Но поменяв «O» можно что-то ускорить в 1000 раз. Готовы купить тысячу машин? Естественно разговор имеет смысл дествительно если параллелизм требует слишком большого количества машин

Зачем же каждому? Только тем, кто имеет к этому отношение (должен копаться в кишках алгоритма). Если таких людей много (а два это число много большее единицы), то у вас явный косяк с декомпозицией задачи.

И по скромному личному опыту - простые решения самые правильные. Т.е. какие нить хитровыкрученные деревья не имеют существенных преимуществ перед обычным rb-tree или дихотомией. KISS!

В интересных задачах создание новго кода это очень прикольно и доставляет эстетическое наслаждение, но код это всего лишь молоток. Интересны результаты, получаемые с помощью кода.

на задачу есть тз, в тз прописано какое время должно чего работать либо явно либо косвенно. если данные временные промежутки соблюдены и всё работает, то не трогай - иди покури. если нет, то надо «усложнять алгоритмы».

а так в российских реалиях код должен быть максимально простым, по одной причине - постоянно меняющиеся требования. вот когда ты напишешь (или только начнешь писать) супер друпер оптимально, а завтра к тебе придут и скажут, что «концепция поменялась» и надо не то что описано, а кое что совсем другое и это надо уже вчера, вот тогда то и поймешь сию простую истину. :) ибо в простой код костыли по быстрому вставлять намного легче чем в алгоритмы.

Никак. Я сам не программист, для меня программирование - просто инструмент. Видимо, поэтому легко не поддаваться перфекционизму.

В данном случае я бы рассуждал так - глупый перебор укладывается в требования по времени, не нуждается в длительном написании/отладке/тестировании, значит он годится. Конечно, можно прикинуться олдфагом и оптимизировать производительность с ассемблером в зубах, но свое время тоже дорого.

Другое дело что многим нужно краткую лекцию прочитать о этой структуре данных

Так прочти, не?

Серьезные алгоритмисты обычно не сильно полагаются на распаралеливание

Это ты байки какик-то задвигаешь.

Скиенна об этом прямо говорит.

Кого е^W волнует, что он там говорит?

Идеально паралельный алгоритм ускоряется в два раза при покупке второй машины.

У нас тут в каждой машине по 4 ядра, ничего покупать не нужно - чтобы ускорить алгоритм в 3-4 раза.

Но поменяв «O» можно что-то ускорить в 1000 раз.

Зависит много от чего: от объема данных, от типа задачи (параллелизм на тяжелых вычислениях или конкурентность на легких), от степени высокоуровневости языка.

Готовы купить тысячу машин? Естественно разговор имеет смысл дествительно если параллелизм требует слишком большого количества машин

Имеет смысл параллелить даже на одной машине, потом оптимизировать алгоритмы, дальше уже думать о кластерах мета^W.

Ну я все понял :)

А регекс в grep?

Это оказалось не очень надёжно, в некоторых случаях лажает, даже если на 10 случайно выбранных всё хорошо. А с парсерами DOM проще: если сработало на двух-трёх, сработает и на 10000. Плюс склонность python бросаться исключениями исключает явные пропущенные ошибки.

Я думал у вас один раз прогнать нужно было

Были другие разы, с другими данными. (Недавно узнал, что это теперь называется data science.) Тогда я знал немного php и немного regexp'ов. Поэтому это были cli скрипты на php (не знаю, чего его все так ненавидят, вполне приемлемый инструмент).

Кстати, тебе может ещё и повезло. Представь другую ситуацию: ты пишешь понятный код, а тебе указывают, что нужно многое поменять, причём замены не по сути алгоритмов, а всякие мелочи типа склеивания строк в одну, чтобы рядом были и в кэш влезали, переупорядочивание полей в структуре, замена массива структур на несколько массивов или наоборот, замена небольших деревьев на простые массивы, ибо последовательное сканирование лучше ляжет в кэш и тому подобное. Ты всё меняешь, и в результате твой красивый код превращается в нагромождение костылей, но тем не менее работает на 5-10% быстрее. И его страшно трогать.

Не понял. Отвращение к прозрачному коду? Или к тормозному? Что ты имеешь в виду?

К тормозному, когда есть быстрый и элегантный

работает на 5-10% быстрее

Насколько я понимаю, топик о выигрышах в разы.

скрипты на php (не знаю, чего его все так ненавидят

Ну, для скриптов-то можно использовать что угодно: написал и выбросил. В случае пхп этот процесс (особенно фаза «выбросил») должен наверное приносить даже чуть больше удовольствия, чем обычно :P

После выигрыша в разы может быть выигрыш в 5%. Это две крайности; неизвестно, какая хуже.