Обновить
14
Денис Щетинин@chaetal

Пользователь

Отправить сообщение

И классы были придуманы еще в докомпьютерную эпоху… И объекты. И сообщения… И вообще почти всё было придумано в докомпьютерную эпоху. Даже сами компьютеры тоже были придуманы в докомпьютерную эпоху :D

Что с того? Речь о том, какой смысл был вложен в понятие уже при историческом материализме "в компьютерную эпоху".

Я бы сказал иначе: человек в естественном языке чаще мыслит не классами, а типами - причём контекстными и довольно мягкими. 

А вот я, например. не мыслю ни классами, ни типами. Может быть, я в этом разительно отличаюсь от всего остального человечества… но почему-то очень сильно сомневаюсь в этом.

Если я очень устал и хочу присесть, то я не ищу вокруг объекты типа стул. И объекты класса Стул тоже не ищу. Я ищу то, на что я могу присесть. И если рядом окажется не стул, а табуретка, то вряд ли я откажу своим ногам в отдыхе по причине несовпадения типа.

А когда мне нужно отпереть дверь, то я не ищу "какой-нибудь ключ" — я ищу конкретный ключ, который может отпереть данный конкретный замок. И это не мешает кому-то воспользоваться отмычкой. А кому-то просто выломать дверь. И при этом я могу использовать ключ от дверного замка, например, для того, чтобы проткнуть и вскрыть конверт при отсутствии поблизости ножа.

Вы же что-то подобное имеете ввиду, когда делаете оговорку о том, что типы "контекстные и довольно мягкие"?

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

"Объектная ориентированность" заключается ни в классах, и ни в типах — она заключается в том, чтобы из окружающего мира выделять объекты и взаимодействовать с ними. И ООП уж точно не создавалось, чтобы "сделать … типизацию мира более жёсткой, формальной…". Кэй преследовал, скорее, как раз обратную цель — избавиться от навязываемой машиной излишней жёсткости и ненужной формализации, спрятав её внутри объектов, а связи между ними сделать максимально гибкими и раскрепощёнными за счёт (динамически интерпретируемых) сообщений.

Есть и другие варианты, как можно попробовать решить эту проблему. Но на данном этапе я согласен с тезисом "пофиг". Есть, вероятно, проблемы и посерьёзнее. Из не трудно увидеть, если попробовать написать и затем проинтерпретировать что-то более интересное.

Да пофиг на приоритеты, в принципе скобки же для того и существуют

Со скобками получим LISP :D

То есть x это сообщение в контекст выполнения.

Да, это ключевой момент для объектной чистоты.

По-моему, отказываться от объектности приходится в двух случаях:

  • для реализации необходимых примитивов — как от этого можно избавиться не вижу, так что это можно/нужно только минимизировать

  • когда нужная "функциональность" не ложится на "синтаксис" языка.

Во втором случае тоже надо минимизировать, но здесь, подозреваю, есть возможность избавиться от синтаксиса полностью (или почти полностью). Собственно, синтаксическая конструкция "получитель сообщение" и лежит в основе синтаксиса Smalltalk-а. И мешается. Например, как в случае с возвратом из метода: кто является получателем сообщения "вернуть объект"?

Объект переменной - звучит бред

Почему бред?

Тут, конечно есть проблема — например, приоритет выполнения. И не факт, что одна. Но если уж мы пытаемся придумать чистый объектный язык, где "всё — объект", то и "переменная" — тоже объект.

нужно что-то сделать понятнее, а что-то - изменить

Что именно вызывает непонимание? Что и с какой целью нужно изменить?

Идею —  видимо, поняли правильно, да. В деталях могут быть разночтения.

Не знаю, что у вас означает assign — что-то типа примитивной операции?

В каком-то смысле, x := 5 это thisContext addVariable: $x withValue: 5, но с оговорками. Я представляю себе, что x := 5 должен выполняться примерно так:

  • В "среду"/контекст посылается сообщение x.

  • Контекст (например, метод, в котором данный код выполняется) получает это сообщение и создаёт у себя слот с именем х; этот слот становится контекстом.

  • Слот получает сообщение := 5 и кладёт в себя соответствующее значение.

Чистый ООП-язык — это (логично же?) когда ничего, кроме ООП, в языке нет :) Разумеется, на сколько это возможно (об этом ниже).

ООП — это "двоица" объекты и сообщения.

  • "Объект" — это то, что может реагировать на "сообщения".

  • "Сообщение" — это "объект", который можно послать "объекту".

"Двоица" — потому что одно невозможно определить без другого, но при этом, очевидно, "одно" и "другое" не совпадают. Специально не хочу использовать термин "пара", так как у него несколько иная коннотация (да и смысл другой на самом деле).

