Фактически это проприетарная лицензия с доступным исходным кодом, а не лицензия с открытым исходным кодом.
Не цитируйте слова коммерческих компаний и купленных ими аналитиков.
Это такая же свободная и открытая лицензия, только со своими особенностями для сервис провайдеров. Она не запрещает использовать ПО, а налагает условие для такого использования. И это ничем не отличается от GPL, копилефт которой так же должен распространяться на линкуемое ПО.
Очень похоже, что в левитации задействован эффект волчка (гиростабилизатор), который очень заметен на первых минутах видео. После замены левитирующего предмета на шар, эффект вращения уже не бросается в глаза.
Посмотрите комментарии к предыдущей статье habr.com/ru/post/531400.
Тестируемая идея почти в точности соответствует ДСЛ (человекопонятный язык для всех).
Но очень простой контраргумент, какой бы язык предметной области не был и пользователь его не знает, то он будет новым для него языком, который все равно нужно будет учиться применять (правила, возможные комбинации и допустимые взаимодействия, исключения из правил т.д.), и это даже в том случае, если сами термины ему знакомы. Ведь простого знания слов не достаточно для их реального применения.
А вот с любым формализованным языком гораздо проще. В них практически нет исключений из правил, и самое главное, публикуя объявление о вакансии на должность разработчика со заданным стеком технологий, можно быть уверенным, что эти знания описаются на реальную базу, а не на кастомный диалект ДСЛ языка, который он использовал в одном из предыдущих проектов.
А что касается автоматической проверки правил, в формальных ЯП можно не только правила проверять, но и использовать различные сканеры кода для выявления ошибок, потенциальных уязвимостей и пр. И пять, это сделать гораздо проще и удобнее для единого формального языка, чем городить огород для своего подмножества.
Подходов может быть множество, и я ничуть не возражаю против описанного вами, хотя некоторые места мне и кажутся сомнительными (например, создание собственного языка под свою собственную задачу).
Ведь если спрогнозировать его развитие, то в конечном итоге каждая библиотека или заимствованный модуль будут иметь свой собственный язык.
И эта проблема возникает на пустом месте, просто потому, что у хорошего архитектора с разработчиком появилось мысль, сделать пользователям хорошо, уменьшив порог вхождения и реализовать собственное подмножество языка :-)
Это относится скорее к методологии разработки, а не к языкам программирования. И она, по моему, достаточно хорошо вписывается в концепцию Языково-ориентированного программирования
Меня и текущее определение вполне устраивает «Декларати́вное программи́рование — парадигма программирования, в которой задаётся спецификация решения задачи, то есть описывается, что представляет собой проблема и ожидаемый результат.»
Я не согласен с необоснованным ограничением для основного определения.
Например, спецификация решения задачи, как «результат выполнения функции равен значению, хранящемуся в переменной», будет вполне в декларативном стиле.
И причем тут запрет на использование переменных? Ведь это только один из способов реализации чистоты функций, причем не единственный.
Честно говоря, я не согласен с утверждением, что «Как следствие, декларативные программы не используют понятия состояния, в частности, не содержат переменных и операторов присваивания, обеспечивается ссылочная прозрачность.»
Отсутствие переменных, это один из способов реализации конкретной проблемы и не более того. Но сама проблема (отказ от состояния и обеспечение ссылочной прозрачности), не является частью или обязательной составляющей парадигмы декларативного программирования.
Так я и не приводил примеры по теме «программирования в ограничениях».
Изначально, вы меня обвили в том, что проблема «Комбинаторного взрыва» вообще не имеет отношения к декларативному программированию и ссылаетесь на концепцию «Программирование в ограничениях».
Но согласно вики, эта концепция как раз и является подмножеством декларативного программирования.
Если честно, что я вообще потерял предмет обсуждения.
… сам по себе не решит на обум вашу задачу, для этого, вам необходимо еще и дать очень детальное и непротиворечивое описание конкретно вашего частного случая.
Так я с этого и начал пару комментариев выше.
И у меня нет «механизма поиска решений». Я просто отметил определенную проблему, что в тех предметно ориентированных языках, где «механизм поиска решений» реализован, при определенных условиях могут возникать сложности с поиском решений.
Лол, вы до моего комментария не знали о существовании программирования в ограничениях, иначе бы хоть как-то упомянули его в своей статье, а теперь мне же цитируете вики по данной теме)
Конечно, индексы это детали реализации. Ровно такие детали и скрыты для программиста, в то время, когда он пишет запросы к данным.
Именно поэтому такой стиль написания и называется декларативным. Так как оставляет на усмотрение компьютера детали его выполнения.
Что же касается оптимизации, то тут ничего сомнительного. Что будет легче, оптимизировать одну единственную строку или уже множество строк, между которыми могут быть различные связи, в том числе рекурсивные?
Я писал не про сам Пролог, а назвал его только как самый распространенный пример и прародитель языков логического программирования.
На нем действительно можно писать программы в интересном стиле, но уж очень они заумно выглядят. Но если ты в этом сумел разобраться, то действительно — становится море по колено!
Один из вариантов реализации поиска решения — полный перебор вариантов.
Еще один, уже поддерживающий оптимизацию — SQL.
Любой диалект Пролога, тоже пойдет как вариант реализации механизма поиска решений.
Как видите, вариантов реализации уже сейчас много, и еще больше можно придумать, особенно их различных комбинаций. Вот только все они завязаны либо на свою предметную область, либо привязаны к конкретному языку программирования (среде выполнения).
Одной из проблем Пролога отмечают как раз отсутствие возможности писать программы в императивном стиле.
Поэтому, я с вами соглашусь, что использовать только декларативный не очень удобно и гораздо лучше иметь возможность комбинировать стили написания в рамках одной программы.
А Open Source Definition — это условия для использования товарного знака
Это такая же свободная и открытая лицензия, только со своими особенностями для сервис провайдеров. Она не запрещает использовать ПО, а налагает условие для такого использования. И это ничем не отличается от GPL, копилефт которой так же должен распространяться на линкуемое ПО.
так как:Для меня, это самый ужасный конфиг, т.к. в нем нельзя использовать возможности автоматического форматирования :-)
Тестируемая идея почти в точности соответствует ДСЛ (человекопонятный язык для всех).
Но очень простой контраргумент, какой бы язык предметной области не был и пользователь его не знает, то он будет новым для него языком, который все равно нужно будет учиться применять (правила, возможные комбинации и допустимые взаимодействия, исключения из правил т.д.), и это даже в том случае, если сами термины ему знакомы. Ведь простого знания слов не достаточно для их реального применения.
А вот с любым формализованным языком гораздо проще. В них практически нет исключений из правил, и самое главное, публикуя объявление о вакансии на должность разработчика со заданным стеком технологий, можно быть уверенным, что эти знания описаются на реальную базу, а не на кастомный диалект ДСЛ языка, который он использовал в одном из предыдущих проектов.
А что касается автоматической проверки правил, в формальных ЯП можно не только правила проверять, но и использовать различные сканеры кода для выявления ошибок, потенциальных уязвимостей и пр. И пять, это сделать гораздо проще и удобнее для единого формального языка, чем городить огород для своего подмножества.
Ведь если спрогнозировать его развитие, то в конечном итоге каждая библиотека или заимствованный модуль будут иметь свой собственный язык.
И эта проблема возникает на пустом месте, просто потому, что у хорошего архитектора с разработчиком появилось мысль, сделать пользователям хорошо, уменьшив порог вхождения и реализовать собственное подмножество языка :-)
Я не согласен с необоснованным ограничением для основного определения.
Например, спецификация решения задачи, как «результат выполнения функции равен значению, хранящемуся в переменной», будет вполне в декларативном стиле.
И причем тут запрет на использование переменных? Ведь это только один из способов реализации чистоты функций, причем не единственный.
Отсутствие переменных, это один из способов реализации конкретной проблемы и не более того. Но сама проблема (отказ от состояния и обеспечение ссылочной прозрачности), не является частью или обязательной составляющей парадигмы декларативного программирования.
Изначально, вы меня обвили в том, что проблема «Комбинаторного взрыва» вообще не имеет отношения к декларативному программированию и ссылаетесь на концепцию «Программирование в ограничениях».
Но согласно вики, эта концепция как раз и является подмножеством декларативного программирования.
Если честно, что я вообще потерял предмет обсуждения.
И у меня нет «механизма поиска решений». Я просто отметил определенную проблему, что в тех предметно ориентированных языках, где «механизм поиска решений» реализован, при определенных условиях могут возникать сложности с поиском решений.
Именно поэтому такой стиль написания и называется декларативным. Так как оставляет на усмотрение компьютера детали его выполнения.
Что же касается оптимизации, то тут ничего сомнительного. Что будет легче, оптимизировать одну единственную строку или уже множество строк, между которыми могут быть различные связи, в том числе рекурсивные?
На нем действительно можно писать программы в интересном стиле, но уж очень они заумно выглядят. Но если ты в этом сумел разобраться, то действительно — становится море по колено!
Еще один, уже поддерживающий оптимизацию — SQL.
Любой диалект Пролога, тоже пойдет как вариант реализации механизма поиска решений.
Как видите, вариантов реализации уже сейчас много, и еще больше можно придумать, особенно их различных комбинаций. Вот только все они завязаны либо на свою предметную область, либо привязаны к конкретному языку программирования (среде выполнения).
Поэтому, я с вами соглашусь, что использовать только декларативный не очень удобно и гораздо лучше иметь возможность комбинировать стили написания в рамках одной программы.