OberonCore

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

Угу. Но иногда таки навелосипедить что-то своё оказывается правильней-быстрее. Т.е. например есть туча же всяких платных и бесплатных библиотек для sip+rtp+кодеки+работа с устройствами. Ну, т.е. в общем то остается только написать гуй. Однако оказалось что они все какие-то не такие. Т.е. навелосипедить своё оказалось банально быстрее и выгдней. Даже в очень краткосрочной перспективе (пара месяцев), в "среднесрочной" (год) стороннее решение вообще не вариант, как оказалось. Потому как нужен линук, winmo, и ещё черт знает что. А сторонние решения не могут или то, или другое + мутный цикл разработки. Что-то допилить там -- проблема. Особенно много проблем с коммерческими/закрытыми решениями. С опенсорсом всё намного проще и понятней.

Другой пример: необходима некоторая обработка (mining) HTML из произвольных источников. Всякого, не XHTML.
Сначала не хочется "с этой дрянью возится", в голове рисуется картина - взять какой-нибудь Gecko, загнать в него - и получить доступ к построенному DOM-дереву. Стоит начать влезать в Gecko, как дело ясное, что дело тёмное )) Неспроста уже второй API сделали, ибо первым никто не спешит пользоваться (у них там свой аналог COM-SOM навёрнут). Кроме того, браузерные ядра ориентированы на гуёвый запуск, у них неотъемлемо впаяны абстракции для рендеринга, парсер отдельно фиг выделишь.
Есть кое-какие решения, но они под-дотнетные.

Закапываться в Gecko ради этого это всё равно что закапываться в OpenOffice, если бы нам потребовалось вдруг искать по doc-файлам. И то и то бесперспективно. Существуют более вменяемые средства для этого

Сути дела это не меняет, даже если под один конкретный проект веса факторов выпадут в сторону КП. Даже в этой области уже есть выбор... и давно, коль скоро изменился подход к решению задач (еще совсем недавно, по моим меркам системщики практически для любой задачи разогревали паяльники и ...). Врочем о чем я... лет 15 назад такая хрень была и с GUI.

Открою Вам секрет: это только для поверхностного взгляда кажется, что прогресс что-то меняет. На самом деле происходит просто смещение, вытеснение - какие-то противоречия, проблемы удаётся вытеснить на другой уровень и т.п. Какие-то задачи сместились в область тривиальной рутины. Но неизменно то, что новые интересные задачи предъявляют точно такие же требования, какие предъявляли старые интересные задачи. Точно так же любая интересная задача потребует в какой-то момент полноценного программирования (параметризации готовых продуктов будет недостаточно). Точно так же за каким-то порогом сложности возникнет потребность в основательном программировании - и балансе качеств, заложенных в Виртовские языки. Ну и т.п. Всё неизменно.

Очень тяжело иметь дело с человеком, который все рассматривает с позиций "Раскин -Вирт", который стал законченным "сиськовиртом". Но в очередной раз , поясняю - в топике речь идет о КОНКРЕТНОМ выборе КОНКРЕТНОГО человеком КОНКРЕТНОГО инструмента для решения КОНКРЕТНОЙ задачи -то с чем регулярно сталкивается СТАНДАРТНЫЙ ГРАМОТНЫЙ СПЕЦИАЛИСТ - УПРАВЛЕНЕЦ... В действительности, ситуация сложнее при выборе учитываются этические аспекты решения связанные , например , с текущим составом группы, навыками... и т.д. Интерес примера, приведенного Веселовским - на мой взгляд - заключается в том, что даже в его случае, когда многими РЕАЛЬНЫМИ - требующими реального учета факторами можно пренебречь -выбор идет против ББ.

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

Есть подозрение, что как раз потому, что можно ими пренебречь, выбор и идёт по утоптанной, пусть сколь угодно витиеватой дорожке.

Поверьте управленцу, есть заботы поважнее, чем выбирать "КОНКРЕТНЫЙ инструмент для решения КОНКРЕТНОЙ задачи". И так не поступают в стабильных организациях с налаженным процессом. Единообразный набор инструментов и накопление компонентов на небольшом количестве (желательно на одном) языке важнее, чем сиюминутная оптимизация под задачу.

У Веселовского ситуация особая, да. Отдел макетов конкретно-технического характера (подготовить плацдарм для освоения компанией какой-то уже существующей технологии - ниши). Это не researches, а достаточно своеобразное занятие. И не обязывающее к накоплению чего-либо (проверил - на свалку).

Немного не так. Конкретные технологии по сути не важны. Важен результат. Есть некая идея некого продукта-услуги. Перед нами цель:
1) доказать что это реализуемо в принципе (за разумные сроки-ресурсы).
2) доказать что оно востребовано. Или опровергнуть.

А уж на существующих ли это решениях будет базироваться, или же на наших велосипедах, или вообще уникальных разработках -- никого не волнует.

Это разведка, исследование, research. Просто техническая составляющая тут вторична.

Программирование не ради программирования, а для достижения вполне конкретных результатов.

а) задачи разные бывают;
б) инструменты тоже бывают разные;
в) есть понятие экономической целесообразности, которое помимо выгод/потерь в текущем проекте рассматривает и перспективность освоения нового инструмента (перспективность и распространенность новых задач).
То есть, руководство должно помимо управления текущими делами... заглядывать в перспективу. Иначе может быть беда... которая любит приходить с разных сторон одновременно. Сократится объем финансирования; наиболее талантливым разработчикам надоест делать одно и то же с помощью все того же; завершится поддержка/развитие инструментария и т.д. и т.п.
По моим наблюдениям привязка к конкретным инструментам характерна для тех коллективов, которые нашли свою задачу и стригут потихоньку... заказчиков. Это рабы своего продукта, создания, сознания... Что-то мне подсказывает, что Вы не из их числа...