Здравствуйте, IB, Вы писали:

_>>а желанием защитить свою точку зрения, даже если всем (включая наверное уже и тебя самого) очевидно, что она не верна.
IB>Да, только этим я и могу объяснить ваше странное упорство )

Тут стоит посмотреть, от чего отталкивается alex_public, он это повторяет в разных сообщениях явно и не явно.

Возникает ощущение, с его слов, что экономика проекта это вещь недостойная рассмотрения. Единтсвенно, что стоит рассмотрения, это производительность и расход ресурсов. Других критериев эффективности он не учитывает. Подход к разработке в его понимании не зависит от бюджета — сначала задау эстимируем, а потом пилим столько, сколько нужно. Архитектуру у него "получается" продумать лет на 10 вперёд. И любую вещь можно ускорить на низком уровне.
Это все с его слов в разных сообщениях в разное время.

Соотсветсвенно, если применить это "на практике", выходит, что императивный низкоуровневый подход действительно единственно возможный вариант. На самом деле это действительно работает, кто бы спорил — любой кусок кода можно доработать для частного случая руками и ускорить от процентов до сотен и тысяч процентов. Хоть в БД, хоть на клиенте.

Все аргументы, скажем, Синклера, они про экономику проекта на самом деле — опимизировать так, как предлагает alex_public, слишком дорого и непредсказуемо.

Соответсвенно, у него не бывает неожиданных изменений требований, потому что он де выдал архитектурное решение на 10 лет вперёд и аргмент "каждый первый случай модификации структуры" для него просто пустой звук.

Почему так выходит ? Потому что экономика не учитывается, она отдельно от всего остального.

На самом деле то, о чем говорит alex_public действительно было в разработке, в 90е и где то даже в начале нулевых — понавставляли ассемблерных вставок и всякой низкоуровневой механики и всё стало классно.

Именно поэтому Linq это неэффективная вещь — руками можно выжать больше. А сколько это времени займет и какой будет майнтенанс — дело десятое, экономика не в счет. Раз нету проблемы с архитектурой, то можно и строчки склеивать. Соответсвенно преимущество Linq в плане разделение концепций никакое не преимщуство.

В целом он тащит эти манты из сообщения в сообщение. До кучи уже отдельные особенности, где alex_public называет query comprehension Linq, путает реализацию с интерфейсом, видит рефлекцию там где её нет и до кучи начинает обвинять собеседника в чем угодно.

В целом же, если сделать вот те предположения, получается вполне себе стройная картинка. Другое дело, что прогресс лет двадцать назад пошел совсем по другому пути. А то бы и писали по сей день на плюсах с ассемблерными вставками и даже БД программировали так же — в реквест уходил бы С++ или сами ассемблерные вставки.
А что, вполне логично, если каждый программист это эдакий Developer God или Goddes, то нет никакой проблемы за время 0 написать код любой сложности.

Разница на самом деле в экономической целесообразности. Вот эту часть, возникает ощущение, он как будто или не слышит, или не понимает.