Здравствуйте, Undying, Вы писали:
U>Преждевременная пессимизация (например, использование для поиска пробега по списку вместо словаря или бинарного поиска) это тоже зло,
И что, без разницы какой размер списка?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Dufrenite, Вы писали:
D>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>А мне не по душе, когда я вижу код, который мог бы работать быстрее, думая о том парне, которому придется с этой программой работать
D>Поверьте человеку, сотню раз наступившему на грабли. Если с самого начала не заложить в систему максимальную гибкость и модифицируемость, можно увидеть её благополучную кончину ещё до рождения. Грошовые оптимизации на начальном этапе действительно приводят к масштабным переписываниям кода ближе к концу проекта.
О да!
Знаешь, ты скорее говоришь о ситуации, когда люди увлекаются некоторыми подробностями и за деревьями им становится не видно леса. Но это совсем из другой оперы, оптимизация именно быстродействия чего-либо тут вовсе не при чем. Даже если и прозвучало "мы просто хотели сделать оптимальнее" — это обычная отмазка неопытного разработчика, которому хочется быстрее попрограммировать и быстрее увидеть результат. Стоит ли эту отмазку огульно приписывать всем остальным?
Как бы тебе это сказать потактичнее... Когда все делается "как положено", то еще на стадии анализа многие узкие места могут быть увидены и проверена их реальная "узость" в технических экспериментах. Точно так же может стать понятно, насколько гибким должен быть дизайн. За гибкость ВСЕГДА приходится платить, поэтому преждевременная гибкость — это такая же разновидность преждевременной оптимизации. Да, чем хуже формализованы требования, тем большая гибкость требуется относительно реализации каждого такого требования, но это лишь говорит о том, что ни о какой безусловности твоего лозунга не может быть и речи. Например, требуется ли эта "гибкость дизайна" при разработке кодека по устоявшемуся алгоритму или при реализации TCP протокола?
Могу лишь согласиться с тем, что упомянутая тобой разновидность желания "сделать все лучше" не так тяжела в последствиях, как "битовыжимания", ибо наиболее вероятно такой код не придется выкидывать полностью. Но насколько получится его повторно использовать? В 99% не получается, кроме вот этого одного целевого приложения, поэтому вся эта заведомая гибкость лишь добавляет необоснованных трудозатрат.
Вообще о гибкости говорить странно в эпоху продвинутых сред, анализа кода и мощнейшего рефакторинга, где внести лишнюю асбтракцию или перегруппировать имеющиеся — это как два пальца. Единственный универсальный критерий только один — это чтобы на каждом уровне проектирования/программирования было вменяемое кол-во задействованных сущностей. Собственно, это и есть цель любой декомпозиции — сделать каждую задачу легко обозримой для человеческого мышления. Но вот что касается других критериев, например гибкости дизайна, то эти критерии вовсе не универсальны, а должны управляться функциональными и нефункциональными требованиями... вот у нас есть несколько наших библиотек, которые кочуют из проекта в проект, но их гибкость и "мощь архитектуры" наращиваются только в ответ на конкретные требования. Ну посмотри хотя бы на развитие того же BLT (за много лет!), который в первых версиях выглядел не столько ORM, сколько хелпером по генерации эффективных аксесоров.
В плане же быстродействия (раз о нем речь) заниматься полной отрицаловкой, как тут некоторых заносит, тоже не стоит, ибо это попахивает инженерным идиотизмом. Достаточно не забывать о правилах хорошего тона. Например, если серверное приложение долго стартует, то это никого не интересует, но крайне раздражает пользователей в случае клиентских приложений. И не только во время старта — пользователей всегда раздражают случаи демонстрирования "тормознутости" программы. Но опять же, здесь не требуется выжимать разницу в миллисекунды, ибо юзер эту разницу не заметит все-равно... но когда с помощью лишней пары строк кода можно улучшить отклик в десятки раз (как раз обсуждалось), и не заставлять клиента нервничать несколько минут, то это сделать надо непременно. Я не призываю начинать разработку с этого (см. начало моего сообщения), но перед тем, как отдать клиенту — обязательно. И заметь, твоему лозунгу это никак не противоречит.
D>Я не имею в виду конкретно способы обхода дерева, эти вещи в принципе тривиальны. Плох сам принцип. Преждевременная оптимизация зло — доказано теорией и проверено на практике.
Вообще-то смешно видеть, когда коллеги сами себе противоречат в непререкаемом тоне. Не так улыбают замеченные противоречия, как пафос при их декларации... Суммируя вышенагенеренный мною спам: оптимизация бывает не только по быстродействию — сей лозунг всего-навсего предостерегает от любых лишних трудозатрат, оправданность которых сугубо умозрительна.
Здравствуйте, VladD2, Вы писали:
VD>И что, без разницы какой размер списка?
Если можно гарантировать, что размер списка никогда не будет превышать десяток элементов, тогда да можно обойтись пробегом по списку для поиска. Но в подавляющем большинстве задач это гарантировать нельзя.
Здравствуйте, Undying, Вы писали:
U>Если можно гарантировать, что размер списка никогда не будет превышать десяток элементов, тогда да можно обойтись пробегом по списку для поиска. Но в подавляющем большинстве задач это гарантировать нельзя.
Дык 99% списков именно такие. И больше скажу для списков размером в 20 элементов в 90% случаев тоже не критично искать перебором.
Так что, как всегда, рулит одна простая истина — всегда надо думать головой!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>О да! V>Знаешь, ты скорее говоришь о ситуации, когда люди увлекаются некоторыми подробностями и за деревьями им становится не видно леса. Но это совсем из другой оперы, оптимизация именно быстродействия чего-либо тут вовсе не при чем. Даже если и прозвучало "мы просто хотели сделать оптимальнее" — это обычная отмазка неопытного разработчика, которому хочется быстрее попрограммировать и быстрее увидеть результат. Стоит ли эту отмазку огульно приписывать всем остальным?
Да я и не приписываю.
Может я и не прав, но у меня есть свое определение оптимизации: "оптимизация, это ухудшение качества кода с целью повышения его быстродействия".
V>Как бы тебе это сказать потактичнее...
Потактичнее не надо. Я на правду-матку не обижаюсь.
V>Когда все делается "как положено", то еще на стадии анализа многие узкие места могут быть увидены и проверена их реальная "узость" в технических экспериментах.
Я занимаюсь разработкой игр. У нас почти никогда не делается "как положено". Извините, наболело. Под лозунгом повышения быстродействия прокатывают совершенно нереальные по своему убожеству архитектурные решения.
V>Точно так же может стать понятно, насколько гибким должен быть дизайн. За гибкость ВСЕГДА приходится платить, поэтому преждевременная гибкость — это такая же разновидность преждевременной оптимизации. Да, чем хуже формализованы требования, тем большая гибкость требуется относительно реализации каждого такого требования, но это лишь говорит о том, что ни о какой безусловности твоего лозунга не может быть и речи. Например, требуется ли эта "гибкость дизайна" при разработке кодека по устоявшемуся алгоритму или при реализации TCP протокола?
Не поспоришь.
V>Могу лишь согласиться с тем, что упомянутая тобой разновидность желания "сделать все лучше" не так тяжела в последствиях, как "битовыжимания", ибо наиболее вероятно такой код не придется выкидывать полностью. Но насколько получится его повторно использовать? В 99% не получается, кроме вот этого одного целевого приложения, поэтому вся эта заведомая гибкость лишь добавляет необоснованных трудозатрат.
Согласен. Я неоправданно распространил свои задачи на всю индустрию. По себе же скажу — сейчас разрабытаваю игровой движок, фактически технологию или фреймворк, называй как хочешь. Здесь приходится балансировать на острие ножа между требованиями производительности и гибкостью, так как повторное использование предполагается в нескольких проектах.
V>Вообще о гибкости говорить странно в эпоху продвинутых сред, анализа кода и мощнейшего рефакторинга, где внести лишнюю асбтракцию или перегруппировать имеющиеся — это как два пальца. Единственный универсальный критерий только один — это чтобы на каждом уровне проектирования/программирования было вменяемое кол-во задействованных сущностей.
Не совсем. Вопрос в стоимости рефакторинга. Я уже говорил о том, что неумное оптимизирование приводит к масштабному переписыванию кода. Это как раз об этом. Если требуется рефакторинг, затрагивающий, например, 25% кода приложения, как это назвать? Катастрофа.
V>Собственно, это и есть цель любой декомпозиции — сделать каждую задачу легко обозримой для человеческого мышления. Но вот что касается других критериев, например гибкости дизайна, то эти критерии вовсе не универсальны, а должны управляться функциональными и нефункциональными требованиями... вот у нас есть несколько наших библиотек, которые кочуют из проекта в проект, но их гибкость и "мощь архитектуры" наращиваются только в ответ на конкретные требования.
Согласен, но. Если код библиотек измеряется миллионами строк, то без хорошо продуманной архитектуры обойтись невозможно.
V>В плане же быстродействия (раз о нем речь) заниматься полной отрицаловкой, как тут некоторых заносит, тоже не стоит, ибо это попахивает инженерным идиотизмом.
Ни в коем случае. Если с моих слов создается такое впечатление, то прошу прощения за то, что непреднамеренно ввел в заблуждение. Вопросами производительности занимаюсь практически постоянно, но не отношу их к оптимизации (см. определение).
V>Достаточно не забывать о правилах хорошего тона. Например, если серверное приложение долго стартует, то это никого не интересует, но крайне раздражает пользователей в случае клиентских приложений. И не только во время старта — пользователей всегда раздражают случаи демонстрирования "тормознутости" программы. Но опять же, здесь не требуется выжимать разницу в миллисекунды, ибо юзер эту разницу не заметит все-равно... но когда с помощью лишней пары строк кода можно улучшить отклик в десятки раз (как раз обсуждалось), и не заставлять клиента нервничать несколько минут, то это сделать надо непременно. Я не призываю начинать разработку с этого (см. начало моего сообщения), но перед тем, как отдать клиенту — обязательно. И заметь, твоему лозунгу это никак не противоречит.
V>Вообще-то смешно видеть, когда коллеги сами себе противоречат в непререкаемом тоне. Не так улыбают замеченные противоречия, как пафос при их декларации...
Это не пафос. Я просто хотел потаскать за рога священную корову Павла Дворкина. Но он опытен и не поддался
V>Суммируя вышенагенеренный мною спам: оптимизация бывает не только по быстродействию — сей лозунг всего-навсего предостерегает от любых лишних трудозатрат, оправданность которых сугубо умозрительна.
Здравствуйте, Dufrenite, Вы писали:
D>Это не пафос. Я просто хотел потаскать за рога священную корову Павла Дворкина. Но он опытен и не поддался
И что за манера поиска козла отпущения? Знаешь, охота на ведьм — это отличительная черта рунета, и этого сайта, в т.ч. В пылу спора походя присваивают оппоненту противоположное мнение и с треском его разбивают. Проблема только найти такого оппонента, что не так просто, ибо все обкатанные уже — где сядешь, там и слезешь... И вот он, Дворкин, ату его, ату!!! Фигли, он же сам же и напросился (хе, смелый, блин), а у нас как раз недостаток кого бы сжечь, прямо пальцы при виде клавы чешутся. И ты думаешь, Дворкина кто-нить вдумчиво читает? Да упрощают и выдергивают из контекста так, что у меня от такой молодецкой удали кофе бывает на клавиатуру разливается. Ситуация смогла зайти так далеко лишь потому, что Дворкина травят люди из админресурса, а он, судя по многолетнему наблюдению, до конца джентельмен. Т.е. там, где любой давно бы одернул увлекшихся коллег, возможно даже в грубой форме, он до конца пытается (вот наивный) вести осмысленный и порядочный диалог. А хрена толку, тебя в подворотне банда цинично насилует, а ты с ними уговорами...
Понимаешь, во всех этих темах про конкретные решения, без контекста говорить не о чем. Я бы усилил — это суть глубокое нубство, обсуждать тонкости решений без контекстов и требований. Дворкин практически всегда дает контекст, ровно как с тем же успехом это полностью игнорируется оппонентами. В стандартном местном шоу загонщики обычно приписывают словам жертвы универсальный характер, что ес-но обычно звучит провокационно... Но ведь именно это и требовалось, правда?
Столько написал только что, и ничего по делу, буду исправлять.
D>Может я и не прав, но у меня есть свое определение оптимизации: "оптимизация, это ухудшение качества кода с целью повышения его быстродействия".
Да ты экстремист.
На практике ровно наоборот, говнокод никогда не работает ни хорошо, ни быстро. Если быстрый код значительно отличается от небыстрого по эффективности, то в 90% случаев это говорит, что использовался другой алгоритм, а не другое "оформление" одного и того же алгоритма.
Про остальные 10% могу более подробно, ибо они гораздо чаще встречаются, хотя в 10 раз реже дают ту самую поразительную разницу в быстродействии, но иногда и 10%-20% прибавки уже неплохо, особенно когда такая ветка кода вызывается многие тысяч раз в секунду (надеюсь понятно, что я не точными цифрами оперирую, а даю оценку грубо? Сам я "числодроблю" последнее время кодеки и серверные миксеры голоса в VoIP, с потоковым real-time видео возился еще лет 10 назад, когда здесь этим никто толком не занимался, до этого однокристалки в самолетных системах выжимал до суха, так что мой субъективный опыт по эффективности примерно из этих областей). В общем да, иногда у недостаточно опытных разработчиков приходилось наблюдать желание отказаться от декомпозиции, превратить код в "лапшу", чтобы сэкономить на коссвености вызовов. Дык, надо просто поручить им провести сравнительное тестирование. Там сразу видно, что даже при большом кол-ве вложенных циклов, не имеет смысл оптимизировать вызовы никакого уровня, кроме 1-2-х самых глубоких. Например, без отказа от декомпозиции можно легко получать такие же точно результаты, если структуры обрабатываемых данных лежат на стеке по значению.
Т.е. сценарий прост:
— скопировали некую структуру из кучи на стек;
— прогнали "числодробильный" алгоритм по ней;
— скопировали результат в кучу обратно.
Буквально одно это простое правило никак не ухудшает код, а ровно наоборот — превращает участок кода в достаточно независимый и удобный сниппет, ибо мы в самом алгоритме отвязаны от подробностей того, где могут находиться данные, что всегда есть вери гут при поддержке и наследовании наработок/решений в будущем. Да и копирование одной структуры в коде куда как адекватней смотрится, чем аналогичная инициализация десятка стековых переменных. Так что далеко не всегда получаем в результате ухудшение, и это только один мини-пример.
D>Я занимаюсь разработкой игр. У нас почти никогда не делается "как положено". Извините, наболело. Под лозунгом повышения быстродействия прокатывают совершенно нереальные по своему убожеству архитектурные решения.
Лозунгами сыт не будешь, любое архитектурное решение должно быть инженерно обосновано, т.е. объяснено теоретически и доказано экспериментом. Или у вас архитектурные решения принимаются без сравнительных тестов? Ну дык, если действительно так, покажи инвесторам эту ветку и пусть меняют "архитекторов".
D>Согласен. Я неоправданно распространил свои задачи на всю индустрию. По себе же скажу — сейчас разрабытаваю игровой движок, фактически технологию или фреймворк, называй как хочешь. Здесь приходится балансировать на острие ножа между требованиями производительности и гибкостью, так как повторное использование предполагается в нескольких проектах.
Ага, библиотеку разрабатываешь. Но опять же, даже в случае разработки библиотек, достаточно не закладывать в них "тупиков", т.е. тех решений, отказ от которых приведет в переделке всего клиентского, по отношению к библиотеке, кода. Обычно это означает, что из библиотеки должно как можно меньше торчать наружу внутренних подробностей или требований к "корректному протоколу использования библиотеки". Т.е. простая операция в клиентском коде, типа A=B+C, должна одинаково выглядеть и иметь ту же семантику даже после полной (будь такая надобность) переделки библиотечных кишок. Требуется ли здесь лишняя гибкость дизайна библиотеки? Нет, критерием тут является только низкая связанность "внутреннего" и "внешнего" кода, а необходимый минимальный уровень гибкости должен получаться автоматически, но не закладываться умозрительно. Т.е. стандартная ситуация: на каждой итерации проектирования мы порождаем более детальные функциональные требования к низлежащим уровням и корректируем/собираем нефункциональные требования к вышестоящим, исходя из обновленных более подробных представлениях о принципах работы собственной системы.
Да, разработка АПИ библиотек (не реализации, а именно ее АПИ) с одной стороны — искусство, с другой стороны — основные правила просты. Про низкую связанность уже упомянул. Теперь про оформление: АПИ библиотеки должен быть единообразным, я бы сказал, иметь некий узнаваемый "дух" (чтобы могли потом сказать — это сделано в духе такой-то либы). Единообразность и последовательность, как в именовании методов/параметров, порядка аргументов, так и в основных сценариях работы с либой, сделают ее удобной для использования, ввиду облегчения процесса запоминания связанной с либой информации.
В принципе, это все справедливо и для обычного кода любого проекта (ибо до 80-90% любого большого проекта — это "фреймворк" и прочие хелперы, т.е. суть — внутренняя библиотека), здесь разница лишь в приоритетах. Пусть есть шкала от "легче реализовать, но сложнее использовать" до "сложнее реализовать, легче использовать". Так вот, библиотеки на этой шкале, заведомо и сознательно разрабатываемые для многократного повторного использования или для продажи, лежат в крайне правой позиции, а все остальные внутренние "фрейморки" лежат вдоль всей этой шкалы, выбирая каждый раз такой компромисс, чтобы суммарная трудоемкость была минимальной.
D>Не совсем. Вопрос в стоимости рефакторинга. Я уже говорил о том, что неумное оптимизирование приводит к масштабному переписыванию кода. Это как раз об этом. Если требуется рефакторинг, затрагивающий, например, 25% кода приложения, как это назвать? Катастрофа.
Какой язык? Если С++, то да. Но, в свою очередь, С++ дает мощнейшие ср-ва для кодогенерации, для задания декларативных отношений м/у типами, типами и алгоритмами, алгоритмами и алгоритмами и т.д. Это уменьшает общую связанность, так что и надобность в таком глубоком рефакторинге обычно гораздо ниже ниже, ибо изначально имеющиеся ср-ва декомпозиции таковы, что даже и не снились тем же C#/Java/ObjectPascal.
V>>Собственно, это и есть цель любой декомпозиции — сделать каждую задачу легко обозримой для человеческого мышления. Но вот что касается других критериев, например гибкости дизайна, то эти критерии вовсе не универсальны, а должны управляться функциональными и нефункциональными требованиями... вот у нас есть несколько наших библиотек, которые кочуют из проекта в проект, но их гибкость и "мощь архитектуры" наращиваются только в ответ на конкретные требования.
D>Согласен, но. Если код библиотек измеряется миллионами строк, то без хорошо продуманной архитектуры обойтись невозможно.
То она сама должна состоять из нескольких достаточно независимых библиотек. Чем более независимы будут ее составные части, тем более плевать на цифру в мильон. По-другому никак. Да и мильон по нынешним временам цифра частовстречающаяся (если напугать хотел), это всего 10-30 человеколет, т.е. пара лет работы небольшому коллективу.
V>>В плане же быстродействия (раз о нем речь) заниматься полной отрицаловкой, как тут некоторых заносит, тоже не стоит, ибо это попахивает инженерным идиотизмом.
D>Ни в коем случае. Если с моих слов создается такое впечатление, то прошу прощения за то, что непреднамеренно ввел в заблуждение. Вопросами производительности занимаюсь практически постоянно, но не отношу их к оптимизации (см. определение).
Че-то бардак с терминологией. "Оптимизация" — это улучшение чего-то уже существующего. В свою очередь "улучшение" означает сдвиг в положительную сторону одной/нескольких координат вектора оценки решения. Если быстродействие входит в оценку, то увеличение быстродействия всегда есть улучшение. Если не входит — то это "ничего", т.е. потраченное впустую время разработчика. Если качество кода не входит в оценку (как это бывает на небольших задачах или внутренних проектах), то им можно и нужно жертвовать. Если наоборот, то сам понимаешь. А твое определение оптимизации как минимум странное.
Напоследок, скажу страшную вещь, но ты не бойся. При достаточно хорошей декомпозиции все задачи становятся небольшими, угу. А значит... (см. выделенное) Не могу не оговориться, что минимальную культуру кода соблюдать надо по-любому, но это должно быть на уровне мозжечка. А вот что касается "качества" и красоты решения в маленьких задачах-кирпичиках — см. пред. абзац. И тогда вы легко сможете доводить до рабочего состояния даже большие проекты, "оптимизируя" впоследствии лишь, что надо, и в порядке наибольших приоритетов. Просто современный ПО-бизнес очень скотский по-сути, и идеалисты/перфекционисты очень быстро отмирают за невостребованностью...
IT>Наивность в его возрасте и в должности преподавателя? Может здесь лучше подобрать другой "синоним"?
Ну да, не живет человек в нашем мире ПО-бизнеса, не обламывали ему начальники, заказчики и сорванные контракты рогов и не опускали с небес на грешную землю. Счастлив по-своему в своем параллельном мире, однозначно переживет нас всех. Что плохого-то?
И как ты ему прикажешь учить студентов? Преподавать, что реально требуется не качество решения, а сроки и умение "впаривать"? Нет уж, пусть лучше учит писать эффективные алгоритмы. Не использовать имеющиеся знания потом будет гораздо проще, чем использовать отсутствующие. Их и так будет макать в г-но пресловутого треугольника "деньги-время-качество" реальная многолетняя практика, и этому все-равно в теории не научишь. Да простят меня коллеги за выспренность, но преподаватель должен в первую очередь привить интерес к специальности, научить любить свою будущую профессию, лишь тогда будет хоть какая-то вероятность, что студенты чему-нить научатся в ВУЗе. Уверен, писать эффективные алгоритмы куда как интереснее, чем молотить десятки-сотни тысяч примитивнейших строк "бизнес-логики" (повторюсь, еще наедятся этого по самое не хочу), так что пусть пишут "интересненькое", грызут карандаши и ногти. А все эти наши обсуждения про "преждевременную оптимизацию", ИМХО яйца выеденного не стоят относительно процесса получения студентами фундаментальных знаний в области IT.
Здравствуйте, 0x7be, Вы писали:
0>Добрый день.
0>По опыту своих бесед с программистами, не знакомыми с linq, я собрал ряд стереотипных заблуждений и проблем с пониманеим linq, которые у них встречаются. В целом среди них преобладает такое мнение "это убогий SQL в С#, зачем он нужен?". Все попытки объяснить, что linq является воплощением аппарата операций над множествами, который ортогонален языку, и с необходимостью которого никто не спорит, сталкиваются с такой стеной непонимания. Это приводит меня к мысли, что linq подан неудачно. Его SQL-подобный синтаксис вызывает затруднения и у тех кто не знаком с SQL (выглядит больно непривычно) и у тех, кто знаком (не совсем понимают, что SQL делает в языке и сталкиваются с тем, что синтаксис всего лишь похож, а не повторяет SQL). Мое мнение по этому поводу: Linq — хорошая штука, но неудачно подан. Ваши мнения?
Есть такое. Дело не в том, что подан неправильно, а в том, что аудитория пока еще не готова, на мой взгляд.
Постоянно встречаю людей который на yield return смотрят с удивлением, не говоря о большем.
Здравствуйте, vdimas, Вы писали:
V>И как ты ему прикажешь учить студентов? Преподавать, что реально требуется не качество решения, а сроки и умение "впаривать"?
Битовыжимание и качество решения — это слегка разные вещи. Если бы Дворкин агитировал за последнее, то к нему вопросов не было бы совсем.
V>Нет уж, пусть лучше учит писать эффективные алгоритмы.
Битовыжимание и эффективные алгоритмы — это тоже слегка разные вещи.
V>Да простят меня коллеги за выспренность, но преподаватель должен в первую очередь привить интерес к специальности, научить любить свою будущую профессию, лишь тогда будет хоть какая-то вероятность, что студенты чему-нить научатся в ВУЗе.
Битовыжимание и любовь к профессии... ну ты понял.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, vdimas, Вы писали:
V>И что за манера поиска козла отпущения? Знаешь, охота на ведьм — это отличительная черта рунета, и этого сайта, в т.ч. В пылу спора походя присваивают оппоненту противоположное мнение и с треском его разбивают. Проблема только найти такого оппонента, что не так просто, ибо все обкатанные уже — где сядешь, там и слезешь... И вот он, Дворкин, ату его, ату!!! Фигли, он же сам же и напросился (хе, смелый, блин), а у нас как раз недостаток кого бы сжечь, прямо пальцы при виде клавы чешутся. И ты думаешь, Дворкина кто-нить вдумчиво читает? Да упрощают и выдергивают из контекста так, что у меня от такой молодецкой удали кофе бывает на клавиатуру разливается. Ситуация смогла зайти так далеко лишь потому, что Дворкина травят люди из админресурса, а он, судя по многолетнему наблюдению, до конца джентельмен. Т.е. там, где любой давно бы одернул увлекшихся коллег, возможно даже в грубой форме, он до конца пытается (вот наивный) вести осмысленный и порядочный диалог. А хрена толку, тебя в подворотне банда цинично насилует, а ты с ними уговорами...
Я не пытаюсь самоутвердится за счет кого бы то ни было. Павел Дворкин мне показался интересным оппонентом для полемики. Только я переборщил с провокацией и он ушел в "глухую оборону".
V>Понимаешь, во всех этих темах про конкретные решения, без контекста говорить не о чем. Я бы усилил — это суть глубокое нубство, обсуждать тонкости решений без контекстов и требований.
Да никто вроде контекста и не скрывает. Каждый делится своим опытом.
V>Дворкин практически всегда дает контекст, ровно как с тем же успехом это полностью игнорируется оппонентами. В стандартном местном шоу загонщики обычно приписывают словам жертвы универсальный характер, что ес-но обычно звучит провокационно... Но ведь именно это и требовалось, правда?
Я за творчеством Дворкина, честно говоря, не слежу. По поводу его битв с админами, просматривал один топик: было эпично.
А, так это на MVP summit'е было?
А то у нас коллега один тоже съездил на него, приехал, а толком рассказать ничего не может, говорит NDA в этом году ввели явное.
Здравствуйте, Димчанский, Вы писали:
Д>А, так это на MVP summit'е было?
Да.
Д>А то у нас коллега один тоже съездил на него, приехал, а толком рассказать ничего не может, говорит NDA в этом году ввели явное.
В этом году никаких отличий нет, саммит всегда под NDA был. И ничего сверхсекретного тоже особо не рассказывали. Просто перестраховка на предмет "вы обещали и не сделали".
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>В этом году никаких отличий нет, саммит всегда под NDA был. И ничего сверхсекретного тоже особо не рассказывали. Просто перестраховка на предмет "вы обещали и не сделали".
Потому и обидно, что вроде как ничего сверхсекретного, а закрыто за замком. Особенно, когда такие положительные отзывы о докладе.
А может можно в двух словах показать здесь почему мы не знаем/не понимаем LINQ?
Здравствуйте, Димчанский, Вы писали:
Д>А может можно в двух словах показать здесь почему мы не знаем/не понимаем LINQ?
Потому что за линком стоит довольно суровая математика, точнее пара разделов из теории категорий. Эрик просто привел это в качестве примера того, как хардкорная математика, при условии грамотного сахара, становится простой и понятной.
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
Здравствуйте, vdimas, Вы писали:
V>Ситуация смогла зайти так далеко лишь потому, что Дворкина травят люди из админресурса, а он, судя по многолетнему наблюдению, до конца джентельмен. Т.е. там, где любой давно бы одернул увлекшихся коллег, возможно даже в грубой форме, он до конца пытается (вот наивный) вести осмысленный и порядочный диалог. А хрена толку, тебя в подворотне банда цинично насилует, а ты с ними уговорами...
Чуть не выплеснул кофе на клавиатуру
Люди из адмнресурса вероятно более стойкие в среднем по контингенту сайта, не отчаялись и не прекращают вернуть его на путь истинный.
Здравствуйте, vdimas, Вы писали:
D>>Не совсем. Вопрос в стоимости рефакторинга. Я уже говорил о том, что неумное оптимизирование приводит к масштабному переписыванию кода. Это как раз об этом. Если требуется рефакторинг, затрагивающий, например, 25% кода приложения, как это назвать? Катастрофа.
V>Какой язык? Если С++, то да. Но, в свою очередь, С++ дает мощнейшие ср-ва для кодогенерации, для задания декларативных отношений м/у типами, типами и алгоритмами, алгоритмами и алгоритмами и т.д. Это уменьшает общую связанность, так что и надобность в таком глубоком рефакторинге обычно гораздо ниже ниже, ибо изначально имеющиеся ср-ва декомпозиции таковы, что даже и не снились тем же C#/Java/ObjectPascal.
Людей, которые понимают С++ на таком уровне раз-два и обчелся. Кроме того, напши ты хучь самый лучший код, через год-два его все равно придется рефакторить.
Ну дык, если действительно так, покажи инвесторам эту ветку и пусть меняют "архитекторов".
(см. выделенное) Не могу не оговориться, что минимальную культуру кода соблюдать надо по-любому, но это должно быть на уровне мозжечка. А вот что касается "качества" и красоты решения в маленьких задачах-кирпичиках — см. пред. абзац. И тогда вы легко сможете доводить до рабочего состояния даже большие проекты, "оптимизируя" впоследствии лишь, что надо, и в порядке наибольших приоритетов. Просто современный ПО-бизнес очень скотский по-сути, и идеалисты/перфекционисты очень быстро отмирают за невостребованностью...
Если нам не помогут, то мы тоже никого не пощадим.
