Оберон-клуб «ВЄДАsoft»

Том Курц: Сейчас я пытаюсь изучить некоторый язык, якобы являющийся «объектно-ориентированным». Справочное руководство отсутствует — во всяком случае, я его не нашёл. В тех справочниках, которые есть, приводятся весьма тривиальные примеры, а 90% места посвящено утверждению превосходства ООП над другими «религиями». Некоторые мои знакомые посещали курсы С++, полностью несостоятельные с точки зрения преподавания. По моему мнению, ООП — один из величайших обманов общества. Все языки разрабатывались для определённого класса пользователей, например Фортран — для мощных числовых расчётов, и т.д. ООП разрабатывалось затем, чтобы его потребители могли претендовать на высшее знание, недоступное посторонним. Правда в том, что единственным существенным аспектом ООП является метод, придуманный десятилетия назад: инкапсуляция подпрограмм и данных. Всё остальное — украшательство.

Считаете ли вы современный Visual Basic компании Microsoft полноценным объектно-ориентированным языком, и если да, то одобряете ли вы этот его аспект (с учётом вашего неприятия парадигмы ООП)?

Том: Не знаю. Несколько простых опытов, которые я провёл, показали, что работать с Visual Basic относительно легко. Сомневаюсь, что кто-либо за пределами Microsoft воспринимает VB как объектно-ориентированный. Фактически, True BASIC в такой же, если не большей мере, как VB, является объектно-ориентированным языком. В True BASIC есть модули, представляющие собой совокупность подпрограмм и данных, и они обеспечивают главную характеристику ООП, а именно инкапсуляцию данных. (В True BASIC нет наследования типов, поскольку типами, определяемыми пользователем, могут быть только многомерные массивы. И едва ли какой-либо язык поддерживает полиморфизм, поскольку на деле он требует интерпретации на этапе исполнения.)

Вы сказали, что Visual Basic обладает некоторыми серьёзными ограничениями в сравнении с True BASIC. Вы имеете в виду, что в Visual Basic нет чего-либо похожего на вашу систему модулей?

Том: Не знаю. Я всего лишь написал несколько тренировочных программ — фактически, я ничего не писал на Visual Basic. Я просто убедился, что смог бы это сделать. У этой системы достаточно простой интерфейс пользователя — в отличие от других, с которыми я пробовал работать. Visual Basic — это тот же старый Microsoft Basic, который они пытаются выдать за объектно-ориентированный, всего лишь добавив инструмент для построения визуального интерфейса.

Если бы сегодня вам пришлось заново создавать язык для обучения программированию, был бы он похож на Бейсик?

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

В ООП вас привлекает инкапсуляция?

Том: Совершенно верно. Обычно я говорил, что инкапсуляция составляет 70% того, что полезно в ООП, но сейчас я готов увеличить эту долю до 90%. Главное — объединить программы с их данными. Это действительно важно. Я теперь мало пишу программ, но когда я работал с True BASIC, то полностью полагался на инкапсуляцию.
У нас была возможность инкапсулировать группы подпрограмм в так называемые модули, что то же самое, только объединяет подпрограммы, и они отделяются от остальной программы, связываясь с ней только цепочкой вызова. Фактически, у них были свои закрытые данные. Это оказалось очень удобным для отделения функциональности и всего такого.

Язык Java предназначен исключительно для объектно-ориентированного программирования. Есть ли ситуации, в которых код на Java оказывается из-за этого сложнее, чем соответствующий код на С++, использующий возможности обычного программирования?

Бьёрн Страуструп: Пожалуй, создатели Java — а в ещё большей мере те, кто продвигал его на рынке, — придавали ООП такое большое значение, что дошли до абсурда. Когда Java только появился, обещая скромность и простоту, я высказал предположение, что в случае успеха Java значительно увеличится в размере и сложности. Так оно и случилось.
Например, необходимость приведения типа Object для того, чтобы получить значение из контейнера (вроде (Apple)c.get(i)), оказывается нелепым следствием невозможности установить тип объекта в контейнере. Многословно и неэффективно. Теперь, с некоторым опозданием, в Java появились средства обобщённого программирования (generics). Другими примерами возросшей сложности языка (всё для удобства программистов) служат перечисления, отражение и внутренние классы.

