Пример: сложная иммутабельная структура данных (тот же TrieMap). Что лучше — заставить пользователя вручную её модифицировать для добавления и удаления элементов или предоставить простой интерфейс, инкапсулируя реализацию?
Это всё особенно смешно, если учесть, что процессы в Erlang в большинстве (gen_* based) такие же объекты. Отказывая данным внутри процесса и между процессами в собственном состоянии и правах доступа, он выстраивает такие же барьеры на границах процессов. Двоемыслие на марше.
То ли перевод сделан через задницу, то ли статья состоит из "WAAT?!!" чуть менее, чем полностью. А скорее всего — и то, и другое.
Возражение 1: структуры данных и функции не должны быть связанными друг с другом
... много бла-бла о том, что есть функция и что есть структура данных и потом глобальный вывод:
Так как функции и структуры данных имеют разную природу, не надо считать их одинаковыми и работать с ними как с одинаковыми сущностями.
Это с чего бы вдруг? Кофе и молоко имеют разную природу и никто не считает их одинаковыми, но латте и капучино вполне себе нормально существуют. Желание описать основные методы работы с данными где-то непосредственно рядом с их структурой — вполне естественное и закономерное, точно так же, как и желание скрыть часть этих методов. Если эрланг позволяет сделать что-то подобное, не прибегая для этого к ООП — значит надо было такой пример показать и объяснить, чем конкретно он лучше. Иначе это звучит как религиозный догмат "да не объедини ты функции и структуры воедино", и все типа срочно должны в него уверовать.
Возражение 2: всё есть объект
...и в качестве примера, конечно же, Smalltalk и число 3 в качестве объекта.
Конечно, ведь он до сих пор остается ООП-мейнстримом, а не эти ваши всякие java, .Net, python и прочие неудачники, отказавшиеся от реализации "числового пуризма".
Возражение 3: в объектно-ориентированных языках определения типов данных распространяются везде
В Erlang или C можно определить все типы в одном включаемом файле или словаре данных.
Ага, можно. Вот только давайте-ка вспомним, когда в последний раз нам было нужно использовать в своей программе абсолютно все типы данных, которые нам может предоставить какая-нибудь библиотека? М-м-м-м... Постойте... Кажется... Никогда?! И даже в дремучие времена сишных хедер-файлов это было скорее их недостатком, чем достоинством.
В объектно-ориентированном языке мне придётся выбирать объект, в котором я определю глобальный тип. Все остальные объекты, которые захотят использовать эту структуру данных, должны наследовать этот объект.
Да сирьёзна штоле?! То есть если я хочу в своей программе использовать java.util.HashMap — то я должен отнаследовать класс от java.util.HashMap? Просто сделать new и создать экземпляр объекта в нужном методе внезапно стало уже недостаточно, или инстанцирование уже не считается использованием?
Возражение 4: у объектов есть приватное состояние
Состояние — корень всех зол.
Кстати, аминь.
Объектно-ориентированные языки выбрали опцию «прятать состояние от программиста». Это худший вариант из возможных. Вместо того, чтобы работать с состоянием и минимизировать неудобства, они просто прячут его.
Выделенное — это, кажется, называется "создать проблему, а потом героически преодолеть её"? В этом, наверное, есть много доблести, но кто сказал, что это лучше — где критерии оценки, где примеры того, как эту проблему элегантно позволяет решить эрланг? Навсякий: создание копии состояния при каждом чихе — это нифига не решение.
ЗЫ Ну и вывод в статье шикарен, в стиле "ООП — г..но, поэтому оно создало индустрию, эрланг гениален, поэтому никак не может создать". Где-то рядом, наверное, тихо плачут создатели терияков и работающих на воде двигателей внутреннего сгорания, задушенные индустрией большой фармакологии и нефтедобычи, соответственно.
Здравствуйте, Пацак, Вы писали:
П>ЗЫ Ну и вывод в статье шикарен, в стиле "ООП — г..но, поэтому оно создало индустрию, эрланг гениален, поэтому никак не может создать".
Не, классический ООП — та еще кака, но аргументы в статье действительно ни в Красную Армию.
scf>Нет, автор статьи (в интернете) неправ. scf>Пример: сложная иммутабельная структура данных (тот же TrieMap). Что лучше — заставить пользователя вручную её модифицировать для добавления и удаления элементов или предоставить простой интерфейс, инкапсулируя реализацию?
То и удивительно, что ООП существует с середины 60-х годов.
А в 21 веке находится перец, который говорит, что функции и данные должны быть отдельно.
А еще удивительно, что инкапсуляцию этот перец считает злом...
Брукс еще в 1995 году признал, что Парнас был прав.
А этот деятель будто бы не читал Брукса...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Пацак, Вы писали: П>Да сирьёзна штоле?! То есть если я хочу в своей программе использовать java.util.HashMap — то я должен отнаследовать класс от java.util.HashMap? Просто сделать new и создать экземпляр объекта в нужном методе внезапно стало уже недостаточно, или инстанцирование уже не считается использованием?
Он имеет в виду java.lang.object / System.Object.
Опять же враньё даже про java — см. напр. int/float/etc. Не говоря уже о системе типов .Net, где есть много чего мимо object.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Аргументы в статье, как мне кажется, совершенно не по делу.
Но тем не менее — сказка ложь, да в ней намек.
Раз уж в заголовке темы сказано "для начинающих" — вот именно для начинающих, для обучения лучше использовать не ООП, а обычный язык вроде С. А когда человек уже освоится, то тогда узнает, что можно привычные конструкции завернуть в ООП и в каких-то аспектах облегчить себе жизнь.
N>Это всё особенно смешно, если учесть, что процессы в Erlang в большинстве (gen_* based) такие же объекты. Отказывая данным внутри процесса и между процессами в собственном состоянии и правах доступа, он выстраивает такие же барьеры на границах процессов. Двоемыслие на марше.
Похже Джо говорил, что Erlang — это как раз ООП в том виде, в котором его представлял себе Алан Кей.
LVV>>Все прям такие начинающие... scf>Да все понимают, что твой вброс — джинса для слабых мозгом, чтобы они купили ваш курс по программированию, но чего бы не обсудить
Ну, 1. Написано жеж — для начинающих...
2. А мы ничего не продаем, никаких курсов.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Ой, да ладно тебе!
Мода совать ООП везде, где не надо прошла уже лет десять назад.
Сейчас ООП стал обычным инструментом, одним из.
Сейчас мода на функциональное программирование и шаблоны.
Note that these definitions do not belong to any particular object. they are ubiquitous and data structures representing times can be manipulated by any function in the system.
There are no associated methods.
Чем это хорошо-то? Т.е. any function in the system создать дату 31 февраля и никак это не запретить.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Статья совершенно безумная, на неё только Лаптев и мог повестись.
