Комментарии 86
Для этого нужна ассоциативная память на аппаратном уровне, почти такая-же как у нас в мозгах.
Вряд ли все дело в этом. Поведение «почти как как в мозгах» уже частично реализуется на обычных. Со временем наверно придумают и что-то другое, в том числе и ассоциативную память.
Уже давно придумали, только в кремнии реализовать не получается. Обычное адресное пространство на кремнии — линейное. А ассоциативная память живёт в многомерном адресном пространстве. Да для неё даже математику и логику ещё не изобрели в полной мере, так — общие концепты на базовых операциях сложения и вычитания.
И да, основной прикол, нуля как математической единицы для такой памяти не существует.
И да, основной прикол, нуля как математической единицы для такой памяти не существует.
Только хотел написать, что мы — аппаратное обеспечение для такого языка.
Ох уж эта молодость! Дискету как, часто в дисковод вставляешь? По-прежнему читается? Ну орёл!
Знакомые удивляются, как это — заголовок «Проблема логических языков программирования», и не строки кода? Не считывают они, что весь текст статьи — код на эзотерическом языке 'Эпилог', языке кинетическом, кларнетическом, протяжном.
И память для этого нужна на самом памятном уровне, иные уровни здесь не вытянут.
p.s. для дочитавших досюда — закрывающий тэг \сарказм.
Знакомые удивляются, как это — заголовок «Проблема логических языков программирования», и не строки кода? Не считывают они, что весь текст статьи — код на эзотерическом языке 'Эпилог', языке кинетическом, кларнетическом, протяжном.
И память для этого нужна на самом памятном уровне, иные уровни здесь не вытянут.
p.s. для дочитавших досюда — закрывающий тэг \сарказм.
Ха, я бы не сказал, что эти языки — эпилог.
Я буквально недавно использовал сви-пролог для написания поиска словоформ. Перед этим пытался сделать то же на стримах Java с не очень впечатляющими результатами. Да ещё и намучился. Всё-таки работать с большим количеством вариантов и их комбинаций на логическом языке проще.
Кстати после оптимизаций пролог-версия стала работать быстрее императивной. Это во вполне себе современном swi-prolog. А ведь есть ещё новый многообещающий Mercury, который по некоторым утверждениям вообще летать будет.
Что касается именно задач ИИ, то конечно логическое программирование относится к отыгравшему поколению, не оправдав заявленных ожиданий. Но своя ниша у него безусловно есть.
>Что касается именно задач ИИ, то конечно логическое программирование относится к отыгравшему поколению, не оправдав заявленных ожиданий.
Строго говоря, то что называется сегодня ИИ (как правило это ML) основано по большей части на идеях, которые нам еще преподавали на третьем курсе (а это было ой как давно). Ну т.е. новые идеи, плюс более мощные железки — и оно таки выстрелило через много лет после изобретения.
Я бы не исключал такого, что идеи пролога можно объединить с тем же ML, и получить некое новое качество. Просто еще никто не придумал, как.
Строго говоря, то что называется сегодня ИИ (как правило это ML) основано по большей части на идеях, которые нам еще преподавали на третьем курсе (а это было ой как давно). Ну т.е. новые идеи, плюс более мощные железки — и оно таки выстрелило через много лет после изобретения.
Я бы не исключал такого, что идеи пролога можно объединить с тем же ML, и получить некое новое качество. Просто еще никто не придумал, как.
Я бы не исключал такого, что идеи пролога можно объединить с тем же ML, и получить некое новое качество. Просто еще никто не придумал, как.+1
> а это было ой как давно
Представьте себе, это было ещё раньше (70-е годы).
Представьте себе, это было ещё раньше (70-е годы).
Так я и учился в 70-х.
А какие вам идеи рассказывали на третьем курсе? Градиентный спуск?
Ну да, например и это. У нас был отдельный курс на эту тему. Это никто не называл машинным обучением — курс кажется звали Теория оптимизации.
Ну, видимо, потому что машинное обучение не является просто градиентным спуском, а лишь одним из многочисленных прикладных областей, которые ГС используют?
Ну так я и не говорю, что машинное обучение родилось в 70-х. Но многие идеи достаточно старые — просто реализовать их на новом уровне получилось недавно (и новые идеи конечно же тоже в наличии).
Градиентный спуск и другие методы оптимизации — лишь один из кирпичиков в фундаменте, и, вообще, для машинного обучения практически чёрный ящик (оно эти методы не исследует, а просто использует). Вас ведь не смущает, что современные писатели пишут примерно тем же алфавитом (с косметическими изменениями) те же слова (с косметическими изменениями), которые писал ещё Пушкин? Означает ли это, что они лишь реализуют на новом уровне идеи Пушкина и ничего принципиального за 200 лет не произошло?
Я ровно на этот вопрос только что отвечал :)
>новые идеи конечно же тоже в наличии
И тут совершенно не имелось в виду, что все основано на старых идеях, а новые — просто бантики.
>новые идеи конечно же тоже в наличии
И тут совершенно не имелось в виду, что все основано на старых идеях, а новые — просто бантики.
Есть мнение Борхеса, что вся литература состоит всего из четырех архетипических сюжетов.
Так что сравнение не очень удачное. Наука все-таки периодически радует реально новыми открытиями.
Так что сравнение не очень удачное. Наука все-таки периодически радует реально новыми открытиями.
Мне кажется, что Пролог и его различные диалекты, просто появились во времена, еще до начала поголовного увлечения нейросетями. В противном случае, в нем бы обязательно имелись инструменты по их обучению и/или использованию.
Возможно, проблему комбинаторного взрыва решат квантовые вычисления, тем более что они по природе своей скорее декларативные. Но тут я профан, это чисто интуитивное ощущение.
К декларативному стилю написания программ следует относить и язык структурированных запросов (SQL)
основное применения языков программирования в декларативном стиле — отказаться от необходимости описания четкого алгоритма поиска решения, отдав это компьютеру на откуп. Для которого самое простое решение «в лоб» — полный перебор возможных вариантов.
Именно в этом случае и начинается экспоненциальный рост времени выполнения алгоритма.
вы рассказываете о какой-то теории большого «Комбинаторного взрыва» вообще не понимая что это такое, и что к декларативному программированию это совсем не имеет отношения.
в противном случае никто бы не использовал SQL (некоторые задачи решаемые в рамках его предметной области могут привести к «взрыву» комбинаций которые необходимо обработать, но это совсем другой вопрос).
Программирование в ограничениях наиболее адекватный общий знаменатель ваших рассуждений с применением понятий «логическое программирование», «комбинаторный взрыв» и «декларативное программирование».
Программирование в ограничениях — это один из вариантов логического программирования, которое относится к декларативной парадигме.
А SQL используют вполне успешно в первую очередь из-за того, что запрос в одну строку значительно легче оптимизировать, чем заниматься оптимизацией программы в целом.
Но если запрос оптимизировать не получается (например, нет индекса по нужным полям), то он начинает выполнятся путем полного перебора вариантов, который и может привести к комбинаторному взрыву.
А SQL используют вполне успешно в первую очередь из-за того, что запрос в одну строку значительно легче оптимизировать, чем заниматься оптимизацией программы в целом.
Но если запрос оптимизировать не получается (например, нет индекса по нужным полям), то он начинает выполнятся путем полного перебора вариантов, который и может привести к комбинаторному взрыву.
Но вы же понимаете, что индексы — лишь особенность реализации, которая к самому SQL и реляционной алгебре отношения не имеет?
Плюс «одна строка» тоже очень сомниельное утверждение, суть же не в длине строкового представления запроса, а в связях внутри него.
Конечно, индексы это детали реализации. Ровно такие детали и скрыты для программиста, в то время, когда он пишет запросы к данным.
Именно поэтому такой стиль написания и называется декларативным. Так как оставляет на усмотрение компьютера детали его выполнения.
Что же касается оптимизации, то тут ничего сомнительного. Что будет легче, оптимизировать одну единственную строку или уже множество строк, между которыми могут быть различные связи, в том числе рекурсивные?
Именно поэтому такой стиль написания и называется декларативным. Так как оставляет на усмотрение компьютера детали его выполнения.
Что же касается оптимизации, то тут ничего сомнительного. Что будет легче, оптимизировать одну единственную строку или уже множество строк, между которыми могут быть различные связи, в том числе рекурсивные?
Лол, вы до моего комментария не знали о существовании программирования в ограничениях, иначе бы хоть как-то упомянули его в своей статье, а теперь мне же цитируете вики по данной теме)
Термин парадигма как раз является абстракцией самого высокого уровня в категоризации языков программирования, и отнести к нему можно очень много всякого.
Но когда вы отождествляете создание механизма решения задач и сопутствующую проблему комбинаторного взрыва с парадигмой программирования — это крайне глупо.
За языком SQL как раз стоит отличная реализация механизма решения задач, но как и всякий механизм его можно сломать — т.е. не понимая базовых принципов работы таки сделать ему комбинаторный взрыв (перемножить две таблицы по миллиарду строк, ну это диверсия а не проблема языка). Вот как раз ваш же пример основывается на том как сломать механизм своим невежеством
Термин парадигма как раз является абстракцией самого высокого уровня в категоризации языков программирования, и отнести к нему можно очень много всякого.
Но когда вы отождествляете создание механизма решения задач и сопутствующую проблему комбинаторного взрыва с парадигмой программирования — это крайне глупо.
За языком SQL как раз стоит отличная реализация механизма решения задач, но как и всякий механизм его можно сломать — т.е. не понимая базовых принципов работы таки сделать ему комбинаторный взрыв (перемножить две таблицы по миллиарду строк, ну это диверсия а не проблема языка). Вот как раз ваш же пример основывается на том как сломать механизм своим невежеством
Но если запрос оптимизировать не получается (например, нет индекса по нужным полям),когда это за наличие необходимых индексов стал отвечать SQL?! При этом адекватный запрос и без индексирования успешно выполнится, это как раз уже вопрос оптимизации, при чем формальной и без тупого перебора вариантов.
Раз вы лучше меня знаете про программирование в ограничениях, то может быть приведете какой нибудь пример по затронутой теме?
Вам примеров из википедии мало?
Так это вам примеры из вики не нравятся.
Лол, вы до моего комментария не знали о существовании программирования в ограничениях, иначе бы хоть как-то упомянули его в своей статье, а теперь мне же цитируете вики по данной теме)
Не видел от вас никаких примеров по теме «программирования в ограничениях».
Если что, то предметная область SQL к данному классу проблем не относится)
С вики все норм, просто даже после того, как вы прочитали что это такое, не поняв сути, строите на его же основании контраргументы вполне разумному замечанию:
Если что, то предметная область SQL к данному классу проблем не относится)
С вики все норм, просто даже после того, как вы прочитали что это такое, не поняв сути, строите на его же основании контраргументы вполне разумному замечанию:
Программирование в ограничениях — наиболее адекватный общий знаменатель ваших рассуждений с применением понятий «логическое программирование», «комбинаторный взрыв» и «декларативное программирование».
Так я и не приводил примеры по теме «программирования в ограничениях».
Изначально, вы меня обвили в том, что проблема «Комбинаторного взрыва» вообще не имеет отношения к декларативному программированию и ссылаетесь на концепцию «Программирование в ограничениях».
Но согласно вики, эта концепция как раз и является подмножеством декларативного программирования.
Если честно, что я вообще потерял предмет обсуждения.
Изначально, вы меня обвили в том, что проблема «Комбинаторного взрыва» вообще не имеет отношения к декларативному программированию и ссылаетесь на концепцию «Программирование в ограничениях».
Но согласно вики, эта концепция как раз и является подмножеством декларативного программирования.
Если честно, что я вообще потерял предмет обсуждения.
вы меня обвили в том, что проблема «Комбинаторного взрыва» вообще не имеет отношения к декларативному программированию и ссылаетесь на концепцию «Программирование в ограничениях»на самом деле это ваша трактовка данного
Но когда вы отождествляете создание механизма решения задач и сопутствующую проблему комбинаторного взрыва с парадигмой программирования — это крайне глупо.Не стоит смешивать в одно парадигмы программирования, классы задач, специфические проблемы, если уже давно есть конкретные направления работающие на стыке всего вышеперечисленного (подсказка: это «Программирование в ограничениях). Хотя это лишь моя попытка увязать изложенное вами в данной статье, и похоже вы и сами четко не знаете о чем это все, т.к. нет описания конкретных задач, четкого теоретического обоснования.
Мне кажется, тут нужно понять, откуда брался избыточный оптимизм и интерес к подобным системам в прошлом, и как ко всему этому надо относиться сейчас. В «те времена» у каждого языка была какая-то «фишка», чётко позиционировавшая язык в определённой нише. Для обучения, для системного программирования, для бухгалтерии, для математики и т.п.
Сейчас, конечно, тоже можно сказать, что C годится для микроконтроллеров, а JavaScript… ах, ну да, привет, Node.js и Electron. Сейчас (несмотря на всё ещё имеющееся разделение) хорошие идеи кочуют из языка в язык, и разница по большому счёту становится всё более косметически-стилистической, а умение стыковаться с модулями на других языках так просто обязательно для любого вменяемого средства разработки.
Так вот, банальное умение работать с фиксированной точкой в Коболе или хорошая математическая библиотека Фортрана уже могли быть достаточными причинами для выбора конкретного языка. Это сейчас можно рассуждать в стиле «да чё, не найду я на гитхабе хорошей библиотеки для численного решения уравнений?» Соответственно, встроенный «решатель» constraint satisfaction problem уже мог считаться мощной встроенной фичей, особенно в свете тогдашних планов реализовать это всё в быстром железе.
Да, часто встречающееся в источниках утверждение типа «мы просто опишем, что хотим получить, а компьютер сам найдёт способ найти ответ» — это чистое враньё, и думать о том, как именно компьютер в данном случае действует, всё-таки приходится. Впрочем, в известной книге Братко куда более честно сказано, что «многие придерживаются мнения, что лучше иметь хоть какую-то декларативную семантику, чем никакой». Ну, допустим.
Так вот, мне кажется, в наше время мало смысла рассматривать Пролог именно как «Язык Пролог». Он весь построен вокруг некоей единственной «фишки», которая сейчас может считаться уже библиотечной функциональностью. Имеет ли смысл constraint satisfaction problem solver? Да конечно, имеет! Но нужно ли всю программу писать в таком стиле — вот тут уже большой вопрос. Мне кажется, что если я увижу, что где-то возникла именно такого рода задача, я скорее подключу дополнительный модуль «решателя» в свою программу на C++/Python/whatever, нежели решу всё от начала до конца писать на Прологе.
Сейчас, конечно, тоже можно сказать, что C годится для микроконтроллеров, а JavaScript… ах, ну да, привет, Node.js и Electron. Сейчас (несмотря на всё ещё имеющееся разделение) хорошие идеи кочуют из языка в язык, и разница по большому счёту становится всё более косметически-стилистической, а умение стыковаться с модулями на других языках так просто обязательно для любого вменяемого средства разработки.
Так вот, банальное умение работать с фиксированной точкой в Коболе или хорошая математическая библиотека Фортрана уже могли быть достаточными причинами для выбора конкретного языка. Это сейчас можно рассуждать в стиле «да чё, не найду я на гитхабе хорошей библиотеки для численного решения уравнений?» Соответственно, встроенный «решатель» constraint satisfaction problem уже мог считаться мощной встроенной фичей, особенно в свете тогдашних планов реализовать это всё в быстром железе.
Да, часто встречающееся в источниках утверждение типа «мы просто опишем, что хотим получить, а компьютер сам найдёт способ найти ответ» — это чистое враньё, и думать о том, как именно компьютер в данном случае действует, всё-таки приходится. Впрочем, в известной книге Братко куда более честно сказано, что «многие придерживаются мнения, что лучше иметь хоть какую-то декларативную семантику, чем никакой». Ну, допустим.
Так вот, мне кажется, в наше время мало смысла рассматривать Пролог именно как «Язык Пролог». Он весь построен вокруг некоей единственной «фишки», которая сейчас может считаться уже библиотечной функциональностью. Имеет ли смысл constraint satisfaction problem solver? Да конечно, имеет! Но нужно ли всю программу писать в таком стиле — вот тут уже большой вопрос. Мне кажется, что если я увижу, что где-то возникла именно такого рода задача, я скорее подключу дополнительный модуль «решателя» в свою программу на C++/Python/whatever, нежели решу всё от начала до конца писать на Прологе.
Как вы считает, а реально ли создать язык логического программирования, который бы сам умел автоматизировать поиск решений для задач подобных классов?
Казалось бы и при чем тут язык программирования. Вы ищете механизм решения задач, а не механизм их описания. Для описания хватит и самого пролога и кучи других подобных решений. А вот с механизмами решения пока проблемы, но это совсем никак не относится к языку…
Язык программирования задает высокоуровневые абстракции, которыми и оперирует программист. И в конечном итоге все равно все скатывается к низкоуровневому машинному коду, но программировать на нем сейчас уже никто не пытается.
Так и с поиском решений. Недостаточно сделать классную реализацию, еще требуется удобный интерфейс для взаимодействия с ней, которым как раз и может являться язык программирования.
Так и с поиском решений. Недостаточно сделать классную реализацию, еще требуется удобный интерфейс для взаимодействия с ней, которым как раз и может являться язык программирования.
Странный ход мыслей, делать интерфейс к реализации которой еще нет)
Один из вариантов реализации поиска решения — полный перебор вариантов.
Еще один, уже поддерживающий оптимизацию — SQL.
Любой диалект Пролога, тоже пойдет как вариант реализации механизма поиска решений.
Как видите, вариантов реализации уже сейчас много, и еще больше можно придумать, особенно их различных комбинаций. Вот только все они завязаны либо на свою предметную область, либо привязаны к конкретному языку программирования (среде выполнения).
Еще один, уже поддерживающий оптимизацию — SQL.
Любой диалект Пролога, тоже пойдет как вариант реализации механизма поиска решений.
Как видите, вариантов реализации уже сейчас много, и еще больше можно придумать, особенно их различных комбинаций. Вот только все они завязаны либо на свою предметную область, либо привязаны к конкретному языку программирования (среде выполнения).
Очень похоже что ваш абстрактный «механизм поиска решений» это разновидность кнопки «сделать все хорошо», без какой либо конкретики, только акцентируя на проблеме полного перебора.
Более того «механизма поиска решений» который реализован в некой среде выполнения (сервер SQL или алгоритмы Пролога) сам по себе не решит на обум вашу задачу, для этого, вам необходимо еще и дать очень детальное и непротиворечивое описание конкретно вашего частного случая.
Для пролога это внесение набора предикатов, для sql это описание структуры таблиц и их связей, а универсальный «решатель» это уже из области фантастики, без знаний о предмете, ни один алгоритм не может быть полезен.
Вот только все они завязаны либо на свою предметную область, либо привязаны к конкретному языку программированиячто SQL что Пролог как раз языки под конкретную предметную область — то есть предметно ориентированный язык (DSL), никакого «либо» здесь не может быть.
Более того «механизма поиска решений» который реализован в некой среде выполнения (сервер SQL или алгоритмы Пролога) сам по себе не решит на обум вашу задачу, для этого, вам необходимо еще и дать очень детальное и непротиворечивое описание конкретно вашего частного случая.
Для пролога это внесение набора предикатов, для sql это описание структуры таблиц и их связей, а универсальный «решатель» это уже из области фантастики, без знаний о предмете, ни один алгоритм не может быть полезен.
… сам по себе не решит на обум вашу задачу, для этого, вам необходимо еще и дать очень детальное и непротиворечивое описание конкретно вашего частного случая.Так я с этого и начал пару комментариев выше.
И у меня нет «механизма поиска решений». Я просто отметил определенную проблему, что в тех предметно ориентированных языках, где «механизм поиска решений» реализован, при определенных условиях могут возникать сложности с поиском решений.
в тех предметно ориентированных языках, где «механизм поиска решений» реализован, при определенных условиях могут возникать сложности с поиском решенийаналогичное по сути утверждение в отношении математики возможно покажет бессмысленность такой постановки вопроса.
— в целом математика очень хорошо помогает решать большинство задач, но некоторые проблемы все еще остаются нерешенными.
Нужны новые IDE, новые синтаксические сахары…
я вот недавно попробовал джавскрипт на IntelliJ Idea — она кроме всего прочего умеет понимать, какая у полученного JSON-а будет структура (несмотря на то что он высылается в другом файле) и подсказывает об очевидных опечатках. Для интерпретируемого языка это просто чудо-сказка а не IDE!
Теперь бы еще такое же, только для аудио — чтобы например диффы от коммитов коллег можно было воспринимать на слух, и это бы позволило проводить пробежки гораздо болеее продуктивно :)
я вот недавно попробовал джавскрипт на IntelliJ Idea — она кроме всего прочего умеет понимать, какая у полученного JSON-а будет структура (несмотря на то что он высылается в другом файле) и подсказывает об очевидных опечатках. Для интерпретируемого языка это просто чудо-сказка а не IDE!
Теперь бы еще такое же, только для аудио — чтобы например диффы от коммитов коллег можно было воспринимать на слух, и это бы позволило проводить пробежки гораздо болеее продуктивно :)
Сперва я хотел согласиться с подобным предположением (насчет включения подобного функционала в другие языки в виде отдельного модуля). Действительно, можно включить в состав приложения библиотеку, реализующую реляционную базу данных и это вполне нормально будет работать.
Но в итоге, серьезные решения вряд ли получится сделать таким образом. И это уже будет зависеть не от используемого языка, а от требуемой архитектуры конечного приложения. Ведь монолитные приложения редко обладают возможностями для серьезного масштабирования. А при подключении библиотеки в виде интерфейса доступа к вычислительным возможностям отдельного сервиса, не обязывает разрабатывать сам сервис на том же самом языке программирования, что и приложение.
Вторым, и на мой взгляд более серьезным препятствием, может быть принципивльно разный подход программирования при использования императивного и декларативного стиля. Ведь вряд ли в коде программы на Прологе сможет сходу разобраться С++ или Python программист.
Но в итоге, серьезные решения вряд ли получится сделать таким образом. И это уже будет зависеть не от используемого языка, а от требуемой архитектуры конечного приложения. Ведь монолитные приложения редко обладают возможностями для серьезного масштабирования. А при подключении библиотеки в виде интерфейса доступа к вычислительным возможностям отдельного сервиса, не обязывает разрабатывать сам сервис на том же самом языке программирования, что и приложение.
Вторым, и на мой взгляд более серьезным препятствием, может быть принципивльно разный подход программирования при использования императивного и декларативного стиля. Ведь вряд ли в коде программы на Прологе сможет сходу разобраться С++ или Python программист.
Вы изобретаете велосипед, которым математики занимались еще в 19 веке. Если память мне не изменяет, Гильберт пытался придумать некий универсальный алгоритм-генератор для создания математических утверждений с последующим их доказательством. Затем Курт Гедель своей теоремой о неполноте доказал невозможность подобного.
Чем больше я пытаюсь понять отличия «декларативного» и «императивного» стиля (и, в целом, концепцию такого деления), тем меньше принципиальных отличий я в них наблюдаю. При появлении даже простых абстракций в коде, при желании, его можно отнести к «декларативному» стилю. Вызывая код через верхний уровень абстракции мы неизбежно отдаём выбор реализации нижним. Сам же «декларативный» стиль (хотя, я бы использовал слово «подход») не может быть использован без обвязки из «императивного», собственно, и реализующего выбор алгоритма решения. Отсюда, в мало-мальски сложном приложении использованы по отдельности они быть не смогут. Они суть единое целое. В большинстве случаев даже четкой границы не провести: каждый метод или оператор, в сущности, говорит что сделать, а не как (как — сокрыто в его реализации), не говоря уж о более сложных конструкциях. Таким образом, дальнейшие рассуждения, на мой субъективный взгляд, смотрятся как поиск серебряной пули там, где для её наличия нет даже предпосылок.
Одной из проблем Пролога отмечают как раз отсутствие возможности писать программы в императивном стиле.
Поэтому, я с вами соглашусь, что использовать только декларативный не очень удобно и гораздо лучше иметь возможность комбинировать стили написания в рамках одной программы.
Поэтому, я с вами соглашусь, что использовать только декларативный не очень удобно и гораздо лучше иметь возможность комбинировать стили написания в рамках одной программы.
НЛО прилетело и опубликовало эту надпись здесь
И, тем не менее, «Пролог-система» должна быть кем-то императивно написана. С таким подходом разработчик со всем обилием инструментов вырождается в администратора, в лучшем случае. Искусственно можно выделить часть кода, которую, с натяжкой, можно назвать декларативной, но ценность такого результата — максимум, академическая. Ещё один вывод, если принять на веру Вашу интерпретацию — SQL, упомянутый в статье как декларативный, к оному подходу абсолютно никакого отношения не имеет. Даже ANSI, чего уж говорить о его расширениях. Про пролог ничего сказать не могу, даже в глаза не видел) Возможно, когда-нибудь из принципа возьмусь вникать. Из опыта изучения языков/сред могу сказать, что чем меньше подконтрольного разработчику, тем скромнее область применения. Суть разработчика — построение алгоритмов. Отнять второе — исчезнет первое.
Я не знаю, в курсе вы или нет, но именно тенденция вырождения в администрирование прослеживается сейчас везде. Всё потому что все программы уже написаны в десятках вариаций. Теперь задача состоит в эффективной их компоновке.
НЛО прилетело и опубликовало эту надпись здесь
тенденция вырождения в администрирование прослеживается сейчас везде
Прослеживается-то прослеживается, но вот только не выходит никак. Пробуют — откатываются на программирование, пробуют снова — снова откатываются. Ну да, вещи получаются сложнее с каждым разом, только и хотят тоже с каждым разом больше.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
В большинстве случаев даже четкой границы не провести: каждый метод или оператор, в сущности, говорит что сделать, а не как (как — сокрыто в его реализации), не говоря уж о более сложных конструкциях.Сокрытие деталей реализации в методе или операторе — это способ повышения абстрактности (но никак не декларативности), на уровне языка (оператор) или на уровне конкретного проекта (метод), иерархически повышать его можно сколько угодно.
Декларативность кода состоит в том, что он "не используют понятия состояния, в частности, не содержат переменных и операторов присваивания", «на повышение уровня декларативности нацелено языково-ориентированное программирование.»
Честно говоря, я не согласен с утверждением, что «Как следствие, декларативные программы не используют понятия состояния, в частности, не содержат переменных и операторов присваивания, обеспечивается ссылочная прозрачность.»
Отсутствие переменных, это один из способов реализации конкретной проблемы и не более того. Но сама проблема (отказ от состояния и обеспечение ссылочной прозрачности), не является частью или обязательной составляющей парадигмы декларативного программирования.
Отсутствие переменных, это один из способов реализации конкретной проблемы и не более того. Но сама проблема (отказ от состояния и обеспечение ссылочной прозрачности), не является частью или обязательной составляющей парадигмы декларативного программирования.
Не согласны так несогласны, ваше право)
Но
Дайте тогда хоть собственное определение, обязательно поучаствую в его обсуждении.
Но
Дайте тогда хоть собственное определение, обязательно поучаствую в его обсуждении.
Меня и текущее определение вполне устраивает «Декларати́вное программи́рование — парадигма программирования, в которой задаётся спецификация решения задачи, то есть описывается, что представляет собой проблема и ожидаемый результат.»
Я не согласен с необоснованным ограничением для основного определения.
Например, спецификация решения задачи, как «результат выполнения функции равен значению, хранящемуся в переменной», будет вполне в декларативном стиле.
И причем тут запрет на использование переменных? Ведь это только один из способов реализации чистоты функций, причем не единственный.
Я не согласен с необоснованным ограничением для основного определения.
Например, спецификация решения задачи, как «результат выполнения функции равен значению, хранящемуся в переменной», будет вполне в декларативном стиле.
И причем тут запрет на использование переменных? Ведь это только один из способов реализации чистоты функций, причем не единственный.
Перебор очень полезен даже если разработчик знает алгоритм решения.
Есть ветвь по сути всё того же логического програмиирования под названием model checkers. Ветвь очень востребована в узких областях. В более широком смысле это направление развивается в виде theorem provers (автоматического доказательства теорем).
Там перебор упрощает работу разработчика. Если я знаю, что в алгоритме нужно сделать сотню шагов, то все их написать и отладить — долго. Поэтому я беру модель и кручу её на сольвере. Экономия времени — это то, ради чего и развивается программирование.
Есть ветвь по сути всё того же логического програмиирования под названием model checkers. Ветвь очень востребована в узких областях. В более широком смысле это направление развивается в виде theorem provers (автоматического доказательства теорем).
Там перебор упрощает работу разработчика. Если я знаю, что в алгоритме нужно сделать сотню шагов, то все их написать и отладить — долго. Поэтому я беру модель и кручу её на сольвере. Экономия времени — это то, ради чего и развивается программирование.
НЛО прилетело и опубликовало эту надпись здесь
Я писал не про сам Пролог, а назвал его только как самый распространенный пример и прародитель языков логического программирования.
На нем действительно можно писать программы в интересном стиле, но уж очень они заумно выглядят. Но если ты в этом сумел разобраться, то действительно — становится море по колено!
На нем действительно можно писать программы в интересном стиле, но уж очень они заумно выглядят. Но если ты в этом сумел разобраться, то действительно — становится море по колено!
Очевидная проблема состоит в том, что логика высказываний далеко не для всего подходит. Ну то есть как бы да, «вы поняли задачу, если описали её на Прологе», но это описание может быть громоздким или вывернутым наизнанку в сравнении с тем, который я бы назвал «пониманием», а всё из-за неадекватности выразительных средств.
Простой пример — математика, которая к Прологу прикручена к логике чуть ли не на изоленте. Менее очевидный — скажем, события, выстроенные в определённом порядке во времени (и поэтому в специализированных системах типа SPIN используется темпоральная логика, а не просто first-order logic).
Простой пример — математика, которая к Прологу прикручена к логике чуть ли не на изоленте. Менее очевидный — скажем, события, выстроенные в определённом порядке во времени (и поэтому в специализированных системах типа SPIN используется темпоральная логика, а не просто first-order logic).
Достаточно продвинутая технология неотличима от магии. Вы начали с рассуждения о логических языках, но потом обобщили местные проблемы до всего декларативного программирования. Хотя на практике это не так. К декларативным относят и другие языки, абстрагирующие от потока управления. Например регекспы, языки описания конфигураций, грамматики или там функциональные языки. Все это неплохо прижилось, настолько, что мы даже перестали обращать на них особое внимание. Даже в императивных языках, подязыки, которые используются для описания типов вполне декларативны.
НЛО прилетело и опубликовало эту надпись здесь
Это относится скорее к методологии разработки, а не к языкам программирования. И она, по моему, достаточно хорошо вписывается в концепцию Языково-ориентированного программирования
НЛО прилетело и опубликовало эту надпись здесь
Подходов может быть множество, и я ничуть не возражаю против описанного вами, хотя некоторые места мне и кажутся сомнительными (например, создание собственного языка под свою собственную задачу).
Ведь если спрогнозировать его развитие, то в конечном итоге каждая библиотека или заимствованный модуль будут иметь свой собственный язык.
И эта проблема возникает на пустом месте, просто потому, что у хорошего архитектора с разработчиком появилось мысль, сделать пользователям хорошо, уменьшив порог вхождения и реализовать собственное подмножество языка :-)
Ведь если спрогнозировать его развитие, то в конечном итоге каждая библиотека или заимствованный модуль будут иметь свой собственный язык.
И эта проблема возникает на пустом месте, просто потому, что у хорошего архитектора с разработчиком появилось мысль, сделать пользователям хорошо, уменьшив порог вхождения и реализовать собственное подмножество языка :-)
НЛО прилетело и опубликовало эту надпись здесь
Посмотрите комментарии к предыдущей статье habr.com/ru/post/531400.
Тестируемая идея почти в точности соответствует ДСЛ (человекопонятный язык для всех).
Но очень простой контраргумент, какой бы язык предметной области не был и пользователь его не знает, то он будет новым для него языком, который все равно нужно будет учиться применять (правила, возможные комбинации и допустимые взаимодействия, исключения из правил т.д.), и это даже в том случае, если сами термины ему знакомы. Ведь простого знания слов не достаточно для их реального применения.
А вот с любым формализованным языком гораздо проще. В них практически нет исключений из правил, и самое главное, публикуя объявление о вакансии на должность разработчика со заданным стеком технологий, можно быть уверенным, что эти знания описаются на реальную базу, а не на кастомный диалект ДСЛ языка, который он использовал в одном из предыдущих проектов.
А что касается автоматической проверки правил, в формальных ЯП можно не только правила проверять, но и использовать различные сканеры кода для выявления ошибок, потенциальных уязвимостей и пр. И пять, это сделать гораздо проще и удобнее для единого формального языка, чем городить огород для своего подмножества.
Тестируемая идея почти в точности соответствует ДСЛ (человекопонятный язык для всех).
Но очень простой контраргумент, какой бы язык предметной области не был и пользователь его не знает, то он будет новым для него языком, который все равно нужно будет учиться применять (правила, возможные комбинации и допустимые взаимодействия, исключения из правил т.д.), и это даже в том случае, если сами термины ему знакомы. Ведь простого знания слов не достаточно для их реального применения.
А вот с любым формализованным языком гораздо проще. В них практически нет исключений из правил, и самое главное, публикуя объявление о вакансии на должность разработчика со заданным стеком технологий, можно быть уверенным, что эти знания описаются на реальную базу, а не на кастомный диалект ДСЛ языка, который он использовал в одном из предыдущих проектов.
А что касается автоматической проверки правил, в формальных ЯП можно не только правила проверять, но и использовать различные сканеры кода для выявления ошибок, потенциальных уязвимостей и пр. И пять, это сделать гораздо проще и удобнее для единого формального языка, чем городить огород для своего подмножества.
НЛО прилетело и опубликовало эту надпись здесь
«удобство» — это личное качество. Удобно всем не может быть. Всем может быть удобно — только если каждый видит один и тот-же код в своем личном стиле.Подписываюсь!!!
так как:
Идиальный конфиг, где вложенность определяется пробелами…Для меня, это самый ужасный конфиг, т.к. в нем нельзя использовать возможности автоматического форматирования :-)
НЛО прилетело и опубликовало эту надпись здесь
DSL появляются чуть-ли не каждый день, но они редко получают развитие. Для поддержки разработчиков нужна документация, соответствующий инструментарий (IDE с подсветкой синтаксиса, форматтеры, линтеры, рефакторинги, дебагеры, кодмоды), байндинги для интеграции с мейнстрим языками. Дешево разрабатывать все это пока не научились. Ошибки в дизайне языка исправлять существенно дороже, чем поддерживать фреймворк или библиотеку.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проблема логических языков программирования