Зачем мы посылаем сообщения, и что при этом происходит в получателе (я это отношу к "семантике", надеюсь не сильно искажая смысл этого термина) — оставлю пока за кадром. Это довольно сложная и, возможно, принципиальная проблема. Здесь и сейчас её разобрать не смогу. В значительной степени "проектирование" чистого ООП-языка как раз должно помочь разобраться с этим вопросом.

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

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

Я бы очень хотел, чтобы в "чистом ООП-языке" все необъектные операции были максимально скрыты от "пользователя" языка. Как и в какой степени это можно сделать — открытый вопрос, который я упомянул вначале, и который является двойственным вопросу "семантики".

Наконец, отвечаю на поставленный вопрос

А как бы вы видели тот самый чистый ООП-язык?

Для "пользователя" чистого ООП-языка в нём должны быть только объекты и сообщения.

То есть из перечисленных вами пунктов в языке я бы оставил два (с изменениями):

  • Всё есть объект (без исключения).

  • Объекты (по крайней мере, некоторые) могут быть сообщениями.

Всё остальное либо следствия (как инкапсуляция и полиморфизм), либо должны быть вынесены либо в библиотеку (например, классы и, соответственно, наследование), либо в "реализацию" языка.

Уточню: в Smalltalk-е не объектными (не сообщениями) являются (это навскидку, могу что-то забыть):

  • объявления переменных

  • присваивание

  • возврат из метода

На мой взгляд объявления переменных большой проблемы не представляют — есть такая гипотеза, что они вообще не обязательны. Но это не точно. А вот что я точно не знаю, так это как присваивание и возврат сделать сообщениями в рамках конструкции "получатель сообщение". Поэтому я пришёл к мысли, что от неё надо отказаться.

Можно заметить, что в "реальной жизни" "мы" "отправляем" "сообщения" не конкретному получателю, а в "среду", из которой эти сообщения получают те, кому нужно. Вот это я хочу попробовать положить в основу "синтаксиса" чистого ООП-языка. То есть конструкция receiver message будет интерпретироваться как посылка сообщения receiver в среду, которая найдёт в своём контексте соответствующего получателя (например, просто по имени найдёт либо локальную переменную в методе, либо что-то ещё — сейчас не буду разбирать все варианты), и этот объект уже получить сообщение message.

Идея, хотя я уже очень давно её время от времени "думаю", всё ещё очень сырая и шаткая… Особенно с учётом того, что…

…Есть подозрения, что "изначальный" Smalltalk (Smalltalk-72) примерно на подобной концепции и базировался. В Early History of Smalltalk Кэй как-то невнятно про это говорит, и когда я изначально вникал в Smalltalk, особого внимания на это не обратил. Но когда получше разобрался в теме и пришёл к мысли об общей "среде" передачи сообщений, из который адресат(ы) могут вычленять интересующие их сообщения, вспомнил, поискал. Очень похоже на то, но глубоко в вопросе не разобрался. Не уверен, что и нужно. Можно попробовать проработать эту идею независимо — вдруг не наступим на те же грабли, что и в 60-е… А может, и нужно. Потому что Кэй охарактеризовал это дело как строительство Вавилонской башни, которое известно как закончилось.

Закругляюсь, а то я ещё долго могу :) Получилось очень сумбурно и кратко. Но всё же надеюсь, не звучит как абсолютная тарабарщина :/

Выше уже задали весьма правильный и актуальный вопрос: нафига? Я бы его даже сузил: особенно интересно понять, зачем писать ещё один Smalltalk?

Я это спрашиваю не в порядке критики, а, скорее, с целью "прощупать почву". Исходя из того, что вы пишите — да ещё и по выбранному вами нику :) — могу предположить что у нас могут быть схожие интересы… Как вы, например, смотрите на то, чтобы попытаться придумать (именно придумать — про реализацию, вероятно, думать рановато) действительно чистый ООП-язык? На всякий случай уточню: даже Smalltalk при всей своей гениальной чистоте и мощи таковым не является. У меня по этому поводу есть некоторые мысли… которым уже не первый десяток лет, и до не то чтобы воплощения, даже до внятного изложения которых у меня никак "не доходят руки". Если интерес и возможность, можно было бы пообщаться.

Скоро вместо капчи будут просить написать сочинение. Написал грамотно, логично и стройно? Ты --- робот! По нынешним временам звания человека достойны лишь шизофреничные неучи?

Зачем? Зачем создавать что-то новое, пока нет понимания уже существующего?

…Даже, правильнее сказать, "существующИХ". Потому что после Smalltalk-а были и Self, и Strongtalk, и Newspeak… и даже Erlang с Elixir-ом. В общем были, были попытки развития разной степени успешности (разумеется, здесь я не имею ввиду популярность) — именно на основе понимания идеи ООП.

