Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Category:

Foundational ontologies -- типы в языках программирования против БД (1/2)

Когда мы работали с ISO 15926, то вместо триплов одним из вариантов формализма рассматривалась теория категорий — вот, например, я писал об ISO15926L как языке программирования с логическими/категорными вычислениями, и там же идея avlasov рассматривать ISO15926 как язык описания типов в языках программирования, если к его онтологии добавить языковую компоненту -- это 2010 год, https://ailev.livejournal.com/831024.html. Прошло 9 лет с этого поста — и я высказываю обратную идею: не ISO 15926 как система типов в языке программирования, а типы языков программирования как foundational ontology для upper ontology (ISO 15926 или какая там ещё) вот тут, пару дней назад: https://ailev.livejournal.com/1485657.html. В том числе, почему бы и не какая-то система типов, происходящая из теоркатегорного подхода. И я пошёл в чат любителей dependent types (https://t.me/joinchat/Ai4h2D9SWO8GfISyv-CHsQ), где более 400 его участников рассказали мне, что "из коробки" решения никакого пока нет, а "исследования идут" (старт дискуссии был тут: https://t.me/c/1062361327/22873).

В ходе разговора, конечно, много чего всплыло:
-- как это всё связано с теорией концептов, в том числе theory theory
-- онтологическая работа как комментарии к формальным структурам на FOL -- это как физический смысл, приписываемый мат.уравнениям. Это похоже на схемы причинности и причинный вывод (subject experts рисуют схему причинности, а дальше проверки идут вычислениями).
-- дифференцируемые и вероятностные системы типов, выучиваемые типы против традици
-- бестиповые языки и почему они не выживают
-- как работа с типами связана с programming-in-the-large и programming-in-the-small
-- почему не выжили трипл-сторы
-- почему не выжили объектные базы данных
-- абсолютная безопасность как абсолютная непригодность для работы
-- почему богатые системы типов не используются для моделирования окружающего мира как foundational ontology, а вот убогие реляционные базы данных и даже ещё более убогие трипл-сторы активно используются. А богатые системы типов используются для программирования вычислений над убогими системами типов.
-- для F# таки нашлась книжка, описывающая как делать DDD с его системой типов -- https://pragprog.com/book/swdddf/domain-modeling-made-functional (частичный ответ на мой вопрос "как использовать богатую систему типов для моделирования богатого на сущности мира" -- но для частного функционального языка)
-- про табличные базы данных помянуто в Seven Sketches on Compositionality. An Invitation to Applied Category Theory -- http://math.mit.edu/~dspivak/teaching/sp18/7Sketches.pdf. Более подробно про compositionality (как понять целое высказывание, состоящее из связанных частей) и applied category theory см. в https://arxiv.org/pdf/1809.05923.pdf и https://plato.stanford.edu/entries/compositionality/
-- knowledge representation in bicategories of relations -- https://arxiv.org/abs/1706.00526
-- теория категорий для ускорения реляционных данных, CQL (categorical query language, https://www.categoricaldata.net/ -- open source, литература в https://www.categoricaldata.net/papers), с коммерческим решением по интеграции данных на его основе -- https://conexus.ai/
-- стек технологий, где задачи моделирования мира и вычислений над моделью строго развязаны: движки над foundational ontology это могут быть одни движки (все эти SQL, SPARQL и CQL), а вот вычисления над моделью делаются из языков программирования с их богатыми типами ad hoc
-- Использование теории категорий для моделирования модальностей в юридических контрактах: https://legalese.com/. Очень похоже на проект с такими же целями, как SysMoLan, только там для юридизмов — идеи с модальными логиками будут развиваться. Там, правда, у онтологов тоже есть предпочтения, модальности сегодня проще моделируются как раз классификаторами, то бишь теми же типами.
-- ... много всего по мелочи, я не писал сюда подробных ответов, больше собственные реплики. А полезные ссылки привёл прямо тут в предыдущих строчках.

Делать литературную обработку всего треда мне лень, но для архивных целей вытащу свои реплики сюда. Всё началось с перепоста:

-- Высказывается идея, что типы в языках программирования — это foundational ontology. А для upper ontology (в том числе 4D upper ontology) нужно просто сделать DSL в каком-то расширяемом языке (например, взять для этого Julia). Даётся критика требований визуальности, высказываются сомнения в reuse онтологических моделей людьми и осмысленность их подготовки для использования кремниевыми мозгами. И указывается, что вероятностные типы и коннективизм тоже нужно включать в рассмотрение. В тексте предлагаются работы для todo list и приводится много разных ссылок. Незнакомому с онтологической инженерией человеку текст не будет понятен. -- https://ailev.livejournal.com/1485657.html

[но это ж всё философия! нет формул!]
Вот стенфордская энциклопедия философии, как раз статья про Type Theory. Вся из формул состоит: https://plato.stanford.edu/entries/type-theory/. то, что мне нужно — тоже ни разу не философия. И пруверы у онтологов — самый распространённый инструментарий. Только онтологи задаются вопросом, какие объекты в мире они моделируют, а математикам это пофиг. Так что это математика+ ))) Онтологика. )))

Вот пример того, что заботит онтологов: https://www.cyc.com/wp-content/uploads/2015/04/AAAI-SharmaA.1646.pdf

Cognitive systems must reason with large bodies of general knowledge to perform complex tasks in the real world. However, due to the intractability of reasoning in large, expressive knowledge bases (KBs), many AI systems have limited reasoning capabilities. Successful cognitive systems have used a variety of machine learning and axiom selection methods to improve inference. In this paper, we describe a search heuristic that uses a Monte-Carlo simulation technique to choose inference steps. We test the efficacy of this approach on a very large and expressive commonsense KB, Cyc. Experimental results on hundreds of queries show that this method is highly effective in reducing inference time and improving question- answering (Q/A) performance.

Формулы в статье есть, в количестве ))) И ссылки на литературу типа Bridge, J. P., Holden, S. and Paulson, L. 2014. Machine Learning for first-order Theorem Proving. Journal of Automated Reasoning, 53(2):141–172

