Комментарии 18
Судя по описанию, вы пытаетесь изобрести ООП с его абстракцией, наследованием, инкапсуляцией и полиморфизмом. Если нет, то в чём отличие вашего подхода?
Переведите слово "потяное'. Это понимать как протяжное? Не сочтите за придирку.
Это по поводу JSON. Ну 1) малое количество символов: скобки {}, кавычки ", запятая , и вроде все. 2) простая (по сравнению с xml) структура документа, нет аттрибутов, namespace'ов из xml и т.д. 3) маленькое количество типов данных 4) и в целом когда смотришь на JSON обычно сразу понимаешь что там написано.
Самый главный вопрос: что такое "свойство" в вашей идее? Мы знаем интерфейс: пометку "этот компонент обладает/должен обладать свойством X", которую ставит программист. Мы знаем композицию: разбитие кода на компоненты со своими отдельными задачами, а затем сбор их в единый механизм. Мы знаем наследование с переиспользованием кода из родительского класса в дочернем. Мы знаем аннотации, хуки и т.д. и т.п.. Мы Что такое "свойство"? Как свойство реализуется и обеспечивается? Как происходит интеграция свойства и нового компонента и свойств между собой?
Определенно нужно больше примеров, сейчас непонятно. Кажется, что вы хотите то ли просто множественное наследование с соблюдением принципа Лисков, то ли просто грамотную композицию, то ли что-то из аспектно-ориентированного программирования. Кроме объекта (набора данных) и функции (исполняемого кода) какие еще низкоуровневые компоненты можно вообразить и зачем? А если на примерах, более приближенных к бизнес-логике? Идеально было бы схематично описать компоненты какого-нибудь проекта чуть сложнее hello world.
Свойства имхо проистекают из реализации. При создании нового компонента из базового "сериализуемый" как-то понадобится сериализовать новую структуру: значит, либо базовый компонент должен быть достаточно универсален, либо все-таки придется допиливать такую интеграцию, что, кажется, рушит саму идею.
Ну и свойство может оказаться в принципе невозможным: например, "json-сериализуемый" будет фактически невыполним для производного компонента, если в нем используется ленивая подгрузка огромного объема данных, да с правами доступа, а получаемые им данные неконсистентны в отдельный момент времени и содержат рекурсии.
"Простая в структура и понимании" - это просто субъективная оценка, а не свойство.
Кстати, объекты и функции могут быть безымянными как в исходном коде, так и в скомпилированном.
"Свойство" - это то, что можно русским языком расскзать об объекте/сущности.
Например, когда мы описываем функции, обычно мы говорим: "функция имеет имя". Вот то, что "функция имеет имя" - это и есть "свойство" такого объекта как функция.
Т.е, относитесь к свойствам - как к предложениям на русском языке, которыми можно описать функцию. Вот сколько предложений о функции вы сможете сказать - столько свойств и есть у функции.
А затем начинается экспресиионизм - мы говорим несколько предложений о функции и несколько предложений о json строке. И затем комбинируем эти предложения между собой (1-е предложение описывающее функцию, 2-е предложеие описывающее функцию и 3-е предложение описывающее json строку), и пытамеся создать новый объект, обладающий данной комбинацией предложений.
И если бы мы могли внедрить в свой язык программирования новые ключевые слова или любые новые объекты (функции, трейты, интерфейсы, миксины и все что хотим), то мы бы добавили новое ключевое слово и наш язык программирования стал бы описываться нашей парадигмой (нашей комбинацией предложений на русском языке). И это было бы истинно парадигмой программирования.
Но мы не пишем свой язык программирования, по-этому мы не можем добавить новые ключевые слова или новые "объекты" (функции, трейты, интерфейсы, миксины) в свой язык. По-этому мы используем стандартные, данные в нашем языке программирования сущности, и поверх них создаем "метапрограммирование" - поверх функций, трейтов, интерфейсов, миксинов создаем новую сущность, которую если описывать на русском языке, то она будет описана теми предложенями, которые мы решили объединить.
Например в ООП языке программирования новая сущность будет скорее всего классом, реализующим определенное поведение. Например если мы комбинируем 2 свойства - имеет имя и может выполняться, то у нашего класса будет поле name и будет реализован интерфейс типа Invokable, чтобы наш объект можно было вызвать через obj(); Если захотим добавить совйство "может сериализоваться в простую строку", то реализуем интерфейс Stringable.
Т.е. новая сущность - это класс, имеющий поля и реализующий интерфейсы. А в функциональном языке программирования - набор функций.
И тут мы получаем уже не парадигму программирования, а некий "подход к построению метаобъектов (мета - потому что объект поверх стандартных объектов - функции, класса и т.д.) и из этих объектов состоит наша программа, которая выполняет полезное действие". Не парадигма программирования, но некий подход к программированию.
Хм. Давайте пойдем от обратного: когда ООП-код не является реализацией вашей парадигмы? Вот возьмем классический учебный пример с гавкающей собакой: он подходит под ваше описание. Я комбинирую свойства "имеет имя" и "умеет гавкать" и получаю новый компонент - собаку. Затем хочу получить возможность сохранения и добавляю метод ToString() под интерфейс Stringable.
class Dog {
Name string
Bark() {...}
}
Да, все верно, на ООП можно реализовать смыслы, которые я писал в статье. Но можно и не реализовать (если написать плохо по ООП). Т.е. тут я говорю в одной плоскости, а ООП в параллельной плоскости, одно не исключает другого.
Если прям дотошно придираться к слову "парадигма", то я могу предложить выделить минимальные "свойства" в различных языках программирования, скомбинировать их и написать свой язык программирования со своей уникальной комбинацией этих минимальных "свойств", и тогда это уже будет язык программирования своей парадигмы.
И вот выделение этих "минимальных" свойств (элементарных частиц) (и их комбинация) и есть мое предложение парадигмы.
Уважаемый Автор! В Вашем тексте я обнаружил попытку переосмыслить программные парадигмы, так сказать взглянуть на мир программирования по новому, но прежде чем изобретать велосипеды не лучше ли было обратиться к основам программирования? так сказать к теории! Теория наше ВСЁ! И поскольку в тексте очень часто встречается слово "комбинирование" вам нужно ознакомиться с "комбинаторной логикой", эта теория лежит даже глубже лямбда-исчисления, лежащего в основе функциональной парадигмы. Так что рекомендую поискать в интернете: Автор В.Э.Вольфенгаген "Комбинаторная логика в программировании".
Хороший плейлист на тему
По-моему, здесь описано множественное наследование от нескольких абстрактных классов.
Ну, да, трейты и миксины.
Не совсем понял, в чём новизна
Напишите яснее какая проблема существует и как ее решает ваша "парадигма". Иначе непонятно вообще про что речь и зачем это нужно.
На мой взгляд, без конкретных примеров кода для тех же Функции, Класса, JSON эту статью можно интерпритеровать кто как хочет.
Например, как описание миксинов или множественного наследования. А на практике этим может и оказаться )
Великий комбинатор)
Весь этот грабёж корованов (других ассоциаций не возникло) вполне достижим с использованием обеих основных парадигм программирования. Грабить корованы - это не парадигма, а идея
Итак, имеем тои сущности: данные, способ их обработки, протокол для взаимодействия с внешним миром.
Вне рассмотрения остаётся множество мелких, но очень опасных деталей, вроде присваивания, что делает Вашу парадигму обманчиво простой.
Мне был бы очень интересен пример метапрограммы, написанной в объявленной парадигме.
Программирование тем и интересно, что к любой теории всегда прилагается пример :-)
Может быть Вам стоит посмотреть на EO (Eolang), где все есть объект?
А так хорошо бы продемонстрировать предложение примерами, чтобы слова о парадигме были отражены в коде...
Моя парадигма программирования