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

12

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

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 бесполезен, возможно, правильные условия поиска не приходят на ум. Я ищу документы или статьи, подтверждающие эту претензию, если таковые имеются.

casualcoder
источник
8
Вы читали объяснение значения правила в статье в Википедии? Я сомневаюсь, что будут серьезные попытки подтвердить или опровергнуть претензию, на самом деле ее не следует воспринимать всерьез .
Яннис
3
Самое смешное, что хотя правило Гринспена было просто шуткой, я действительно работал над программным обеспечением для моделирования, в котором был встроенный интерпретатор LISP. Конфигурирование программного обеспечения было выполнено с помощью S-Expressions, и можно было написать код LISP для выполнения различных действий в конфигурации.
WKL
@YannisRizos - Буквально ни одна из ваших ссылок не утверждает, что это правило - шутка. Закон Морриса как таковой оформлен. Теперь, образно
говоря
2
@casualcoder « Ирония в том, что после моей смерти это, вероятно, будет единственной вещью, которую кто-нибудь помнит из моего письма». и название правила намекает на то, что оно было написано в легкой форме ...
Яннис
Разве не было похожей цитаты относительно Erlang и параллельных программ?
Джорджио

Ответы:

15

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

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

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

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

Майкл Браун
источник
4
Власть и возраст независимы. Это действительно совершенно неважно, насколько хорош или плох LISP был на момент его создания, важно, как он сравнивается с языками сегодня. Первые совершенно неважны.
DeadMG
2
@DeadMG, эти «первые» - ничто по сравнению с вещами, которые еще не были перенесены из Lisp на другие языки.
SK-logic
1
@DeadMG, ты прав. Одна из вещей, которые люди любят в Ruby после того, как они начинают копаться в нем, - это аспект метапрограммирования. В Lisp это встроено. Разработчики на C # любят LINQ (и на то есть веские причины) и последствия, которые декларативное программирование имеет для параллелизма. Лисп имеет это в пиках. Поскольку системы становятся более сложными, они становятся больше об узлах, реагирующих на сообщения, и меньше об объектах. Lisp начинается там, большинство других языков должны использовать его как ad hoc (отсюда и правило), так и через фреймворк (например, Biztalk, Tibco и т. Д.).
Майкл Браун
2
«вместо того, чтобы создавать плохую специальную реализацию Lisp, вы можете просто использовать Lisp», но вывод Морриса означает, что вы все еще используете плохую, специальную реализацию;)
jk.
1
Идеальный признак этой записи «вся хакерская культура часто воспринимается самими хакерами как ха-ха-серьезная; слишком легкомысленно или слишком серьёзно она воспринимает человека как постороннего, подражателя или в личиночной стадии . "
Майкл Браун
10

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

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

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

Мейсон Уилер
источник
Я предполагаю, что мой вопрос о конкретных частях большой системы. В конце концов, система будет иметь части, которые лучше кодируются на другом языке благодаря мыслительным процессам или методикам, связанным с использованием этого языка, а не присущей скорости или превосходству. История мистера Ленагана - один из примеров.
casualcoder
На самом деле они перестали использовать GOAL, потому что их приобрела компания, чья кодовая база была на C ++. Кроме того, цель была довольно слабым. Не думайте, что онлайн-уроки с наименьшим знаменателем и университетские лекции верны :)
p_l
9

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

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

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

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

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

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

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

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

casualcoder
источник
2

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

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

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

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

SK-логика
источник
2

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

davidk01
источник
1

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

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

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

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

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

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

Джеймс Андерсон
источник
0

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

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

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

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

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

vlsh
источник
Похоже, имеет отношение только к самым древним средам лиспов конца 50-х годов. Лично я обнаружил, что функции Common Lisp для работы с битами, вероятно, являются одними из лучших (главным конкурентом является Erlang). Массивы, хеш-таблицы, структуры - все это часто встречается.
p_l
Легко написать компиляторы для Lisp, так как вам не нужно разбирать их. Можно было бы создать функции Lisp и макрос-компилятор (который похож на оценщик Lisp только на одну-половину страницы кода в начале), который превращает эти выражения List в C, и вы пишете на C на Lisp, но со всей мощью макросов и лямбда-исчисление, если хотите.
aoeu256
0

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

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

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

finnw
источник
-1

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

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

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

Джеймс Андерсон
источник