Отличная статья. Правда немного не хватает примеров, как все эти монады, лифты и линзы выглядят в коде.
Не хотите сделать продолжение? Например, разобрать простенькое приложение и показать, где какой инструмент стоит применить?
Есть еще Combinatory logic и язык Unlambda на ее основе. У комбинаторной логики всего 3 базовых оператора, называемых комбинаторами, I, K, S:
(I x) = x
(K x y) = x
(S x y z) = (x z (y z))
Все остальное можно выразить через эти три.
Unlambda это минимальный функциональный Тьюринг-полный язык программирования.
Hello World на Unlambda выглядит следующим образом:
`r```````````.H.e.l.l.o. .w.o.r.l.di
Если честно, я не уловил идею с максимальной зоной нечистых проявлений. Можете привести пример?
Функция считается чистой, если вычисление зависит только от значений входных аргументов, и она не меняет состояние среды. Если функция считывает какие-то значения из памяти, оборудования, базы данных, откуда угодно кроме входных аргументов, то есть вероятность, что при следующем вызове с теми же аргументами она вернет другой результат. Абсолютно не важно, что на это повлияет, и из какого слоя появилась «нечистота». Результат начинает зависеть от последовательности вызовов функций.
Соответственно, теряются все преимущества чистоты функций, которые базируются на том, что функция абсолютно независима от всего, кроме своих аргументов.
Чистые фукции без побочных эффектов имеют целый ряд преимуществ. Их легко тестировать, достаточно сравнить результат с эталоном, окружение не нужно готовить до и очищать после теста. На уровне среды исполнения можно легко реализовать ленивые отложенные вычисления (вычислять функцию только тогда, когда нужен ее результат). Кеширование становится проще. Порядок вычисления функций не имеет значения: в выражении a(x) + b(x) не важно, какую из функций a или b вычислить первой. Компиляторы могут использовать это свойство для оптимизации кода программы. Программы в функциональном стиле проще для понимания, при их анализе не нужно учитывать текущее состояние среды.
При столкновении с реальным миром эта красивая теория конечно рушится. Пользовательский ввод/вывод, работа с БД, аппаратной частью связаны с побочными эффектами. В чисто функциональных языках эту проблему пытаются обходить с помощью разных хитрых трюков по типу монад. В некоторых случаях бывает, что усилия по сохранению чистоты функции создают такую сложность, что проще работать с обычными «грязными» функциями.
Но «слить» чистые функции с грязными на теоретическом уровне не получится. Появление побочных эффектов убивает все преимущества чистых функий.
Согласно ФП программа будет представлять собой комбинацию функций. Данные в программе будут неизменяемые. Чистая функция не не производит ни каких внешних эффектов, не меняет состояние переменных, просто получает на вход данные и вычисляет результат. Любой вызов функции с одними и теми же переменными приведет к одному и тому же результату, результат вычиления функции зависит только от входных аргументов, но не от внешнего состояния программы.
В ООП программа будет представлять собой комбинацию объектов. Поля объектов хранят его внутреннее состояние. Методы содержат логику поведения объекта — изменения внутреннего состояния и получения доступа к нему. Объекты вызывают методы друг друга динамично меняя свое состояние.
Отличие в том, что программа в ООП стиле имеет внутреннее состояние (переменные и поля объектов), которое меняется по в процессе выполнения программы. Программа в ФП стиле такого состояния не имеет, функции просто трансформируют входные аругменты в выходные. Это фундаментальное отличие этих стилей. Они не сходятся, они существуют и развиваются параллельно. Одну и ту же задачу можно реализовать обоими способами, и структура программы будет разной.
Scala поддерживает оба стиля. Их можно смешивать, часть программы написать в одном стиле, часть в другом, выбирая наиболее удобный для конкретной задачи. Или просто вставить в класс несколько чистых функций, реализовав с помощью ФП какие-то сложные вычисления.
Одну и ту же задачу можно реализовать как в ООП так и в функциональном стиле. Грубо говоря, ООП лучше подходит, если приложение ориентированно на данные, функциональный стиль — если на вычисления. Чтобы выбрать правильный стиль для каждой части приложения нужен опыт. Новичку очень трудо будет объяснить эти ньюансы. Ему для начала надо освоить оба этих стиля по отдельности и на практике прочувствовать их ограничения. Только после этого он сможет понять, как их можно смешивать.
Вот что произойдёт совершенно точно, так это резкое повышение эффективности творческого труда за счёт автоматизации рутинных действий.
С этим полностью согласен
Например, сейчас художникам приходится делать рисунок целиком, а в будущем станет достаточно пятиминутного скетча и пары цветных пятен, чтоб нейросеть поняла, какого цвета будут те или иные элементы. А такие рутинные операции, как обводка и покраска, уже сейчас вполне могут выполняться обученной нейросетью.
А вот с этим полностью не согласен. Художественное творчество очень сильно завязано на человеческий опыт. В картине художник может пытаться передать свои эмоции, впечатления, переживания, отношение к каким-то абстрактным идеям, проблемам. При этом художник выражает свой замысел не только тем, что нарисовано, но и техникой рисования, цветами, стилем. Все важно и должно соответствовать общему замыслу, который нейросеть понять не сможет.
Не уверен, что правильно понял Ваш вопрос.
Меня в первую очередь интересует наиболее удобный способ описания сети понятий. Чтобы можно были наглядно представлены как структура понятий, так и связи между ними. Так же, как это сделано в RDF, SPARQL, OWL и др.
Да, сеть понятий можно представить в виде графа. Но моя цель — не специализированный язык для работы с графами, поэтому я не хочу концентрироваться на удобстве абстрактных операциях над графами.
Графического представления не будет (на уровне языка точно), так как цель — объединить язык описания модели с ООП и/или функциональными языками программирования.
Я планирую 2 следующие публикации посвятить обзорам. В первой проанализировать несколько самых популярных технологий, включающих в себя декларативный стиль — PL/SQL, LINQ и GraphQL. Чтобы почерпнуть из них идеи, которые были бы полезны в языке описания модели. А во второй — сделать обзор языков представления знаний — Prolog, RDF, OWL и фреймовой логики, обсудить их достоинства и недостатки, а затем предложу основные черты своего языка моделирования.
А после этого уже планирую подробно рассказать о своем языке. Сначала об основных его понятиях — способах определения фактов и понятий, наследовании, правилах. Затем о связях с логическим программированием — логических переменных, предположениях о закрытости/открытости мира, отрицании, элементах логики высших порядков. А также о заимствованиях из мира SQL — вложенных определений понятий, агрегировании. Это займет 3 публикации.
Дальше будет рассказ, как объединить логический язык моделирования с ООП и функциональным программированием. Будет обзор функционально-логических языков — Curry и OZ, подходов к онтологически-ориентированному программированию. Планирую рассказать, как можно совместить конструкции языка моделирования с ООП моделью на семантическом уровне. Как решена проблема совмещения поиска с возвратом с императивным и мультипоточным стилями программирования. Как можно организовать области видимости понятий и фактов. Как можно реализовать процедуру логического вывода.
После этого, хочу рассмотреть пару примеров применения языка, приближенных к реальности. А в конце — основные варианты реализации языка.
Многие публикации будут связаны с вопросами и проблемами компьютерной логики, причем с теоретическими вопросами.
Вы упрётесь в количество кода, который нужно написать.
Простое пишется легко на чём угодно. Сложное пишется сложно. Если упрощаем второе, то сложность кто-то как-то должен сократить. Вот это и должны быть вы с тем самым большим количеством кода. Но у вас, скорее всего, времени жизни не хватит.
Да, согласен. Полноценный язык я сделать сам не смогу. Мне были интересны принципы построения такого гибридного языка. Я потратил на их исследования довольно много времени. И решил поделиться результатами.
Да, ещё есть вариант «попроще» — включить в массовый язык какой-то другой, по возможности тоже массовый, язык. Сложность здесь ограничивается написанием компилятора для этого тяни-толкая. Такой вариант вы сможете реализовать. Но, похоже, выбран вариант «язык, который нравится мне», что означает — его никто не знает.
Этот вопрос открыт. Возможные варианты — это полноценный язык, компилятор в байт-код для JVM или другой виртуальной машины, фреймворк по типу GraphQL. Вариант с фреймворком был бы идеальным с практической точки зрения, но, к сожалению, придется пожертвовать некоторой частью функционала. В реальности же у меня сейчас есть только пруф оф концепт версия интерпретатора, на которой я тестировал свои идеи. Я планирую написать об этом подробно, но немного позже.
Кроме математики и механики определения рейтинга еще понадобится решить организационные и маркетинговые вопросы. А они на порядок сложнее.
Чтобы определить качество статьи нужны рецензии. Рецензенты должны быть независимыми и объективными. Иначе друзья и коллеги будут накручивать друг другу рейтинги. За рецензии придется платить деньги. Нужно будет найти профессионалов, которые согласятся рецензировать, собирать заявки на рецензии, принимать платежи, распределять заявки, платить вознаграждения. Регулярно публиковать списки лучших работ, например, за квартал. Рекламировать эти списки. Добиться того, чтоб им доверяли, читали, подписывались на них.
В общем, этот процесс повидимому будет мало отличаться от того, что происходит в журналах.
Получается, что роль журналов заключается в том, чтобы отобрать ограниченное количество самых интересных работ. Другими словами, это независимый центр сертификации работ и, соответственно, ученых. Которому доверяет руководство универститетов, институтов, распорядители грантов и т.п. Именно за это подтверждение качества ученые и готовы платить журналам деньги, а не за сам факт публикации.
Заменить журналы может только такой механизм оценки рейтинга ученых, который обладает одним ключевым качеством — чиновники и руководство научных организаций должно ему доверять больше чем журналам.
Пока что существующие соцсети не смогли предложить такой механизм.
Ну постойте, речь-то идет о всемирной системе. Это миллионы людей. Посмотрите, какой треш тут на хабре в комментах порой творится, а тут всего-то несколько тысяч активных комментаторов и жесткая модерация.
Создайте закрытую ассоциацию или группу, выдавайте туда доступ по приглашениям тем, кто работает в Вашей области, а всем остальным ограничте возможность комментировать. И модерация будет практически не нужна.
Я не понимаю, почему это вдруг станет основным место публикации. Researchgate сейчас — пристанище всяких альтернативщиков (в комментах особенно), и я не вижу, как подобная соцсеть может выйти на адеквантый уровень.
Для этого придется договориться с ведущими учеными в Вашей области совместно и одновременно перейти в соцсеть. Не знаю, правда, насколько это реально.
Потому что я, например, не откажусь от публикации в хорошем журнале, который напрямую влияет на мою карьеру, в пользу некоторого форума, который, возможно, когда-нибудь может взлететь. Для меня публикация на этом форуме — прямое упущение конкурентного преимущества в борьбе за постоянные позиции.
Сейчас да, смысла нет. Но если значительная часть ученых в Вашей области решит перестать публиковаться в журналах и уйти в соцсеть, то на карьеру будет влиять уже рейтинг или количество фолловеров в этой соцсети. И Вы сразу почуствуете разницу в скорости, удобстве и дешевизне публикаций.
Ну собственно проблема в том, что комментарии и обсуждения должны модерироваться, иначе это будет ад.
Какая-то форма модерации безусловно потребуется. Но не думаю, что это большая проблема. Сообщество маленькое, все друг друга знают и привыкли думать прежде чем писать.
Опровержения, списки работ и т.п. уже и так собираются системами типа researchgate (там и комментить можно) или google scholar. Рецензии обычно не доступны публично, и это вопрос к журналам.
Так идея в том и заключается, чтобы соцсеть по типу researchgate стала основным местом публикации. Тогда все, что касается научной работы, сразу было бы в одном месте. А дискуссии гораздо активнее.
На мой взгляд, самое важное — это собрать в одном месте всю информацию о научной работе: тексты статей, рецензии, исправления, комментарии, обсуждения, опровержения, списки работ, которые ее цитируют, описания и результаты экспериментов, код программ, исходные данные и т.п. В таком формате гораздо проще разобраться, в чем суть и ценность работы, проверить валидность результатов. Этот процесс будет гораздо более быстрым и открытым по сравнению с традиционным подходом — публикацией в журналах. А дискуссии — живее и интереснее.
Ну а рейтинги, на мой взгляд, вещь вторичная. Их роль — не оценивать насколько крут тот или иной ученый, а скорее привлекать внимание и распространять наиболее интересные работы. И как-то агрегировать впечатления от работы.
Финансирование подобной платформы я не считаю чем-то нереальным. Крупный богатый университет сможет такое потянуть. Совместное финансирование и гос. поддержка тоже возможны. Самое сложное — убедить сообщество в необходимости подобной инициативы.
Причем сетуют не на саму природу капитализма как они ее понимают. А именно на то, что сами не смогли преуспеть в этом «искусстве обмана». У Кори Пайна прекрасно уживаются желание стать миллиардером и левые идеи с критикой капитализма и требованием запретить и регулировать все, что шевелится.
Не хотите сделать продолжение? Например, разобрать простенькое приложение и показать, где какой инструмент стоит применить?
(I x) = x
(K x y) = x
(S x y z) = (x z (y z))
Все остальное можно выразить через эти три.
Unlambda это минимальный функциональный Тьюринг-полный язык программирования.
Hello World на Unlambda выглядит следующим образом:
`r```````````.H.e.l.l.o. .w.o.r.l.di
Функция считается чистой, если вычисление зависит только от значений входных аргументов, и она не меняет состояние среды. Если функция считывает какие-то значения из памяти, оборудования, базы данных, откуда угодно кроме входных аргументов, то есть вероятность, что при следующем вызове с теми же аргументами она вернет другой результат. Абсолютно не важно, что на это повлияет, и из какого слоя появилась «нечистота». Результат начинает зависеть от последовательности вызовов функций.
Соответственно, теряются все преимущества чистоты функций, которые базируются на том, что функция абсолютно независима от всего, кроме своих аргументов.
При столкновении с реальным миром эта красивая теория конечно рушится. Пользовательский ввод/вывод, работа с БД, аппаратной частью связаны с побочными эффектами. В чисто функциональных языках эту проблему пытаются обходить с помощью разных хитрых трюков по типу монад. В некоторых случаях бывает, что усилия по сохранению чистоты функции создают такую сложность, что проще работать с обычными «грязными» функциями.
Но «слить» чистые функции с грязными на теоретическом уровне не получится. Появление побочных эффектов убивает все преимущества чистых функий.
В ООП программа будет представлять собой комбинацию объектов. Поля объектов хранят его внутреннее состояние. Методы содержат логику поведения объекта — изменения внутреннего состояния и получения доступа к нему. Объекты вызывают методы друг друга динамично меняя свое состояние.
Отличие в том, что программа в ООП стиле имеет внутреннее состояние (переменные и поля объектов), которое меняется по в процессе выполнения программы. Программа в ФП стиле такого состояния не имеет, функции просто трансформируют входные аругменты в выходные. Это фундаментальное отличие этих стилей. Они не сходятся, они существуют и развиваются параллельно. Одну и ту же задачу можно реализовать обоими способами, и структура программы будет разной.
Scala поддерживает оба стиля. Их можно смешивать, часть программы написать в одном стиле, часть в другом, выбирая наиболее удобный для конкретной задачи. Или просто вставить в класс несколько чистых функций, реализовав с помощью ФП какие-то сложные вычисления.
С этим полностью согласен
А вот с этим полностью не согласен. Художественное творчество очень сильно завязано на человеческий опыт. В картине художник может пытаться передать свои эмоции, впечатления, переживания, отношение к каким-то абстрактным идеям, проблемам. При этом художник выражает свой замысел не только тем, что нарисовано, но и техникой рисования, цветами, стилем. Все важно и должно соответствовать общему замыслу, который нейросеть понять не сможет.
Меня в первую очередь интересует наиболее удобный способ описания сети понятий. Чтобы можно были наглядно представлены как структура понятий, так и связи между ними. Так же, как это сделано в RDF, SPARQL, OWL и др.
Да, сеть понятий можно представить в виде графа. Но моя цель — не специализированный язык для работы с графами, поэтому я не хочу концентрироваться на удобстве абстрактных операциях над графами.
Графического представления не будет (на уровне языка точно), так как цель — объединить язык описания модели с ООП и/или функциональными языками программирования.
А после этого уже планирую подробно рассказать о своем языке. Сначала об основных его понятиях — способах определения фактов и понятий, наследовании, правилах. Затем о связях с логическим программированием — логических переменных, предположениях о закрытости/открытости мира, отрицании, элементах логики высших порядков. А также о заимствованиях из мира SQL — вложенных определений понятий, агрегировании. Это займет 3 публикации.
Дальше будет рассказ, как объединить логический язык моделирования с ООП и функциональным программированием. Будет обзор функционально-логических языков — Curry и OZ, подходов к онтологически-ориентированному программированию. Планирую рассказать, как можно совместить конструкции языка моделирования с ООП моделью на семантическом уровне. Как решена проблема совмещения поиска с возвратом с императивным и мультипоточным стилями программирования. Как можно организовать области видимости понятий и фактов. Как можно реализовать процедуру логического вывода.
После этого, хочу рассмотреть пару примеров применения языка, приближенных к реальности. А в конце — основные варианты реализации языка.
Многие публикации будут связаны с вопросами и проблемами компьютерной логики, причем с теоретическими вопросами.
Да, согласен. Полноценный язык я сделать сам не смогу. Мне были интересны принципы построения такого гибридного языка. Я потратил на их исследования довольно много времени. И решил поделиться результатами.
Этот вопрос открыт. Возможные варианты — это полноценный язык, компилятор в байт-код для JVM или другой виртуальной машины, фреймворк по типу GraphQL. Вариант с фреймворком был бы идеальным с практической точки зрения, но, к сожалению, придется пожертвовать некоторой частью функционала. В реальности же у меня сейчас есть только пруф оф концепт версия интерпретатора, на которой я тестировал свои идеи. Я планирую написать об этом подробно, но немного позже.
Кроме математики и механики определения рейтинга еще понадобится решить организационные и маркетинговые вопросы. А они на порядок сложнее.
Чтобы определить качество статьи нужны рецензии. Рецензенты должны быть независимыми и объективными. Иначе друзья и коллеги будут накручивать друг другу рейтинги. За рецензии придется платить деньги. Нужно будет найти профессионалов, которые согласятся рецензировать, собирать заявки на рецензии, принимать платежи, распределять заявки, платить вознаграждения. Регулярно публиковать списки лучших работ, например, за квартал. Рекламировать эти списки. Добиться того, чтоб им доверяли, читали, подписывались на них.
В общем, этот процесс повидимому будет мало отличаться от того, что происходит в журналах.
Получается, что роль журналов заключается в том, чтобы отобрать ограниченное количество самых интересных работ. Другими словами, это независимый центр сертификации работ и, соответственно, ученых. Которому доверяет руководство универститетов, институтов, распорядители грантов и т.п. Именно за это подтверждение качества ученые и готовы платить журналам деньги, а не за сам факт публикации.
Заменить журналы может только такой механизм оценки рейтинга ученых, который обладает одним ключевым качеством — чиновники и руководство научных организаций должно ему доверять больше чем журналам.
Пока что существующие соцсети не смогли предложить такой механизм.
Ну или альтернативный вариант, если один из ведущих издателей решит сделать онлайн версию своих журналов со всем функционалом соцсети.
Создайте закрытую ассоциацию или группу, выдавайте туда доступ по приглашениям тем, кто работает в Вашей области, а всем остальным ограничте возможность комментировать. И модерация будет практически не нужна.
Для этого придется договориться с ведущими учеными в Вашей области совместно и одновременно перейти в соцсеть. Не знаю, правда, насколько это реально.
Сейчас да, смысла нет. Но если значительная часть ученых в Вашей области решит перестать публиковаться в журналах и уйти в соцсеть, то на карьеру будет влиять уже рейтинг или количество фолловеров в этой соцсети. И Вы сразу почуствуете разницу в скорости, удобстве и дешевизне публикаций.
Какая-то форма модерации безусловно потребуется. Но не думаю, что это большая проблема. Сообщество маленькое, все друг друга знают и привыкли думать прежде чем писать.
Так идея в том и заключается, чтобы соцсеть по типу researchgate стала основным местом публикации. Тогда все, что касается научной работы, сразу было бы в одном месте. А дискуссии гораздо активнее.
Ну а рейтинги, на мой взгляд, вещь вторичная. Их роль — не оценивать насколько крут тот или иной ученый, а скорее привлекать внимание и распространять наиболее интересные работы. И как-то агрегировать впечатления от работы.
Финансирование подобной платформы я не считаю чем-то нереальным. Крупный богатый университет сможет такое потянуть. Совместное финансирование и гос. поддержка тоже возможны. Самое сложное — убедить сообщество в необходимости подобной инициативы.