Об изобретении велосипедов и "готовых" решениях

[metaclass]

Как известно, страшным грехом в современном программировании считаются синдром NIH, изобретение велосипедов и попытки решить уже решенные задачи, а уже нахождение новых задач - страшнейшее богохульство, на уровне осквернения могил и нежелания смотреть олимпиаду по телевизору.
В связи с этим, в своих дотнет-проектах я стараюсь использовать два стандарных инструмента: MSBuild для сборки и t4 для генерации повторяющегося кода.
Так вот, если первый всего лишь содержит мелкие странности (типа считает переменные окружения своими переменными, но не передает автоматически свои обычные переменные, если вызывает сам себя и не содержит внятных средств организации подпроцедур - т.е. области видимости переменных в нем - это ad-hoc ад писанный людьми, которые никогда не читали SICP), то второй - это теоретически правильное, но неудобное при разработке дичайшее безумие.
И я уверен, что аналогичный темплейтер, сделанный на clojure, был бы намного понятнее, нежели "готовое" решение.

Comments

[jakobz.livejournal.com]

Вот это вот любимое мое про msbuild. TLDR: во всех студиях инкрементальный билд отключен грязным хаком

    
  <!--
    ================================================================
                                        _ComputeNonExistentFileProperty

    There are certain situations in which we want to always run the CoreCompile target (and
    thus the Csc task), even if the timestamps of the outputs appear to be up-to-date on disk.
    If we're inside the IDE during design-time, then the Csc/Vbc/Vjc task is simply being used to
    initialize the host compiler, so we always want to run it.  Also, if we're inside the IDE, and
    the host compiler is responsible for doing the compilation during an actual build, we want to let
    the host compiler determine whether the output is up-to-date, because there may be source files
    in the IDE's in-memory buffers that we don't know about.

    So, we always run the CoreCompile target if we're in the IDE, and either we're in design-time or
    we're delegating to the host compiler for the actual build.

    We compare against BuildOutOfProcess != true because we cannot assume that the build process will 
    have set BuildOutOfProcess to true or false. Therefore the default behavior should be to do the 
    legacy behavior seen before BuildingOutOfProcess was introduced if the property is not set.
    ================================================================
    -->
  <Target
      Name="_ComputeNonExistentFileProperty"
      Condition="('$(BuildingInsideVisualStudio)' == 'true') and ('$(BuildingOutOfProcess)' != 'true') and (('$(BuildingProject)' == 'false') or ('$(UseHostCompilerIfAvailable)' == 'true'))">

    <PropertyGroup>
      <NonExistentFile>__NonExistentSubDir__\__NonExistentFile__</NonExistentFile>
    </PropertyGroup>

  </Target>