Здравствуйте коллеги!
В предыдущей статье речь шла о проблеме ООЯП в общем, в данной статье я бы хотел развить эту тему и показать более конкретно проблемы ООЯП.
Основные идеи: ООЯП имеют две ключевые проблемы: неполноценная объектная парадигма и преждевременная типизация. Неполноценная объектная парадигма не даёт определения понятию нетипизированной объектной композиции (композиция является важнейшим элементом любой парадигмы). Преждевременная типизация ограничивает семантику абстрактных понятий (семантических абстракций).
Неполноценная объектная парадигма
Объектная парадигма в явном виде не определяет базовых механизмов. Любая парадигма должна определять:
- Примитив абстракции – определяет стиль мышления парадигмы и является базовым элементом моделирования.
- Композиция примитивов – позволяет описывать (моделировать) системы произвольной сложности. Сама композиция также сама должна являться примитивом.
- Агрегирующее отношение – абстрактный механизм, который связывает примитивы в композиции. Точно такой же механизм проявляет примитив и во внешнем взаимодействии.
- Глобальное состояние – где (но не как!) будет локализовано абстрактное (наблюдаемое) состояние системы. Это свойство не сколько парадигмы, сколько следствие вычислительной архитектуры. Результат выполнения любой модели можно обнаружить лишь по изменению состояния в самом общем смысле.
Принципиально, что парадигма определяется в нетипизированном виде. Чтобы пользоваться парадигмой (не путать с использованием ЯП, основанных на данной парадигме), типизация не нужна. Парадигма должна лишь определять, как и на каких механизмах строится модель (т.е. одна или несколько композиций).
Ещё более важно, что композиция, а не примитив, является "кирпичом" при моделировании в силу сложности моделируемых систем. Композиции являются чистыми семантическими абстракциями, без привязки типов или любых других "ресурсов". Семантическая абстракция – это понятие, заданное только своим именем, причём имя в произвольном виде, слово или словосочетание.
Для примера, функциональная парадигма полностью удовлетворяет этим свойствам (то же самое можно показать и для процедурной/императивной парадигмы):
- Примитив абстракции: функция – отображение некоторого входа в некоторый выход.
- Функциональная композиция: цепочка функций (отображений).
- Агрегирующее отношение: выход одной функции подаётся на вход другой. Т.е. это связь в композиции, и вызов функции как таковой.
- Глобальное состояние: аргументы функций.
В ООП и текущих определениях объектной парадигмы, объектная композиция в лучшем случае подразумевается, в худшем её вообще нет. Так называемые постулаты ООП (абстракция/инкапсуляция/наследование/полиморфизм) – это отвлечённый набор понятий, причём два последних вообще относятся к типизации и к объектной парадигме не имеют никакого отношения. Всё есть объект. Объекты взаимодействуют между собой. – тут объектная композиция по крайней мере подразумевается, и как-то логически её можно вывести.
Кончено, в ООЯП технически можно увидеть композиции в том или ином виде, но объектная композиция должна быть базовым и основным механизмом ООЯП, а не опциональным и второстепенным.
Как должна примерно выглядеть объектная парадигма (по аналогии с функциональной):
- Примитив абстракции: объект – агент, поддерживающий некоторый протокол взаимодействия. Протокол подразумевает правила и семантику взаимодействия для обеих сторон.
- Объектная композиция: граф объектов, поддерживающих протоколы друг друга. Сам граф является объектом с собственным протоколом.
- Агрегирующее отношение: поддержка протокола объекта (т.е. понимание протокола и следование ему). Способность поддерживать протокол друг друга связывает объекты в композицию, равно как и внешнее взаимодействие с конкретным объектом возможно лишь в случае поддержки его протокола.
- Глобальное состояние: внутреннее состояния объекта.
Отличительной особенностью объектной парадигмы является то, что объект, в отличие от функции и процедуры, не является чисто трансформирующим (т.е. меняющим состояние) примитивом. Т.к. глобальное состояние распределено по объектам (в ООЯП это инкапсуляция), протокол объекта становится способом изменения состояния. Это должно быть отражено на уровне объектной парадигмы.
Для этого объектная парадигма может использовать любую парадигму с трансформирующим примитивом, собственно функциональную и/или процедурную парадигмы для протоколов объектов. Обе парадигмы используются в таком же абстрактном нетипизированном виде. Если протокол объекта основан на функциональной парадигме, мы получаем немутабельный объект, если же на процедурной – то мутабельный.
Преждевременная типизация
Типизация (система типов) в конечном счёте нужна для единственной цели: формальной верификации корректности программ. Правила задаются через грамматику ЯП, транслятор на основе грамматики проводит собственно верификацию.
Преждевременность типизации заключается в том, что ООЯП (класс-ориентированные) делают сильный акцент на использовании типов, на трактовке классов как типов. Первое что бросается в глаза (причём как на практике при использовании ООЯП, так и в учебниках/книгах при описании ООЯП) – система типов ООЯП, хотя по идее должна быть объектная парадигма с её композицией и семантическими абстракциями. Ссылочные типы и типы значений, полиморфизм подтипов, наследование, принцип подстановки Лисков (LSP), перегрузка методов, обобщения (generics), абстрактные типы данных, функциональный тип и ФВП как элементы функционального программирования, вывод типов, приведение типов, абстрактные классы и интерфейсы – все эти понятия являются следствием типизации.
С одной стороны, типизация неизбежна, т.к. только корректные программы можно выполнить. Но с другой, появление типизации вводит ограничения на семантику абстракций. Идея в том, чтобы появление типизации отложить на столько позже, на сколько это возможно. Другими словами, формальную верификацию корректности проводить только после того как определена объектная композиция. В идеале, типизация должна быть подключаемой, её место где-нибудь перед этапом компиляции, и уже на этапе компиляции собственно и выполняется верификация.
Если посмотреть на типизацию более широко, то преждевременная типизация в ООЯП проявляется также и в фиксированном толковании абстрактных механизмов объектной парадигмы в виде конкретных типов реализации. Показательный пример – протокол объекта (он же контракт) жёстко реализован в виде методов с фиксированными структурой и поведением (параметры, возвращаемое значение) как одна из возможных типов реализаций протокола объекта. Причина добавления модификаторов методов async/wait в C# — видимо стало понятно, что жёсткая (синхронная) связь вызова метода и возвращаемого значения не соответствует практическим задачам. На самом деле это исправление последствий преждевременной типизации. Опять же, в идеале конкретный тип реализации протокола должен быть подключаемым, с конкретной реализацией любого механизма.
Идея подключаемой типизации мне представляется в виде нескольких этапов (это не какой-то водопадный процесс разработки ПО, все этапы происходят при написании кода, не выходя из IDE).
Описывается объектная модель (одна/несколько нетипизированных объектных композиций), которая содержит только семантические абстракции. Объекты, их протоколы, композиции объектов – всё неформально описывается в виде семантических абстракций. На этом этапе смысл объектной модели следует из самих понятий.
Затем происходит атрибутизация, т.е. определение (привязка) нетипизированных атрибутов для семантических абстракций. В результате получаются атрибутированные семантические абстракции. Атрибуты – это не поля данных, свойства и т.п. из ООП/ООЯП, атрибуты определяют смысловую структуру понятия. На этапе атрибутизации вообще нет понятия состояния.
Следующий этап – абстрактная (нетипизированная) реализация протоколов объектов (говоря традиционно – реализация методов). Для протоколов объектов выбирается парадигма реализации с трансформирующими примитивами (функциональная и/или процедурная). На этом этапе уже доступны атрибуты, но они (как и абстрактные функции и/или процедуры) всё ещё семантические абстракции. Использование трансформирующих парадигм на этом этапе подразумевает абстрактное состояние объектов (раз есть что трансформировать), и структура этого состояния как раз и вытекает из атрибутов объектов.
Далее идёт конкретная (типизированная) реализация – именно тут происходит привязка типов к объектам и их атрибутам, а также параметрам/аргументам в протоколах объектов. Абстрактные процедуры/функции абстрактной реализации протоколов объектов конкретизируются до традиционных конструкций типа методы класса.
Отдельно отмечу, что привязка типов происходит через инжектирование выражений, а не указание имени типа. Другими словами, тип выводится из типа выражения, что гарантирует явную инициализацию.
После этапа конкретной реализации все понятия типизированы, и можно проводить формальную верификацию (как часть трансляции).
Заключение
Обозначенные проблемы, на мой взгляд, являются причиной того, что ООЯП фундаментально противоречивы. Неудивительно, что ООЯП и ООП в их текущем виде всегда будут объектом критики.
Есть ещё и третья проблема, но она касается не только ООЯП, но и других языков: это синтаксис, основанный на текстовой грамматике. В настоящее время поддержка текстовых грамматик в IDE настолько развита, что возникает вопрос: а зачем требуется текстовое представление кода? IDE манипулируют целыми структурными блоками типа методов или выражений, что текст как такой вырождается. Сравнивать версии в системах контроля версий как текст? Но это лишь вопрос реализации поддержки в IDE.
Синтаксис, основанный на текстовой грамматике ограничивает мета-возможности по той же причине, что мета-уровень требует от IDE дополнительной поддержки, и нет особого смысла задавать их в виде текста. Т.е. мета-возможности реализуются только на уровне IDE. По сути IDE и есть грамматика.
Поэтому глобальная идея – разработать объектно-ориентированный язык (т.е. IDE) на основе внятной объектной парадигмы, без текстовой грамматики и с развитыми мета-возможностями трансформации объектных композиций в читаемый код.
Комментарии (22)
Amareis
18.03.2018 18:20Преждевременная типизация хуже преждевременной эякуляции?)
Вообще, текст действительно не всегда самый оптимальный способ передачи смысла, просто он самый простой для генерации и чтения и способен передать большинство смыслов за счет прямой привязки к способу мышления — универсальней него только "сырое" представление мысли, которое пока выделять и передавать не научились. Это как с низкоуровневыми языками — описать через текст можно что угодно, другое дело что часто гораздо проще использовать более высокоуровневые вещи, те же картинки.
lair
18.03.2018 23:07Любая парадигма должна
Вот прямо с этого и начнем. Вы не могли бы показать (общепринятое) определение парадигмы, где это указано?
PalladaProject Автор
19.03.2018 17:09Определение парадигмы (по-моему достаточное для темы) дано в самом начале поста, собственно вы и процетировали его начало. Я определил парадигму через её ключевые атрибуты и указал смысл этих атрибутов.
Вы ожидаете какое-то общепринятое определение, и которое будет совпадать с моим (точнее наоборот, моё должно совпадать с ним)? Википедийное определение заключается в том, что нет общепринятого и однозначного определения парадигмы. Но всё это и не требуется. Моё определение — это допущение, что если оно верно, то верны и следствия из него (при условии корректности вывода).
Например, покажите пожалуйста ложность/противоречивость моих выводов, тогда автоматом встанет вопрос о корректности изначальных допущений (в данном случае определение парадигмы) и/или логики вывода.
lair
19.03.2018 17:20Например, покажите пожалуйста ложность/противоречивость моих выводов, тогда автоматом встанет вопрос о корректности изначальных допущений (в данном случае определение парадигмы) и/или логики вывода.
Да нет, все проще. Вы утверждаете, что "объектная парадигма неполноценна". В случае, если вы используете собственное определение парадигмы, это означает, что объектная парадигма не удовлетворяет вашему определению парадигмы — однако какое мне до этого дело? То, что ООП не удовлетворяет это определению — это не проблема ООП.
PalladaProject Автор
20.03.2018 18:12объектная парадигма не удовлетворяет вашему определению парадигмы
Т.е. вы имеет ввиду что всё-таки существует какое-то общепринятое определение? Которое определяет объектную парадигму и которому удовлетворяют ООП/ООЯП и которое не совпадает с моим определением? Общепринятого определения парадигме нет, отсюда следует простой вывод: какое-бы не было сущесвующее определение (и которое вы подразумеваете) — оно спорное и потенциально содержит изъяны, следовательно моё определение (теоретически) может быть более правильным.
То, что если вы не видите проблем, вовсе не означает их там действительно нет. Допустим, для вас существующие определения объектоной парадигмы и ООЯП вполне согласуются. Но без анализа содержательной части моего поста вы не можете утверждать что в ООП нет проблем — я как раз утверждаю что есть. Разработчики ООП/ООЯП могли ошибаться и текущее определения ошибочны. Я и пытаюсь в посте показать своё видение и какие следствия из него получаются.
lair
20.03.2018 18:28Т.е. вы имеет ввиду что всё-таки существует какое-то общепринятое определение?
Ну да.
следовательно моё определение (теоретически) может быть более правильным
Как вы определяете правильность определения?
То, что если вы не видите проблем, вовсе не означает их там действительно нет.
Да нет, именно это это и обозначает. Вы ввели определение "сепулька — это ...", потом сказали "ООП/ООЯП — неполноценная сепулька, потму что..." — ну и что? Для меня в этом нет никакой проблемы, потому что мне совершенно все равно, являются ли ООП/ООЯП сепулькой.
в ООП нет проблем — я как раз утверждаю что есть
В ООП, очевидно, есть проблемы, потому что ни одной совершенной парадигмы программирования не существует. Просто эти проблемы — они не в несоответствии вашему определению.
PalladaProject Автор
20.03.2018 19:48Как вы определяете правильность определения?
Это зависит от определяемого понятия. В данном случае, для парадигмы — какого качества/удобства языки програмирования на ней построены. Такого количества критики как у ООЯП ещё надо поискать.
потому что мне совершенно все равно, являются ли ООП/ООЯП сепулькой.
В ООП, очевидно, есть проблемы, потому что ни одной совершенной парадигмы программирования не существует.Пока вы не вникните в суть сепульки, как вы можете утверждать что проблемы ООП/ООЯП не в сепульке? Т.е. вы допускаете что ООП/ООЯП не без слабостей, при этом заранее уверены что не в сепульке дело?
И тем более, что суть не в соответсвии моему определению парадигмы, а в выводах которые из моих определений следуют. В контексте моих определений ООЯП имеют проблемы, в контексте общепринятых определений — не имеют. Но общепринятые определения под вопросом, мои могут оказаться как хуже так и лучше. Т.о. общепринятые определения не истина, а допущение (как и моё). Я не могу пока показать конечный вывод из моей "теории" в виде языка (IDE), чтобы можно было показать что постоеный язык (IDE) на моём определении лучше (или хуже) чем существующие ООЯП. Этот пост демонстрирует промежуточные выводы, и только в таком умозрительном виде, к сожалению.
lair
20.03.2018 22:14В данном случае, для парадигмы — какого качества/удобства языки програмирования на ней построены. Такого количества критики как у ООЯП ещё надо поискать.
Ээээ, тут путаница, прямо вот несколько раз.
Начнем с парадигмы. С парадигмой, на самом деле, все просто: это "совокупность фундаментальных научных установок, представлений и терминов, принимаемая и разделяемая научным сообществом и объединяющая большинство его членов". Казалось бы, как на это определение может повлиять то, "какого качества на ней построен язык программирования"?
Ладно, может вы, на самом деле, про парадигму программирования? "это совокупность идей и понятий, определяющих стиль написания компьютерных программ (подход к программированию)." Тоже нет, на это определение качество языка программирования повлиять не может.
Таким образом, ваша метрика выглядит бесполезной для определения качества определения термина "парадигма".
Такого количества критики как у ООЯП ещё надо поискать.
Чего искать-то? Берете процедурные языки, и получаете все то же самое. Более того, если отнормировать по распространенности, то, я думаю, у вас по всем парадигмам будет более-менее одинаково. Так что тоже не показатель.
Пока вы не вникните в суть сепульки, как вы можете утверждать что проблемы ООП/ООЯП не в сепульке? Т.е. вы допускаете что ООП/ООЯП не без слабостей, при этом заранее уверены что не в сепульке дело?
Конечно. Потому что я утверждаю, что проблема ООП не в том, что ООП не сепулька. Я нигде не утверждаю, что проблема ООП не в сепульке.
в контексте общепринятых определений — [ООЯП проблем] не имеют
Приехали. А критика, на которую вы ссылаетесь выше, она в контексте каких определений существует? Или ее нет на самом деле?
Но общепринятые определения под вопросом, мои могут оказаться как хуже так и лучше.
Для того, чтобы об этом говорить, надо определить "лучше" и "хуже" для определений, а этого пока не наблюдается.
постоеный язык (IDE) на моём определении лучше (или хуже) чем существующие ООЯП
А что с того, что на вашем определении ваш язык лучше? Как это согласуется с моими задачами?
PalladaProject Автор
21.03.2018 07:05Таким образом, ваша метрика выглядит бесполезной для определения качества определения термина "парадигма".
Я имел в виду объектную парадигму, а не парадигму вообще. Как пример, покажите пожалуйста общепринятое определение объектной парадигмы? Как оно согласуется с приведёнными общими определениями парадигмы?
Приехали. А критика, на которую вы ссылаетесь выше, она в контексте каких определений существует? Или ее нет на самом деле?
Не, не приехали :) Эта часть фразы обозначает вашу позицию.
А что с того, что на вашем определении ваш язык лучше?
По идее он не на моём определнии лучше, и лучше не в абсолютном смысле. Он лучше тем что решает проблемы (некоторые) ООП/ООЯП (которые вы почему-то свели к несоответсвию определений).
Как это согласуется с моими задачами?
К вашим задачам это не имеет никакого отношения. ООП/ООЯП живут не одно десятилетие. В посте я высказал допущение (гипотизу), на основе которой получаются некоторые выводы. Насколько я понял, вы считаете что гипотиза не заслуживает даже постановки, не говоря уже о том чтобы разбирать её содержательную часть. Вы начали с разбора определений, хотя по-моему ими нужно заканчивать (а начинать с выводов). Суть поста: обсудить концепцию нового ЯП/IDE. Это не касается ваших задач, и не попытка модернизировать ООП/ООЯП, это просто мысли к размышлению.
lair
21.03.2018 09:01Я имел в виду объектную парадигму, а не парадигму вообще.
Эм. Давайте подставим это в ваше изначальное высказывание: "Объектная парадигма в явном виде не определяет базовых механизмов. Любая объектная парадигма должна определять..". Получается фигня — сначала вы даете определение объектной парадигмы, а потом говорите, что она же ему не удовлетворяет.
Как пример, покажите пожалуйста общепринятое определение объектной парадигмы?
Я никогда не встречал этого термина. Или вы имеете в виду "объектно-ориентированную"?
Эта часть фразы обозначает вашу позицию.
То есть, согласно вашей позиции, критики ООП/ООЯП нет?
Насколько я понял, вы считаете что гипотиза не заслуживает даже постановки, не говоря уже о том чтобы разбирать её содержательную часть.
Вы поняли неправильно. Я считаю, что ваша гипотеза некорректно сформулирована, что не позволяет в дальнейшем ее обсуждать (не говоря уже о том, что нигде не указана, собственно формулировка гипотезы, дан просто набор утверждений, выдающихся за корректные).
Суть поста: обсудить концепцию нового ЯП/IDE
А зачем он тогда называется "проблемы ООЯП"?
а начинать с выводов
Эмм. А какие у вас выводы? Вот эти: "Обозначенные проблемы, на мой взгляд, являются причиной того, что ООЯП фундаментально противоречивы."? Ну так во-первых, оно решает непоставленный вопрос ("почему ООЯП фундаментально противоречивы"), а во-вторых, возвращает нас к "описанным проблемам"… которые являются проблемами только из-за неразрешенности вашей системы определений.
Вы постоянно возвращаетесь в своем посте вот к этому: "объектная композиция должна быть базовым и основным механизмом ООЯП, а не опциональным и второстепенным. " Но почему "должна"? Почему если это не так, у ООЯП — проблема? Почему то, что есть — не "объектная композиция"? Как следствие, все последующие выводы из этого постулата тоже не определены.
PalladaProject Автор
21.03.2018 17:58Или вы имеете в виду "объектно-ориентированную"?
Да, верно (для простоты одним словом: функиональная, процедурная, объектная).
Давайте для ясности проведём параллели. Во-первых, определение "парадигма программирования":
общепринятое: это совокупность идей и понятий, определяющих стиль написания компьютерных программ (подход к программированию). Это способ концептуализации, определяющий организацию вычислений и структурирование работы, выполняемой компьютером.
из моего поста: Любая парадигма должна определять: Примитив абстракции (...), Композиция примитивов (...), Агрегирующее отношение (...), Глобальное состояние (...)
Вы считаете эти два определения абсолютно безсвязными? Моё определение конкретизирует обтекаемое общепринятое определение (совокупность идей и понятий, определяющих стиль написания компьютерных программ), но никак не противоречит ему.
Во-вторых, определение "объекто-ориентированная парадигма". Какое определение считать общепринятым — чуть позже, главное что нужно показать как оно соответсвует общепринятому определению парадигмы программирования. В моём посте я показываю свой вариант опредения объекто-ориентированной парадигмы (но ещё и функциональной) и его соответсвие моему определению парадигмы программирования.
Теперь общепринятое определение "объекто-ориентированная парадигма": в варианте постулатов ООП или вариант Всё есть объект..., может что-то ещё? Что бы это нибыло, как оно соотносится с общепринятым определением парадигмы программирования?
gonzazoid
18.03.2018 23:51idris — type, refine, define. В книге от автора языка про type driven development эти вещи на первых страницах объясняются. И без обид — гораздо более системно.
oleg_ra
19.03.2018 08:59Причина добавления модификаторов методов async/wait в C# — видимо стало понятно, что жёсткая (синхронная) связь вызова метода и возвращаемого значения не соответствует практическим задачам.
Что? И это пишет человек, у которого в профиле значится «Разработчик .NET»! Модификатор async никак не влияет на тип возвращаемого методом значения, то есть к типизации не имеет вообще никакого отношения. А что касается языков моделирования (потому что большая часть тут описанного это как раз о моделировании, а не о реализации) — чем вам UML то не угодил? Не идеал, конечно, но свою задачу более-менее выполняет.PalladaProject Автор
19.03.2018 09:26Модификатор async никак не влияет на тип возвращаемого методом значения, то есть к типизации не имеет вообще никакого отношения.
Модификатор async, разумеется, не имеет отношения к типу возвращаемого значения. Может я не верно выразился в том абзаце, но там речь о том что в C# методы классов и их вызовы — это конкретный тип реализации (вот какой тип имелся ввиду) абстрактной концепции протокола/контракта объекта. До появления async методы были синхронные, но практика показала что такое жёсткое поведение непрактично (хотя можно было использовать Task[T]). И добавили async/wait (которые под капотом реализованы через Task[T]).
чем вам UML то не угодил?
Именно тем что он язык моделирования. UML это на мой взгляд крайность в моделировании, ООЯП наоборот акцентируются на типах без объектной композиции. Идея в том чтобы сделать комбинированый вариант.
lair
19.03.2018 11:49До появления async методы были синхронные
Конечно же, нет. APM был в .net начиная с первой версии.
(ну или наоборот, если вам угодно: методы синхронные до сих пор, ничего не изменилось)
PalladaProject Автор
19.03.2018 16:33APM был в .net начиная с первой версии.
APM который вы имеете ввиду — это не часть языка C#, я же говорю про сам язык. APM это паттерн, причём как в варианте Begin/End/IAsyncResult, так и в вариации Event-based Asynchronous Pattern, а затем и Task-based Asynchronous Pattern (TAP). Но сам язык C# формально сделал методы асинхронными с введением ключевых слов async/wait.
lair
19.03.2018 16:37Но сам язык C# формально сделал методы асинхронными с введением ключевых слов async/wait.
Но нет же.
async-метод возвращает управление синхронно в известный момент времени.
(более того, с точки зрения контракта вы вообще не знаете, async-метод или нет)
PalladaProject Автор
19.03.2018 17:37По-моему мы о понятиях на разных уровнях. Технически (это о чём говорите вы как я понял), конечно, async метод синхронно возвращает задачу, но собственно результат вызова придёт асинхронно (ещё и с возможной сменой потока, в зависимости от планировщика). Но это всё техническая сторона.
Я же говорю о грамматике языка, что async/wait это ключевые слова с конкретной семантикой, т.е. на уровне языка появились новые слова. Т.е. теперь на уровне языка есть синхронные и асинхронные методы. Моя мысль в том что на уровне объектной композиции вообще не нужно задавать тип реализации контракта.
lair
19.03.2018 17:39Технически (это о чём говорите вы как я понял), конечно, async метод синхронно возвращает задачу, но собственно результат вызова придёт асинхронно (ещё и с возможной сменой потока, в зависимости от планировщика).
… и чем это отличается от APM? Технически
BeginXвернется синхронно, но собственно результат вызова придет асинхронно.
Т.е. теперь на уровне языка есть синхронные и асинхронные методы.
… которые никак не видны в контракте. Правда, забавно?
По большому счету, нет никакой разницы с
yieldи генераторами — там тоже тип в контракте не меняется, а вот внутренняя реализация меняется.
iCpu
19.03.2018 09:08Эх, «Потеряла я колечко, а в колечке 22 дивизии!»
Как должна примерно выглядеть объектная парадигма (по аналогии с функциональной):
Примитив абстракции: объект – агент, поддерживающий некоторый протокол взаимодействия. Протокол подразумевает правила и семантику взаимодействия для обеих сторон.
Примитив абстракции: интерфейсы — контракты взаимодействия агентов; классы — комбинация реализаций одного или нескольких интерфейсов; объекты — агенты экземпляры классов.
Агрегирующее отношение: передача сообщений. Сообщения являются объектами. Объект — получатель сообщения не обязан, в общем случае, уметь обрабатывать полученные сообщения.
Типизация — не преждевременная. Она происходит именно там, где должна происходить в выбранной парадигме. Вы подмешали async/await, но это не корректно. ООП не определяет протоколы взаимодействия объектов. ООП описывает лишь отправку сообщения от объекта к объекту. Формат сообщения — это уже отдельная история, которая лежит на уровне между языком и компилятором. К тому же, кроме async/await есть ещё и callback, и очередь сообщений, и signal/slot, и прочее прочее.
VolCh
Спорное утверждение, особенно в части единственности. В мейнстримовых языках типизация (где она есть) или её аналоги, кроме возможности частичной формальной верификации, ещё обычно усиливает выразительность текста программы, облегчает её неформальный анализ и дальнейшую модификацию. По сути типизация служит инструментом создания DSL. Во многих задачах адекватные домену имена классов имеют большую ценность чем возможность формальной верификации.
PalladaProject Автор
Это всё следствие проявления верификации (в конечном счёте). Верификация происходит уже на этапе написания кода, и даже при чтении у нас в голове. Если понятия типизированы, семантика типов просто исключает вариации смысла понятия.
Подскажите, что вы имеете в виду под "усиливает выразительность"? Думаю как пример это могло быть Constraints on Type Parameters в generics?
Мне кажется что тут вы как раз смешиваете понятия и типизированные понятия. DSL как вокабюляр для описания предметной области можно построить и в нетипизиорванном виде, на основе семантики понятий из самой же предметной области.
Полностью согласен. Хотя классы рано или поздно будут интерпретироваться как типы.