Disclaimer: да, в понедельник мы опубликовали хабрапост с именно таким сравнением языков. Нет, мы не сошли с ума. Всё идёт по плану.
Виталий Брагилевский совмещает в себе знания о теоретической информатике и актуальную программистскую практику. Он преподает дисциплины, связанные с теоретической информатикой, является членом комитета по стандартизации Haskell и входит в наблюдательный комитет по разработке Haskell-компилятора GHC.
Эта хабрастатья — большое интервью с Виталием на следующие темы:
- Преподавание и знакомство с JavaScript;
- Зачем выбирать Haskell;
- Место функциональных языков в жизни программиста;
- Чего хорошего в JavaScript и как он развивается;
- Что появится в языках программирования в ближайшие 10-15 лет;
- Какие языки программирования вызывают доверие и почему;
- В чем разница между научными конференциями и конференциями для разработчиков. Зачем преподавателю вообще на них ходить;
- Важно ли читать программисту, устаревают ли книги и какие из них must read.
Интервью ведут члены Программного комитета конференции HolyJS 2019 Moscow, Алексей Золотых и Артём Кобзарь. Если интервью вам недостаточно, то уже совсем скоро, на следующей HolyJS, Виталий расскажет и покажет на примерах, как связать JavaScript с теорией алгоритмов.
О преподавании и знакомстве с JavaScript
Артём: Среди наших слушателей, особенно среди JavaScript-комьюнити ты не широко известен, расскажи, пожалуйста, о себе, чем ты занимаешься, какие у тебя увлечения — рабочие, профессиональные, возможно, нерабочие.
Виталий: Я занимаюсь преимущественно преподаванием, читаю курс в петербургском госуниверситете и периодически участвую в других работах. Поскольку я преподаватель, мне приходилось изучать массу разных тем. Как это обычно бывает в вузе, есть необходимость прочитать тот или иной курс, а для этого во всём этом нужно разобраться.
Так получилось, что я преподавал много всего. Например, один из моих самых первых спецкурсов, который мне поручили в первый же год работы, когда я был совсем молодым, назывался «Web XML-технологии». Тогда это были горячие темы, только появился Ajax в JavaScript, ещё толком не было литературы. Я объяснял, как всем этим пользоваться.
Поскольку тогда толком ещё никто не понимал, как этим пользоваться, всё ограничивалось примерами вроде такого: есть два выпадающих списка, пользователь в одном из списков выбирает какой-то пункт, идёт запрос на сервер, и тебе приходят данные, чем наполнить второй выпадающий список. Это была новинка, на сайтах такое мало где встречалось. Тогда только появился Google-поиск в бета-режиме, когда, пока ты начинаешь набирать какой-то запрос, он тебе подсказывает продолжение. Ajax-овые штуки были в новинку, и я их преподавал.
Чего я только после этого не преподавал: и математические, и программистские вещи. Когда-то давно наткнулся на Haskell, и с тех пор он стал главной сферой притяжения, чем я занимался. Помимо преподавательской деятельности, изучения вообще всего в информатике, чтобы преподавать, я начал сотрудничать с издательством «ДМК-пресс», перевёл для них несколько книжек (с другими людьми, сам или что-то редактировал). Это всё тоже было вокруг Haskell. Пожалуй, вот эти два вида деятельности — преподавание и то, что связано с переводами книг на русский язык, — это основное, чем я занимался.
Артём: То есть мы прямо ветерана JavaScript к себе позвали. Застал Ajax и, наверное, даже PHP.
Виталий: Да, на PHP в самые первые годы даже программировал, несколько сайтов написал.
О причинах выбора Haskell
Артём: Ты больше всего известен именно в Haskell-сообществе. Почему ты остановился на Haskell и на этой экосистеме?
Виталий: Поскольку я никогда не рассматривал для себя карьеру программиста, то я был свободен в том, что мне нравится. Мне не нужно было интересоваться тем, за что платят больше денег. Когда я узнал про Haskell, мне он очень понравился. Об этом не очень хорошо говорить, и я даже как-то в англоязычном комьюнити позволил себе сказать что-то вроде «Haskell — это язык для умных, там и комьюнити в среднем более умное». Меня за это побили американцы, и они правы. Но мне именно это было интересно.
То есть я в своё время, пока ещё учился в вузе, занимался достаточно суровой математикой, поэтому переключение в относительно суровую программистскую тему для меня было очень естественным. Вообще понятно, что сейчас из таких языков программирования, которые используются в продакшене, Haskell — один из самых наукоёмких, что ли, ресурсоёмких. Вся эта абстракция, которая там есть, наиболее близка к математике. Поэтому для меня это был естественный выбор.
О функциональных языках и их месте в мире программистов
Алексей: А как ты относишься к языкам динамической и функциональной направленности? Что насчёт Lisp-подобных вещей?
Виталий: Я люблю себя позиционировать даже не столько хаскелистом, сколько любителем языков программирования вообще. Во-первых, понятно, что все языки имеют право на существование. Я считаю, что сравнивать языки программирования по принципу «лучше-хуже» — это совершенно идиотское занятие. К сожалению, этим часто занимаются в соцсетях и не только, но в этом нет смысла.
Мне нравится изучать фичи языков программирования и как-то классифицировать языки программирования по этим фичам. Но считать, что вот это хорошая фича, а это плохая — глупость. Поэтому ясно, что языки с динамической типизацией безусловно имеют право на существование. Я, например, сейчас в своём курсе для первокурсников взял за основу язык программирования Julia. Это динамический язык, там есть система типов. Мне было интересно его преподавать, чтобы заодно посмотреть такую область применимости.
Вообще первый функциональный язык, который я встретил, был Lisp. Когда я много лет назад читал книжку «Структура и интерпретация компьютерных программ», конечно, это всё производит впечатление. Поэтому я с огромным интересом ко всему этому отношусь. Например, к JavaScript я тоже отношусь с большой любовью, потому что я хорошо знаю его историю.
Знаю, что когда он только появился, он должен был быть чем-то вроде Lisp, потому что вначале оригинальный синтаксис был Scheme-подобный. А потом, скорее, из каких-то маркетинговых соображений он был заменён на C-подобный, но внутри там сидят, безусловно, Lisp-овые языки, и это мне импонирует.
У меня вообще такое ощущение, что многие любители JavaScript этого не знают, и им нормально, но я знаю, поэтому мне ещё лучше. Так что все языки хороши, и мне интересно их изучать, интересно изучать область применимости, интересно смотреть, что на них делается проще и удобнее. И вообще вот такое сравнение языков по отдельным задачам — это тоже отдельная интересная область, которой мне нравится заниматься.
Что хорошего в JavaScript
Артём: Пока ты готовил доклад, соприкасался с новой версий JavaScript, с тем, что в него внедрили. Что ты с точки зрения теории языков программирования можешь выделить хорошего, плохого, возможно, какое-то интересное решение?
Виталий: Оценивая с точки зрения разнообразия языков программирования, конечно, самое интересное в JavaScript — это его объектная модель. Это то, что было с самого начала. У прототипной модели очень богатая история, это суперинтересно тем, что практически ни в одном другом из современных языков сейчас её нет.
В языках типа C# с помощью методов расширения решают такую задачу, как добавить существующим объектам какие-то методы. Это то, что в JavaScript было с самого начала, и там оно гораздо более естественно выглядит. То есть у нас есть прототип, к которому мы добавляем методы и потом на его основе создаём новые объекты. В языках типа C# это более искусственно, на мой взгляд.
Мне было интересно посмотреть на то, как в JS добавляются модули. В JavaScript уже очень давно существуют проблемы, связанные с модулями, десятки лет, можно сказать, и интересно, как они этим всем начали заниматься. Потому что модули — это глубокая теоретическая тема, есть много разных подходов к их реализации. Я, правда, не могу сказать, что я досконально это изучил, но это то, что мне кажется интересным кейсом в области развития языков программирования. То есть как в сложившийся язык добавлять фичи, которых там раньше не было.
Это ещё интересно, потому что несколько лет назад в Haskell была попытка добавить, скажем, более правильные модули. Сейчас можно сказать, что эта попытка провалилась, никто не стал этим пользоваться. Это так называемый бэкпэк-проект, то есть это вроде как реализовали, но использование настолько несущественное, что стало ясно, что сделали хорошую новую модульную систему, но не очень получилось.
У меня такое ощущение из разговоров с разными ребятами, кто занимается JavaScript, что модули в JS получились лучше. Правда, это я очень поверхностно знаю. Я думаю, на мнение о JavaScript очень сильно влияет то, что там можно писать очень плохой код. И если очень плохой код можно написать, его кто-то обязательно пишет и в больших количествах. Это негативно сказывается на оценке языка. С точки зрения теории языков программирования это, конечно, не очень хорошо.
Алексей: Удалось ли посмотреть JavaScript последних версий? Что удивило кроме системы модулей?
Виталий: Я не могу сказать, что удалось. Я что-то полистал, но совсем неглубоко. Я не могу перечислить.
Что появится в языках программирования в ближайшем будущем
Артём: Теория языков программирования — довольно академическая среда и, в принципе, интересная. Какие за последние годы новые фичи в языках, которые вот-вот появятся через 10-15 лет? Какие сейчас ведутся исследования в этой области?
Виталий: Я бы сказал, что самая горячая тема сейчас — это gradual typing. Это когда одновременно в программе существуют и оттипизированные части, и не оттипизированные. Это есть для Python, для JavaScript, это делается и для игрушечных языков. То есть мы можем, во-первых, совмещать типизированные и нетипизированные части, во-вторых, у нас есть простой способ расширять типизацию.
То есть мы делаем прототипную реализацию чего-то, как это всегда делалось в динамических языках без всяких типов, а потом начинаем на отдельные компоненты навешивать типы, всё больше и больше. В идеале получаем типизированную программу со всеми преимуществами. Там меньше ошибок на этапе выполнения и так далее.
Это, пожалуй, одно из самых главных развитий. Какие-то элементы уже есть в виде библиотек, но пока это ещё область исследования. Если мы будем смотреть ведущие конференции по языкам программирования, там обязательно несколько секций будет посвящено gradual typing, типизации. Это то, что почти наверняка войдёт в большинство динамических языков, потому что это очень удобно. Получается совмещение двух миров.
Уже лет десять идут исследования над зависимыми типами, когда тип зависит от значений. Самая главная проблема в том, что это стирает границу между этапом компиляции и этапом выполнения, потому что на этапе компиляции конкретные значения ещё не известны, но нужно проверить типы. То есть конкретные значения появляются в рантайме, но типы уже должны быть правильными.
А там уже нужно написать функцию, в которой в зависимости от переданного значения меняется тип результата. Это стирание границы между рантаймом и временем компиляции — очень интересная вещь, это тоже сейчас в теории уже лет 10-15 активно исследуется и почти наверняка попадёт во многие языки, в первую очередь статически типизированные, потому что существенно повышается выразительная система типов благодаря такому развитию.
Правда, там есть обратная сторона. Оказывается, что писать программы может быть слишком сложно. Вроде бы типы всё контролируют, но писать очень сложно, поэтому иногда думаешь, что чёрт с ними, с этими зависимыми типами, взять какой-нибудь тип any и с ним программировать.
Артём: У нас так и делают.
Виталий: Так тоже можно делать при большом желании, просто иногда деваться некуда. Когда тебе с сервера приходит не пойми что, и пока ты не запустишь программу, не узнаешь, тебе всё равно приходится пользоваться такими вещами, даже в Haskell, тут уж никуда не деться.
Как Виталий развивает Haskell
Артём: Забавно. Вернёмся к Haskell. Ты состоишь в комитете Haskell 2020. В Podlodka ты говорил, что вы там ничем не занимаетесь, но в одном интервью ты упомянул, что всё-таки работаешь над простыми ограниченными семействами функций. Какие ещё конкретные вещи ты имплементируешь, курируешь или участвуешь в имплементации, возможно, в новый стандарт Haskell?
Виталий: Это два разных комитета. Я состою в двух комитетах. Один — Haskell 2020, в котором действительно ничего не происходит, это мёртвый комитет. Его цель — написать стандарт языка, и это уже точно не будет написано. Он выигрышнее звучит — «Комитет по разработке стандарта языка», но не работает.
Второй комитет называется «Наблюдательный комитет компилятора GHC» — Glasgow Haskell Compiler. В нём я состою чуть больше года, у него задача гораздо менее амбициозная. Этот комитет рассматривает фичи-пропоузалы, предложения для изменения компилятора и той версии языка, которая в этом компиляторе реализована. Есть стандартный Haskell, а есть Haskell, реализованный конкретным компилятором. Вот пример такого расширения языка: «простые семейства типов». Это попытка облегчить программирование на уровне типов, добавив дополнительные средства контроля.
Я, правда, должен сказать, там достаточно свободная среда, то есть я всё лето, наверное, вообще не следил ни за какими пропоузалами и задолжал много своего времени этому комитету, всё планирую к этому вернуться.
Моя задача там такая — шефердить пропоузал: есть описанное предложение, мне нужно посмотреть, может быть, посоветовать автору что-то доработать и в конце концов выйти к комитету с предложением либо рекомендовать включение в компилятор, либо отказаться. После того, как я это предложение вношу, комитет обсуждает и принимает решение — там всё решается коллективно.
Одно из предложений, которые я задолжал, связано с обозначением подчёркивания в типовых аннотациях. Когда можно тип не полностью указывать, то есть там есть дырки, и есть предложение реформировать эту систему, чтобы как-то единообразно всё анализировать. Дырки могут быть в типовых аннотациях, в реализации функций. Предлагается некий единый подход.
Этот комитет рассматривает узкие изменения именно в компилятор.
Артём: У нас тоже есть комитет по стандартизации — TC39. Сначала приходит какой-то пропоузал, и он ищет чемпиона. Чемпион — это человек из комитета, который готов курировать этот пропоузал. Потом, насколько я знаю, у нас идёт градация по стейджам. Есть 4 стейджа, по которым фича двигается. Нулевой — это когда только есть предложение, единичка — это когда нашёлся чемпион и описан высокоуровневый API, и так далее. Четвёртый — это уже занесено в язык. Человек, который делал пропоузал, и куратор участвуют в совещаниях этого комитета и продвигают этот пропоузал. Как это у вас происходит? Это просто комитет потом внутри решает?
Виталий: У нас вся деятельность открыта, она ведётся на GitHub и частично в открытых mailing-листах. Приходит автор предложения — мы пока рассматриваем предложение, реализация нас не очень интересует. Она может быть, её может не быть, мы это никак не анализируем, от этого ничего не зависит. Сначала идёт обсуждение широким сообществом, все желающие могут комментировать это предложение.
Потом, когда устоялся пропоузал, автор сабмитит его комитету, то есть просит комитет рассмотреть. Секретарь комитета назначает шеферда, который будет его курировать. Он смотрит, анализирует, может быть, предлагает доработки или наоборот пытается обосновать, почему это не имеет права на существование, после чего он выходит с предложением отвергнуть или, может быть, отправить на доработку, или принять. Комитет обсуждает, принимает решение.
И когда комитет решает, что мы согласны с этим пропоузалом, и он переходит в статус принятых, в принципе, кто угодно может взяться за его реализацию. До этого момента может не быть никакой реализации, мы просто принимаем решение — да, вот такую фичу в языке или компиляторе иметь бы неплохо, и у нас есть такой список принятых, но не реализованных пропоузалов.
Дальше это уже не задача комитета, дальше кто угодно делает pull request к исходному коду компилятора, там есть инженеры, команда частично пересекается с комитетом, те, кто уже будет принимать решение о том, принимается этот pull request или нет.
Поскольку комитет согласен принять такое, то есть в принципе, нужно принять merge request, но там есть вопросы по инженерии, там не так закодировано, какие-то перформанс проблемы — это всё уже решает команда, которая непосредственно разрабатывает компилятор. Это уже не наша работа.
Алексей: Получается, сейчас у Haskell достаточно старые стандарты. Я смотрю, есть Haskell 2010.
Виталий: Да, 2010, очень старый. Было несколько попыток написать новый. Была идея каждый год выпускать стандарты, но, к сожалению, это всё провалилось. В 2016 году собрался комитет 2020, но он тоже ничего не сделал. Есть несколько причин разной степени сложности, почему эта работа не ведётся. Да, последний стандарт 2010, нового нет и не видно, чтобы он появился.
О курсах и новых проектах
Артём: Вернёмся к твоей основной деятельности, к преподаванию. Я лично с тобой познакомился по курсу теории категорий, который мне очень нравится. Ты говоришь, что тебе он не нравится. Какие у тебя ещё есть курсы, которыми, возможно, ты гордишься, и курсы, с которыми ты думаешь, было бы неплохо познакомиться? Например, курс, возможно, был с косяками, но в принципе, сама программа повествования очень хороша.
Виталий: Во-первых, у меня на YouTube опубликованы все курсы, которые у меня есть. Там у меня есть курс по Idris — этой такой язык программирования с зависимыми типами, причём даже две версии, я читал его два раза. Также у меня там есть пара курсов по компилятору языка Haskell. Один посвящён теоретико-типовым вопросам. Я не помню точно название, но там про то, как теория типов непосредственно работает в компиляторе Haskell.
Идея простая: весь код на Haskell компилируется в некое достаточно простое λ-исчисление, так называемую систему F с небольшими расширениями. Это реально есть в коде компилятора, и курс посвящен тому, как эти элементы теории типов используются непосредственно в компиляторе.
И есть курс, в котором я рассказываю вообще про историю вывода типов и про то, как вывод типов был устроен в самом начале, когда его изобрели в 60-е годы, до того, как сейчас в языке Haskell устроен вывод типов, какие там сложности, как это всё работает.
Есть коротенький курс, который я читал на летней математической школе. Там периодически, как мне сказали, берут курсы по информатике для того, чтобы дети отдыхали. А там собираются старшеклассники и младшекурсники, причём олимпиадники, они все жутко умные, все крутые математики, у них страшные курсы по самым современным вещам: алгебраическая геометрия и всё такое. Меня взяли туда с курсом по соответствию Карри — Ховарда — это такое соответствие между математической логикой и теорией типов. Вот такой развлекательный курс из четырех лекций получился, я там отдельно рассказываю элементы матлогики, отдельно элементы теории типов и потом показываю, как они тесно между собой связаны.
Пожалуй, это то, что есть из записанного. Так-то я много курсов читал за свою жизнь, но это обычно университетские курсы, и они не записывались, потому что я вообще, честно говоря, запись курсов не очень люблю, потому что это что-то такое мёртвое. Когда курс читаешь, иной раз наговоришь какой-нибудь ерунды, а потом это всё записанное выставляется на весь свет. Курс прочитал, и тебе потом тыкают много лет, что ты в таком-то месте в такой-то лекции сказал глупость. Мне это очень не нравится.
С курсом по теории категории ровно такая история. Во-первых, очень сложно, когда первый раз читаешь курс, прочитать его нормально, не знаешь, чем закончишь. Нужно учесть все его методические особенности, зависимости. Это как с написанием программы, только там есть какая-то большая стадия планирования, фичи какие-то, а здесь вроде как что-то распланировал, но курс идет, развивается сам по себе независимо от тебя. И потом ты что-то неправильно прочитал, не рассказал, что-то должно было там быть, что тебе сейчас нужно. Ну и вот таких зависимостей и дырок очень много получилось. Если бы я его читал во второй раз, наверное, сделал бы это гораздо лучше.
Но теперь в интернете осталась первая копия, которая, с моей точки зрения, ужасная. Организатор этого курса, который записывал, рассказывал, что у первой лекции много просмотров, это самая популярная по числу просмотров в этой категории в рунете, но мне не нравится, я не пересматриваю этот курс.
Алексей: А стоит ли ждать чего-нибудь нового? Потому что, как видим, иногда это очень помогает. Вот Артём вдохновился, мне, в целом, понравилось, мы хотели бы что-нибудь ещё увидеть.
Виталий: Я буквально недавно начал планировать новый курс для Computer Science Club. У меня так получается, что последние три весны я там читаю курсы в Петербурге, они записываются, поэтому материал остаётся в вечности. Опять же, там я свои интересы преследую.
Это будет курс на 10 лекций. Я придумал название «Компилятор GHC Haskell: вводный курс». У меня есть несколько коротких рассказов про компилятор GHC, парочка рассказов на конференции, примерно по 40 минут, а это вводный курс на 10 лекций. Я хочу рассказать про все аспекты компилятора с самого начала: от парсинга текста до кодогенерации.
То есть это курс вроде как про разработку конкретного компилятора, но на самом деле со спецификой Haskell, это то, что будет новое. У меня есть ещё идея сделать вторую итерацию курса по теории категорий, может быть, весной. Но немножко с другим упором.
В первый раз я его читал для того, чтобы его понимали интересующиеся математикой студенты 1-2 курсов. Там были примеры с математикой и всё такое. А во второй итерации я бы, может быть, украл идею Бартоша Милевски по курсам для программистов. Мне не очень нравится, как он рассказывает: ну, преподаватели — это такие ребята, им свои-то курсы не нравятся, а чужие и подавно. Вот я хочу сделать свою версию курса теорий категорий для программистов, чтобы кто угодно мог с этим разобраться.
Правда, не знаю, сделаю или нет, мысли такие есть. Я после первого курса по теории категорий поклялся, что больше никогда не буду никому рассказывать теорию категорий, но немного она меня тянет. Это вот то, что в планах есть.
Про компилятор точно получится, потому что мне нужно было такое место, куда бы я отправлял студентов, которые записываются ко мне на проекты, чтобы сначала смотрели, прежде чем приходить. А насчет теории категорий не знаю, соберусь или нет.
Артём: Насколько я знаю, ты ещё и в JetBrains рассказываешь какие-то вещи, связанные с академическими дисциплинами. Есть ли записи оттуда? Может, что-то оттуда можно посмотреть?
Виталий: В JetBrains я один раз делал внутренний доклад, он был посвящен Haskell и тому подобному, как инструменты JetBrains в Haskell-разработке можно использовать, но больше ничего не делал.
Артём: Инструменты Haskell в JetBrains?
Виталий: Я имею ввиду разработку на Haskell c помощью инструментов JetBrains, я делал обзор плагинов. Но это был внутренний доклад, он не опубликован.
Артём: А есть ли вообще Haskell в JetBrains?
Виталий: В смысле программирует ли кто-нибудь на Haskell в продуктах JetBrains? Я думаю, что нет.
Артём: Жаль, не знают они прелестей. (смеется)
Виталий: Там же джависты в основном. Есть другие ребята, но в основном Java, им не до Haskell.
Артём: Насколько я знаю, ты ресерчил внутри JetBrains?
Виталий: У меня официально это называется JetBrains Education. То есть JetBrains Research — отдельно, а Education — отдельно.
О JavaScript-движухе
Алексей: Как ты относишься к там штукам, которые живут в браузере, например, компиляция в JavaScript? И, соответственно, сопутствующие вещи, типа Elm, которые нельзя назвать в чистом виде Haskell.
Виталий: Во-первых, меня вся движуха в этом направлении очень радует. С GHCJS я не сталкивался, точнее как, я сталкивался с рассказами о том, насколько там всё плохо. Про Elm я вроде как слышал, что всё хорошо и это урезанный Haskell, всё такое. Очень положительно отношусь, и вообще мне сама идея нравится, что ты пишешь на каком-то языке и переводишь это всё в другой язык.
Я так понимаю, что там часто возникают проблемы с производительностью, то есть сгенерированный код оказывается настолько тяжеловесным, что медленно выполняется. Но на все эксперименты по компиляции в JavaScript я смотрю с большим интересом.
Например, у языка Idris много бэкендов — и они могут Idris компилировать в PHP, в JavaScript, и это очень интересно. Межъязыковая жизнь прекрасна. Можно, наверное, JavaScript в Haskell компилировать.
Вообще языки программирования же интересные, и какой-нибудь компилятор, который компилирует нативный код — это всем давно известная область, а когда мы один язык в другой компилируем — это суперинтересно, миллионы задач.
Миллионы языков программирования — это, скажем, десятки миллионов задач, и каждая очень самобытная, потому что везде возникают свои аспекты. И что интересно, это же имеет давние корни. Опять же, в докладе на HolyJS я буду рассказывать про разные модели вычислений, и для моделей вычисления основные теоремы состоят в том, что две модели вычислений эквивалентны, и для того, чтобы этот фактор эквивалентности доказать, нужно на одной модели вычислений запрограммировать вторую и наоборот. Когда они сделаны в обе стороны — мы получаем теорему, что обе модели равны.
Первая такая работа делалась в своё время Аланом Тьюрингом, который в λ-исчислении выразил машину Тьюринга, а в ней — λ-исчисление, и доказал, что это две эквивалентные модели, потому что по времени так получилось. Он придумал свою машину Тьюринга, а потом ему показали λ-исчисление, и ему нужно было доказать, что это эквивалентные вещи.
Это было в 1936 году, и с тех пор в некотором смысле задача преобразования из одного языка в другой — это продолжение ровно этой же задачи доказательства эквивалентности исчислений. Поскольку языков много, задача тоже интересная.
Какие языки используются в продакшене и почему
Артём: А какие ты вообще можешь выделить современные языки, которые в продакшене везде используются? Вот ты в Подлодке выделял Swift, говорил, что там enum очень интересные, которые эквивалентны Union, какие еще подобные языки с теоретической точки зрения очень хорошо спроектированы?
Виталий: Не знаю, вообще, очень холиварный вопрос. Я тут недавно убедился: то, что один человек называет хорошо спроектированным с точки зрения теории, другой считает безобразно спроектированным. Например, буквально недавно я услышал такое утверждение, что Python проектировался в полном соответствии с теорией языков программирования, и что Гвидо ван Россум занимался этой теорией и решил сделать язык, полностью соответствующий этим принципам.
Я очень удивился, потому что примерно представляю себе, что такое Python, и что такое теория языков программирования. В общем, я бы не соотносил одно с другим, но тем не менее, такое мнение тоже есть.
Я должен сказать, что языки, которые появляются последний десяток лет, особенно языки, которые разрабатываются крупными компаниями, все выглядят очень неплохо. Из самых заметных и больших языков я хочу отметить C#. Как C# появляется: во-первых, Microsoft учла все проблемы Java, пригласила суперумных людей, например, Андерс Хейлсберг, который в своё время сделал Delphi, помогал с С#, в разработке C# участвовал Эрик Мейер, который ещё с первого комитета Haskell, известный человек в нашем комьюнити.
То есть собирают крупных ученых, и они делают приличные языки без дырок. Понятно, что JetBrains, которая делает Kotlin, тоже старается делать хорошо. Kotlin, C#, Swift от Apple, к которому нет претензий с точки зрения теории. По крайней мере, я ни о чем таком не слышал.
С++ какой-то своей жизнью живет, и, в общем, его оценивать как-то сложно, потому что многие решения в нем нельзя сделать иначе, и там действительно очень умные люди им занимаются, им виднее. Я, кстати говоря, не очень представляю, как JavaScript развивается, поэтому не могу это оценить. Вот, пожалуй, и всё.
Сейчас я доверяю в этом вопросе крупным компаниям, которые делают новые языки, потому что они серьезно к этому подходят.
Артём: Почему-то, когда ты начал говорить о крупной компании, которая делает хороший язык, я сразу подумал о Mozilla и Rust.
Виталий: Ну, Mozilla — это же не то, чтобы компания, это все-таки open source-сообщество, это немного другое. Им я в меньшей степени доверяю. Но с другой стороны, я про Rust очень мало знаю, слышал хорошие и плохие отзывы. Иногда возникает ощущение, что из Rust делают такого Франкенштейна, соединяя какие-то несоединяемые вещи, посмотрим.
С другой стороны, недавно в Twitter была дискуссия — кто-то из одного из подразделений Microsoft, занимающихся безопасностью кода, заявил, что нужно уходить от C++ и всему Microsoft переходить на Rust. Возможное мнение, да. Но там это было связано с тем, что безопасные программы проще писать на Rust. Им, в общем, виднее, но я не думаю, что это произойдет в обозримом будущем. Во всяком случае, такие мнения действительно возникают.
Но вообще Rust относится к языкам, которые мне нужно будет очень внимательно посмотреть в какое-то время, пока это в планах.
Чем научные конференции отличаются от программистских
Артём: Конференция! Ты, наверняка, участвовал не только в программистских конференциях, но, наверное, и в научных — либо принимал участие, либо выступал. Что ты можешь выделить особенного в таких конференциях, и, возможно, какие-то моменты, которых тебе не хватает в конференциях сообществ?
Виталий: У меня очень небольшой опыт участия в научных конференциях, можно сказать, что его практически и нет. Но я слежу за этим удаленно, смотрю записи и все такое. Во-первых, конференции разработчиков лучше организованы, однозначно. На научных конференциях всегда за участие платят сами докладчики. Слушателей там либо нет, либо есть, но основная масса слушателей — это докладчики конференций. И подготовкой этих докладов никто особо не занимается — это не тут, когда тебя терзают прогонами, чтобы всё было хорошо. Там все гораздо более свободно.
Если ты там хорошо выступаешь — ты сделаешь хороший доклад, если нет, сделаешь фигню какую-то, которую никто не поймет, что ты там вообще хотел сказать. Может быть по уровню контента там интереснее, но по качеству представления однозначно научные конференции проигрывают.
Плюс там всегда проблемы с записью, если есть, то смотреть невозможно, звук ужасный. Запись есть, а смотреть её просто нельзя, хотя и очень обидно. Так что это тоже очень плохо. Но, с другой стороны, конечно, лично мне тематика там бывает более интересна, потому что обычно это передний край. Они полгода придумывали какой-то свежачок и об этом рассказывают. Это не то что использование уже готовых технологий. Так что в этом смысле гораздо интереснее.
Алексей: А это можно обычному инженеру понять? Если он интересуется теорией языков программирования, например, может он прийти на конференцию и без особой подготовки, просто послушав доклад, понять, что хочет донести человек?
Виталий: Очень редко, когда это удастся. В большинстве случаев, конечно, этот передний край науки сложный, требуется большой опыт и чтение статей, и вообще нужно разбираться в этой тематике достаточно глубоко. То есть на научных конференциях бывают докладчики, которые в состоянии более-менее понятно объяснять широкому кругу слушателей, но это, скорее, исключение, чем правило. Кроме того, там же докладам всегда предшествует статья. Если ты прочитал статью, потом послушал доклад — тебе проще. Или в другом порядке, чаще и так, и так может получаться.
Но так, чтобы без подготовки прийти и послушать — очень редко бывает.
Зачем нужны конференции
Артём: А чего ты вообще ждешь от HolyJS как от конференции? Может, какие-то доклады тебя заинтересовали уже? Вот, Дмитрий Волошин будет про образование рассказывать.
Виталий: Ну, я посмотрел названия, сейчас не вспомню, что для себя отметил, но однозначно я увидел несколько докладов, которые мне интересно посмотреть и послушать. Я уже начал прикидывать, куда я пойду, по какой траектории. Но я должен сказать, что у меня опыт участия и вообще присутствия на конференциях разработчиков очень небольшой.
Начали привлекать меня только в этом году, спасибо мобильщикам, которые меня к себе призвали в апреле на AppsConf. А до этого я ни разу не был. Так что я новичок здесь. И мне интересно всё время вообще смотреть на разработчиков, я преследую такую задачу.
Я много лет учил программировать, сам, фактически, не программируя. В этой позиции есть некая шаткость: «А имею ли я вообще право учить программировать, если не являюсь профессионалом в программировании?». И я долгие годы пытался как-то эту проблему решить, например, очень много беседовал с разработчиками из разных компаний: Яндекс, разные заграничные, в Twitter был, с Google разговаривал. То есть пытался понять, как вообще в реальности работает разработка ПО.
И конференции я тоже для этого использую. Я смотрю, как люди рассказывают, чем они занимаются, пытаюсь задавать вопросы, общаться, смотреть на то, какие технологии интереснее, а какие менее интересны.
Опять же, поскольку я участвую в разработке учебных планов, мне с этой точки зрения интересно, на что сделать упор в преподавании при постановке новых курсов. Чем живут разработчики и как это может быть полезно в образовании — вот то, что мне там интересно.
Нужны ли книги программисту
Артём: Ещё один вопрос, может быть сумбурный. Ты написал книгу про Haskell, называется Haskell in Depth?
Виталий: Не написал, к сожалению, книжка в процессе. Это называется «программа раннего доступа». И она, к сожалению, затормозилась, и я потихоньку возвращаюсь к работе над ней. Там где-то половина написана, а вторая половина задерживается, за что мне очень стыдно перед теми, кто этот ранний доступ приобрел.
Артём: Вот тут интересный факт: в сообществе есть мнение, что книги по программированию, особенно если они не про фундаментальные знания, не очень хороши, потому что информация быстро устаревает. Как у тебя, как у автора книги, складывается такой опыт? И обдумывал ли ты такую проблему, что информация, которую ты указываешь в книге, может быстро устареть?
Виталий: Я, конечно, не понимаю, как пишут книги по JavaScript — по-моему, это вообще невозможное занятие. С Haskell в этом смысле немного проще. Но я вот что могу сказать.
Когда в школе мы изучаем математику, эта математика тоже в общем сильно устарела. Это вещи, которые придумали пару тысяч лет назад, какая-нибудь теорема Пифагора. Она-то, может быть, выполняется до сих пор, но сказать, что кто-нибудь измеряет высоты пирамид с помощью теоремы Пифагора — такое себе, обычно используют лазерные рулетки или что-то в этом роде.
Здесь примерно то же самое. Если человек крупный профессионал в чём-то и давно использует какую-то технологию, конечно, ему книжка не нужна. Ну так книжка не для него и пишется, она нужна для того, чтобы войти в какую-то технологию, чтобы начать в этом разбираться. А когда ты уже вошёл, у тебя появляются другие источники для развития.
Поэтому мне кажется, что книжки никуда не денутся. Когда ты начинаешь что-то изучать, можно, конечно, по статьям изучать языки программирования, но в большинстве случаев результат не получится хорошим. Чаще всего это перенос своих представлений о другом языке программирования на новый. Ты не узнаёшь идиоматические конструкции для этого языка и не знаешь, как его правильно использовать.
Так что вначале лучше всё-таки взять книжку, разобраться по ней, получить базу. Пусть она будет описывать не самые новые версии библиотек, пусть в языке что-то добавилось, это всё можно наверстать. Для получения базы, на мой взгляд, всё-таки книжка нужна. Это для всех языков программирования, даже для JavaScript. Всё равно нужна какая-то стабильность, такой point of reference, на которую можно ссылаться.
Это, кстати говоря, одна из целей при написании стандарта языка Haskell, чтобы создать такую стабильную точку в истории языка, по которой можно писать книжку. Дальше так или иначе язык может развиваться, но вот стандарт есть, и любой обучающийся может на него ориентироваться.
Интересно же, как для многих языков программирования книги играют роль стандарта. Например, Страуструп написал книгу по C++, и это вот такая точка, на которую всегда можно ссылаться. C++ ушёл далеко вперёд, но при изучении языка ориентироваться на эту версию, которая описана у Страуструпа, вполне можно.
Артём: Ты затронул интересную тему по поводу ресурсов, которые нужны людям, которые не изучают язык, а хотят углубиться и идти дальше. Ты можешь посоветовать какие-то ресурсы, которые ты используешь для изучения, и ресурсы, которое было бы хорошо изучить инженеру, чтобы погрузиться в теор. информатики, в теорию типов, либо, как ты говорил, устранить определённое невежество инженера?
Виталий: Мне сложно привести пример, я вообще не могу сказать, что у меня есть какие-то регулярные источники информации. Пожалуй, самый главный источник для меня — Twitter. Так получается, что всё ко мне приходит через Twitter. Появляются какие-то интересные мне ссылки, я себе их сохраняю и периодически читаю. У меня такое ощущение, что по крайней мере в Haskell нет такого источника, но есть много уважаемых людей, которые пишут толковые вещи.
Я как-то пытался регулярно использовать Reddit для этой цели, но как-то мне не зашло, просто не хватает времени за этим следить. А в Twitter всё равно всё, что появляется, рано или поздно до меня доходит. Быстро посмотрел, интересно — сохранил, потом прочитал.
А так, чтобы в целом что-то такое рекомендовать в области информатики или IT, я, честно говоря, не готов, я не знаю такого сайта или ресурса. Для тех, кто занимается языками программирования, важный источник — сайт http://lambda-the-ultimate.org. Там появляются все самые интересные вещи и идёт обсуждение. Это такой must read для тех, кто интересуется теорией языков программирования.
Что почитать программисту
Алексей: Ты говоришь, что книги не устаревают. Есть ли список must have-вещей, которые нужно прочитать, или просто любимые книги, которые рекомендуешь? Я говорю о теории программирования, об общей инженерной грамотности.
Виталий: Меня периодически просят составить список, я не берусь за такую работу, это очень тяжёлое дело.
По теории языков программирования, чтобы начать в это въезжать, есть книжка Пирса «Типы в языках программирования». Это в общем букварь, с которого нужно начинать типы. Наверное, её первая треть была бы полезна всем программистам.
Мы с коллегой переводили книжку, которая называется «Введение в теорию языков программирования». Она совсем маленькая, и там объясняется формальная семантика, вывод типов, теоретические вещи из компиляции. Такое полезное введение в языки программирования.
Есть книжка Чарльза Петцольда «Annotated Turing». Это потрясающий жанр: автор взял статью Тьюринга 1936 года, где Тьюринг описал то, что позднее стало известно как машина Тьюринга, и написал толстенную книжку, которая объясняет эту статью. А сама статья страниц 15. Причём там история из жизни самого Тьюринга, предыстория этой задачи, как это всё происходило. Раздел за разделом он приводит фрагмент статьи и объяснение того, что там имелось в виду.
Если мы сейчас будем читать статью, нам будет очень сложно. Но эта книжка Петцольда потрясающая, она воссоздаёт весь контекст и описывает саму статью. Это я всем рекомендую, это очень интересное чтение, расширяет кругозор. Там и про λ-исчисление есть, потому что это всё рядом, и философские вопросы поднимаются, связанные с вычислениями.
Ещё, конечно, с технологической точки зрения я являюсь большим фанатом книжки «Совершенный код» МакКоннелла. Мне кажется, что это тоже важное чтение. Можно не читать всё подряд, а просто открывать на случайных страницах, читать пару страниц и закрывать. Это про то, как писать код.
Правда, я недавно разговаривал с несколькими мобильщиками, они говорят, что дурацкая книжка, в которой нет ничего полезного. Но она про то, как писать такой код, чтобы он долго жил, чтобы его можно было поддерживать, менять. Может быть у них таких потребностей действительно нет.
Да, и там не Swift, не Kotlin, какая-то там Java, разные примеры на разных языках, которые современным программистам уже не особо о чем-то говорят. Книга начала двухтысячных. Но я считаю, что для любого программиста это чтение очень полезное. Макконнелл ещё хорош тем, что все подтверждает исследованиями, говорит: «Вот, провели такое-то исследование, ещё такое-то, и вот результаты. Давайте вместе обсудим, как нужно написать код, чтобы было хорошо».
Вот, пожалуй, хватит такого чтения.
Артём: По более специализированным спрошу: ты рекомендовал «Modern Compiler Implementation», которая в трёх версиях — Java, C и ML.
Виталий: Да, это книжка по компиляторам. Я не знаю, нужно ли её всем читать, это, скорее, тем, кто интересуется компиляторами. Но, да, она мне нравится — она небольшая, и работая с ней, можно действительно написать свой компилятор. Я не уверен, что всем программистам нужно писать свой компилятор, но если вдруг любопытно, то книжки Аппеля — это действительно интересно, но уже что-то узкое.
Сейчас я просто не могу всё припомнить. Периодически что-то всплывает на поверхность, ведь в свое время я много читал. Например, «Структура и интерпретация компьютерных программ» — это тоже классика, которую полезно читать и делать упражнения. Даже если не совсем согласен, но само чтение очень полезное.
Виталий Брагилевский с докладом «JavaScript на службе у теоретической информатики» приедет на конференцию HolyJS 2019 Moscow, которая пройдет 8-9 ноября 2019. Приобрести билеты можно на официальном сайте.
Автор: olegchir