Люди, занимающиеся только "традиционными нетрадиционными" языками программирования и математикой просто не залезали в AI. А там сейчас бодро, и у машинных обучателей, и у онтологов.

[а что такое вероятностные типы?]
Ну, теория веороятностей стала логикой. Вот вам короткая ранняя статья на эту тему -- E.T.Jaynes, Probability theory as logic, 1989, 16 страниц -- https://b-ok.cc/book/454548/12202a. А вот более современная классическая книжка: E.T.Jaynes, Probability Theory: The Logic of Science, 2003, 757 страниц --
https://b-ok.cc/book/942315/05fbc7. Другое направление — это probabilistic programming, https://arxiv.org/abs/1809.10756. Языков на эту тему уже чёртова туча (в частности, реализованных как DSL, в последнее время чаще всего на Julia): https://en.wikipedia.org/wiki/Probabilistic_programming [а вот работа по доказательству правильности вероятностных программ -- Formal verification of higher-order probabilistic programs: reasoning about approximation, convergence, Bayesian inference, and optimization, https://dl.acm.org/citation.cfm?doid=3302515.3290351, январь 2019. И ещё наброски
http://users-cs.au.dk/spitters/ProbProg.pdf Faissole, Spitters, "Synthetic topology in Homotopy Type Theory for probabilistic programming"
https://github.com/FFaissole/Valuations/].

Если брать онтологическое понимание типа как участника отношения классификации, то все задачи распознавания в deep learning — это вероятностное отнесение к типу. Поэтому получают распространение сейчас и вероятностные онтологии, но там пока не слишком весело (ибо люди из deep learning пока обходятся без онтологов, они работают с простейшими онтиками для отдельных задач. Онтологи нужны, когда нужно собрать какую-то общую модельку из десятка разных моделек, или объяснить что-то, или работать с особо большими структурированными моделями, а в deep learning работа с multitask ещё не слишком развита).

[это оффтопик, это статистический анализ программ, а у нас тут логика]
Не надо путать вероятностную логику со "статистическим анализом программ", да и речь не идёт о доказательстве правильности программ. Другое дело, что логика -- это одновременно и про:
— правила хороших рассуждений вообще
— конкретный вариант хороших рассуждений
— тесно переплетена с онтологией (ибо рассуждать всегда нужно над чем-то)

И везде есть математика, доказательства, языки программирования, семантики и т.д.

