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

PD>Собрался наконец написать. Минусов мне за эти тезисы поставят, это уж точно.
Это вряд ли. Наоборот, правду-матку режешь.

Тут флейм уже заполыхал вовсю на тему проведения границы между тем, когда оптимизировать вредно, и тем, когда это необходимо.
Кратко выскажу несколько мыслей на заданную тему:

• Не стоит бояться того, что программисты определенного склада "вымрут". Программистов порождает среда. Когда среда приветствовала нердов — программерами были нерды. Сейчас есть и нерды, которые живут на работе, иногда высовываются в сеть, а живых людей видят только на коференции. Есть и "индусы" — малоквалифицированные люди, которые покрывают потребность в "давай-давай", "нам некогда учиться — надо сдать систему вчера", "если у тебя есть рабочий кусок кода — скопируй его целиком" и так далее. Есть также промежуточное звено — люди, не испытывающие коммуникативных проблем, у которых есть некомпьютерные хобби, но при этом они любят свою работу и стараются делать ее хорошо.
  И все это — исключительно потому, что есть потребность в каждой из этих категорий. Напоремся на потолок производительности — те же индусы научатся писать эффективные программы. Ну, не все, а кроме 99% не сумевших и вымерших
  
• Собственно, о самой эффективности. С одной стороны, я полностью согласен с теми, кто придает максимум значения экономии времени программиста. Ребята, время, когда можно было годами полировать текстовый редактор в одиночку, кануло в лету. Сейчас у нас нет времени на эту ерунду. Нам надо удовлетворять потребности бизнеса очень быстро. В первую очередь это означает переход к групповой разработке. Да, до сих пор очень редко в природе встречаются команды численностью более 10 человек. Я подозреваю — из-за технических и организационных проблем. Любой наш заказчик будет счастлив сократить время разработки вдвое. Кроме этого, большое значение имеет стоимость поддержки.
  Резюме: понятность программы сейчас значительно важнее ее эффективности (в большинстве случаев!). Соответственно, рулят платформы, которые позволяют писать более понятные программы. Рулят платформы, которые предоставляют исчерпывающую информацию об ошибках, а не Сore Dump. Рулят платформы, которые выполняют рутину за разработчика. Чтобы он мог сосредоточиться на написании действительно существенной части. Потому что ему надо будет писать (а его коллегам читать) меньше кода.
  
  Тем не менее, я тоже испытываю дискомфорт, глядя на неэффективности на ровном месте.
  
  В итоге, я свожу свою мысль к следующему замечанию:
  — нельзя ставить эффективность во главу угла. Она не является приоритетом
  — Это не значит, что стоит применять заведомо неэффективные решения.
  Этого простого правила, я считаю, должно быть достаточно. Остается только тонкость с этим "заведомо". (Это слово, кстати, встречается в тексте статьи 273 УК РФ). Тут каждый решает для себя. Главный критерий — насколько дорого обойдется применение альтернативного решения. Если чувствуешь, что объем работ вырастает больше, чем на 20%-50%, то лучше забей. Если стоимость примерно одинакова — применяй лучшее.
  
  Отдельный разговор надо завести об архитектуре. Premature optimization касается только микро-уровня. Если вдруг в саму архитектуру не было заложено возможности по повышению эффективности, то выполнение mature optimization может оказаться postmature, т.е. слишком поздним. И это сведет полученную экономию средств к нулю.
  
  
• Ну, и последнее замечание: Очень важно правильно применять оптимизации. В предыдущем пункте я упоминал про неиспользование откровенно неэффективного кода. В большинстве случаев это будут мелкие глупости, вроде вызова new в цикле или ресайза динамического массива на 1. Так вот, на каждой платформе эти хитрости — свои. И ни в коем случае нельзя переносить привычные методы в другую среду. В дотнете new может означать всего лишь очистку памяти. Округление размера выделяемых объектов до "круглых" типа 32, 64 в дотнете контрэффективно — аллокатор сам разберется с выравниванием, а увеличение размера ускоряет забивание хипа и учащает сборку мусора.
  
  Поэтому для выполнения пункта 2 просто необходимо тщательно изучать среду, в которой работаешь. Чтобы, например, нутром чуять, что
  

  ...(string a, string b, string c)
  {
    return "Hello" + a + b + c;
  }

  
  — эффективно, а за
  

  ...(IEnumerable<string> strings)
  {
    string s = string.Empty;
          foreach(string a in strings) s=s+a;
      return s;
  }

  
  надо бить линейкой.