тема - Программирование/будь моя воля, я бы вообще ООП запретил.

/ответ писал в оффлайне, пардон, если не совсем в тему/
Тема, конечно, интересная. Хотелось бы спросить следующее - нафига вообще вы загоняетесь? У каждого метода и подхода есть свои плюсы и минусы. И программирование также может применяться для разных целей. Если для написания/воплощения чистых алгоритмов - то здесь (возможно) можно обойтись и без ООП - в контроллере лифтового механизма или привода дисковода оно вряд ли понадобиться :).

Но если понадобится создать что-то более глобальное, может быть уже такой вариант, когда процедурное программирование либо не пройдёт, либо будет приближаться к программированию объектно-ориентированному.

Как я понимаю, (применительно к C++) при достаточно большом количестве функций может возникнуть необходимости разделения области видимости, что может быть представлено префиксами (пример - D3DXVec3Add), namespace'ами, или классами.

Так же исходный код может быть разбит по смыслу на отдельные блоки, в которых ограничены области видимости, и есть статические переменные, которые не видны из других блоков/модулей (*.c, *.cpp). А разве это не есть вариант воплощения класса?

Что касается различных "наездов" на различные языки программирования. Во-первых, каждый язык предлагает инструментарий, более или менее направленный на какой-то специфический блок проблем. Я помню, что кто-то (кажется, это
был создатель EMacs :), хотя я в этом не уверен), осуждал практику, когда происходило повальное переучивание (где-то в 70х, кажется?) программистов с COBOL на C++, так как COBOL был ПРЕДНАЗНАЧЕН для работы с базами данных, а в
C++ это было нетривиальной задачей. Ряд современных языков ТАКЖЕ имеют свое специфическое направление - есть ведь Lisp, Perl, Python? Это ведь чисто абстрактные интерпретируемые языки, позволяющие легко рашать задачи, не генерируя машинный код! А строки в Паскале? Можно, конечно заниматься мазохизмом, и работать со строками в C++ "по-старинке" (я сам так и делаю), но сейчас уже часто под это делают классы, которые являются всё-таки довольно грубым и трудоемким воплощением того, что в Паскале уже встроено. Java, про которую здесь тоже упоминалось, тоже имела специфическую задачу, как я понимаю - верх кросплатформенности. И она, как я понимаю, этим языком выполняется, так как формат кода для всех систем одинаков, хотя и не соответствует ни одному реальному железу. Во-вторых, если неудобно пользоваться языком - не пользуйся! Только нафига его при этом объявлять "попсой" и "плохим языком"?

Что касается ассемблера, который здесь упоминался, я помню, видел то ли "аддон", то ли пакет макросов под MASM, который позволял использовать объектно-проектированное программирование в ассемблере. :) Вообще, последние варианты конкретно MASM, которые я видел, уже очень сильно приближаются к языкам типа Pascal и C++ - один макрос INVOKE чего стоит.

Вообще, меня задел наезд на Дельфи. Я с неё начинал работать, и, хотя сейчас сижу на Visual Studio 2003, и программлю под C++, ещё не встречал другого такого же удобного в работе инструмента. Кроме того, Паскаль (который здесь фиг знает почему обозвали), в том варианте, который используется в Delphi (хотя и оригинальный тоже был неплох), имеет ряд вещей, которые в C++ ОТСУТСТВУЮТ. это:
1) оператор with.
при его помощи можно временно расширить локальную область видимости так, чтобы в неё попали поля структуры. в C++ такого нет, можно использовать схожий вариант с ссылками (some_type& a), если структура многократно вложенная.

2) встроенный тип "set" - "множество" с логическими операциями.
можно объявить свой тип данных - enum, или ограниченный целый (в пределах каких-то чисел, например, от 2 до 63), а потом создать по нему множество в котором каждый из элементов может присутствовать, а может и отсутствовать :). В C++ такое надо делать при помощи классов и париться, хотя в C++ можно обойти встроенное паскалёвское ограничение на максимум 256 элементов во множестве. (во внутреннем представлении оно представлено битовым массивом размером до 32 байт).Обалденно удобная вещь - set of char - при написании, например строкового парсера им удобно задавать набр символов, которые, например, отсекаются.