Факт то, что сложность всё равно где-то проявится, — если не в конструкции языка, то в многочисленных приложениях или библиотеках. Аналогичным образом, навязываемое Java размещение любого алгоритма (операции) в классе приводит к таким нелепым вещам, как классы без данных, состоящие только из статических функций. Всё же в математике неспроста пишут f(x) и f(x,y) , а не x.f(), x.f(y) или (x,y).f(); в последнем случае делается попытка представить «подлинный объектно-ориентированный метод» с двумя аргументами и избавиться от несимметричности, свойственной x.f(y) .

В С++ многие проблемы логики и обозначений объектной ориентации решаются сочетанием абстрагирования данных и методов обобщённого программирования. Классическим примером служит vector<T>, где Т может быть любым типом, допускающим копирование, включая встроенные типы, указатели на ОО-иерархии и пользовательские типы, такие как строки и комплексные числа. И всё это достигается без дополнительной нагрузки на вычислительные ресурсы, наложения ограничений на структуры данных или особых правил для стандартных библиотечных компонентов. Другой пример, когда классическая модель ООП с единичной диспетчеризацией оказывается неудовлетворительной, это операция, требующая обращения к двум классам, скажем operator*(Matrix,Vector), и не являющаяся обычным «методом» какого-либо из классов.

Одно из фундаментальных различий между С++ и Java состоит в способе реализации указателей. В некотором смысле можно сказать, что в Java нет настоящих указателей. В чём разница между этими двумя подходами?

Бьёрн: Нет, конечно, в Java есть указатели. На самом деле, там почти всё неявно оказывается указателем. Просто там их называют ссылками (references). В том, что указатели неявные, есть свои преимущества и недостатки. Попутно отмечу, что наличие подлинно локальных объектов (как в С++) также имеет как преимущества, так и недостатки.

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

Рассмотрим различные издержки, связанные со структурой. В С++ vector <complex>(10) представляется как структура, содержащая массив из 10 комплексных чисел и хранящаяся в свободной памяти. В сумме это составляет 25 слов: 3 слова на вектор, 20 слов на комплексные числа и 2 слова на заголовок массива в свободной памяти (куче). Аналогичная структура в Java (определённый пользователем контейнер для объектов определённого пользователем типа) займёт 56 слов: 1 для ссылки на контейнер, 3 для контейнера, 10 для ссылок на объекты, 20 для объектов и 24 для заголовков в свободной памяти 12 независимо размещаемых объектов. Очевидно, это приблизительные расчёты, поскольку стоимость размещения в куче определяется в каждом языке отдельно выбранной в нём реализацией. Тем не менее вывод ясен: благодаря повсеместному и неявному использованию ссылок в Java, возможно, удалось упростить модель программирования и сборку мусора, но расход памяти при этом резко вырос — и соответственно выросли стоимость доступа к памяти (осуществляемого более косвенным образом) и расходы на выделение памяти.

Чего в Java, к счастью, нет, так это допускаемого Си и С++ неправильного применения арифметики указателей. Но и эта проблема решается, если корректно писать код на С++, используя такие высокоуровневые абстракции, как потоки ввода/вывода, контейнеры и алгоритмы, а не занимаясь вознёй с указателями. В сущности, все массивы и значительная часть указателей относятся к нижним уровням реализации, с которыми большинство программистов не имеет дела. К сожалению, повсюду немало и скверного кода на С++, без всякой надобности действующего на низком уровне.

Есть, однако, важная область, где указатели и действия с ними оказываются большим подспорьем: прямое и эффективное описание структур данных. Ссылок Java здесь оказывается недостаточно: например, с их помощью не опишешь операцию swap. Другой пример — простота непосредственного доступа к реальной памяти с помощью указателей: в любой системе должен быть язык, который может это делать, и часто им оказывается
С++.

