Dependent Typing and Monads as type system extensions.

Интересная беседа со Стефани Вейрих по зависимым типам, монадам, как коллекциям типов для расширения базовой системы типов языка Haskell (системы типов Хиндли-Милнера, λω = λ2 + λω_) — применении теории категорий для создания струкурных (высокоуровневых) и субструктурных (низкоуровневых) систем типов, применении теории типов Мартина-Лёфа (Martin-Löf type theory) для создания систем зависимых типов (исчисление конструкций, CoC, λPω) для (структурного и субструктурного) вывода типов при статическом анализе программ.

https://www.infoq.com/interviews/weirich-haskell-dependent-types

#Haskell

Ссылки по теме:
https://xn--r1a.website/technologique/1051
https://xn--r1a.website/technologique/1052
https://xn--r1a.website/technologique/1054

О тщете всего сущего. :)

Недавно в одном из чатов я писал:

"Синтаксис реально важен! Читабельность важна! Аккуратная ментальная модель языка, чтобы держать её в голове (и пользоваться ей) важна! Гвидо это прекрасно понимал, поэтому Python вышел настолько удачным!"

Как в подтверждение моих слов попалась статья Алексис Кинг "Восхождение по бесконечной лестнице абстракций", переведённая на русский язык недавно:

https://lexi-lambda.github.io/blog/2016/08/11/climbing-the-infinite-ladder-of-abstraction/

Перевод на русский язык:
https://ru.hexlet.io/blog/posts/infinite-ladder-of-abstraction

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

Сегодня в разговоре мне мой старый добрый друг и коллега, программист за 40 (yes, you can! you made it! =), сказал такую мысль, очень важную я считаю, поэтому хочу донести её до каждого из вас:

"Вот представь, что наша цивилизация вымерла (факторов для этого сейчас предостаточно, взять хотя бы биологические - питание, перенаселение, устойчивость вирусов и бактерий к антибиотикам), но до вымирания мы успели на неком носителе (типа кварцевого голографического, имеющего самую высокую ёмкость) сохранить хотя бы весь GitHub - какой код сможет понять будущая цивилизация (при допустимости того факта, что цивилизации умирали и жизнь возобновлялась на нашей планете не один раз), как расшифровать логику его работы, не имея железа архитектуры наших дней?
Cкорее всего большинство кода будет подобно манускриптам древних цивилизаций (типа шумерского царства или древнеегипетской цивилизации) - что-то смогут расшифровать и постичь, но большая часть останется не ясной, многое зависит от логики исследователей.
Той постижимой частью будет простой человеческий язык в комментариях с аналитической семантикой (языки индо-европейской группы) и код с императивной семантикой и структурной логикой (языки программирования высокого и среднего уровня), например байт-код виртуальных машин будет понятен, если их исходники на языках среднего уровня останутся, но работающее железо, кремниевая логика нанометровых транзисторных цепей, будут навсегда утеряны!
Поэтому - пиши комментарии в коде на русском и английском языках, выбирай языки не слишком низкоуровневые и не слишком высокоуровневые, практичные, ищи золотую середину и пиши код так, будто завтра мы все разом вымрем и цивилизациям будущего придётся читать, дебажить и запускать наши исходники! =)
Остальные принципы не столь важны!"

Этот пост за дружбу посвящается моему давнему другу Ярославу, разработчику Linux kernel subsystems developer at Novell - я уверен, ты скоро поправишься, выздоравливай! Иначе с кем мне крушить мои философские камни!? =)

Также огромное спасибо Александру Чистякову за подачу хорошего поста (ко времени) и за канал (for sure, это реально философский авторский блог!):
https://xn--r1a.website/lhommequipleure/21
http://telegra.ph/Da-zdravstvuet-zhizn-na-vysokoj-stupenke-12-02

#Telegram
#IT
#Software
#Development

Serverless/FaaS архитектура сервисов и платформа OpenFaaS на базе Docker контейнеризации.

Functions as a service (FaaS) это готовая к работе и самодостаточная (не требующая обслуживания со стороны пользователя/разработчика, serverless) облачная инфраструктура, чаще на базе нижележащих Docker контейнеризации и инструментов оркестрирования контейнеров (Kubernetes, Docker Swarm), предоставляемых как сервис, для упрощения развёртывания и обслуживания наносервисов.

