Кодеры за работой. Размышления о ремесле программиста

Реализация чего-нибудь - сильный мотивирующий фактор. Рекомендую всем. Хотите понять Си - напишите для него компилятор. Хотите понять Лисп - напишите для него компилятор или интерпретатор. Некоторые говорят: “Компилятор - это же так трудно”. Совсем нет. Это легко. Есть масса мелочей, которые не трудны и которые нужно освоить. Надо разбираться в структурах данных. Надо разбираться в хеш-таблицах и в парсинге. В генерировании кода. В техниках интерпретации. Каждый из этих предметов не особенно сложен. Начинающие думают, что это все большие и сложные темы, и поэтому к ним не подступают. Все, что вы не делаете, трудно, все, что вы уже сделали, легко. Люди даже не пытаются ничего делать, и я думаю, это ошибка.

Сейбел: Кое-кто из моих собеседников советовал учить разные языки, потому что в них применяются разные подходы к решению задач.

Армстронг: Да, но только если эти языки делают разные вещи. Нет смысла учить несколько языков, делающих одно и то же. Я немало писал на JavaScript, и на Tel, и на Си, и на Прологе - в действительности на Прологе, на Фортране и на Erlang даже очень много. Чуть-чуть на Ruby и на Haskell. Я знаком со всеми языками, но не на всех могу программировать. Хотя я могу писать программы на довольно многих языках.

Сейбел: Но не на C++?

Армстронг: Нет. На C++ я едва могу читать и писать. Не люблю C++; плохо его чувствую, он слишком переусложнен. Мне по душе компактные небольшие языки, а этот большой и громоздкий.

Сейбел: Какие языки повлияли на структуру Erlang?

Армстронг: Пролог. Разумеется, он вырос из Пролога.

Сейбел: Сегодня в нем уже непросто распознать то, что идет от Пролога.

Армстронг: Унификация, сопоставление образцов - все это напрямую идет от Пролога. Как и структуры данных. Синтаксис кортежей и списков слегка различается, но тем не менее очень похож. Еще теория взаимодействующих последовательных процессов Тони Хоара. Я также читал об охраняемых командах Дейкстры. Вот почему я требую, чтобы сопоставление с образцом всегда было явным, не должно быть случая по умолчанию, всегда должна быть ветка с совпадением. Вот основные влияния.

Сейбел: А функциональный облик языка - он откуда?

Армстронг: После внедрения параллелизма в Пролог надо было сделать так, чтобы после какого-нибудь действия не происходил возврат назад. В Прологе можно вызвать что-нибудь и вернуться назад, полностью уничтожая эффект от вызова. Поэтому идея была та, чтобы после команды, скажем “Пуск ракет”, они вылетают - ррраз! - и отменить уже нельзя. Чистые Пролог-программы обратимы. Но при взаимодействии с реальным миром все действия совершаются только в одном направлении. Подали команду “Пуск” - ракеты пущены. Подали команду “Зеленый сигнал светофора” - загорается зеленый, и нельзя потом пересмотреть решение, сочтя его плохим.

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

Сейбел: Где необратимые программы могут посылать сообщения другим процессам?

Армстронг: Да. Но это просто вызов функции, хотя, возможно, и не функции, запускающей ракеты. Это вызов функции, которая вызывает другую, а та - функцию, запускающую ракеты. По этой причине код, который вы создаете, становится все более функциональным, превращаясь в диалект Пролога - функциональное подмножество. А функциональное подмножество можно сделать полноценным функциональным языком.

Сейбел: Erlang сильно отличается от прочих функциональных языков, поскольку в нем есть динамическая типизация. Вы ощущаете свою принадлежность к сообществу функциональных программистов?

Армстронг: Безусловно. На конференциях по функциональному программированию мы спорим, выпячивая расхождения. Мы спорим о “жадных” и “ленивых” вычислениях, о динамической и статической типизации. Но несмотря ни на что, остается центральная идея функционального программирования: х не обозначает место в памяти, это неизменяемое значение. Мы задаем х равным 3, и дальше с этим ничего не сделаешь. Различные функциональные сообщества сходятся на том, что это крайне полезно для понимания программ, для параллелизма, для отладки. Однако есть функциональные языки с динамической типизацией, такие как Erlang, и функциональные языки со статической типизацией. У тех и других свои сильные и слабые стороны.

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