«Отрицательная» сторона наличия указателей (и массивов в стиле Си) — это, конечно, возможность злоупотреблений: переполнение буфера, указатели на удалённую память, неинициализированные указатели и т.п. Но если корректно писать код на С++, всё не столь страшно. Эти проблемы с указателями и массивами не возникают, если они употребляются внутри таких абстракций, как vector, string, map и т.д. Управление ресурсами с использованием областей видимости снимает большинство проблем; с остальными обычно можно справиться с помощью умных указателей и специальных дескрипторов. Те, кто привык работать на Си или придерживается старого стиля в С++, с трудом верят тому, что управление ресурсами на основе областей видимости представляет собой исключительно мощный инструмент, который при определении пользователем для соответствующих операций может решать классические проблемы с помощью меньшего объёма кода, чем старые и ненадёжные хаки. Вот, к примеру, простейший вид классического переполнения буфера, создающего угрозу безопасности:

char buf[MAX_BUF]; gets(buf); // Yuck!
При использовании стандартной библиотеки string проблема исчезает:

string s;
cin >> s; // чтение символов, среди // которых есть пробельные

Это тривиальные примеры, но подходящие «строки» и «контейнеры» можно придумать практически для любых задач, а начать полезно со стандартной библиотеки.

Насколько нас удовлетворяет ООП? Нельзя ли попробовать что-то ещё, найти или добавить какие-то вещи, которые позволят упростить процесс создания крупных систем?

Брайан: ООП очень полезно в некоторых ситуациях. Если вы пишете на Java, у вас просто нет другого выбора; если вы пишете на Python или С++, можете применять ООП или отказаться от него. Мне кажется, что это правильная модель: в зависимости от конкретного приложения можно использовать ООП или нет. По мере развития языков, несомненно, появятся другие механизмы формирования модулей вычислений и структурирования программ.

Если взять СОМ, объектно-компонентную модель Microsoft, то она основана на объектно-ориентированном программировании, но не ограничивается этим, потому что компонент — не один объект, а целая их группа. Как организовать такую систему более упорядоченным образом, чем это сделано в СОМ, чтобы получить лучшее представление об имеющихся в ней связях?
Нужны механизмы для работы с большими количествами объектов. В результате роста размеров программ или объединения в них разнородных частей мы сталкиваемся с весьма сложными структурами объектов.

Простота. Ко времени появления Явы чрезмерная сложность Си++ уже вполне осознавалась сообществом программистов. В языке Ява многие сложные и запутанные механизмы Си++ были отвергнуты. Однако, объективные данные, характеризующие сложность языков, показывают, что тезис о том, что Ява существенно проще Си++, не вполне оправдан. Результаты этих исследований будут приведены далее. Да и вообще, разве можно назвать простым язык, спецификация которого — это книга объемом более 700 страниц. Кроме того, многие из программирующих на Си++ в действительности используют его просто как «улучшенный» Си, не применяя объектных возможностей. В то время как писать программы на языке Ява, не освоив объектно-ориентированного подхода, затруднительно. А методология ООП отнюдь не проста.

Объектная ориентированность. Стремление разработчиков Явы к чистой объектной ориентации, своего рода объектный экстремизм лишили язык ряда полезных свойств.
Программа на Яве состоит только из классов. Отсутствует понятие модуля. Из-за этого классы играют две совершенно разные роли. Во-первых, класс — это тип объектов, во-вторых — контейнер, содержащий описания статических данных, не имеющих никакого отношения к объектам данного класса. Такое объединение представляется противоестественным, трудным для понимания и объяснения и концептуально ущербным.
Все, кроме элементарных данных, — объекты. В том числе строки. Это уже не просто массивы символов. Записать s [i], чтобы получить i-й символ строки s нельзя. Нужно отправить объекту s сообщение: s. charAt (i) . Уровень абстракции при этом, конечно, повышается, но насколько это оправданно?
Все объекты существуют только в динамической форме. Память для них распределяется в куче. Неоправданным представляется отказ от простого и эффективного статического и автоматического (стекового) распределения памяти под массивы и записи (структуры, объекты), что является одной из причин снижения эффективности Ява-программ.
Часто говорят, что в Яве нет указателей. Правильнее было бы сказать, что нет арифметики указателей. А переменные-массивы и переменные-объекты представляют в Яве именно указатели на массивы и указатели на объекты. Поэтому, например, массив из массивов оказывается не матрицей, а массивом из указателей на массивы. Особой гибкости это не добавляет, а неудобства и путаницу создает. Многомерные массивы в обычном понимании стали вообще невозможны.
Все это издержки «чистой» объектной ориентации.

