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

V> К чему это я, а к тому, что с возростанием уровня абстракции избыточность, неоптимальность, объем и т.д. кода растет в геометрической прогрессии.
Хм. Очень интересное мнение. А вот академик Ершов, например, считал путем к оптимальности т.н. смешанные вычисления. Все пересказывать не буду, но принцип — в том, что из более общего и абстрактного алгоритма можно получить более оптимальный для частного случая вполне детерминированным путем. А вот получить из алгоритма, оптимального в одном частном случае, алгоритм, оптимальный в другом частном случае почему-то в общем случае нельзя.
Это я к тому, что даже не учитывая оптимальность в разработке мы вынужденно приходим к необходимости введения абстракций как раз для уменьшения избыточности, неоптимальности, объема и т.д. кода.
Более того, это вовсе не теория. Как ни странно, редкий программист сейчас сможет существенно улучшить производительность, объем и.т.д. кода, который генерят современные компиляторы С++. А они, в общем-то, как раз и пользуются теми самыми теоретическими положениями, разработанными Ершовым и его последователями.

V> Когда появились персоналки, стоял крик, что это истина в последней инстанции, народ быстро повыбрасывал EC (IBM360). Сейчас вовсю используются терминальные версии, сервера приложений, в Нью Йорке, Мэр пробивает идею супер фрейма для города (а по домам и офисам, типа вообще системные блоки не нужны). Как Вам это, ничего не напоминает.
Да. Мне это напоминает маятник. Неизбежное свойство систем с ограниченной скоростью распространения взаимодействий. Никакого отношения к ООП это, увы, не имеет — ни за ни против.
V> Идем дальше, использавание интеллектуальных датчиков, контроллеров и т.д. IMHO с такой периферией остается только интерфейс.
Хм. То есть эти интеллектуальные датчики сами по себе соединятся в систему, которая будет делать что-то полезное? Очень интересно.
V> Идем дальше, компы Be (ветка от MAC), единственная разработка, которой в штатах, за всю историю, при презентации рукоплескали стоя. Да, они как-то втихаря загнулись (денег не хватило или задавили). Но ведь писюк в сегодняшнем виде себя исчерпал.
Это тоже интересное мнение. Я пока не вижу симптомов исчерпания писюка.
V> IMHO, должен быть качественный скачок (Be — было попыткой). Для этого правда надо пристрелить дядю Билли (жадный был наш дядя Билли, дети дядю не любили).
Это — тема отдельного рассуждения. Вкратце: ребята, Билли никому пистолет к виску не приставляет со словами "пользуйте ООП", или "... Windows" или еще что-то. Он также никак не виноват в том, что отечественная информатика находится в глубоком отверстии, по MTV гоняют попсу, а от программера Евпилдора ушла девушка.
V> Вполне возможно, этот скачок уже происходит. Что мы например знаем о технологиях и ПО той-же IBM. Те-же СУБД IBM держат 39% амер.рынка и никакого отношения к InterBase или Oracle (17%) не имеют.
Мы? Много знаем. Пока IBM не повернется к пользователям лицом, и не наймет хотя бы десяток спецов по юзабилити, потребительский рынок будет занят кем-то другим. Да, у них обалденные разработки в РСУБД. Почти все технологические особенности MS SQL 2000 присутствовали у них еще 10-20 лет назад. Но взгляните на MS SQL Query Analyzer, Profiler, и Enterprize Manager, а также на www.tpc.org, и вы получите адекватное представление о том, кто будет рулить enterprize сектором в 2010.
V>........
V> А если предположить, что качественный скачок будет (IMHO все предидущее развитие, со времени первых PC — все-таки колличественное), то вполне возможно ООП и идеями ООП там пахнуть и не будет .
Я думаю, что "закрыть" ООП уже не удастся. Да, программирование неизбежно изменится, но запах ООП все еще будет. Что, в ООП не пахнет модульным программированием?
V> В конце концов — переход линейное-структурное-ООП это на глобальном уровне, всего-лишь возможность создавать ПО все большими и большими толпами разработчиков, говорить о том, что это оптимальное или если хотите красивое (ну не технический термин — знаю) не приходится.
V>........
Ну, для начала, возможность создавать ПО большими толпами разработчиков — это принципиальное требование к современным технологиям программирования. Допустим у нас есть проект Хы. И оценка его трудоемкости — десять в четвертой человеко-лет. Если выбранная технология ограничивает количество одновременно работающих участников десятью, то про нее можно забыть сразу и навсегда. Даже если код будет оптимальнее, красивее, и.т.д. Хорошо было древним египтянам — строили себе Карнакских храм две тысячи лет, и не боялись, что конкуренты применят более совершенную технологию, или что заказчик перестанет испытывать в нем необходимость. А сейчас рулят не ассемблерные вставки, а TTM (time to market).
Красота кода — это понятие субъективное, потому я воздержусь от ее обсуждения до последнего .
А вот оптимальность — вполне измеримое. Я в свое время был изрядно потрясен тем фактом, что БПФ (быстрое преобразование фурье) имеет достаточно строгое математическое обоснование, неизвестное большинству программистов. И что есть способ построения таких алгоритмов. И что для него вовсе не требуется, чтобы количество элементов в массиве было равно степени двойки. Что оптимальность алгоритма зависит только от количества множителей в разложении этого числа (потому-то двойку так любят). Но эти факты невыразимы на ассемблере в принципе. Для того, чтобы воспользоваться ими, необходимо работать на значительно более высоком уровне абстракции.
V> Кто такой ЩАС программер, ну кто угодно, но не творец, чуть, что — иди читай MSDN, НУ ЧТО ЗА БРЕД, ГОСПОДИ. Это, ЧТО истина в последней инстанции, изучать тупые куски написанные левой ногой, чтоб подтвердить, что винда бозя всех бозь в последней инстанции.
Нда. Опять. Где ООП — и где МСДН? Хороший программист и сейчас — творец. Только для этого надо очень много чего прочитать. И, в частности, МСДН — потому, что матчасть надо знать. Не работаете под винду — читайте маны. В любом случае надо читать всяких Кнутов, Бучей, Александреску и иже с ними. Потому как одного знания алгоритма неполной разборки БТР-70 недостаточно для того, чтобы командовать даже взводом.