Поэтому легко запутаться с этими топиками-оффтопиками.
Мне просто показали место, где "с людьми можно поговорить о типах в языках программирования", я и обрадовался. Выяснилось, что отнюдь не о всех типах, и не о всех языках программирования/моделирования. А жаль. Все сидят по своим норкам, каждый занимается маленьким кусочком проблемы типов, результаты одних невидимы другим.

[может, это всё в чат по теории категорий? -- https://t.me/ru_catheory]
У нас было множество попыток использовать теорию категорий в качестве аппарата для языка системного моделирования — все закончились ничем. Не приспособлены кролики для лазания ))) Там кстати и в названии "учим и обсуждаем", но не "обсуждаем и применяем" — прикладность всё никак и никак не получается.
То, что в любой формальной системе можно выразить что угодно, это понятно. Вопрос был в том, что это "легкое и простое выражение" что потом позволяет делать? А ничего особенного, как выяснилось. Просто выражать. Ну, просто выражать можно и так, как сейчас выражают — инженеры же искали не теоретическую красоту, а облегчение свой работы. Облегчения не было предъявлено, пути к облегчению работы не были показаны.

[так а что инженеры ищут в новых теориях?]
Речь шла о создании языка системного моделирования. И обсуждался формализм (или отсутствие такового). Было много разных заседаний. Вот тексты, там в ранних много про теорию категорий — но так и не срослось. Цепочка SysMoLan -- https://ailev.livejournal.com/1443879.html. Но есть и ещё одна задача, по факту та же самая -- о предмете курса вычислительного мышления, https://ailev.livejournal.com/1477090.html

[а что мешает инженерам взять Coq, Idris и прочие языки исчисления конструкций?]
Тогда программисты бы это взяли ещё раньше инженеров. Но не берут ))) Язык оказывается социальной проблемой: берут языки за возможность что-то на них делать, а не за математичность, красоту, современность и прочие качества.

Заход на обучение computer science на базе функционального маленького языка не получился: все остальные курсы не получалось надстраивать над знаменитым SICP, обучение дальше шло по факту с нуля. Прикладная польза была ноль, хотя курс сам легендарный. Для Coq ведь будет то же самое.

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

[вы ходите увидеть язык на все случаи жизни? так универсальные языки универсально неудобны. Инженерам нужны DSL, собранные конкретно для них. И собирайте эти DSL хоть на машине Тьюринга]
Под каждым DSL своя онтология. И мы возвращаемся к проблеме типов. DSL — это domain-specific language. Domain — это предметная область, набор предметов. Что попадает в эти предметы, и как эти предметы описывать — онтологический вопрос. Дальше вопрос не в математической мощности, а в вычислимости, удобстве написания и т.д.

Про машины Тьюринга развлекитесь: https://arxiv.org/abs/1611.02854. Вы ещё дифференцируемые типы не обсуждаете? Пора бы уже. Оптимумы для типов будете искать )))

[так инженеру по требованиям, инженеру-архитектору, инженеру по испытаниям нужны разные языки, они по-разному описывают систему. Так?]
Нет, я не согласен с таким различением — и ровно потому, что вопрос ставится онтологически. Целевой системой и у инженера по требованиям, и у инженера-архитектора, и у конструктора, и у инженера по испытаниям является работающая установка-в-железе (или программа в тот момент, когда она на рабочих серверах и на неё передано управление), в тот момент, когда они наносят непоправимую пользу своей работой. Описание (документирование) происходит и потребностей, и требований, и архитектуры, и планов испытаний, и результатов испытаний. Ключевое требование — чтобы они отражали реальность (онтологичность, моделирование мира, а не просто запись всяких фантазий), а не были просто упражнением в формализации.

Вот это моделирование мира инженерами выполняется:
— в программировании in-the-small (обычно один человек решающий как бы задачку олимпиадного программирования) типами языков программирования, у кого это Julia, у кого-то Haskell, у кого-то Coq (хи-хи), но чаще всего это Java и ООП в полном расцвете сил.
— в программировании in-the-large (много софтов, работающих над какими-то общими данными на разных серверах) некоторой системой типов, наваянной либо над трипл-стором с запросами на FOL, либо над реляционной базой данных, где жужжит реляционная алгебра
— а ещё есть много-много обработки данных, где явной работы с типами нет, а есть Excel-таблицы и всякие запрограммированные на них формулы, работа с типами ведётся тем самым "в уме", а типы представимы в ER-модельке, выраженной набором табличек (но это ни разу не реляционная база данных, и там никакой алгебры, всё руками и не нормализовано).

