[LOR] Роб Пайк дал оценку Java и C++

[t.t]

sciko,
если мне не изменяет память, LISP — первый язык со сборкой мусора, и один из первых — с ООП.

Насчёт первого Вы правы. А насчёт второго — не путайте Lisp и CLOS.

[watashiwa_daredeska]

Но разве это неравенство опровергает сказанное?

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

Проектирование (design) вообще лежит в несколько иной плоскости.

[deadhead]

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

STL. Если почитать справку по STL, то там фигурирует такое понятие, как «concept», и все сущности отнесены какой-нибудь «концепции», будь то Forward Iterator, Unary Function, Reversible Container или еще что. Однако, в реализациях (до последнего времени, во всяком случае) эти «concept» никак не фигурировали вообще.

Не очень понятно как отсутсвие реализации связано с ООП и ООД... Вы намекаете, что реализация может базироваться, например, на парадигме ФП? Тогда как, по вашему, она будет вписываться в ООД?

[watashiwa_daredeska]

Тогда как, по вашему, она будет вписываться в ООД?

Как я говорил, я не видел вживую примеров, а изобретать искусственные мне не хочется. Хотя... простейший пример: объект (с т.з. ООД) может быть реализован просто как запись в одной или нескольких таблицах БД, без ОО обёртки. Т.е. design и implementation — вообще разного уровня вещи, слабо связанные друг с другом.

[diesel]

ну то есть говоря про ООП мы слышим:

с каким-нибудь многомиллионнострочным аналогом, написанным с использованием ООП

вместо:

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

А вот тут есть большая разница. Вторая цитата относится к относительно маломасштабному коду. А ООП начинает играть существенную роль на больших масштабах.

ок. почему ООП выигрывает на больших масштабах?

[watashiwa_daredeska]

почему ООП выигрывает на больших масштабах?

На больших масштабах начинает играть большую роль взаимодействие разработчиков. Немаловажной (если не важнейшей) в этой области задачей является описание программных интерфейсов. ООП предлагает достаточно мощный (если не самый мощный) язык для описания интерфейсов. Многие прочие всё равно сводятся к ОО описанию, пусть и на словах, в документации. Взять, к примеру, тот же Tcl/Tk (я имею в виду Tk при использовании в Tcl). С одной стороны, прям DSL, т.е. Language Orientented Programming в чистом виде, но документация для описания этого DSL всё равно скатывается к описанию объектов, их поведения и наследования. Дескать эта конструкция делает с объектом таким-то то-то, эта сё-то, а этот объект — контейнер, и для него работает всё то, что работает и для других контейнеров. Т.е. можно сказать, что LOP — лишь обертка для ООП, для более удобного его использования в конкретных ситуациях. Вроде как, ООП — если не ассемблер, то язык Си описания программных интерфейсов, а остальное — более высокоуровневые, более удобные описания, но лишь в конкретных ситуациях, при том, что их можно-таки свести к ООП.

[diesel]

почему ООП выигрывает на больших масштабах?

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

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

[watashiwa_daredeska]

как-то так?

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

[diesel]

как-то так?

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

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

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

[watashiwa_daredeska]

то есть за рамки типов данных определяемых пользователем мы не убежали.

Что такое "рамки типов данных, определяемых пользователем"?

[diesel]

то есть за рамки типов данных определяемых пользователем мы не убежали.

Что такое "рамки типов данных, определяемых пользователем"?

ну то есть ничего принципиально нового под солнцем
есть у нас какой-нить int, с которым связан диапазон значений, и возможные операции над экземплярами
и есть какие-нить Student, Teacher whatever, определенные на основе определенных ранее типов, с которыми так же связан диапазон допустимых значений, и операции над ними.

[watashiwa_daredeska]

ну то есть ничего принципиально нового под солнцем

Не, ну если на таком уровне, то тензорное исчисление — тоже не новость. Подумаешь, числа в табличку записали