Так называемое "индустриальное" программирование, культивируемое мегакопорациями, плавно съехало с методик "как надо, чтобы получить результат" к так называемым "антипаттернам", то есть к объяснению того "как НЕ надо". Собственно говоря, такой переход сам по себе является провалом, хотя и не самой идеи индустриализации софтостроения, но методов ее проведения.

Вот на пороге стоит C# .NET версии 4.0. А основная промышленная версия у разработчиков по-прежнему 2.0. Куда же дели 3.0 и 3.5 (пламенный привет и почетная грамота от корпорации добра всем зубрившим матчасть 3.х)? Да просто слили в помойку. Тем самым подтвердив, что это были не самостоятельные версии, а переходные внутренние релизы, которые вместе с 2008 студией выпустили на широкий рынок с единственной целью подсобрать деньжат на пропитание. Это напрямую подтверждается отсутствием сертификаций и учебных курсов (то есть книг на тему "как надо") для нее.

С такими скачками разработка методик "как надо" - дело дорогое, хлопотное и, в итоге, выброшенное в помойку. Поэтому проще пойти по пути поиска "граблей". Мол, "как надо" мы еще не знаем, но что "так не надо" - это уже точно.

Поиск "антипаттернов" - задача исследовательская. Но со знаком "минус". Это поиск отрицаний. На нем не построишь фреймворков. Но эта работа востребована тем больше, чем чаще мелькают версии сырых релизов. И тем больше в сети профилей со значком MVP (Most Visible Professional)

Программисты-"путепроходчики" (картографы) ищут пути "как надо". Это позволяет им строить собственные фреймворки и реально индустриализовать софтостроение внутри команд и компаний. Но тогда приходится плотно "садиться" на версию выбранной платформы и мигрировать с нее лишь когда без того уже совсем не обойтись.

Вывел следующую формулировку по поводу языка С++ на базе относительно старого текста: "Достоинством является правило "если ты пишешь на С++, то априори ты не ламер". На самом деле это новая версия старого правила "настоящие программисты пишут на Си".

Оговорюсь сразу, целью очередной заметки серии не является "очернение светлого образа" сборщика мусора (GC - garbage collector) в средах программирования с автоматическим управлением памятью.

Computer Language Benchmarks - база данных по тестам на разных языках программирования

Коллега пишет программу, цитирую:

И была дискуссия на тему кризиса в софтостроении. И о сравнении, мол в железостроении все шоколадно. Ну, или почти. А в софтостроении не хватает аналогичного компонентного подхода. И тогда я подумал вот о чем.

Симптомы. В Delphi 2007 эта проблема вылезла на ровном месте после удаления/переноса некоторых файлов из пакета. Манипуляции проводились не из IDE, а в файловом менеджере. Аналогичный эффект наблюдался при обновлении директорий проекта на другом компьютере (часть файлов удаляется, часть добавляется).

Весьма полезна, например, при разработке с веб-сервисов.

Статьи:

Настроить использование очень просто. Вначале копируем файлы из каталога Help дистрибутива Delphi 7 в один из каталогов на локальном диске, например, в D7Help в домашней директории Delphi 2007. Потом конфигурируем инструменты, как показано на картинке

По крайней мере, отладчик Visual Studio 2005 считает именно так.