Поэтому иногда нужно схлопывать эти слои путем сложных преобразований с помощью компилятора, чтобы не делать так много вещей. Границы абстракций могут быть полезны для людей, но машины к ним безразличны. Поэтому я не думаю, что даже после достижения границ возможностей компьютеров программы перестанут усложняться. К тому времени они уже будут работать очень быстро. Думаю, главное ограничение здесь - не скорость процессора, а наша способность понять, что должна делать программа.
Сейбел:Что вам особенно нравится в программировании?
Джонс:Мне нравится писать внутренне логичные программы. Если прилепить к программе что-то наспех, она заработает, но это не лучший вариант. Поэтому мне кажется, что хороший программист - тот, который стремится найти красивое решение. Не каждый может позволить себе роскошь отложить сдачу готовой работы, потому что не нашел красивого решения.
Еще программы хороши своей пластичностью — с ними можно делать что угодно! Но это значит также, что вы можете делать программы уродливые, недолговечные, трудные в обслуживании. Меня иногда пугает индустрия ПО, где все диктуется, с одной стороны, желанием покупателя увидеть продукт на следующей неделе, а с другой - стремлением распространять системы вширь, а не вглубь.
Системы слишком уж распухли. Если вы хотите сделать веб-сервис на ASP.NET, то должны освоить API и инструменты, уметь писать на трех разных языках, знать Silverlight и LINQ - и вы можете создавать акронимы до конца света. И про каждый из них есть толстая книга.
Есть противоречие, неразрешимое для меня. Это полезные системы, придуманные не просто так. Их тщательно продумывали умные люди. Но у каждой - широкий интерфейс. Глубокий или нет, неважно - он широкий. И в голове приходится держать кучу разных программ. Все равно что учить обычный язык с очень богатым словарным запасом.
И это мне не нравится. Я так и не запомнил таблицу умножения. Я всегда все делал на основе нескольких простых правил и придумал много хитростей, чтобы делать это быстро. Все умножают семь на девять, а я умножаю семь на десять, вычитаю, получаю шестьдесят три. Другие просто запоминают таблицу. А она ведь совсем небольшая. Поэтому я не люблю системы, которые заставляют меня держать много чего в голове, и инстинктивно их сторонюсь. В то же время я признаю, что они полезны и важны в практическом плане. Но я задаю себе вопрос: если подумать над ними чуть дольше, нельзя ли сделать интерфейсы меньше, проще и универсальнее?
Сейбел:Мне иногда кажется, что вся эта сложность - именно из-за того, что системы разрабатывают умные люди. И им хочется играть в свои игры.
Пейтон-Джонс:Да, есть и такое. Но можно подойти к этому вопросу и более конструктивно. Перед нами - огромный, сложный мир, где так много надо сделать. Человек со зрением олимпийца, с могучим умом и невероятной проницательностью способен создать нечто стройное и цельное.
На практике нам приходится разбивать задачи на кусочки. За каждый кусочек отвечает человек, который исходит из собственного опыта и культурного багажа. То, что он создает на своем пространстве, хуже, чем могло бы быть, - человеку не хватает времени. В итоге весь ансамбль тоже выглядит хуже, чем мог бы. Плюс отрицательное влияние наследства прежних систем.
Это наследство - как ядро каторжника, которое мы волочим за собой. И в этом отношении удачей стал Haskell. Оглядываясь, я всегда вижу перед собой принцип, который мы в него заложили: “Избегать успеха любой ценой”. Теперь это что-то вроде мема - люди запомнили эту фразу и мне же ее цитируют.
В этом есть доля правды - именно потому, что мы не хотели быть слишком успешными и слишком поспешными, у нас было какое-то время, чтобы изменять Haskell на протяжении его жизни. Я даже переживаю из-за того, что Haskell стал более успешным, - мне приходит больше сообщений об ошибках, больше запросов новых функций. Все больше людей говорят: “Прошу вас, не ломайте мою программу”. Раньше такого не было.
Сейбел: Вы несколько раз упоминали о красоте кода. Каковы признаки красивого кода?
Пейтон-Джонс:Тони Хоар замечательно сказал: нужен код, совершенно очевидно свободный от ошибок, а не код, свободный от очевидных ошибок. Думаю, красивый код - это код, который совершенно очевидно правилен. Абсолютно прозрачный код.
Сейбел: А как насчет перлов - небольших замысловатых, но интересных фрагментов кода, - они тоже красивы?
Читать дальше
Конец ознакомительного отрывка
Купить книгу