Но большинству милее деградация через всякие С++, Java и прочие химеры. Неадекватность заложенных в основу подобных ЯП принципов, "идеям ООП" (которые они тщатся "воплотить") компенсируется извращением и вырождением этих самых идей. Зато Algol-истый синтаксис — он же такой знакомый и "простой" (точнее, привычный) в реализации. Не зря же в ВУЗах основы теории компиляторов преподают. …Или уже не преподают?

А ещё можно очень успешно критиковать то, что не понимаешь. Особенно, если не хочешь понимать. Это ведь очень удобно делать, когда вокруг столько уродливо-кривых воплощений. Железная же "логика": идея —> извращение идеи —> воплощение извращённой идеи —> провал => вывод: идея была неправильной. Столько простора для "творчества"!

Так что ждать новых ЯП не приходится. А если они появятся, вряд ли это будет шагом вперёд для ООП.

Зато можно ожидать повторения раундов борьбы инкапсуляции с иммутабельностью и наследования с полиморфизмом. Это — всегда пожалуйста, это — сколько угодно! :D

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

100%

Упрощённый — там, где нужно учесть неустранимую сложность. Почему-то все при любом удобном случае радостно кричат "давайте проще!", но при этом предпочитают ездить на работу на сложных автомобилях и летать в отпуска на сверх-сложных самолётах, а не передвигаться на гораздо более простых средствах передвижения (типа собственных ног). Может быть потому, что сложность бывает полезной, и устранить её не всегда возможно?

…Но ещё и переусложнённый — там, где всё действительно просто и можно обойтись одной фразой: "не надо превносить лишнюю сложность". Про то, как это сделать (что, в свою очередь, тоже не просто) — речи, разумеется нет.

Но зато сколько хайпа вокруг этого упрощённо-переусложнённого взгляда! :)

Вы не путаете "забыто" и "умерло"?

Нет. Но что вы понимаете под "умерло" — я понять не смог. Я-то всего лишь говорил о том, что исходная идея ООП существенно отличалась от "общепринятой" сейчас. И нет, она не умерла — просто забыта. И это печально, потому что она обладает гораздо большими выразительным возможностями, но при этом ещё и проще.

ООП соответствует базису мышления человека.

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

  • Тот ООП, который (как я понимаю) имел ввиду Алан Кэй, придумывая этот термин, — да, похоже, является "базисом" человеческого мировосприятия.

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

Есть гипотеза, что я понял, наконец, что вас так выводит из себя.

Меня ничто не выводит из себя. Я всегда в себе, что бы со мной ни происходило ;) И уж точно повальное извращение ООП не может вывести из себя — я всё ещё продолжаю удивляться, как можно, но уже почти не верю, что это всё можно изменить :)

Я использую термин «полиморфизм» в качестве синонима для /…/

Я всё больше склоняюсь к тому, что использование одних и тех же слов для обозначения разные вещей — одна из основных проблем человечества :D

Попробуйте открыть статью "Полиморфизм (информатика)" в Википедии, и должно стать понятно, что и почему я понимаю под термином "полиморфизм".

И я бы тоже с удовольствием сокращал количество фрикций в фалангах своих пальцев, ограничившись словом "сообщение", но почему-то это всякий раз приходится объясняться…

Сути это, впрочем, не меняет.

Ну, вот как?! Как использование слов не по их исходному значению может не менять сути?

Как можно просто брать и использовать термин "полиморфизм", у которого есть вполне определённый (хотя и очень сложный) смысл, преданный этому термину ещё до появления термина "ООП", для краткой передачи смысла сообщений? Да ещё и учитывая, что с помощью этого термина переврали, извратили и буквально поставили с ног на голову всю концепцию? :)

Как можно говорить, что Кэй "дистанцировался" от ООП, используя «genericity», если Кэй с помощью этого термина пытался объяснить смысл ООП, (безрезультатно) демонстрируя, что "полиморфизм" (несмотря на всю сложность) не в состоянии дать те же возможности, что и концепция ООП и сообщений?

Не понимаю как, но вот вижу, что можно: именно так и превратили ООП в того уродца, о котором нынче ломают копья "тупоконечники" с "остроконечниками". И нет, это не выводит меня из себя. Скорее, уже забавляет ;)

Да окститесь, в смолтолке полиморфизм был с первого дня.

Вы про какой полиморфизм? Тот, который сейчас используют для "объяснения" что такое "ООП" — но который при про функции, а не про сообщения? Или всё же про ваш личный, который вы каким-то образом привязываете к связке объект-сообщение?