3) property.
property - это открытое поле класса, каждое обращение к которому транслируется (на запись, считывание) компилятором (по выбору программиста) либо в вызов какой-то процедуры, либо в доступ к переменной. property может быть КАК БЫ виртуальным(многократно переопределяться), может ограничить доступ (т.е. не давасть записывать в поле, или
считывать из него). При помощи property в VCL(Visual Component Library) реализовали способ построения классов, при котором ПОЛНОСТЬЮ(90%) закрыт доступ к их содержимому - т.е. работа с классом осуществляется исключительно через методы (само собой, из-за использованиия property). Это правило сохраняется в большинстве классов VCL. Похожий (но не такой же)
механизм есть в COM, насколько я помню, но он не является встроенным механизмом C++; Отсутствие property как раз и представляет основную сложность при работе в C++ после Delphi. Для меня, по крайне мере.

4) в Delphi МОЖНО ВЗЯТЬ УКАЗАТЕЛЬ НА МЕТОД КЛАССА, НЕИЗВЕСТНОГО НА ЭТАПЕ РАЗРАБОТКИ!
Как я понимаю, в C++ эта задача принципиально неразрешима. в Delphi такой указатель объявляется как "function of object"; и занимает 8 байт - как я понимаю, 4 на метод, и 4 - на базовый указатель объекта.

5) Виртуальный конструктор. Фиг знает, каким образом он реализован, но он есть.

6) динамические методы. (dynamic)
в принципе, почто то же, что и виртуальные, но храняться в отдельной таблице динамических методов, в которой записаны только методы, ПЕРЕОПРЕДЕЛЁННЫЙ В ДАННОМ КЛАССЕ. т.е. - занимает меньше места, чем виртуальные, но больше времени уходит на вызов (лезет по родителям, если надо).

С ДРУГОЙ стороны, в C++ есть механизмы, которые принципиально невозможны в Delphi, это:

1) Макросы.
Хотя Microsoft и использует их активно, чтобы приблизить свои программы к чёрной магии, когда программа на практике оказывается совсем не тем, чем она кажется (попробуйте объявить в C++ проецедуру CreateWindow(), включить <windows.h> а потом вызвать эту процедуру! Получите ошибку о том, что "недостаточно параметров для макроса CreateWindow", хотя системная функция вообще-то выглядит как ФУНКЦИЯ а не макрос, и перегрузка функция должна (по идее) корректно срабатывать :)), макросы всё равно представляют собой очень мощный механизм, которого в Delphi нет, или есть в зачаточном состоянии -
директивами {$IFDEF} {$ENDIF}
2) template'ы.
очередная зубодробительная в применении фича языка. В Delphi отсутствует. В C++ неудобна (хотя и очень полезна время от времени) тем, что требуется создать экземпляр tempalte'а, чтобы его отладить. До тех пор ошибки в нём вообще ( как я помню) не обнаруживаются).
3) операторы.
В Delphi нельзя создать собственные операторы сложения и вычитания для своих типов данных. С другой стороны, в C++ есть ограничение на то, что оператор может создаваться только для КЛАССА - т.е. я не могу использовать их на типах, полученных через typedef.

4) множественное наследование.
в Delphi невозможно. Возможна реализация через включение.