Существует проект открытой платформы OpenFaaS на базе Docker для самостоятельного (self-hosted) развертывания FaaS инфтраструктуры на собственной хостинг площадке (например в дата-центре компании) для обслуживания сервисов.

Плэйлист с недавней конференции DockerCon Europe 2017, прошедшей в Копенгагене, Дании, 17 октября 2017 года - главной темой конферении были FaaS платфома OpenFaaS и serverless инфраструктуры для наносервисов:
https://www.youtube.com/watch?v=C3agSKv2s_w&list=PLlIapFDp305AiwA17mUNtgi5-u23eHm5j

https://www.openfaas.com

https://github.com/openfaas/faas

Автор проекта платформы OpenFaaS - Алекс Эллис.

Демонстрация работы:
https://www.youtube.com/watch?v=sp1B7l5mEzc
https://www.youtube.com/watch?v=BK076ChLKKE

Канал Алекса:
https://www.youtube.com/channel/UCJsK5Zbq0dyFZUBtMTHzxjQ

Также есть несколько коммерческих FaaS платформ - Amazon Lambda, Oracle Fn и Iron Functions:

https://github.com/fnproject/fn
http://www.opennet.ru/opennews/art.shtml?num=47314

https://github.com/iron-io/functions
https://xn--r1a.website/technologique/608

#FaaS
#Go
#Golang

Код проекта системы контроля версий Mercurial переводят на Rust.

Представлен план переноса (портирования) кодовой базы проекта распределённой системы управления версиями исходного кода Mercurial с языка Python на язык программирования #Rust.

https://www.mercurial-scm.org/wiki/OxidationPlan

Проект Mesosphere планирует активно применять Rust в DevOps инструментах.

Платформа Mesosphere и Datacenter Operating System (DC/OS) будут активно применять #Rust в серверной облачной инфраструктуре и DevOps инструментарии.

На вопросы Флориана Лейберта (CEO Mesosphere) о применении Rust для создания инструментов управления (DevOps) облачными инфраструктурами ответил Стив Клабник, один из основных core developers проекта компилятора Rust, а также Rust Community Manager (неофициально).

https://mesosphere.com/blog/rust-devops/

Designing Futures. Design Fiction.

Семинар CS547 по человеко-машинному взаимодействию Университета Стэнфорда.

Джулиан Бликер (Julian Bleecker), инженер, промышленный дизайнер человеко-машинных интерфейсов, о проектировании и юзабилити тестировании прототипов и человеко-ориентированных интерфейсов для взаимодействия с машинами.

https://www.youtube.com/watch?v=iH8X6Bcs7w8

Вы когда-нибудь задумывались о том почему кнопки и элементы управления в любых интерфейсах сгруппированы и расположены справа или слева (симметричный дизайн)? Я задумывался. Но многие ли из нас левши или от природы воспринимают мир иначе?
Грамотно спроектированный интерфейс должен быть интуитивным, транспарентным, прозрачным и понятным, не ощущаемым и естественным, как воздух. Этому способствует вертикально и горизонтально симметричный дизайн.

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

