Не очень-то и #meme

А вы тоже так и не нашли, с кем отмечать Новый год, или вы нормальные?

#prog #parsing #article

В Just write a parser (примечание к небольшому набору уроков по реализации парсера) автор выступает против глубокого изучения подходов к парсингу в курсах по обучению компиляторостроения и за то, чтобы забить на "академические" подходы и делать рекурсивный спуск руками. В качестве аргументов он приводит:

* Рекурсивный спуск очень хорошо даёт понять, как работает парсер, в отличие от генераторов парсеров.
* Это практичный навык: парсеры реальных компиляторов написаны вручную.
* Это не так уж и сложно.

В статье Why We Need to Know LR and Recursive Descent Parsing Techniques Laurence Tratt соглашается с первым тезисом (не перегружать курс по компиляторам подходами к парсингу), но оспаривает второй.

Именно, он указывает на LR-грамматики: такие грамматики точно являются однозначными, а то, является ли грамматика LR, можно проверить автоматически. Рекурсивный спуск же не даёт ясно понять, какова реализуемая парсером грамматика. В частности, реализуемая парсером грамматика может быть неоднозначной. Более того, то, что самописный рекурсивный спуск сам по себе вполне детерминирован, означает, что парсер таки разрешает неоднозначности грамматики, причём зачастую неочевидным способом.

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

> If writing a grammar in LR style is hard for you as the language author, it will almost certainly be hard for users to understand!

Разумеется, автор признаёт, что не для всех языков возможно написать LR-грамматику в принципе, но он отмечает, что попытка написать такую грамматику может как минимум подсказать, где в реализации парсера могут крыться баги из-за неоднозначности.

Разумеется, это не всё, что есть в статье, так что советую прочитать целиком.

#prog #article

Debugging A Failing Hotkey

<...> So, yes, I’d just spent 30 minutes debugging a literally stuck key on my keyboard.

Один член — это хорошо, а 200+ — ещё лучше

#meme про котов и деньги

Кстати, я провалил Whamageddon

...админы телеграм-каналов?

Чинуши сменили желто-синий герб московского района Коптево

Глава Коптева Ольга Глаголева заявила «Подъёму», что прежний символ, который был утверждён почти 20 лет назад, не был зарегистрирован в Геральдическом совете.

Сам герб обновили в ноябре. По решению чинуш с левой части щита убрали фигуру солнца, добавив кресты. Почему понадобилось его менять именно сейчас, и с чем связано решение изменить цветовую гамму символов района не говорится.

#prog #article

Putting the I back in IDE: Towards a Github Explorer

Статья о том, как происходит процесс разработки и ревью кода в Jane street — значительно более интегрированный процесс, чем с комбинацией git и GitHub/Gitlab. Серьёзно, я хочу, чтобы у меня так на работе было.

Imagine a system for editing and reviewing code where:

* Every branch of every repo gets its own sandboxed directory. Your revision history in each branch, including uncommitted stuff, is persisted, as are build artifacts. When you switch contexts, each project is just as you left it.
* Within your editor, you can pull up a global view of all your branches, your outstanding pull requests, and the pull requests you’re assigned to review. It’s one keystroke to view the summary for a pull, and one more to start editing any of its files right there under your cursor.
* Code review happens entirely within the editor. You’re fed a series of diffs: one keystroke to approve, one keystroke to start editing. Dive in, make your changes, leave comments for the author, push, and move on.

We’ve actually developed this workflow at Jane Street, and it’s been used daily by hundreds of engineers for about two years now.

<...>

The trouble is that it’s pretty coupled to our somewhat uncommon toolchain: <...>

The goal of this post, then, is just to show off what the result looks like – to show you what kind of workflow is possible – in the hope that it inspires similar tools in other ecosystems. The truth is that after writing code at work this way for a while, you start to wish that you had something similar at home.

#prog #video

How Jane Street Does Code Review

И небольшой доклад с точки зрения пользователя этой системы. Вместе с ценными ответами на вопросы аудитории.

А на телефоне табличку что-то перекорёжило 😒

Кстати, накидал её в asciiflow.com

#prog #моё

Давайте немного поговорим о вариантности и о том, как она связана с мутабельностью и алиасингом.

Сначала немного напомню о вариантности. Если Sub является подтипом Sup (что записывается как Sub <: Sup), то:

Обобщённый тип Co<T> называется ковариантным по T, если из Sub <: Sup вытекает Co<Sub> <: Co<Sup>;
Обобщённый тип Contr<T> называется контравариантным по T, если из Sub <: Sup вытекает Contr<Sub> :> Contr<Sup> (или, что то же самое, Contr<Sup> <: Contr<Sub>);
Обобщённый тип Inv<T> называется инвариантным по T, если из Sub <: Sup не вытекает ни Inv<Sub> <: Inv<Sup>, ни Inv<Sup> <: Inv<Sub>.

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

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

Пусть у нас есть функция из T в R, сигнатуры T -> R. Тип функции можно представить как применение конструктора типа -> к типам T и R (собственно, в Haskell синтаксис (->) T R валиден), и потому тип функции можно воспринимать, как обобщённый тип с двумя параметрами. Какая же у этого конструктора типов вариантность?

Если мы где-то вызываем функцию типа T -> R, то мы получаем значение типа R. По определению подтипа, вместо значения типа R мы можем использовать значение типа RSub, подтипа R. Значит, если выражение с вызовом функции T -> R тайпчекается, то оно должно продолжить тайпчекаться, если поменять функцию на функцию типа T -> RSub. Обратное, очевидно, неверно: привести супертип к подтипу в общем случае безопасно нельзя. Получается, что конструктор типа функции является ковариантным по возвращаемому типу.

А что насчёт типа аргумента? Очевидно, поменять T -> R на TSub -> R, где TSub <: T, мы не можем: это потребовало по месту вызова приведения T к TSub — направлении, противоположном отношению субтипизации. Но возможно поменять T -> R на TSup -> R, где T <: TSup — в этом случае по месту вызова будет апкаст аргумента, что всегда разрешено. Выходит, конструктор типа функции контрвариантен по типу аргумента.

А теперь немного подумаем о том, что из себя представляет мутабельная переменная. Это не значение как таковое — это имя, которое мы можем использовать для того, чтобы получить значение, и для того, чтобы значение записать. Иными словами, мутабельную переменную можно представить, как некую метку и пару функций для считывания значения и его записи (в принципе, это близко к тому, как выглядят ссылочные ячейки в SML и IORef в Haskell). Функция считывания значения ковариантна по возвращаемому типу — типу значения в мутабельной переменной, а функция записи — контрвариантна по аргументу, то есть по тому же самому типу. Пара этих функций имеет совместные ограничения, которые комбинируются и образуют инвариантность по типу внутри мутабельной переменной. Иными словами, мутабельная переменная может хранить только значения строго обозначенного типа — ни субтипы, ни супертипы. Так как коллекции предоставляют доступ к, по сути, множественным изменяемым переменным, из этого с необходимостью вытекает, что коллекции должны быть инвариантными по типу содержащихся элементов.

Логично? Логично. Но не для дизайнеров Java.