Обсуждение

Факт-ориентированность — это типа rdf с его триплетами?

Ну да.

, в них в ВУЗе намертво вколочен аристотелевский онтологический подход Вот Korzybski с его General Semantics развернулся бы...

Ему жаловаться не приходится, о его существовании все знают. Хотя не уверен, что знают о содержании его учения -- слова General Semantics и про "карта не территория" слышали все, но не более того. Увы, в ВУЗе не про парадигмы рассказывают, а просто некоторые из них вбивают намертво. После чего рыбки воду не замечают.

Я бы не согласился что намертво вколочен. Программеры таки обычно знают SQL а там кагбэ декларативный язык, который ближе к логическому подходу. Т.е. таблица в БД это и есть отношение (предикат) по сути. После нормализации той или иной степени мы и получаем факт-ориентированность. Но в целом подобная проблема есть. Например, есть дурацкий O/R mapping который подменяет удобный "логический" (предикатный) подход, когда можно join'ить отношения, на очень корявое (ибо сильно различающееся в своей "онтологической" основе) отображение на классы/атрибуты. Но проблема скорее в поверхностном образовании. Т.е. типа про другие подходы не рассказали.

SQL по факту недалеко от Аристотелевщины ушёл с его таблицами, это тот же Крис Партридж убедительно показывает. А потом рассказывает, чем факт-ориентированность отличается и почему трудно после таблиц мыслить просто тройками. Проблема же в образовании тут как раз в соседнем абзаце отражена. Говорят, что есть ООП, функциональное и императивное программирование. Потом учат много и долго ООП. Всё, full stop, быдлокодер на выпуске.

R это схема (лисп), и в ней можно написать (очень быстро) _любую_ абстракцию, и _любой_ встроенный язык.

На кванторы всеобщности ("любой") принято отвечать вопросом с их удвоением: "Любой-любой?", а в случае Julia ехидно спрашивать -- "ну, и какая там будет скорость работы этого языка по сравнению с чистым си? Так же медленно, как сам R?"? И, кстати, метапрограммирование в Julia честно взято из lisp. Только этот "любой встроенный язык" может потом быстро работать. Опять же, лисп и схема и прочие из этой серии такие хорошие языки, что даже удивительно, почему их вытеснили другие языки. Они ж всегда были в моде, и всегда были самые крутые! R тут выделился только тем, что ему сто лет в субботу, и поэтому для него наработано очень много библиотек. Мне было бы печально обнаружить, что Julia и Lisp обладают общим недостатком, который делает эти языки нишевыми: они не любят тупости на них программирующих, они не прощают ошибок. Хотя разработчики Julia и говорят, что на Julia можно пробовать быдлокодить, и всё получится, только результаты будут работать примерно так же, как на Python и R, не быстрее. С другой стороны, они мечтают иметь встроенный оптимизатор, который будет помогать с этим справляться. Баттлы с любителями R -- это традиционное развлечение в среде разработчиков Julia. Когда только открыли Julia language группу в Telegram, туда пришёл сторонник R (что он там забыл?) и тоже устроил большую рекламу R. Только беда: большинство, кто приползают работать на Julia, гонимые грузом своих вычислительных задач, уже успели как-то поработать на R, так что за ответами у них не ржавеет.

SQL он на основе реляционной модели, которая на основе отношений, пусть и не обязательно бинарных. А произвольные отношения отношения всегда можно декомпозировать на набор бинарных (ну может унарных тоже чутка). Ну и соответственно, ежели еще следить за тем, чтобы новые отношения отражали факты, то по сути мы и придем к факт-ориентированности. С программистами же тут такой момент, что они обычно же действуют на уровне дизайна и прогроммирования. А факт-ориентированность - это уровень архитектуры/требований. Т.е. тут противоречия-то по сути и нет, ибо когда мы мапим на SQL и ОО языки, то нам и нужно денормализовывать отношения в какой-то степени и использовать объекты с атрибутами. Просто программерам еще надо объяснять разницу между архитектурой, дизайном и программированием. Ну и тогда, думаю, проблемы объяснить факт-ориентированность не будет. Разве что ленивый мозгом программер попадется.

