хочу освоить c++

>в нормальном ООП таких задротских терменов просто нет, потому что типы там тоже являются полноценными объектами.

Причем здесь ООП?

>Я могу посоветовать книгу "Философия С++" Брюса Эккеля.

По-моему, она более ориентирована на C-программистов, которые хотят перейти на С++.

> ни ФП нормального

Ой, а в плюсах оно, стало быть, нормальное?

>Ой, а в плюсах оно, стало быть, нормальное?

Ну в плюсах хотя бы есть функциональные объекты и стандартная библиотека инструментов для работы с ними :).

<мечтательно> Эх, если бы в плюсах появились лямбды...

> Ой, а в плюсах оно, стало быть, нормальное?

За твои плюсы, чувак, ваще базара нет. Мы, вроде, начали про OCaml.

> Причем здесь ООП?

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

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

Понятно, значит слив.

Ты наркоман? А ну в сад, читать букварь по ООП.

>Ты наркоман? А ну в сад, читать букварь по ООП.

Вначале ответьте на два простых вопроса:

1) что общего generic programming имеет с OOP?

2) что является "нормальным ООП" (ответы вроде "как в Smalltalk/OCaml/VisualBasic" не принимаются)?

ООП обещает code reuse, но писать reusable code в ООП настолько сложнее чем не reusable, что никто этим не занимается. Поэтому в реальных проектах есть очень большая проблема с утеканием абстракций. А так как из за перегрузки и виртуальных функций там где раньше вызывался один код может начать вызыватся другой, а абстракции текут, грабли могут вылезать в совершенно неожиданных местах. Паттерны же - это костыли как раз направленные на уменьшение утекания абстракций, по их количеству можно судить о костыльности самой парадигмы. В то же время в Haskell'е мы наблюдаем только один паттерн - Монаду, или если обобщить Arrow. Правильный ОО дизайн сложнее, больше всего нужно учитывать чтобы потом не вышло боком, и сложнее потом этот дизайн реализовывать. Потому ООП так любят большие конторы, потому как нужно больше программистов, больше бабла, и они никогда не останутся без работы. ФП же гораздо проще, потому как там абстракции текут заметно меньше.

>ООП обещает code reuse, но писать reusable code в ООП настолько сложнее чем не reusable, что никто этим не занимается. Поэтому в реальных проектах

Видимо, вам просто не везло с "реальными проектами" :)

>так как из за перегрузки и виртуальных функций там где раньше вызывался один код может начать вызываться другой

Без виртуальных функций (т.е. без полиморфизма) ООП _невозможно_! Иначе это не object-oriented, а object-based programming. Обычная процедурщина с абстрактными типами данных.

>Паттерны же - это костыли как раз направленные на уменьшение утекания абстракций, по их количеству можно судить о костыльности самой парадигмы.

Скорее, о ее гибкости.

>Правильный ОО дизайн сложнее

Но он позволяет мыслить понятиями, более приближенными к предметной области, чем при использовании ФП (прошу не бить ногами, это мое ИМХО:)).

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

По-вашему, выходит, что большие конторы очень заботятся о заработке и трудоустройстве обычных программистов. Уверяю вас, это не так:). Большие конторы заботятся прежде всего о своих бабках, и если бы они могли экономить, нанимая меньшее количество работников, то они бы это делали.

>ФП же гораздо проще, потому как там абстракции текут заметно меньше.

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

1) что общего generic programming имеет с OOP?

Ничего. В полноценных языках вообще такого термина не возникает, потому что там programming всегда generic. Хоть в Smalltalk, хоть в Haskell, хоть в Питоне, хоть в лиспах, хоть где. А в плюсах для такой элементарной вещи потребовалась своя терминология, свой отдельный недоязычок и свои шизофреничные гуру, типа александреску. Этого не понимает только гсмное быдло, вроде тебя.

2) что является "нормальным ООП"

Нормальное - такое, при котором _любая_ сущность является объектом, в том числе, классы (они же типы) и методы (функции). Да-да, как в Smalltalk. А не как в твоём несуразном си с классами.

>Видимо, вам просто не везло с "реальными проектами" :)

Это не невезение, это то что неизбежно происходит когда проект вырастает больше некоторого размера. Это происходит раньше если пускать все на самотек.

>Без виртуальных функций (т.е. без полиморфизма) ООП _невозможно_! Иначе это не object-oriented, а object-based programming. Обычная процедурщина с абстрактными типами данных.

А вот в Хаскелле есть полиморфизм, но при этом весь код проверяется статически и на стадии компиляции известно что будет вызыватся. А еще там есть пользовательские типы и классы типов, но это не ООП. Но я с вами согласен, это необходимый для ООП костыль.

>Скорее, о ее гибкости.

Каким образом наличие паттернов свидетельствует о гибкости парадигмы?

> Но он позволяет мыслить понятиями, более приближенными к предметной области, чем при использовании ФП (прошу не бить ногами, это мое ИМХО:)).

Это позволяют пользовательские типы данных, которые много где есть, но при этом далеко не всегда ООП.

>По-вашему, выходит, что большие конторы очень заботятся о заработке и трудоустройстве обычных программистов.

Я имел ввиду аутсорсинговые конторы, которые как раз получают бабло пропорционально количеству программистов.

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

У меня опыт в С++/Java/Python ООП больше чем в ФП, поэтому я очевидно вижу его недостатки.

> <мечтательно> Эх, если бы в плюсах появились лямбды...

С помощью boost в плюсах можно организовать и лямбды. Недлинные (иначе можно утонуть в слабочитаемом коде), довольно костылеобразные, но, тем не менее, полноценные, а главное, очень быстрые лямбды. Так что я считаю, что C++ поддерживает и лямбда-программирование.

ЕМНИП, в бусте лямбды реализованы при помощи макросов, а это не Ъ :)

Увы, не полноценные. Они как замыкания не работают, контекст не спасают.

> Увы, не полноценные. Они как замыкания не работают, контекст не спасают.

Да, похоже тут я не прав. После беглого прочтения документации мне казалось, что boost умеет и замыкания, но сейчас промучался пару часов, пытаясь создать простейший счётчик, и не получилось...