И про первый день какого именно Smalltalk-а речь? Про Smalltalk-80? Или про Smalltalk-76? Или, может быть, про Smalltalk-72? Было бы интересно услышать, как вы к нему привяжете полиморфизм… Или вообще про концепцию 71-го года — это было бы даже интереснее.

…Хотя, вы же, наверное, привяжете полиморфно — наделив термин "полиморфизм" ещё какой-нибудь интерпретацией? :)

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

Трейтами, например. Еще раз: я оперирую сущностями, а не ООП-шными паттернами.

По всей видимости, под "прилагательными" и "наречиями" вы тоже имеете ввиду что-то другое — не то, что в учебниках по русскому языку? Можно считать этот вопрос риторическим :)

Дайте угадаю, вы никогда не сталкивались с понятийными аппаратами современной математики (всякие там аффинные геометрии, теории групп, и т. п.).

Не угадали.

Все эти понятийные аппараты именно упорядочивают и упрощают — то есть убирают избыточную сложность, а не добавляют её. Они появились по необходимости — без них просто не удавалось получить желаемое (формализованные доказательства).

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

Я же про это и спросил! Только не про аксиоматику Пеано, а про аксиоматику ООП.

Какое утверждение провозглашает "теорема" под названием "полиморфизм" в ООП? Что она даёт, чего не даёт на порядки более простая пара утверждений: "одно и то же сообщение может быть по-разному обработана разными объектами" и "один и тот же объект может по-разному обработать одно и то же сообщение в разные моменты времени"? Зачем мне может понадобится для определения (sic!) понятия ООП начинать ссылаться на "способность функции обрабатывать данные различных типов", строя искусственные изоморфизмы из пространства объектов и сообщений в пространство функций, данных и типов? А затем перечислять все виды и подвиды полиморфизма, добавляя ещё больше бессмысленной избыточности?

(В классическом определении ООП через объекты и сообщения, дополненного вариантом реализации через поведение и состояние не хватает…) Прилагательных и наречий :) Поведение — это глагол. Состояние — существительное. И пока мы с вами — не Бродский, — нам не обойтись одними глаголами. «Красный» — это не поведение и не состояние.

"Красный" — это именно состояние, которое влияет на поведение.

И как же полиморфизм с инкапсуляцией позволяют добавить прилагательные и наречия?

И ещё интересно, как же, по вашему мнению, без них древние смогли создать, например, Smalltalk, который до сих пор по выразительным/функциональным возможностям и простоте минимум на порядок превосходит все ополиморфленные и обинкапсулированные якобы ООП-шные современные языки? ;)

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

Как странно получается… Про сообщения и объекты вы в курсе. Про то, что на их основе сделаны Smalltalk/Self, Erlang (с оговорками, но всё же) и акторы — видимо, тоже? Про то, что "инкапсуляция" с "полиморфизмом" в отношении ООП появились позже, наверное, как минимум, догадываетесь. Но для описания очевидных следствий из "аксиоматики" всё равно почему-то считаете необходимым введение "понятийного аппарата" на основе переусложнённого и искажённого "полиморфизма" и шизофреничной "инкапсуляции". А чем они лучше простейших и интуитивно понятных, наверное, любому школьнику "поведения" и "состояния"? В последних по вашему мнению чего-то не хватает? Чего?

Всё уже давно предложено. С самого начала. И благополучно забыто.

В целом, позиция ясна.

Но тезис «ОО очень хорошо ложится на окружающий мир» — не подтвержден буквально ничем. Меж тем, Аланкаевская модель с сообщениями — вот она действительно блистательно описывает мир, ибо объекты гораздо менее важны, в сравнении с обменом информацией. ОБ этом очень много говорил Армстронг, и его реализация «окружающего мира» — гораздо убедительнее Гослинговой.

За это вам наша искренняя сердечная благодарность!

Настоящий ("аланкеевский") ООП не просто хорошо, а изумительно хорошо описывает буквально всё. При этом всего-то и нужны объекты и сообщения.

Универсальность * Простота = МОЩЬ

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

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

Кто-то кого-то не понимает — либо я вас, либо вы меня. Давайте выясним:

Буду краток - все три пункта выше - фи-игня. 

Вот и четвёртый (я бы его на первое место поставил) пункт про инкапсуляцию, наследование, полиморфизм — не меньшая фи-игня. Да?

1
23 ...

Информация

В рейтинге
Не участвует
Откуда
Тверь, Тверская обл., Россия
Дата рождения
Зарегистрирован
Активность

Специализация

Десктоп разработчик, Бэкенд разработчик
Ведущий
ООП
TDD/BDD
Smalltalk
Java
PostgreSQL
SQL
Git
REST
Docker
Английский язык