Вообще, с факт-ориентированностью в SQL на порядок лучше, ибо есть прямая поддержка N-ary фактов. А "тройки", включая тот же RDF, это https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model Где всё не-binary делается через костыли.

Всегда можно запрограммировать одну парадигму в языке другой. Ещё и теоремку какую доказать по изоморфизму (Карри-Ховард или что-то подобное). Но это уже дефект программиста, который всплыл над всеми этими парадигмами: он не может их воспринимать сами по себе, он про них сразу думает на языке какой-то другой удобной ему (или требуемой кем-то другим) парадигмы. Понятно, что на факт-ориентированном языке можно и таблицы описать, почему бы и нет. Наоборот трудней будет, но тоже можно (сделать одну реляционную таблицу на три колонки, в самом простейшем случае, и объявить, что задача решена -- все запросы SQL к этой таблице заведомо факт-ориентированы ;-) ) Но я тут про другое: есть какие-то средства, и нужно показать эффективность работы самих этих средств, а не эмулирование других парадигм. Вот ссылки, которые я привёл, показывают эффективность multiple dispatch, плюс плюшки для модульности и создания DSL, которые получаются из сочетания multiple dispatch с метапрограммированием.

Но никто не работает с SQL факт-ориентированно, работают с табличками. И получают базы данных на 33тысячи табличек, с которыми потом не знают, что делать (хотя понятно что: делают простые таблички, на которых моделируют факт-ориентированные структуры. Или сразу уходят в NoSQL, не от хорошей жизни с SQL).

Нет, работают с SQL именно факт-ориентированно, там иначе нельзя. Это снаружи могут прикрутить объектный мэппинг или что-то подобное. А внутри только факты. И та проблема, что не всегда удобно под тип факта создавать отдельную таблицу в схеме, идентифицирована, и существуют заходы на её решение (тот же SQLite4). В принципе же, прогресс сейчас двигается в сторону сочетания характеристик SQL, key-value и документных баз. Тройки к этому не относятся, так как являются не возможностью, а ограничением (EAV-схемой), чаще всего над теми же SQL-решениями.

1. В R ничего ниоткуда "не бралось", это просто написанная по заветам SICP еще одна схема + eDSl (а теперь уже _"куча eDSL"_, которые благодаря такой гибкой основе бесшовно стыкуются) поверх неё. Юля как "убийца R"ТМ _протух_ (причем "совсем совсем" _протух_). Dixi. Пора "слезть с дохлой лошади"ТМ. 2. R так же быстр как быстр вариант используемый вариант BLAS (в том числе и использующий GPU). Тормозят на R только "тормоза" :). На машине с ограниченными ресурсами _все_ среды покажут результат с практической точки зрения не отличимый по скорости исполнения. (Кроме конечно высосанных из ... пальца синтетических примеров) 3. Что в Юле уже и "циклики" поломали, раз быдлокодить наяривая их уже нельзя стало? :) LISP это язык для создания (e)DSL в которых потом решается задача наиболее естественным образом (просто путем её описания). Естественно, что для "наяривающих циклики" это недоступно. PS Но в целом всё закончилось предсказуемо -- написанием "еще одного лисп" :) (раз уже это преподноситься как самый верный способ написание DSL и иллюстрируется типично сициповским примером :). Но это такой "китайский способ прогресса в программировании"ТМ, подкрасться к какому то зрелому продукту и .... переписать его на "си плюс плюс" одним_кускомТМ. Это крайне опрометчивый шаг, поскольку обычно просто происходит замораживание дальнейшего развития продукта. Получившийся быстрый_блоб потом переписывается настолько стремительно, что никто не хочет им заниматься... да и сами авторы увы не успевают толком хоть что то делать. :( PPS а приход описанный очевиден, уже очень юлькины создатели некоррекно себя вели с синтетическими тестами (кое что они принципиально делали переделав тесты и примеры кода на R которые показывали гибкость и превосходство R над блобами не способными например прервать "лишние вычисления", Вставляешь в такой тест тупую (поскольку совершенно не нужную на практике) операцию и получаешь "превосходство" цельных операций над матрицами, которые внезапно все равно медленнее чем lapackовские) на да ладно, "убийца R" сдулся сам :)