Вот мой вопрос начальный как раз к тому, что довольно много литературы во отражению мира в реляционных базах данных (равно как работ по критике табличных представлений для подобной работы), чуток меньше литературы про отражение мира во всяких нереляционных моделях данных, например трипл-сторах (семантик веб, как оно называлось — и FOL там была наше всё). Но и там случилась засада, хорошо описанная в https://justy-tylor.livejournal.com/171175.html. Сейчас растёт литература по моделированию мира во всяких NoSQL моделях данных.

А вот литературы по отражению мира в системах типов, развивающихся в "просто языках программирования" нет. Так что там делают всё более и более хитрые модели данных, но неведомо, как их использовать для моделирования задач. Известно же, что в DDD для предметов предметной области (domain-driven design, слово domain то же, что в DSL, и слово "предметы" в "предметной области" я неслучайно употребил вместо привычного "объекта") должны существать какие-то объекты в программе. И эти объекты обычно выражают системой типов. И вот это место сразу становится мутным — какие типы брать, и что ими выражать в мире полностью отдаётся на "опыт и смекалку". Базы данных проектируют хоть как-то, этому специально учат, а вот модели данных в программах почему-то не проектируют — весь акцент идёт на алгоритмику, а не моделирование данных.

Это и был мой начальный вопрос: вот изобрели новую систему типов, всунули её в какой-то язык программирования — но объяснили, что даёт эта система типов для улучшения моделирования данных, для улучшения описания мира? Или это просто выпендрёж из серии "у меня ещё про типы столько разных интересных идей, и ещё столько разной недоиспользованной математики осталось"? (я надеюсь, что достаточно выразительно сформулировал наезд )))

Мой вьюнош как-то пришёл с одного из первых своих уроков физики, и сказал, что физика трудней математики: в математике можно писать что угодно, если не нарушаешь простые правила, а вот в физике нужно всегда проверять экспериментами, соответствует ли это "что угодно" миру за окошком. И математику нужно знать в полном объёме плюс добавить сюда знание мира за окошком, чтобы не фантазировать в своих формульных выкладках. Вот я примерно то же самое спрашиваю про системы типов в языках программирования: пофиг, что там крутая математика — но как в этих типах мир выражать, чтобы ошибок потом поменьше было? Например, в ООП что для одного проекта объект, то для другого атрибут, и наборот (как печально сформулировал консорциум по моделированию данных EPISTLE в конце 20 века). Поэтому для инженерных данных ООП не подходит, ибо страшная головная боль объединять данные разных проектов — в том числе проектов инженерии требований, инженерии системной архитектуры, конструирования (когда на САПР работают и строят трёхмерные модели деталей, проверяя их прочность), испытаний. Если система большая, типа Боинга или атомной станции, то с ООП просто головная боль. Поэтому объектные-из-ООП базы данных не взлетели вообще никогда.

И после того, как объектные-из-ООП базы данных не взлетели по причине неадекватности представления мира для многих проектов (и тем самым для обработки одних и тех же данных многими алгоритмами из разных проектов), я задаю вопрос: а с современными системами типов что на эту тему? Почему не делают базы данных с зависимыми типами? Потому что это полный отстой в проектировании работы разных алгоритмов из разных проектов над одними и теми же данными — ибо есть какие-то аналоги тех же проблем, что и с системой типов из ООП? (надеюсь, и тут наезд достаточно жирно сформулирован, чтобы ожидать на него содержательный ответ)))

[так вы занимаетесь эдакого рода физикой?]
Даже точнее: онтологию традиционно относили к метафизике, а не физике ("над физикой") )))

Хотя я больше занимаюсь эпистемологией — вопросом о том, как я эту онтологию познаю/выучиваю из мира )))

