Десятое правило Гринспуна, включает ли каждый крупный проект интерпретатор Lisp? [закрыто]

Десятое правило Гринспуна (фактически единственное правило) гласит:

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

Я помню, что есть некоторые статьи по этой теме, возможно, для проекта Borland Quattro (электронная таблица) и, возможно, другие. Google бесполезен, возможно, правильные условия поиска не приходят на ум. Я ищу документы или статьи, подтверждающие эту претензию, если таковые имеются.

Утверждение гипербола. Но на других языках есть явные признаки зависти к Лиспу. Посмотрите на C # и как он становится все более функциональным по своей природе. Посмотрите на различные среды управления бизнес-процессами, рабочих процессов и EAI, которые позволяют программировать систему без изменения программы.

Есть книга Мартина Фаулера по предметно-ориентированным языкам, в которой рассказывается, как выполнять метапрограммирование на объектно-ориентированных языках. Так что в гиперболе есть доля правды.

Пол Грэм назвал Lisp самым мощным языком, глядя на список первых, пришедших с Lisp , легко понять, почему многие языки бледнеют по сравнению.

Способ обойти десятое правило - программирование полиглотов. Понимая, что один язык / рамки не золотой молоток. Тогда вместо создания плохой специальной реализации Lisp, вы можете просто использовать Lisp.

«Десятое правило» Гринспуна было немного странным. Если растянуть достаточно далеко, если вы сделаете так, чтобы он охватывал «любую систему сценариев или конфигурацию», тогда, очевидно, ответ на этот вопрос должен быть «да», поскольку конфигурация - это то, что требуется в какой-то степени любой нетривиальной программе, и сценарии только немного реже, когда вы двигаетесь вверх по шкале сложности.

С другой стороны, взгляните на GOAL , вариант Lisp, изобретенный Naughty Dog для программирования игр. Это совсем не похоже на «классический» Лисп. Это система крайне императивного стиля, с объектно-ориентированной функциональностью, без интерпретатора, минимальной поддержкой сборки мусора (вместо этого полагаются на средства очистки на уровне выполнения) и обширной поддержкой встроенной сборки.

Другими словами, когда они пытались использовать Lisp для достаточно сложного проекта, они обнаружили, что для того, чтобы сделать что-нибудь полезное, они должны были превратить язык в специальную, неофициально заданную реализацию половины C ++! ;) (И в конце концов им пришлось прекратить использовать его после ухода парня, который разработал GOAL, потому что никто не мог понять его код.)

Любопытно, что один ответ на этот вопрос уже есть в Programmers SE .

Чтобы процитировать соответствующую часть:

Гринспен утверждал (частично), что многие сложные программы имеют встроенные интерпретаторы. Вместо того, чтобы встроить интерпретатор в язык, он предположил, что было бы более разумно использовать язык, подобный Lisp, который уже имеет встроенный интерпретатор (или компилятор).

В то время я работал над довольно большим приложением, которое выполняло пользовательские вычисления с использованием специального интерпретатора для пользовательского языка. Я решил попробовать переписать его ядро ​​на Лиспе в качестве масштабного эксперимента.

Это заняло примерно шесть недель. Оригинальный код был ~ 100 000 строк Delphi (вариант Паскаля). В Лиспе это было сокращено до ~ 10000 строк. Еще более удивительным было то, что двигатель Lisp работал в 3-6 раз быстрее. И имейте в виду, что это была работа новичка Лиспа! Весь этот опыт был довольно откровением для меня; Впервые я увидел возможность сочетать производительность и выразительность на одном языке.
- Майкл Ленаган

Чтобы уточнить эту часть, Майкл ответил на комментарий:

Ого, это, должно быть, какой-то действительно ужасный код Delphi, если он каким-то образом мог выполнять в 3-6 раз медленнее, чем реализация на Лиспе! " пользовательские выражения в выражения Lisp - тривиально простой процесс, а затем компилирование выражений Lisp в нативный код (с полной оптимизацией). В этом смысл десятого правила Гринспуна.
- Майкл Ленаган

Учитывая, что этот ответ состоит из чужого ответа, это вики сообщества.

Правило - это шутка, но в этом есть доля правды. Любая сложная система будет содержать несколько интерпретируемых частей (посмотрите, как «Шаблон интерпретатора» популярен среди тех, кто верит во все эти шаблоны mumbo-jumbo). Любая сложная система должна обеспечивать некоторые средства конфигурации, часто структурированные, часто интерпретируемые.

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

Многие системы манипулируют сложными древовидными структурами данных, используя набор (почти всегда) плохо спроектированных инструментов для обхода и преобразования дерева, очень похожих на функциональность библиотеки из Common Lisp.

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

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

Правило, вероятно, могло бы быть более точным (и менее забавным), поскольку «для реализации динамического поведения потребуется любая большая программная система».

Это можно сделать двумя способами:

1. Большой сложный файл конфигурации с десятками параметров и сотнями определений.

2. Язык сценариев AD-HOC.

«sendmail», вероятно, является каноническим примером типа «1». Я не могу вспомнить ни одного хорошего примера типа «2», который не включает в себя встраивание «настоящего» языка сценариев в духе Warcraft / LUA или даже Netscape / Javascript.

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

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

Однако это утверждение также с ухмылкой подразумевает, что все, что вам нужно для создания программы, это Лисп, и что все остальные языки уступают ей.

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

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

Скорее, наоборот, неважно, насколько сложным, умным или изощренным вы придумываете язык, все заканчивается тем, что он является просто еще одним способом написания ассемблера.

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

Неверно то, что пользовательские скриптовые языки напоминают Common Lisp. Положительные примеры напоминают Scheme (потому что более умные дизайнеры интегрировали Guile, SpiderMonkey и Lua вместо того, чтобы изобретать свой собственный язык.) Наиболее достойными DailyWTF примерами были Forth-подобный язык и MUMPS-подобный язык.

Другим примером (не уверен, считается ли он Гринспаннингом, но, безусловно, WTF) был интерпретатор XSLT, используемый для сценариев общего назначения. Это было больше похоже на Lisp, так как они добавили цикл обратной связи, в котором выходные данные будут преобразованы в XSLT во второй раз - так что теперь у вас фактически есть макросы.
Мотивом здесь, однако, было не получение доступа к ошибочным функциям, а обход процедур проверки кода компании (которые добавляли 3 недели задержки к каждому исправлению ошибки. XML считался «данными» и исключался из процесса).

К сожалению нет!

Хотя лучше всего просто вставить настоящий интерпретатор lisp (y) (javascript или lua alos отлично работают), добавление доморощенного 4gl в проект уменьшает общий размер при одновременном повышении гибкости.

Проекты, которые «кодируют все», имеют значительно большее количество модулей и становятся громоздкими и негибкими.