Кто кого убивает? Оно ж понятно, что языки вымирают (как и научные парадигмы) только с их носителями. R будет жить ещё некоторое время, там богатая экосистема и куча людей, много учебных курсов и книг. А на Julia будут программировать другие люди, но не те, которые сейчас программируют на R. И Python тоже никто не убивает. И Matlab. Но с появлением Julia становится чуток веселей, и эта весёлость пока главным образом среди вычислительных математиков, а там посмотрим. В этих холиварах с любителями R все разговоры на много ходов вперёд прописаны, ничего нового.

Юля "как язык" это несостоятельный коктейль, натасканый из других языков по описанному выше "китайскому рецепту успеха". "Еще одна PL1схема"ТМ, которая никому не нужна. А "кто кого убивает" хейп стоял прямо на сайте узкой группки разработчиков Юли. Всем вокруг после первого возмущения это стало до фонаря, ничего нового.

Вот мне натасканность из разных языков как раз и нравится, сочетание разных идей. С "научными языками одной идеи" я нахлебался за свою жизнь, а с эклектичными с набором разных изюминок получал большое удовольствие. Вам, конечно, Джулией заниматься не нужно, вам она не нужна.

Юля "как язык" это несостоятельный коктейль, натасканый из других языков по описанному выше "китайскому рецепту успеха". Хорошее описание R. Или, скажем, PHP. R -- достойная среда для статистиков и математиков, но это не язык программирования, сделанный программистами для программистов. Программировать на нём можно (как и на PHP), но тяжело.

Мне возможности схемы (в виде текущей реализации R) достаточно, поскольку я могу очень просто "бесшовно" интегрировать в неё код практически _любых_ других языков программирования (как только это становиться имеющим практический смысл и пользу). И использовать эффективные (e)DSL в том числе (например dplyr, и как следствие к примеру spark или другие бекэнды). Или встраивать код в любое приложение одной строчкой кода через ZeroMQ. Или использовать Hadoop Или, если припрет, написать свой интерпретатор (эффективно снижающий сложность) под свою задачу (если, каким то волшебным образом, его упустили написать до меня более компетентные товарищи). Я не верю, что там где мне не хватит оперативной памяти в data.table (ведь только идиоты будут хранить действительно большие данные по сути в списках? но такие идиоты таки есть (и даже пишут тесты для Юли)), меня каким то "волшебным образом" спасет в обработке датасета Юля. Или, что blas слинкованный с Юлей, волшебным способом работает быстрее, чем он же слинкованный с R. :) Одна идея схемы (и соответственно R) это быть "конструктором языков-клеем" который позволяет реализовать описание "сложности задачи" в виде простого к использованию генератора кода + интегрировать в себя простым способом код других языков программирования. Зачем вот это вот всё "писать одним куском"? А это единственное внятное, что декларирует группа разработчиков Юли. Вообще эта попытка "снять скисшие 30 лет назад чужие сливки" ("пост-объектное", это на самом деле "пре-объектное" :) ) уже превратилась в анекдот какой то. :) PS А Джулией мне "заниматься" действительно не надо, мне надо конкретные задачи прикладные решать. Пока я вижу просто развод с написание "всемогущего блоба"ТМ. Спасибо, я еще помню изучение PL1 :)

Еще один "программист на цикликах"? Что в самом деле "программисту" возможностей Lisp "не хватает"? :) R это Scheme + синтаксический сахар. Читайте Автора https://www.stat.auckland.ac.nz/~ihaka/downloads/Interface98.pdf