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