LINQ или foreach? Добрый день, коллеги по цеху!
Пишу высоконагруженные сервисы как для корпоративного сектора, так и для массового потребителя.
Стек технологий: от чистого Python-Perl-PHP до .NET и Java, не считая всяких 1С, SAP и прочего узкоспециализированного ПО.
В последнее время стал задавать себе вопрос: а не далеко ли мы, программисты, зашли в вопросе облегчения себе труда?
Я, как поклонник Entity Framework, Doctrine (и не только, вообще ORM), jQuery (XQuery и им подобные), в разумных, конечно, пределах, не могу избавиться от мысли, что облегчая себе работу (шаблонизаторы, фреймворки с генерацией кода, различные хелперы всех мастей) мы нагружаем сервера, которые и без того дороговато стоят (я даже не про стоимость железа, сколько про облачную инфраструктуру AWS, Azure, Google, DigitalOcean, вот Яндекс тут порадовал ценами на Облака на уровне почти как у AWS)?
Абстрагирование от реальности в области программирования в последние лет 10 идет к тому, что скоро бОльшая часть программистов просто забудет про стек, кучу, оптимизацию SQL-запросов, ведь MS, Oracle, Zend и независимые разработчики средств разработки ПО просто идут навстречу не оптимальному коду и закупке серверов в космических масштабах...
Вот, например LINQ или его аналоги в других языках... Скорость отработки запросов на LINQ существенно (в разы) ниже, чем прямой перебор коллекций, однако мы, разработчики, внедряем всякие умные Parallel LINQ или начинаем заниматься разделением потоков вместо того, чтобы не писать LINQ-запрос, а просто перебрать коллекцию...
Тоже самое относится в некотором роде и к jQuery - можно ведь написать все на чистом JS, применяя jQuery там где это нужно.
Мне всегда казалось, что использование технологии ради удобства чтения кода - это абсурд, посмотреть мои коды на Delphi 5-6-7 15-летней давности, так там все понятно и читаемо, код поддерживается, тесты проходят, однако там даже ORM-подхода нет, вообще половина на stored proc сделана, половина на прямом SQL, а уж про перебор коллекций в Object Pascal тех лет вообще молчу)
Рискуя на себя навлечь тонны ненависти и лучи коричневой радуги, все таки сделаю вывод, исходя исключительно из своей практики: неужели принцип “лучше день потерять, потом за 5 минут долететь” не работает в нашей отрасли? В большинстве случаев в моей практике, когда я получал какой-то код на доработку или участвовал в конкурсе на получение контракта мои конкуренты выдавали такие астрономические суммы по закупке серверных мощностей, что я их “уделывал” только на стоимости серверов: мои расчеты по серверам оказывались в 2-3-5 иногда в 10 раз меньше, чем расчеты конкурентов именно из-за архаичности моих подходов к экономии на стороне исходного кода и созданию баланса в решении, чтобы прежде всего экономить средства заказчика как сейчас так и на стадии поддержки проекта.
Кстати, если кто скажет про то что код на LINQ и прочих “упростителях жизни” проще тестировать, то тут возможно соглашусь, но ведь и тесты пишут программисты, пусть и называющиеся тестировщиками...
Программист, как мне кажется, это прежде всего инженер, а инженерный подход предусматривает создание оптимального, с точки зрения экономики, решения.
Это не значит, что я противник прогресса, но “лучшее - враг хорошего” тоже надо учитывать и не бросаться на все новомодные фишки, особенно если их навязывает производитель серверных мощностей (например MS со своим LINQ)
Так что, будем продолжать идти на поводу у гиков MS и Google, создающих фреймворки и прочие “удобные” решения для быстрой разработки или все-таки научимся сами “держать баланс”?
Кстати, для любителей вывести все в абсолют, скажу сразу: я не считаю, что раз я такой умный, то писать надо все на C и ASM, а лучше на перфокартах, чего уж там…
Еще раз подчеркиваю, инженерный подход! Экономим средства заказчика.
Am I wrong?

Предыдущий
вопрос Следующий
вопрос