Если вы будете хранить в XML или JSON, это тоже будет текстовая грамматика.
Дело не в самом тексте, а в том что дерево в XML/JSOM сериализуется как дерево, т.е. сохраняется вся информация о его узлах. В случае плоского текста утрачивается явная структура дерева, и её приходится восстанавливать прибегая к парсерам.
Текстом можно записать ровно то же самое.
Можно конечно, раз это эквивалентные представления. Я уже описывал ситуацию со сниппетами, где промежуточный этап с текстом просто не нужен. Моя идея это продолжение и развитие сниппетов.
Только это гораздо проще, чем накликивать мышкой блоки в IDE.
Это делается, конечно, не мышкой. Всё как обычно, как текст, только структурированый, или как сказать, шаблонированый. Вообще структурные (проекционные) редакторы (structured or projectional editors) уже существуют, мышкой там в принципе пользуются не больше чем в обычных IDE, например MPS от JetBrains.
По сути, единственное отличие, которое вы предлагаете, это хранить вот так.
А отображать без названий ключей. Это вполне может быть полезно в случаях типа новых ключевых слов. Только ни с ООП ни с типом грамматики это не связано.
Это от другой "фичи", черновик старый, поэтому оно действительно не связано с темой ветки.
Что будет храниться в файле и отображаться на экране в том варианте, который предлагаете вы? Интересует не описание общими словами, а именно конкретные байты и пикселы.
Вообще-то это и был ответ по существу. Может я не так понял акценты в вашем вопросе, но если байты и пикселы…
Вас действительно интересует именно как сериализуется такая структура данных как дерево? Может всё-таки акцент на дереве разбора, какие там типы узлов и пр.?
Дерево разбора первично, текст — это "побочный эффект", один из способов сериализации этого дерева. Вот поэтому дерево разбора можно представить (отрендерить) не только в виде текста.
Насчёт пикселей, если позволите тогда там ссылку на свой черновик. Это совсем черновой вариант, там нет полноты функционала, и уже очень многое в концепциях/дизайне поменялось на текущий момент, но если схематично вот так себе представляю визуально.
Проблема в том, что когда для вашего языка нужен специальный формат хранения, вы получили следующую кучу проблем.
Этот специальный формат и есть "грамматика" языка. Либо вы описываете текстовую грамматику в виде какой-нить BNF нотации, либо описываете схему формата хранения дерева, которое абсолютно эквивалентно BNF нотации текстовой грамматики. Текстовые файлы с кодом на C# и Java различаются точно также как и, например, бинарные файлы с деревьями для C# и Java. Вы не можете подать на вход компилятору C# текстовый файл с кодом на Java по известной причине, с файлами дерева точно такая ситуация.
О какой куче проблем тогда речь?
А теперь, значит, представим себе ситуацию, что у вас компиляция выполняется не в IDE (потому что билд-сервер), и версии IDE и компилятора разошлись.
Это проблема не следствие идеи текст/дерево. Такая проблема возникнет и при разных версиях компилятора например IDE C# 7 и билд-сервер C# 5.
(а) придумывать формат хранения для этих "узлов дерева" (потому что если этого не делать, то вы просто оптимизировали задачу отображения, что неинтересно)
Формат хранения может быть любой, начиная от XML и заканчивая бинарным оптимизированным. Причём хранить можно не дерево, а граф с семантическими связями уже.
(б) связывать IDE с компилятором (по крайней мере, с его первой частью, которая отвечает за разбор)
IDE и компилятор уже содержат парсер в том или ином виде ( подсветка синтаксиса и пр.). Что подавать на вход компилятору, текст или дерево/граф — это вопрос архитектуры IDE. Парсер как компонет может шариться IDE и компилятором, собственно Roslyn как раз про это.
Можете показать результат, как в этом случае будет выглядеть ваш пример?
Выглядеть визуально он может точно также, тут суть в том IDE показывает не текст, а отформатированое поддерево. Т.е. текст можно всегда легко получить из дерева, а вот распарсить текст — тут не всякая контекстно-зависимая грамматика справится.
Вот интересная картина получается. IDE поддерживают вставку сниппетов, типа свойство get; private set; Т.е. человек заранее знает какой тип элемента кода ему нужен. Но IDE вставляет плоский текст и это знание теряется. Компилятор опять парсит текст чтобы понять какие там элементы указаны, свойства, методы и пр. Если бы после propg IDE вставляла узел дерева и показывала шаблон для указания setter and/or getter, возможно какие-то проблемы были бы просто исключены.
Поэтому, как я понимаю, и предлагается вводить типизацию перед компиляцией. Так? Сначала почти всё реализуем, а потом введём типы, чтобы убедиться, что ошибок нет.
Я предлагаю вводить типизацию постепенно. К этапу компиляции всё будет типизировано и конкретизировано, конечно. Количество информации будет не меньше, точнее говоря такое же.
Из определения типа (как множества допустимых значений (состояние) и операций над ними (поведение)) возникла идея вводить эти две составляющие раздельно. Объектная композиция основана на протоколе объектов, т.е. только поведение. Атрибуты (нетипизированые) определяют структуру объекта (понятия) но тоже без типов. Затем атрибуты объектов трактуются как состояние, контракт как поведение, там где нужно привязываются уже существующие (встроенные) типы, после этого можно проводить верификацию.
Мозг человека склонен разбивать множества сущностей по категориям/типам/классам.
Вот как раз классификация основана на атрибутах (признаках), и любая классификация указывает по какому признаку(признакам) она производится. Введение атрибутов позволяет определять классафикацию как таковую по каким-то атрибутам. Далее, для атрибутов можно определить допустимые значения (но не операции), и тогда классфикация приводит к классам с выбраной гранулярностью. Это я к тому, что жёсткая связь из определения типа домен+операции возможно и не требуется, копмоненты типа (домен и операции) можно вводить независимо друг от друга.
Вообще, я думаю что объектный подход обоснован не тем что человек как-то мыслит объектами, а именно атрибутированными понятиями, на которых и возможны классификации.
А вы как будете расширять семантику своего нового языка? Или вы настолько уверенны в его полноте, что подобные вещи вам в голову не приходят?
На уровне нетипизированных композиций всё абстрактно и расширение семантики очень маловероятно. Но даже не в этом дело.
у Эрика Липперта очень толково изложено зачем ключевое слово async вообще притащили в язык. То есть, можно было без него, но это потенциально ломало работающий код и поэтому было принято такое решение.
А дело в том, что из-за текстовой грамматики и возникает эта проблема, которую решили довольно красиво я бы даже сказал. Вот пример из статьи:
var x = await + y;
При разборе как интерпретировать await — как идентификатор (тогда всё выражение это вызов бинарного оператора) или как точка разрыва и далее continuation (тогда выражение вызов асинхронного перегруженного оператора)? Решение: если у перегруженного оператора указан async — значит в данном выражении компилятор считает точка разрыва, иначе — бинарный оператор с агрументами await и y.
Если бы это была не текстовая грамматика, а некоторое дерево разбора типа AST, то проблема в принципе не возникает, т.к. await однозначно определён типом узла (т.е. это однозначно идентификатор т.к. legacy code). Чтобы извлечь смысл из плоского текста и приходится прибегать к решениям типа маркера async.
Бинго! Это и есть моя та самая гипотиза, что более конкретизированное и ограниченное определение приведёт к определённым результатам. Я описал её в виде "Потребуем, чтобы...", поэтому там "Каждая парадигма должна...".
Следовательно, могут быть парадигмы программирования, которые не удовлетворяют вашему определению.
Конечно, это очевидная мысль, и после моего определения парадигмы я показал что фунциональная парадигма удовлетворяет такому суженому определению. В черновиках статьи я и для процедурной парадигмы описал, но выкинул из-за объёма статьи.
Возвращаясь к сути поста: если допустить более сторогое (суженное) определение парадигмы (которому тем не менее удовлетворяет функциональная, но и процедурная тоже я считаю), из него вытекает некоторый смысл объектной парадигмы (я показал как на моём определени парадигмы должна выглядеть собственно объектная парадигма). Отсюда одно из следствий — ООП/ООЯП слабо поддерживают объектную композицию, и в новом языке/IDE её можно поддержать и получше.
Ну да, вот возьмем Кеевское:
Меня смущает то, что а) общее определение парадигмы довольно расплывчатое, б) определение А.Кея не формальное, и в) ООЯП на таком фундаменте могут интерпретировать ООП довольно в широком смысле, вплоть до потери специализации. Я считаю именно это и произошло на практике в ООЯП.
Опять же, я не против определений А.Кея или любых других. Вы, получается, поддерживаете определение А.Кея, и ООЯП в принципе с ним согласуются. Но меня не устраивает туманность и неоднозначность определений ООП, и то положение вещей что из себя предствляют ООЯП. Поэтому предлагаю пообсуждать альтернативные идеи.
Да, верно (для простоты одним словом: функиональная, процедурная, объектная).
Давайте для ясности проведём параллели. Во-первых, определение "парадигма программирования":
общепринятое: это совокупность идей и понятий, определяющих стиль написания компьютерных программ (подход к программированию). Это способ концептуализации, определяющий организацию вычислений и структурирование работы, выполняемой компьютером.
из моего поста: Любая парадигма должна определять: Примитив абстракции (...), Композиция примитивов (...), Агрегирующее отношение (...), Глобальное состояние (...)
Вы считаете эти два определения абсолютно безсвязными? Моё определение конкретизирует обтекаемое общепринятое определение (совокупность идей и понятий, определяющих стиль написания компьютерных программ), но никак не противоречит ему.
Во-вторых, определение "объекто-ориентированная парадигма". Какое определение считать общепринятым — чуть позже, главное что нужно показать как оно соответсвует общепринятому определению парадигмы программирования. В моём посте я показываю свой вариант опредения объекто-ориентированной парадигмы (но ещё и функциональной) и его соответсвие моему определению парадигмы программирования.
Теперь общепринятое определение "объекто-ориентированная парадигма": в варианте постулатов ООП или вариант Всё есть объект..., может что-то ещё? Что бы это нибыло, как оно соотносится с общепринятым определением парадигмы программирования?
ещё обычно усиливает выразительность текста программы, облегчает её неформальный анализ и дальнейшую модификацию.
Это всё следствие проявления верификации (в конечном счёте). Верификация происходит уже на этапе написания кода, и даже при чтении у нас в голове. Если понятия типизированы, семантика типов просто исключает вариации смысла понятия.
Подскажите, что вы имеете в виду под "усиливает выразительность"? Думаю как пример это могло быть Constraints on Type Parameters в generics?
По сути типизация служит инструментом создания DSL.
Мне кажется что тут вы как раз смешиваете понятия и типизированные понятия. DSL как вокабюляр для описания предметной области можно построить и в нетипизиорванном виде, на основе семантики понятий из самой же предметной области.
Во многих задачах адекватные домену имена классов имеют большую ценность чем возможность формальной верификации.
Полностью согласен. Хотя классы рано или поздно будут интерпретироваться как типы.
Таким образом, ваша метрика выглядит бесполезной для определения качества определения термина "парадигма".
Я имел в виду объектную парадигму, а не парадигму вообще. Как пример, покажите пожалуйста общепринятое определение объектной парадигмы? Как оно согласуется с приведёнными общими определениями парадигмы?
Приехали. А критика, на которую вы ссылаетесь выше, она в контексте каких определений существует? Или ее нет на самом деле?
Не, не приехали :) Эта часть фразы обозначает вашу позицию.
А что с того, что на вашем определении ваш язык лучше?
По идее он не на моём определнии лучше, и лучше не в абсолютном смысле. Он лучше тем что решает проблемы (некоторые) ООП/ООЯП (которые вы почему-то свели к несоответсвию определений).
Как это согласуется с моими задачами?
К вашим задачам это не имеет никакого отношения. ООП/ООЯП живут не одно десятилетие. В посте я высказал допущение (гипотизу), на основе которой получаются некоторые выводы. Насколько я понял, вы считаете что гипотиза не заслуживает даже постановки, не говоря уже о том чтобы разбирать её содержательную часть. Вы начали с разбора определений, хотя по-моему ими нужно заканчивать (а начинать с выводов). Суть поста: обсудить концепцию нового ЯП/IDE. Это не касается ваших задач, и не попытка модернизировать ООП/ООЯП, это просто мысли к размышлению.
Это зависит от определяемого понятия. В данном случае, для парадигмы — какого качества/удобства языки програмирования на ней построены. Такого количества критики как у ООЯП ещё надо поискать.
потому что мне совершенно все равно, являются ли ООП/ООЯП сепулькой.
В ООП, очевидно, есть проблемы, потому что ни одной совершенной парадигмы программирования не существует.
Пока вы не вникните в суть сепульки, как вы можете утверждать что проблемы ООП/ООЯП не в сепульке? Т.е. вы допускаете что ООП/ООЯП не без слабостей, при этом заранее уверены что не в сепульке дело?
И тем более, что суть не в соответсвии моему определению парадигмы, а в выводах которые из моих определений следуют. В контексте моих определений ООЯП имеют проблемы, в контексте общепринятых определений — не имеют. Но общепринятые определения под вопросом, мои могут оказаться как хуже так и лучше. Т.о. общепринятые определения не истина, а допущение (как и моё). Я не могу пока показать конечный вывод из моей "теории" в виде языка (IDE), чтобы можно было показать что постоеный язык (IDE) на моём определении лучше (или хуже) чем существующие ООЯП. Этот пост демонстрирует промежуточные выводы, и только в таком умозрительном виде, к сожалению.
объектная парадигма не удовлетворяет вашему определению парадигмы
Т.е. вы имеет ввиду что всё-таки существует какое-то общепринятое определение? Которое определяет объектную парадигму и которому удовлетворяют ООП/ООЯП и которое не совпадает с моим определением? Общепринятого определения парадигме нет, отсюда следует простой вывод: какое-бы не было сущесвующее определение (и которое вы подразумеваете) — оно спорное и потенциально содержит изъяны, следовательно моё определение (теоретически) может быть более правильным.
То, что если вы не видите проблем, вовсе не означает их там действительно нет. Допустим, для вас существующие определения объектоной парадигмы и ООЯП вполне согласуются. Но без анализа содержательной части моего поста вы не можете утверждать что в ООП нет проблем — я как раз утверждаю что есть. Разработчики ООП/ООЯП могли ошибаться и текущее определения ошибочны. Я и пытаюсь в посте показать своё видение и какие следствия из него получаются.
По-моему мы о понятиях на разных уровнях. Технически (это о чём говорите вы как я понял), конечно, async метод синхронно возвращает задачу, но собственно результат вызова придёт асинхронно (ещё и с возможной сменой потока, в зависимости от планировщика). Но это всё техническая сторона.
Я же говорю о грамматике языка, что async/wait это ключевые слова с конкретной семантикой, т.е. на уровне языка появились новые слова. Т.е. теперь на уровне языка есть синхронные и асинхронные методы. Моя мысль в том что на уровне объектной композиции вообще не нужно задавать тип реализации контракта.
Определение парадигмы (по-моему достаточное для темы) дано в самом начале поста, собственно вы и процетировали его начало. Я определил парадигму через её ключевые атрибуты и указал смысл этих атрибутов.
Вы ожидаете какое-то общепринятое определение, и которое будет совпадать с моим (точнее наоборот, моё должно совпадать с ним)? Википедийное определение заключается в том, что нет общепринятого и однозначного определения парадигмы. Но всё это и не требуется. Моё определение — это допущение, что если оно верно, то верны и следствия из него (при условии корректности вывода).
Например, покажите пожалуйста ложность/противоречивость моих выводов, тогда автоматом встанет вопрос о корректности изначальных допущений (в данном случае определение парадигмы) и/или логики вывода.
APM который вы имеете ввиду — это не часть языка C#, я же говорю про сам язык. APM это паттерн, причём как в варианте Begin/End/IAsyncResult, так и в вариации Event-based Asynchronous Pattern, а затем и Task-based Asynchronous Pattern (TAP). Но сам язык C# формально сделал методы асинхронными с введением ключевых слов async/wait.
Модификатор async никак не влияет на тип возвращаемого методом значения, то есть к типизации не имеет вообще никакого отношения.
Модификатор async, разумеется, не имеет отношения к типу возвращаемого значения. Может я не верно выразился в том абзаце, но там речь о том что в C# методы классов и их вызовы — это конкретный тип реализации (вот какой тип имелся ввиду) абстрактной концепции протокола/контракта объекта. До появления async методы были синхронные, но практика показала что такое жёсткое поведение непрактично (хотя можно было использовать Task[T]). И добавили async/wait (которые под капотом реализованы через Task[T]).
чем вам UML то не угодил?
Именно тем что он язык моделирования. UML это на мой взгляд крайность в моделировании, ООЯП наоборот акцентируются на типах без объектной композиции. Идея в том чтобы сделать комбинированый вариант.
Добрый день!
Поправьте если ошибаюсь, 999999 строк в таблице, кол-во строк на странице 12, даёт 83333 страниц, что покрывает 999996 строк.
Этот код для 10 строк и 3 строк на страницу даёт 3 страницы. Это так задумано?
Дело не в самом тексте, а в том что дерево в XML/JSOM сериализуется как дерево, т.е. сохраняется вся информация о его узлах. В случае плоского текста утрачивается явная структура дерева, и её приходится восстанавливать прибегая к парсерам.
Можно конечно, раз это эквивалентные представления. Я уже описывал ситуацию со сниппетами, где промежуточный этап с текстом просто не нужен. Моя идея это продолжение и развитие сниппетов.
Это делается, конечно, не мышкой. Всё как обычно, как текст, только структурированый, или как сказать, шаблонированый. Вообще структурные (проекционные) редакторы (structured or projectional editors) уже существуют, мышкой там в принципе пользуются не больше чем в обычных IDE, например MPS от JetBrains.
Это от другой "фичи", черновик старый, поэтому оно действительно не связано с темой ветки.
Вообще-то это и был ответ по существу. Может я не так понял акценты в вашем вопросе, но если байты и пикселы…
Вас действительно интересует именно как сериализуется такая структура данных как дерево? Может всё-таки акцент на дереве разбора, какие там типы узлов и пр.?
Дерево разбора первично, текст — это "побочный эффект", один из способов сериализации этого дерева. Вот поэтому дерево разбора можно представить (отрендерить) не только в виде текста.
Насчёт пикселей, если позволите тогда там ссылку на свой черновик. Это совсем черновой вариант, там нет полноты функционала, и уже очень многое в концепциях/дизайне поменялось на текущий момент, но если схематично вот так себе представляю визуально.
Этот специальный формат и есть "грамматика" языка. Либо вы описываете текстовую грамматику в виде какой-нить BNF нотации, либо описываете схему формата хранения дерева, которое абсолютно эквивалентно BNF нотации текстовой грамматики. Текстовые файлы с кодом на C# и Java различаются точно также как и, например, бинарные файлы с деревьями для C# и Java. Вы не можете подать на вход компилятору C# текстовый файл с кодом на Java по известной причине, с файлами дерева точно такая ситуация.
О какой куче проблем тогда речь?
Это проблема не следствие идеи текст/дерево. Такая проблема возникнет и при разных версиях компилятора например IDE C# 7 и билд-сервер C# 5.
Формат хранения может быть любой, начиная от XML и заканчивая бинарным оптимизированным. Причём хранить можно не дерево, а граф с семантическими связями уже.
IDE и компилятор уже содержат парсер в том или ином виде ( подсветка синтаксиса и пр.). Что подавать на вход компилятору, текст или дерево/граф — это вопрос архитектуры IDE. Парсер как компонет может шариться IDE и компилятором, собственно Roslyn как раз про это.
Каких например?
Выглядеть визуально он может точно также, тут суть в том IDE показывает не текст, а отформатированое поддерево. Т.е. текст можно всегда легко получить из дерева, а вот распарсить текст — тут не всякая контекстно-зависимая грамматика справится.
Вот интересная картина получается. IDE поддерживают вставку сниппетов, типа свойство
get; private set;Т.е. человек заранее знает какой тип элемента кода ему нужен. Но IDE вставляет плоский текст и это знание теряется. Компилятор опять парсит текст чтобы понять какие там элементы указаны, свойства, методы и пр. Если бы послеpropgIDE вставляла узел дерева и показывала шаблон для указания setter and/or getter, возможно какие-то проблемы были бы просто исключены.Я предлагаю вводить типизацию постепенно. К этапу компиляции всё будет типизировано и конкретизировано, конечно. Количество информации будет не меньше, точнее говоря такое же.
Из определения типа (как множества допустимых значений (состояние) и операций над ними (поведение)) возникла идея вводить эти две составляющие раздельно. Объектная композиция основана на протоколе объектов, т.е. только поведение. Атрибуты (нетипизированые) определяют структуру объекта (понятия) но тоже без типов. Затем атрибуты объектов трактуются как состояние, контракт как поведение, там где нужно привязываются уже существующие (встроенные) типы, после этого можно проводить верификацию.
Вот как раз классификация основана на атрибутах (признаках), и любая классификация указывает по какому признаку(признакам) она производится. Введение атрибутов позволяет определять классафикацию как таковую по каким-то атрибутам. Далее, для атрибутов можно определить допустимые значения (но не операции), и тогда классфикация приводит к классам с выбраной гранулярностью. Это я к тому, что жёсткая связь из определения типа домен+операции возможно и не требуется, копмоненты типа (домен и операции) можно вводить независимо друг от друга.
Вообще, я думаю что объектный подход обоснован не тем что человек как-то мыслит объектами, а именно атрибутированными понятиями, на которых и возможны классификации.
Да, есть такое. Хотя до строгой формальности определение очевидно не дотягивает, по крайней мере задумывалось в том направлении.
На уровне нетипизированных композиций всё абстрактно и расширение семантики очень маловероятно. Но даже не в этом дело.
А дело в том, что из-за текстовой грамматики и возникает эта проблема, которую решили довольно красиво я бы даже сказал. Вот пример из статьи:
var x = await + y;При разборе как интерпретировать await — как идентификатор (тогда всё выражение это вызов бинарного оператора) или как точка разрыва и далее continuation (тогда выражение вызов асинхронного перегруженного оператора)? Решение: если у перегруженного оператора указан async — значит в данном выражении компилятор считает точка разрыва, иначе — бинарный оператор с агрументами await и y.
Если бы это была не текстовая грамматика, а некоторое дерево разбора типа AST, то проблема в принципе не возникает, т.к. await однозначно определён типом узла (т.е. это однозначно идентификатор т.к. legacy code). Чтобы извлечь смысл из плоского текста и приходится прибегать к решениям типа маркера async.
Бинго! Это и есть моя та самая гипотиза, что более конкретизированное и ограниченное определение приведёт к определённым результатам. Я описал её в виде "Потребуем, чтобы...", поэтому там "Каждая парадигма должна...".
Конечно, это очевидная мысль, и после моего определения парадигмы я показал что фунциональная парадигма удовлетворяет такому суженому определению. В черновиках статьи я и для процедурной парадигмы описал, но выкинул из-за объёма статьи.
Возвращаясь к сути поста: если допустить более сторогое (суженное) определение парадигмы (которому тем не менее удовлетворяет функциональная, но и процедурная тоже я считаю), из него вытекает некоторый смысл объектной парадигмы (я показал как на моём определени парадигмы должна выглядеть собственно объектная парадигма). Отсюда одно из следствий — ООП/ООЯП слабо поддерживают объектную композицию, и в новом языке/IDE её можно поддержать и получше.
Меня смущает то, что а) общее определение парадигмы довольно расплывчатое, б) определение А.Кея не формальное, и в) ООЯП на таком фундаменте могут интерпретировать ООП довольно в широком смысле, вплоть до потери специализации. Я считаю именно это и произошло на практике в ООЯП.
Опять же, я не против определений А.Кея или любых других. Вы, получается, поддерживаете определение А.Кея, и ООЯП в принципе с ним согласуются. Но меня не устраивает туманность и неоднозначность определений ООП, и то положение вещей что из себя предствляют ООЯП. Поэтому предлагаю пообсуждать альтернативные идеи.
Да, верно (для простоты одним словом: функиональная, процедурная, объектная).
Давайте для ясности проведём параллели. Во-первых, определение "парадигма программирования":
общепринятое: это совокупность идей и понятий, определяющих стиль написания компьютерных программ (подход к программированию). Это способ концептуализации, определяющий организацию вычислений и структурирование работы, выполняемой компьютером.
из моего поста: Любая парадигма должна определять: Примитив абстракции (...), Композиция примитивов (...), Агрегирующее отношение (...), Глобальное состояние (...)
Вы считаете эти два определения абсолютно безсвязными? Моё определение конкретизирует обтекаемое общепринятое определение (совокупность идей и понятий, определяющих стиль написания компьютерных программ), но никак не противоречит ему.
Во-вторых, определение "объекто-ориентированная парадигма". Какое определение считать общепринятым — чуть позже, главное что нужно показать как оно соответсвует общепринятому определению парадигмы программирования. В моём посте я показываю свой вариант опредения объекто-ориентированной парадигмы (но ещё и функциональной) и его соответсвие моему определению парадигмы программирования.
Теперь общепринятое определение "объекто-ориентированная парадигма": в варианте постулатов ООП или вариант Всё есть объект..., может что-то ещё? Что бы это нибыло, как оно соотносится с общепринятым определением парадигмы программирования?
Это всё следствие проявления верификации (в конечном счёте). Верификация происходит уже на этапе написания кода, и даже при чтении у нас в голове. Если понятия типизированы, семантика типов просто исключает вариации смысла понятия.
Подскажите, что вы имеете в виду под "усиливает выразительность"? Думаю как пример это могло быть Constraints on Type Parameters в generics?
Мне кажется что тут вы как раз смешиваете понятия и типизированные понятия. DSL как вокабюляр для описания предметной области можно построить и в нетипизиорванном виде, на основе семантики понятий из самой же предметной области.
Полностью согласен. Хотя классы рано или поздно будут интерпретироваться как типы.
Я имел в виду объектную парадигму, а не парадигму вообще. Как пример, покажите пожалуйста общепринятое определение объектной парадигмы? Как оно согласуется с приведёнными общими определениями парадигмы?
Не, не приехали :) Эта часть фразы обозначает вашу позицию.
По идее он не на моём определнии лучше, и лучше не в абсолютном смысле. Он лучше тем что решает проблемы (некоторые) ООП/ООЯП (которые вы почему-то свели к несоответсвию определений).
К вашим задачам это не имеет никакого отношения. ООП/ООЯП живут не одно десятилетие. В посте я высказал допущение (гипотизу), на основе которой получаются некоторые выводы. Насколько я понял, вы считаете что гипотиза не заслуживает даже постановки, не говоря уже о том чтобы разбирать её содержательную часть. Вы начали с разбора определений, хотя по-моему ими нужно заканчивать (а начинать с выводов). Суть поста: обсудить концепцию нового ЯП/IDE. Это не касается ваших задач, и не попытка модернизировать ООП/ООЯП, это просто мысли к размышлению.
Это зависит от определяемого понятия. В данном случае, для парадигмы — какого качества/удобства языки програмирования на ней построены. Такого количества критики как у ООЯП ещё надо поискать.
Пока вы не вникните в суть сепульки, как вы можете утверждать что проблемы ООП/ООЯП не в сепульке? Т.е. вы допускаете что ООП/ООЯП не без слабостей, при этом заранее уверены что не в сепульке дело?
И тем более, что суть не в соответсвии моему определению парадигмы, а в выводах которые из моих определений следуют. В контексте моих определений ООЯП имеют проблемы, в контексте общепринятых определений — не имеют. Но общепринятые определения под вопросом, мои могут оказаться как хуже так и лучше. Т.о. общепринятые определения не истина, а допущение (как и моё). Я не могу пока показать конечный вывод из моей "теории" в виде языка (IDE), чтобы можно было показать что постоеный язык (IDE) на моём определении лучше (или хуже) чем существующие ООЯП. Этот пост демонстрирует промежуточные выводы, и только в таком умозрительном виде, к сожалению.
Т.е. вы имеет ввиду что всё-таки существует какое-то общепринятое определение? Которое определяет объектную парадигму и которому удовлетворяют ООП/ООЯП и которое не совпадает с моим определением? Общепринятого определения парадигме нет, отсюда следует простой вывод: какое-бы не было сущесвующее определение (и которое вы подразумеваете) — оно спорное и потенциально содержит изъяны, следовательно моё определение (теоретически) может быть более правильным.
То, что если вы не видите проблем, вовсе не означает их там действительно нет. Допустим, для вас существующие определения объектоной парадигмы и ООЯП вполне согласуются. Но без анализа содержательной части моего поста вы не можете утверждать что в ООП нет проблем — я как раз утверждаю что есть. Разработчики ООП/ООЯП могли ошибаться и текущее определения ошибочны. Я и пытаюсь в посте показать своё видение и какие следствия из него получаются.
По-моему мы о понятиях на разных уровнях. Технически (это о чём говорите вы как я понял), конечно, async метод синхронно возвращает задачу, но собственно результат вызова придёт асинхронно (ещё и с возможной сменой потока, в зависимости от планировщика). Но это всё техническая сторона.
Я же говорю о грамматике языка, что async/wait это ключевые слова с конкретной семантикой, т.е. на уровне языка появились новые слова. Т.е. теперь на уровне языка есть синхронные и асинхронные методы. Моя мысль в том что на уровне объектной композиции вообще не нужно задавать тип реализации контракта.
Определение парадигмы (по-моему достаточное для темы) дано в самом начале поста, собственно вы и процетировали его начало. Я определил парадигму через её ключевые атрибуты и указал смысл этих атрибутов.
Вы ожидаете какое-то общепринятое определение, и которое будет совпадать с моим (точнее наоборот, моё должно совпадать с ним)? Википедийное определение заключается в том, что нет общепринятого и однозначного определения парадигмы. Но всё это и не требуется. Моё определение — это допущение, что если оно верно, то верны и следствия из него (при условии корректности вывода).
Например, покажите пожалуйста ложность/противоречивость моих выводов, тогда автоматом встанет вопрос о корректности изначальных допущений (в данном случае определение парадигмы) и/или логики вывода.
APM который вы имеете ввиду — это не часть языка C#, я же говорю про сам язык. APM это паттерн, причём как в варианте Begin/End/IAsyncResult, так и в вариации Event-based Asynchronous Pattern, а затем и Task-based Asynchronous Pattern (TAP). Но сам язык C# формально сделал методы асинхронными с введением ключевых слов async/wait.
Модификатор async, разумеется, не имеет отношения к типу возвращаемого значения. Может я не верно выразился в том абзаце, но там речь о том что в C# методы классов и их вызовы — это конкретный тип реализации (вот какой тип имелся ввиду) абстрактной концепции протокола/контракта объекта. До появления async методы были синхронные, но практика показала что такое жёсткое поведение непрактично (хотя можно было использовать Task[T]). И добавили async/wait (которые под капотом реализованы через Task[T]).
Именно тем что он язык моделирования. UML это на мой взгляд крайность в моделировании, ООЯП наоборот акцентируются на типах без объектной композиции. Идея в том чтобы сделать комбинированый вариант.