Очень советую поискать лекции и интервью Ноама Хомски (автора принципов универсальной и порождающей грамматики, на основе которых базируются все инструменты NLP, в т.ч. NLTK на Python), Марвина Мински (заложившего основы науки об искусственных нейросетях и машинном обучении) и Яна ЛеКуна (https://xn--r1a.website/technologique/1152).

Сам я это всё узнал, когда стал изучать машинное обучение для анализа данных - на EDX был курс по "дизайну человеко-машинных интерфейсов", в котором даже рассказывали как AI помогает дизайнерам в создании интуитивных интерфейсов, а на Coursera был интереснейший курс по лингвистической антропологии на основе работ Ноама Хомски.

#thinkingoutloud

Благодарю за идеи и вдохновение на посты по данной теме:
@Schvepsss и @Luger_08

О юзабилити и как оно связано с проектированием и прототипированием в более широком смысле промышленной разработки.

#thinkingoutloud

Юзабилити (usability, от use ability, возможности использования) - это такой показатель, как коэффициент полезного действия в человеко-машинных интерфейсах, определяющий удобство, практичность и простоту в использовании интерфейсов для взаимодействия с устройством, визическим или виртуальным. Также юзабилити это частный случай эргономичности, которая более свойственна разработкам в области промышленного дизайна, физическим устройствам, например интерьеру и экстерьеру автомобилей.

Высокий показатель юзабилити (usability) это фактически показатель удобства и положительного пользовательского опыта (User eXperience, UX - не нужно путать с UI, User Interface, самим интерфейсом взаимодействия пользователя с устройством!).

В промышленном дизайне интерфейсов есть способы измерения юзабилити на тестовых группах пользователей - юзабилити тестирование, которое хорошо интегрируется в цикл производства от тестирования прототипов до запуска в массовое производство (production).

По статистике многих юзаюилити тестирований наиболее удобными являются симметричные структурированные интерфейсы, которые по своей сути позволяют использовать компонентный подход в их проектировании. В промышленности такой подход хорошо подходит для массового производства (конвейерного производства и сборки, pipelining).

Тоже самое свойственно промышленному программирванию и дизайну интерфейсов - компонентный подход.

Когда-то Borland развивала серию RAD (Rapid Application Development) IDE (Delphi, C++ Builder, JBuilder) с удобным компонентным проектированием интерфейсов на базе библиотеки компонентов интерфейса (interface widget toolkit library) VCL (Visual Component Library), которая работала поверх WinAPI.
Сейчас тоже есть Lazarus для FreePascal, Glade (для GTK+), wxGlade (для wxWidgets) и Qt Creator (для Qt).

Ключевое здесь - юзабилити и компонентный подход к проектированию интерфейсов, который позволял даже программистам без чувства прекрасного быстро делать приложения со вполне приемлемым юзабилити!

С готовыми компонентами было проще cделать композицию с потребным юзабилити.
Сейчас же, с веб-технологиями, можно сделать вообще любой интерфейс (хоть с применением WebGL!), до такой степени, что теперь макеты интерфейса разрабатывают дизайнеры в графических редакторах.
И когда столько свободы в построении интерфейсов резко встаёт вопрос (и спрос) в обучении подходам в юзабилити. (Маркетинг и рынок это с радостью продают и потребляют. =)

Многие компании стараются унифицировать проектирование интерфейсов при помощи Material и других компонентных подходов к дизайну, при помощи компонентных библиотек элеметов интерфейса (виджетов) и фреймворков, напрмер Polymer (JS), Bootstrap (CSS) и подобных.

Все подходы (How-To), продвигаемые крупными компаниями и вендорами, нацелены на то, чтобы сделать приложения единообразными, с определённым расположением и видом элементов интерфейса, чтобы опять же прийти к компонентному дизайну и единому интуитивному опыту для пользователя (UX, User eXperience) и повысить юзабилити.

Однако после курса MIT на EDX становится вполне очевидно, что все самые базовые и основные подходы основаны даже не на психологии пользователя - но на человеческой физиологии и нейробиологии работы полушаний человеческого мозга!
Именно на физиологических корнях особенностей восприятия строятся все человеко-машинные интерфейсы, в том числе и программные интерфейсы.

Например, взять мобильное приложение Telegram для Android - это образец послойного Material дизайна интерфейса, где можно слои двигать свайпами, это и есть основная концепция Material дизайна интерфейсов, управление жестами в одно касание, для удобства управления одним пальцем, держа устройство в одной руке. Для более сложных жестов, кроме свайпов (swipe) - это всегда проблема стандартизации, т.к. нет единых соглашений и данных об их удобстве.

Почему я затронул эту тему...

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

Дизайнер может и способен быть и программистом, например разработчиком клиентских приложений.
Я много раз за свою практику и среди своих друзей наблюдал как разработчики интерфейсов и клиентских приложений, веб-дизайнеры и графические дизайнеры, становятся server-side разработчиками с отличными навыками проектирования.
Могу сказать и про себя - я изучал математику, занимался веб и графическим дизайном (с 2002 по 2010 годы) одновременно с разработкой клиентских и серверных приложений, быстро перерос в системного программиста (С/C++, с 2005 года по сей день).

Многие утверждают, что программисту не нужны дизайн или математика.
Я убеждён в обратном.
Для умения проектировать, видеть всю систему сразу и всю цепочку шагов для полного достижения абстрактной композиции и структуры системы - программисту широкого профиля и проектировщику (архитектору) необходимы знания и дизайна и математики.

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

#thinkingoutloud

Видео докладов с недавней конференции KotlinConf 2017, прошедшей в Сан-Франциско 2-3 ноября.

Полный плэйлист докладов:
https://www.youtube.com/playlist?list=PLQ176FUIyIUY6UK1cgVsbdPYA3X5WLam5

https://www.kotlinconf.com

#Kotlin

Ссылки на предыдущие посты и материалы по теме:
https://xn--r1a.website/technologique/1126
https://xn--r1a.website/technologique/1108
https://xn--r1a.website/technologique/1042
https://xn--r1a.website/technologique/1043
https://xn--r1a.website/technologique/1044
https://xn--r1a.website/technologique/995
https://xn--r1a.website/technologique/928

Дискуссия по ключевым темам на открытии конференции.

https://www.youtube.com/watch?v=pjnHDXkeK-4

(https://www.youtube.com/watch?v=pt0MYJWvxtc)

Дискуссия с обсуждением итогов и ключевых тем докладов, перспектив развития Kotlin, на закрытии конференции.

https://www.youtube.com/watch?v=NMs8Z6rFnzE

Андрей Бреслав немного приоткрыл завесу тайны над будущим внутренним устройством проекта компилятора Kotlin/Native.

https://www.youtube.com/watch?v=3Lqiupxo4CE

Рассказал о том какая модель автоматического управления памятью будет в Kotlin/Native - ARC (т.к. используется LLVM бэкэнд компилятор), очень похожая на подобную в Swift и Vala/Genie, с использованием weak references, но также дополнительно уже реализована сборка мусора (GC) в видео циклического коллектора:
https://www.youtube.com/watch?v=3Lqiupxo4CE&t=28m

Насколько безопасной будет система типов Kotlin/Native, будет ли реализована субструктурная система уникальных или линейных типов (uniqueness types, linear types/logic - проверка обёрнутых в типы (boxed, box model) указателей с помощью правил системы типов на низком уровне в процессе статического анализа и компиляции программы) для контроля владений (owned, unowned) и заимствований (borrowed) для указателей на сегменты памяти - вопрос открытый и пока не решённый.

И главная киллер-фича, которая будет в Kotlin/Native (и есть в Kotlin на всех платформах) и которая приравнивает его к Go - это сопрограммы и CSP многопоточность, которая очень лаконично объединяет концепции асинхронного и многопоточного кода, делает программирование асинхронного и многопоточного кода очень простым, снижая при этом накладные расходы по памяти и времени/задержкам порождения новых потоков, но нужен также фреймворк для удобного мапинга сопрограмм на системные треды (при ARC механизме управления памятью), либо автоматический мапинг в run-time (при реализации автоматической сборки мусора, GC механизме управления памятью):
https://www.youtube.coma/watch?v=3Lqiupxo4CE&t=34m56s

https://twitter.com/abreslav/status/937651203873431552

https://twitter.com/andrcmdr/status/936679638339850240

Безопасность работы с памятью и указателями в Kotlin/Native будет, но не ценой усложнения и неудобства использования языка, а также борьбы с компилятором - команда разработки в поиске иных решений, отличных от применённой в Rust модели владений/заимствований и времени жизни областей видимости (пространств имён, scopes).

Хорошо было бы иметь в одном языке и безопасность памяти и сопрограммы/продолжения, интегрированные на уровне языка (suspend functions в Kotlin).

Вообще есть всего две основные сложности при создании нативной реализации компилятора языка - реализация поддержки системных Threads и IO, которые решаются через реализацию собственного run-time для программ (RAII/RC/GC управление памятью, thread-mapper (M:N) для маппинга программных потоков на системные потоки, создания пулов потоков и процессов) и использование системных вызовов ОС (syscalls), но проблема в том, что системные вызовы у каждой системы/ядра свои и только Unix системы стараются придерживаться POSIX стандарта, хотя и в них различий хватает (взять те же сигналы для процессов - есть и уникальные сигналы в проприетарных Unix системах).

Роман Элизаров снова очень хорошо рассказал про сопрограммы и глубоко погрузил всех в асинхронный и многопоточный код на базе сопрограмм, продолжений и suspend functions.

https://www.youtube.com/watch?v=_hfBv0a09Jc

Ссылки на предыдущие материалы по теме:
https://xn--r1a.website/technologique/1042
https://xn--r1a.website/technologique/1043
https://xn--r1a.website/technologique/1044

Седрик Беюст (Cedric Beust) рассказал про Kobalt - это очень классная билд-система сборки проектов на Kotlin, написанная на самом Kotlin.

https://www.youtube.com/watch?v=BoGJL2ZPK0o

http://beust.com/kobalt/home/index.html

http://beust.com/kobalt/plug-in-development/index.html

https://github.com/cbeust/kobalt

Ссылки:
https://xn--r1a.website/technologique/1154

Разработчики из Netflix рассказали об этапах создания, сборки, формировании поставки и развёртывании проектов в своей облачной инфраструктуре (continuous delivery, deployment, continuous integration) при помощи облачной системы сборки Nebula и облачной платформы непрерывной поставки Spinnaker, которые применяются во всех проектах компании и в которых активно применяется Kotlin - следующие поколения системы сборки и платформы поставки будут полагаться на Kotlin практически полностью, как на базовую технологию, применяемую в этих проектах.

https://www.youtube.com/watch?v=CbL1d2Nd3Rg

Machine learning strikes back!

Но круче всех, с более футуристичным докладом, полным отменного юмора и проницательного предвидения дальнейшей ситуации на рынке разработки софта и анализа данных, в развитии языков и методов программирования, выступил Эрик Мейер и рассказал о будущем языке (который уже разрабатывается в Facebook) связывающем текущую традиционную императивно-функциональную парадигму программирования с парадигмой, методами и моделями машинного обучения.

https://www.youtube.com/watch?v=NKeHrApPWlo

Как связать парадигмы программирования, как внедрить машинное обучение в языки программирования, не при помощи движков и фреймворков машинного обучения, но на уровне языка и для помощи в написании программ, как в этом поможет математика - связывание функций, сопрограммы (напрммер в Kotlin =), futures, монады, теория категорий, универсальная алгебра, графовая алгебра и теория моделей - обязательно внимательно посмотрите и послушайте видео доклада, автор говорит про очень интересные и важные, определяющие для всей индустрии вещи.

Машинное обучение базируется на эмуляции нейросетей, которое построено на тензорном исчислении (тензорной алгебре Риччи), разделе линейной алгебры - кто изучал математику легко поймёт насколько это близко к алгебраической топологии, теории категорий и теории множеств, теории графов.

Эрик потрясающий человек и автор, он умеет мастерски объяснять крайне сложные концепции невероятно простым языком.

Главный посыл доклада:
Нейросети должны помогать писать программы, например в IDE и языках поддерживающих flow-sensitive typing, IDE должны не просто уметь показывать места ошибок, но и предлагать варианты решений.

В свою очередь сам язык программирования должен в современных условиях и в текущем состоянии отрасли/индустрии позволять связывать данные из разных источников (выходов нейросетей) и преобразовывать данные для их обработки в других системах (входов других нейросетей) - источниками и приёмниками данных в данном контексте выступают нейросети, а язык программирования должен иметь средства обработки, преобразования и связывания данных, например монады/функторы для связывания категорий и базовые функции для распределённой и параллельной обработки данных (map, fold/reduce). Языки поддерживающие функциональную парадигму программирования в своей основе (например Haskell, OCaml) имеют все необходимые средства структурирования, композиции и обработки данных и прекрасно подходят для этих целей.

Но нейросети не должны оставить нас, программистов, без работы, а возможность этого весьма высока в ближайшие годы, если в методы автоматного программирования, метапрограммирования и транс-компиляцию внедрить методы машинного обучения.
Именно для этого сейчас нужен язык объединяющий машинное обучение и традиционное программирование через парадигму функционального програмирования, монады и теорию категорий.

https://www.youtube.com/watch?v=NKeHrApPWlo&t=50m

"The program of the future is a mix of imperative code with machine learn models... So the programming language of the future are the mix of traditional languages plus machine learn models... So we have to embed that into programming languages, and a way we can do that embedding is using monads and in particular the Probability Monad".

#Great_Insights

Ссылки:
https://xn--r1a.website/technologique/1002
https://xn--r1a.website/technologique/1006
https://xn--r1a.website/technologique/1007
https://xn--r1a.website/technologique/1131

Заметка для администраторов каналов (и групп) Telegram.

Сегодня заморочился с исходниками недавно вышедшей новой версии десктопного клиента Telegram - https://github.com/telegramdesktop/tdesktop/tree/v1.2.0

В общем, смысл такой — все печатаемые символы которые не покрываются регулярным выражением типа [0-9a-zA-Zа-яА-Я\s\_\-\+\!\@\(\)\[\]\{\}\<\>\,\.\:\;\'\"], т.е. вводимые символы `~#$%^&*=\|/? (а также символы Unicode) позволяют выводить полный листинг участников каналов (и групп) в десктопном клиенте. (!!!)

Т.е. ввод этих символов (`~#$%^&*=\|/? и Unicode, даже смайлов) в поле поиска member'ов позволяет преодолеть показ стандартного списка из 200 подписчиков каналов и показывает всех. В группах работает аналогично.

Подобный очень полезный финт для полного вывода списка/листинга всех пользователей работает как в последней версии (v1.2) десктоп клиента Telegram, вышедшей недавно на днях, так и в предыдущих версиях.

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

Как сделать подобный запрос с выводом member-list'а через API.

Для вывода всех данных о канале или групп-чате и вывода списка участников в числе этих данных, в клиентском API протокола MTProto есть метод getFullChat объекта Messages, который возвращает объект messages.ChatFull с полной информацией о канале или группе.

https://core.telegram.org/method/messages.getFullChat

https://core.telegram.org/type/messages.ChatFull
https://core.telegram.org/constructor/messages.chatFull

https://core.telegram.org/type/ChatFull
https://core.telegram.org/constructor/chatFull

https://core.telegram.org/type/ChatParticipant
https://core.telegram.org/constructor/chatParticipant

https://core.telegram.org/type/ChatParticipants
https://core.telegram.org/constructor/chatParticipants
https://core.telegram.org/constructor/chatParticipantsForbidden

Для справки есть исчерпывающая и актуальная документация о всех методах работы с данными протокола MTProto - https://core.telegram.org/methods

Более того авторы также озаботились созданием Haskell-подобного метаязыка TL с зависимыми типами для описания представления и работы с композицией типов данных протокола MTProto — https://core.telegram.org/mtproto/TL

https://core.telegram.org/schema - схема клиентского API на языке TL, декларативно описывающая типы данных и методы работы с ними в протоколе

https://core.telegram.org/schema/mtproto - схема самого протокола

Композиция типов данных в протоколе довольно сложно структурирована, но для облегчения можно использовтаь сторонние бибилотеки-мапперы типов и методов/функций работы с типами для их использования в парадигме другого языка программирования, например Python с помощью библиотеки Telethon — https://github.com/LonamiWebs/Telethon

https://lonamiwebs.github.io/Telethon/methods/channels/get_full_channel.html

PS: Хочу также порекомендовать жутко полезную библотеку для создания ботов на Haskell, если вы изучаете язык и хотите в него вникнуть через pet проект - https://hackage.haskell.org/package/telegram-api

Но, Bot API при этом например не позволяет запросить полный список подписчиков - только общее количество участников каналов и логировать подписавшихся/ушедших участников после добавления бота в канал или группу:
https://core.telegram.org/bots/api#getchatmemberscount
https://core.telegram.org/bots/api#getchatmember
https://core.telegram.org/bots/api#message (поля данных new_chat_members и left_chat_member объекта Message)

https://hackage.haskell.org/package/telegram-api-0.7.0.0/docs/Web-Telegram-API-Bot-API-Chats.html