OOП, продолжение.
 

Существуют ли задачи которые можно решить с помощью ООП, но недоступные для функционального программирования ?

Простой, казалось бы, вопрос.
Есть примеры таких задач ?

Первое что приходит спонтанно на ум, что вообще-то операционки пишутся на чистом С, а там таких задач...!!! Однако подумав начинает почему казаться, что нет таких задач. Хотя может я чего то не знаю и не понимаю...и канешн по ходу понятно, что с ООП удобнее, код более красивый, более гибкий... А если не секрет, к чему такой вопрос? ;) Потому как начинают приходить мысли о подвохе.

Нет подвоха.
На вскидку я знаю пару пунктов, которые нельзя реализовать без ООП, не затратив много усилий. Но это моё мнение, мой опыт. Поэтому примеров приводить не стал, а спросил мнение окружающих.

Операционки это конечно хороший пример, но для написания ядра не требуется ООП. А вот оболочку и всё остальное писать можно уже на чём угодно имея АПИ.

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

Ну ты же сам себе и ответил - без дополнительных производственных затрат. Т.е. задач, которые бы нельзя было решить без ООП нет, но ООП значительно облегчает решение некоторого круга (значительного) всех задач. При этом ООП - не панацея. ООП создает свои "производственные расходы", только уже на уровне исполняемого кода. Вообще, ООП - это просто способ человека охватить своим мизерным умишком бесконечное множество сложностей реального мира. И чем раньше программист осознает бессилие своего мозга, тем более качественным программистом он становится, т.к. он начинает верить в программирование как в строгую систему контроля над собой.
ИМХО.

Наверное время пришло?! Пример в студию! А мы репки почешем. :) Полезнее будет, чем решать задачи с дурацкими шариками...

Я-то сам себе уже давно ответил =)) А хотел бы послушать мнение окружающих.
С самоконтролем я согласен полностью, а с "производственными расходами" - нет. Есть пример, когда "узким местом" в исполнении становится ООП? Мне кажется очень небольшой выигрыш в 99% задач.

Думаю хороший движок современной 3D-игрушки невозможно сделать чисто в ООП.
ЗЫ я не спец по игрушкам, поэтому спорить не собираюсь, просто имхо :)

Не трогайте шарики!!! В) Мне задачка очень понравилась. Особенно тем, что в ходе решения постоянно приходишь к неверному результату, пока наконец не вылезешь к верному.

Не сам ООП, а те действия (лишние), которые появляются при использовании ООП там, где этого делать не обязательно. Думаю, примеров можно найти в тырнете. Например, использование объектов вместо простых типов.

Вы. наверное, будете удивлены, но на Igf за 2007 год было несколько докладов об объектных моделях для 3д игр. Особливо там интеловцы распинались по поводу своей парадигмы (фабрики) для многопоточных игр, точнее для игр, которые должны использовать несколько ядер. Они предлагают разработчику игр использовать их модель в которой разработчик создает "действия" и инфраструктура сама эти действия синхронизирует, диспетчеризирует и т.д. Судя по графикам - выигрыш опупенный.