5) битовые поля.
Возможность создать в структуре поле размером меньше байта, или равное, например, 9 бит. Microsoft
о таком, судя по всему, не подозревает, так как все виндовские многочисленные поля "ФЛАГОВ" нааамного было бы
объявить как раз таким типом данных. Вот пример воплощения поля Flags из
WIN32_FIND_DATA:
[fix]
union{
DWORD flags;
struct {
//#define FILE_ATTRIBUTE_READONLY 0x00000001
unsigned readonly: 1;
//#define FILE_ATTRIBUTE_HIDDEN 0x00000002
unsigned hidden: 1;
//#define FILE_ATTRIBUTE_SYSTEM 0x00000004
unsigned system: 1;
//#define FILE_ATTRIBUTE_DIRECTORY 0x00000010
unsigned rsvd: 1;
unsigned directory: 1;
//#define FILE_ATTRIBUTE_ARCHIVE 0x00000020
unsigned archive: 1;
//#define FILE_ATTRIBUTE_DEVICE 0x00000040
unsigned device: 1;
//#define FILE_ATTRIBUTE_NORMAL 0x00000080
unsigned normal: 1;
//#define FILE_ATTRIBUTE_TEMPORARY 0x00000100
unsigned temporary: 1;
//#define FILE_ATTRIBUTE_SPARSE_FILE 0x00000200
unsigned sparse_file: 1;
//#define FILE_ATTRIBUTE_REPARSE_POINT 0x00000400
unsigned reparse_point: 1;
//#define FILE_ATTRIBUTE_COMPRESSED 0x00000800
unsigned compressed: 1;
//#define FILE_ATTRIBUTE_OFFLINE 0x00001000
unsigned offline: 1;
//#define FILE_ATTRIBUTE_NOT_CONTENT_INDEXED 0x00002000
unsigned not_indexed: 1;
//#define FILE_ATTRIBUTE_ENCRYPTED 0x00004000
unsigned encrypted: 1;
}file_attrs;
};[/fix]

Это краткое сравнение языков не говоря уж об удобстве интерфейсов, справочной системе, а также размере минимального приложения под Win32(WinAPI) - в Дельфи - 16 кб (зависит от версии), в C++ (если не извращаться) - 40 кб. Если извращаться, то 4 кб, но нужно будет попариться и "открутить" стандартную библиотеку, что кое-кому может и не быть "по зубам".

2 Ortodox_programmer, Silly Cat:
Знаете, я читал то, что вы тут понаписали, и у меня действительно мысль была о том, что тут без грибов не обошлось :). Я, например, не вижу связи между ООП и тем, что вы понаписали про Гитлера, Сталина, заговор против России и т.д. и т.п.. По-моему, с таким же успехом можно было бы обвинять, допустим, микроскоп в начале второй мировой войны.

ООП - это инструмент. А инструмент не может нести пользу или вред сам по себе - это зависит от того, кто и в каких целях его использует. (Молотком можно забивать гвозди, а можно и кого-нибудь им стукнуть, например :))

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

Вообще, ИМХО, вопрос стоит о типе мышления - процедурный код предполагает чисто алгоритмический тип + логический(кто чего после чего сделал), а ООП предполагает мышление абстрактное/образное - т.е. построение объектных моделей. А уж на вопрос "КАК ЛУЧШЕ ДУМАТЬ" каждый уж точно ответить по-своему.

И, по сему, ИМХО, попытка запретить использовать ООП есть попытка запретить мыслить образами/символами, то
есть изначально бессмысленна.

P.S. Ещё раз пересмотрел форум и наткнулся на фразу:

Что их, да, можно будет использовать другим программистам. Но что ВНУИРЕННОСТЬ этих объектов БУДЕТ ДЛЯ НИХ НАВСЕГДА И ПОЛНОСТЬЮ ЗАКРЫТА!!!!!
Это полностью аналогично тому, как в этой стране имела хождение идея ВЦКП....

Извиняюсь, но причём тут ВЦКП? :) Идея-то состояла в том, чтобы класс с точки зрения программиста приближался к той абстрактной концепции, которую он представляет, и программист не забивал себе мозги фигней касательно того, как эта концепция была воплощена. :) Просто - ДЛЯ УДОБСТВА РАБОТЫ! И нечего тут "идею заговора" раздувать...