[ну вот поглядите на CQL -- categorical query language, https://www.categoricaldata.net/]
О, это интересно. Про моделирование данных меж тем ничего не сказано, кроме того что вроде как можно отследить преобразования в разных пайплайнах — что откуда пришло и куда ушло.

У меня вообще впечатление, что все "математические" работы идут из постановки задачи programming/modelling-in-the-small. То есть один человек сидит и пишет программку на 200 строк, кучерявые данные не нужны, зависимостей от программ других людей минимум, всё внимание алгоритму и правильности в пределах этих 200 строк. Умножьте даже на порядок или два, это всё равно in the small — один человек=одна картина мира.

Мои вопросы главным образом про поддержку работы in the lagre, когда множество проектных групп делают разные куски системы, исходя из своих разных картин мира, а потом эти куски системы ухитряются совместно работать — ибо они договорились, как совмещать эти разные картины мира/онтики в рамках какой-то одной онтологии.

https://en.wikipedia.org/wiki/Programming_in_the_large_and_programming_in_the_small

[для сохранения композициональности (когда можно в лоб составлять систему из мелких кусочков) и городится весь теоркатегорный огород!]
Вот не факт, ибо есть мир, есть я, есть они и есть описание мира моё и их — и композициональность как она тут понимается это больше про описание мира без мира, меня и их. Математическая композициональность. Это тоже нужно, да, но дальше хорошо бы показать, как этим пользоваться, тот самый domain modeling в мультипроектной команде, когда они складывают свои описания мира.

В мире моделирования тоже есть запросы на композициональность, и вместо Simulink придумали акаузальное моделирование. Когда для каждого аспекта моделирования делают свой набор уравнений (теплотехники свой, экономисты свой, электрики свой и т.д.), и оформляют эти наборы уравнений как библиотеки. А потом (в отличие от Simulink, где каждое усложнение модели приходится аккуратно вписывать в каждое место кода) машина из этих наборов из разных библиотек составляет систему уравнений и решает её.

Ещё есть expression problem — http://en.wikipedia.org/wiki/Expression_problem (и Julia решает её через multiple dispatch, там типы добавляются без необходимости что-то перекомпилировать в старом коде).

То есть заход на эксперименты в in the small хорош, но его недостаточно. Мышление коллективно, программирование/моделирование/онтологизирование тоже коллективно и суть одно.

[ну, мы ещё не разобрались, как записывать всё зависимыми типами, у нас только исследования]
Мой вопрос был главным образом не про "как", а про "зачем" ))) То, что до in the large не добрались, так это часть моего вопроса: по принципиальным сображениям, то есть невозможно до этого будет добраться, ибо работать не будет (как не заработали трипл-сторы и объектные базы данных), или наоборот, после окончания экспериментов вдруг все проблемы будут решены и это станет возможным.

[так инженерам что, нужен для перевода с двух их DSL какой-то третий язык?]
Я вот как раз сразу про этот третий язык — какой он должен быть? ))) Ибо после этого сразу появляется идея, что можно было бы сразу выучить его, если уж на него всё можно перевести с других языков. Он ведь самый универсальный. Собственно, нужда в общей картине мира возникает только в момент встречи двух разных языков и понимании, что начиная с третьего языка уже выгодно иметь какой-нибудь "рабочий английский" в проекте. Когда встречаются китаец, малазиец и испанец, то в этой компании все говорят по-английски, хотя англичан среди них нет ))) Вот вопрос сразу к "английскому для моделирования данных": каким он должен быть? Удовлетворительного ответа на этот вопрос нет.

Ну, и про то, что инженер по требованиям работает на одном языке, а инженер-архитектор на другом, так не совсем так. Различия в языках диктуются различиями в предметной области, а не различиями в требованиях или архитектуре (ибо что для одного "потребности", то для другого "требования" для третьего "архитектурные решения" — эта терминология относительна в части системных уровней). То есть это всё описания каких-то систем, просто на разных границах. А описания да, все на разных языках — ибо при пересечении системной границы появляется эмерджентность, и приходится описывать другие свойства.

[ну, у нас люди идут по пути создания своей математики со своими основаниями математики. И в гомотопических типах это даже более правда, чем в зависимых типах]
Моделировать не "как в математике". Физики моделируют "как в физике", напрямую используя математику. И в математике есть даже мнения, что математика интенсивно развивалась в 20 веке, именно обслуживая запросы физиков.

У меня запрос похож на запрос физиков к математике. Только я не физик, а разработчики типов в языках программирования не математики. )))