Надёжность. Переняв принцип строгой типизации от языков, происходящих от Паскаля, Ява действительно обеспечивает высокую надежность при обращении с данными. Но проявила себя ненадежность иного рода.
Первые реализации технологии Ява (компилятор, виртуальная машина, библиотеки) не были избавлены от ошибок. Система в целом оказалась довольно громоздкой. Виртуальная машина языка Ява выполняет непростые функции. Кроме собственно интерпретации байт-кода должна обеспечиваться динамическая загрузка классов по сети, контроль безопасности и т. д. Все это делает реализацию виртуальной машины для различных платформ не слишком простой задачей. Библиотеки, составляющие интерфейс прикладного программирования (API — Application Programming Interface) и являющиеся важнейшим компонентом технологии, также весьма сложны. В их составе заметную долю составляют так называемые
«родные методы» (native methods) — подпрограммы, существующие в виде машинного кода того процессора, на котором работает виртуальная машина. Такие методы программируются, как правило, на языке Си (виртуальная машина по заявлению ее разработчиков также запрограммирована на ANSI Си) и должны отлаживаться отдельно для каждой реализации виртуальной машины. Встраивание виртуальной машины в браузеры также сопряжено с возможностью внесения ошибок.
В результате пришлось столкнуться с тем, что отладка программ на языке Ява, в частности аплетов, была сопряжена с преодолением ошибок и нестыковок новой технологии. Методом проб приходилось находить решения, которые бы приемлемо работали в различных браузерах. И тем не менее полной уверенности в работоспособности аплетов в любой среде так и не возникало.
Проблемы сохранялись и через пять лет после появления технологии. Вот показательный пример. В январе 2001 года я несколько раз заглядывал на страницу веб-сервера компании Sun, посвященную истории языка Ява (http://java.sun.com/ features/1998/05/birthday.html). Из трех имевшихся на этой странице аплетов работали только два. Третий аплет, иллюстрирующий сортировку, не загружался (сообщение «load: class Sortltem not found»). И это происходило на сайте компании — автора технологии, с одним из первых написанных на Яве аплетов! Именно этот аплет был продемонстрирован на одной из первых презентаций технологии Ява и, как говорится на упомянутой странице, произвел на участников презентации неизгладимое впечатление.

Независимость от архитектуры и переносимость. Безусловно, язык Ява машинно-независим, не привязан ни к какой конкретной платформе. Но получить программу, которая бы одинаково работала в любой среде, оказывается не всегда просто. Я уже упоминал трудности, с которыми пришлось столкнуться при отладке аплетов в среде различных браузеров. Довелось также слышать мнения разработчиков корпоративных информационных систем, которые были вынуждены отказаться от использования Явы для создания программного обеспечения клиентских рабочих мест. Они столкнулись с тем, что одинакового поведения на разных платформах удавалось добиться только для относительно простых программ. По мере же усложнения приложений трудности, связанные с переносимостью, возрастали.
Сама компания Sun в 2000 году предлагала реализацию технологии Ява для операционных систем Windows, Solaris, Mac OS и Linux, в то время как некоторые альтернативные технологии реализуются разработчиками для гораздо большего числа систем.

Интерпретируемость и высокая эффективность. Хотя программы на Яве обычно выполняются с помощью интерпретатора, но программа не исполняется непосредственно по ее исходному тексту. Присутствует этап компиляции с языка Ява в байт-код. Получается, что от интерпретации Яве достались недостатки (низкая скорость выполнения), а многие преимущества (отсутствие промежуточных файлов, отсутствие затрат времени на компиляцию, отсутствие необходимости в отдельном инструменте-компиляторе) оказались невостребованными. Часть программистов предпочитает при создании интернет-приложений работать с системами, которые выполняют интерпретацию программы прямо по ее исходному тексту. В этом случае отпадает необходимость освоения и использования при разработке сразу нескольких инструментов, выполнения нескольких этапов обработки программы, не нужно возиться с множеством создаваемых компилятором файлов1. В результате, популярностью пользуются системы, основанные на более примитивных языках, таких как JavaScript и Перл.
Как показал опыт применения Явы, низкая скорость работы программ оказалась одним из главных недостатков технологии. Это проявлялось уже при первом знакомстве. Достаточно было взглянуть на работу написанного на Яве браузера Hotjava, как недостаточная производительность сразу же бросалась в глаза. Не решали проблему и встроенные в виртуальную машину компиляторы байт-кода, которые преобразуют файлы классов в машинные команды процессора во время загрузки, «на лету». Такие системы были не в состоянии выполнить серьезную оптимизацию получаемого кода. В результате этот код не мог сравниться по скорости с кодом, порождаемым оптимизирующими компиляторами. Не добавляют производительности программам на Яве и отказ от эффективных механизмов статического и автоматического распределения памяти, представление строк как объектов, отсутствие многомерных массивов. Так что заявления авторов технологии о высокой производительности можно расценивать скорее как попытку выдать желаемое за действительное.

В языке Java все параметры методов передаются только по значению.
В языке Си параметры также передаются по значению, но существует возможность в качестве фактического параметра указать адрес, а в качестве формального — ссылку. В Си++ есть возможность передачи параметров по ссылке. Отсутствие в Яве адресов и ссылок и передача параметров только по значению не позволяют запрограммировать метод, имеющий выходные или изменяемые параметры примитивных типов (int, char и др.). На Яве нельзя, к примеру, написать метод для обмена значениями двух целых, подобный procedure Swap (var х, у: integer). Необходимость решения этого вопроса породила одну из самых неуклюжих конструкций языка Ява — классы-фантики (wrapper classes).

Запутанный многословный синтаксис. Многие конструкции, унаследованные из языка Си, не способствуют получению понятных программ: операторы-выражения, стимулирующие побочный эффект, условная операция, большое число уровней приоритета операций. Управление областями действия (областями видимости) объектов программы при отсутствии ясной модульной структуры приводит к необходимости использования многочисленных модификаторов доступа.
Причины появления в Яве некоторых громоздких конструкций плохо объяснимы. Сравните, например, описание экспортируемой вещественной константы в Обероне и Яве. На Обероне: CONST Pi*=3.14159; На Яве: public static final float Pi=3.14159f;

Распространение языка Ява
Язык Ява был представлен в первую очередь как средство программирования для Интернета. При этом уже в первых версиях JDK — инструментального комплекта средств разработки, содержались библиотеки для создания не только аплетов, но и приложений с оконным пользовательским интерфейсом. Такие программы тоже имели возможность взаимодействовать с Интернетом.
Благодаря бесплатному распространению компанией Sun средств разработки на Яве возможность поэкспериментировать с аплетами получили множество программистов. Самым распространенным сюжетом для аплетов стали простенькие игры, играть в которые можно прямо на веб-странице.
Были предприняты и попытки реализовать на Яве крупномасштабные программные комплексы. Главным мотивом при этом было стремление получить не зависящие от платформы системы. Так, известная канадская компания Corel взялась за создание на Яве набора офисных приложений: текстовый процессор, электронная таблица и т. д. Проект завершился неудачей. Corel Office for Java ни по производительности, ни по функциональным возможностям, ни по устойчивости работы не мог соперничать с конкурирующими продуктами. Бесславно закончился и проект так называемого «сетевого компьютера». Его замысел состоял в том, чтобы уменьшить стоимость пользовательского рабочего места за счет того, что все необходимые программы (написанные, конечно же, на Яве), загружаются в такой компьютер по сети. Выпущенные компанией Sun компьютеры JavaStation, способные исполнять Ява-программы и работающие под управлением Java OS, не получили распространения.
Все эти неудачи позволили скептикам заявить, что Ява годится только для написания игрушечных программ, предназначенных для показа движущихся картинок на веб-страницах. Но и ситуация с аплетами оказалась непростой. Появилось сразу несколько альтернативных технологий, позволяющих помещать на страницы динамические элементы, в том числе обеспечивающие интерактивное взаимодействие с пользователем. В первую очередь в ряду таких технологий надо назвать скриптовый язык JavaScript. Программа на таком языке прямо в исходном виде включается в текст веб-страницы. На JavaScript можно написать в том числе и несложные игры.

Как средство оживления веб-страниц, JavaScript стал намного популярней Явы. Для проверки этого тезиса был проведен (в начале 2001 года) простой опыт. С помощью поисковой системы AltaVista были взяты 20 первых страниц, выданных по запросу на слово «dynamic». Оказалось, что на 13 из этих 20 страниц присутствуют программы на JavaScript, и только на одной — аплет, написанный на Яве. Подобный опыт в русском Интернете дал такие результаты: из 20 первых страниц, выданных поисковой системой Яндекс на запрос по слову «динамический», на 9 присутствовали скрипты на JavaScript и ни на одной странице не обнаружилось аплета.

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

Улучшились характеристики эффективности Ява-систем. Использование продвинутых технологий компиляции в сочетании с ростом быстродействия компьютеров позволило снять проблему низкой производительности.

Фактором, который, по мнению экспертов, сдерживает распространение Ява-технологии, является отсутствие международного стандарта языка. Sun Microsystems предпочитает получать доход от продажи торговой марки другим фирмам, разрабатывающим собственные реализации. Все спецификации Ява-технологии до сих пор остаются ведомственными стандартами Sun.

В нашей стране распространение языка Ява в конце 1990-х годов было, судя по всему, незначительным. Подтверждением этому служит, например, тот факт, что книг по Яве на русском языке выпускалось в несколько раз меньше, чем по Delphi и Си++ (в отдельности). Пик издательской активности пришелся на 1997 год. Не просуществовав и года, в 1998 году прекратил издаваться журнал «Java World/Россия». Среди причин такого положения, кроме свойств самой технологии, можно назвать очень высокую долю используемых в России IBM PC-совместимых компьютеров и операционных систем семейства Windows. Поэтому любые разговоры о важности межплатформенной переносимости приложений в наших условиях оказывались не слишком актуальны.

При всей неоднозначности оценок язык Ява обладает рядом неоспоримых достоинств. Он, например, гораздо лучше подходит на роль языка для обучения программированию, чем несостоятельные в этом отношении Си и Си++. Нет сомнения в том, что язык Ява займет, в конце концов, достойное место среди прочих языков программирования, но надежды на то, что он революционизирует всю технологию разработки программ, вряд ли оправданы.

Си не поддерживает объекты, но при этом практикуется создание небольших инструментов — компонентов UNIX, которые можно совместно использовать для создания сложных функций. В какой мере эффективнее создавать объекты внутри языка как части большой программы, чем строить компоненты, входящие в состав системы?

Питер Вайнбергер: Здесь у меня возникает два вопроса. Первый касается связывания или модулярности. Вопрос в том, что делать с помощью языка, а что — пытаясь комбинировать инструменты. Более тесной и, конечно, более сложной связь между компонентами окажется, если все они будут реализованы в языке. Отчасти это обусловлено просто эффективностью вычислений, но, мне кажется, здесь и проблема концептуальной последовательности.

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