[а что там с экстенсиональным/интенсиональным?]
На эту тему идёт вечная дискуссия. В 4D экстенсиональной онтологии принято считать, что вся система тамошних типов идёт от того факта, что это типизация объектов из реального физического мира (то есть это объекты, занимающие место в пространстве-времени). Если объекты занимают одно и то же место в пространстве-времени, то это один и тот же объект. Например, "Анатолий Левенчук" и "интенсивно цокающий по клавишам субъект" прямо сейчас занимают одно и то же место в пространстве (а "прямо сейчас" указывает ещё и на время). Значит прямо сейчас это один и тот же объект. Внешнее определение через пространство-время — экстенсинональное, а extent это (со времён Декарта) протяжённость в пространстве-времени, то что задаёт наличие объекта в этом мире. Всё остальное — это работа со множествами этих существующих в мире объектов. Множество, понятно, уже не существует в мире, это другой объект.

Ну, и это всё постоянно обсуждается, ибо не все онтологи согласны считать 4D представления о мире чем-то важным. А другие говорят, что тогда им немедленно попрёт фишка фантазировать о мире, плюс появляются неприятные вопросы про то, каков мир в момент времени между 3D его срезами )))

[так у нас математика в типах, в чистой отвязке от физики!]
Ну вот не так. У меня ж полно друзей с мехмата, и он недаром называется "механико-математический" — связь с физикой там предполагается! Вообще, эта привязка к миру или отвязка от мира есть и в самой математике, даже если отползти подальше от физики как таковой. Поглядите текст М.Атья "Математика в двадцатом веке", http://www.mccme.ru/free-books/matpros/i8005024.pdf.zip — он там про алгебраическую ветвь математики, "фон-нейман-компьютерную" и геометрическую ветвь, с приветом физикам, пространству и deep learning.

Можно ещё пообсуждать: когда я пишу про математику и про приготовление зелёного чая — это я по-русски пишу, или таки использую два языка "чтобы удобно было"? Или это DSL на базе русского хост-языка? )))

[если нужен таки третий язык, то это будет линейщина-моноидальщина, выраженная n-категорным языком. Если совсем попросту, то мультимодальная линейщина]
Ну вот ткните меня в книжку типа https://pragprog.com/book/swdddf/domain-modeling-made-functional для этого, или места, где такое обсуждают сейчас для этой мультимодальной линейщины. [7 скетчей, наверное, самое близкое]

[Но задачи будет решать не проще, если всё просто переписать в более общий язык]
Верное замечание. В deep learning в последнее время там воздерживаются от публикации работ с обобщениями или переформулированием в другие формализмы, если это не двигает как-то SoTA. Теоркатегорщикам можно заказывать кружку "your model is a special case of my model", это недорого: https://www.cafepress.com/mf/34058049/special-case_mugs

[так а CQL чем не подходит? язык запросов к базе данных на теоркатегорных основаниях!]
Там в статьях ссылка на categorical.info перенаправляется на https://conexus.ai/ — мотенизация CQL идёт полным ходом.

сonexus offers support for open-source CQL, support for data integration projects using CQL, and sells a proprietary extension of CQL that scales the open-source version along three dimensions:
- Visualization and programmer productivity
- Data size beyond a single in-memory node
- Artificial intelligence capabilities beyond simple equational reasoning

Но с онтологической точки зрения это опять-таки таблицы, только в них искать теперь можно другим языком запросов, и работать это будет чуть быстрее. Вся критика реляционного представления данных сохраняется.

Вот критика этих табличных и реляционных представлений (BORO Book, http://borosolutions.net/sites/default/files/Business%20Objects%20-%20Re-Engineering%20for%20Re-Use%20%282nd%20Ed%20-%20watermarked%20draft%20-%2020050531%29.pdf#page=1&zoom=auto,-22,848), и это же пример IMHO лучшей онтологической книжки по моделированию данных (про концептуальное моделирование, а не про физическую реализацию, языки запросов, скорость работы и т.д. про foundational ontology там нет, там только про мир и его модели и как это должно отображаться разными типами в upper ontology).

Печаль момента в том, что предложенная концептуальная модель кладётся далее в триплы — а это тупик.
* * *
Окончание текста в https://ailev.livejournal.com/1486407.html

Обсуждение в чате блога -- https://t.me/ailev_blog_discussion/402, в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216100232112621, в новом чате телеграмма про типы языков программирования (уже все типы, а не только depended), буквально с самого начала чата -- https://t.me/typeslife
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 1 comment