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

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

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

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

Заява - гіпербола. Але очевидні ознаки заздрості Ліспа в інших мовах. Подивіться на C # і як він набуває більш функціонального характеру. Подивіться на різні системи управління бізнес-процесами, робочий процес та EAI, які виходять із шляху, щоб зробити можливість програмувати систему без зміни програми.

Є книга про мови, специфічні для домену Мартіна Фаулера, яка розповідає про те, як робити метапрограмування на об'єктно-орієнтованих мовах. Значить, є якась правда в гіперболі.

Пол Грехем назвав Лісп найпотужнішою мовою, дивлячись на список перших, які потрапили з Ліспом , легко зрозуміти, чому багато мов бліді в порівнянні.

Шлях навколо десятого правила - програмування поліглотів. Зрозумівши, що одна мова / рамка не є золотим молотом. Тоді замість створення поганої, спеціальної реалізації Lisp, ви можете просто використовувати Lisp.

"Десяте правило" Грінспана було несильним шматочком. Якщо ви розтягнетесь досить далеко, якщо ви змусите його охоплювати "будь-яку систему сценаріїв або конфігурації", то, очевидно, відповідь на це питання повинна бути "так", оскільки конфігурація - це те, що в якійсь мірі вимагає будь-яка нетривіальна програма, і сценарій є лише дещо рідше, коли ви рухаєтесь вгору за шкалою складності.

З іншого боку, погляньте на ціль GOAL - лісовий варіант, придуманий Naughty Dog для програмування ігор. Це зовсім не схоже на "класичний" Лісп. Це вкрай необхідна система, з об'єктно-орієнтованою функціональністю, відсутністю інтерпретатора, мінімальною підтримкою для збору сміття (натомість покладаючись на засоби очищення на рівні виконання) та широкою підтримкою для складання вбудованих даних.

Іншими словами, коли вони намагалися використати Lisp для досить складного проекту, вони виявили, що для того, щоб зробити все корисне, їм довелося перетворити мову на спеціальну, неофіційно задану реалізацію половини C ++! ;) (І врешті-решт їм довелося припинити його використання після того, як хлопець, який сконструював ЦІЛ, пішов, бо ніхто не міг зрозуміти його код.)

Цікаво, що одна відповідь на це питання вже є у програмістів SE .

Процитуйте відповідну частину:

Теза Грінспуна (частково) полягала в тому, що у багатьох складних програмах є вбудовані перекладачі. Замість того, щоб перекладати інтерпретатор на мову, він припустив, що може мати більше сенсу використовувати мову на зразок Lisp, яка вже має вбудований інтерпретатор (або компілятор).

У той час я працював над досить великим додатком, який виконував розрахунки, визначені користувачем, використовуючи спеціальний інтерпретатор для власної мови. Я вирішив спробувати переписати його ядро ​​в Лісп як масштабний експеримент.

Минуло приблизно шість тижнів. Початковий код складав ~ 100 000 рядків Delphi (варіант Паскаля). У Ліспі це було скорочено до ~ 10000 рядків. Ще більш дивовижним було те, що двигун Lisp був у 3-6 разів швидшим. І майте на увазі, що це була робота неофіта Ліса! Весь цей досвід був для мене досить відкритим для очей; вперше я побачив можливість поєднання продуктивності та виразності однією мовою.
- Майкл Ленаган

Щоб уточнити цю частину, Майкл відповів на коментар:

Нічого собі, це, мабуть, був якийсь жахливий код Delphi, якщо йому якимось чином вдалося виконати 3-6 разів повільніше, ніж реалізація Lisp! "Правильно, я вважаю, що як мій збій не пояснив це краще. Реалізація Lisp змогла перетворити вирази користувачів у вирази Lisp - тривіально простий процес - а потім компілюйте вирази Lisp у рідний код (з повною оптимізацією). У цьому сенс десятого правила
Грінспуна . - Майкл Ленаган

Оскільки ця відповідь складається з чужої відповіді в іншому місці, це вікі спільноти.

Правило - це жарт, але в цьому є трохи правди. Будь-яка складна система містила б ряд інтерпретованих частин (дивіться, наскільки "Шаблон інтерпретатора" популярний серед тих, хто вірить у все, що є шаблоном мамбо-джамбо). Будь-яка складна система повинна забезпечувати певні засоби конфігурації, часто структуровані, часто інтерпретовані.

Будь-яка складна система, швидше за все, має декілька пропусків генерації коду та різних налаштованих препроцесорів у процесі збирання (подумайте про такі речі, як mocу Qt чи tablegenLLVM).

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

Усі ці речі отримують безкоштовно з Lisp, і в більшості випадків все те, що ad hoc, незаплановане, не продумане досить ретельно реалізовано, було б абсолютно неповноцінним.

Будь-яка досить складна система матиме конкретні доменні поняття та вимоги, які надзвичайно важко виразити абстракціями мови, на якій ви працюєте. Це ненавмисно змушує програмістів створити конкретні доменні абстракції, щоб полегшити тягар усунення смислового розриву між мовою програмування і конкретний домен. Коли цих абстракцій буде достатньо, ви, в основному, маєте перекладача мови, визначеної для домену. Це неминуча частина розробки програмного забезпечення.

Це правило, ймовірно, може бути більш точним (і менш кумедним), оскільки "для впровадження динамічної поведінки буде потрібно кожна велика система, заснована на програмному забезпеченні".

Це можна зробити двома способами-

1. Великий складний файл конфігурації з десятками параметрів і сотнями визначень.

2. Мова скриптів AD-HOC.

"sendmail" - це, мабуть, канонічний приклад типу "1". Я не можу придумати жодних хороших прикладів типу "2", які не передбачають вбудовування "справжньої" мови сценаріїв a la Warcraft / LUA або навіть Netscape / Javascript.

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

Це може бути правдою, як зазначають інші, для багатьох програм потрібна конфігурація, і тому вони містять різні інтерпретатори, подібні до шпиля.

Однак заява також з усмішкою передбачає, що все, що потрібно для створення програми, - це Lisp, і що всі інші мови їй поступаються.

Але це неправильно, Lisp може бути виразним, але він також занадто абстрактний, він намагається приховати деталі платформи і робити вигляд, що немає нічого, крім списків, що існують у світі комп'ютерів.

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

Це навпаки, незалежно від того, наскільки складною, розумною чи витонченою мовою винайдете, все, що в кінцевому підсумку є лише іншим способом написання збірки.

Незалежно від того, чи це було призначено сприймати серйозно, це стосується найбільших проектів C і C ++, над якими я працював.

Що неправда, це те, що власні мови сценаріїв нагадують звичайний Lisp. Позитивні приклади нагадують схему (адже розумніші дизайнери інтегрували Guile, SpiderMonkey та Lua замість того, щоб вигадувати власну мову.) Найбільш гідними прикладами DailyWTF були мова схожа на Forth та мова, схожа на MUMPS.

Іншим прикладом (не впевнений, чи вважається це Зеленим наскоком, але, звичайно, WTF), був перекладач XSLT, який використовується для сценаріїв загального призначення. Це було більше схоже на Lisp, оскільки вони додавали цикл зворотного зв’язку, де вихід буде перетворений XSLT вдруге - так що тепер у вас є ефективні макроси.
Хоча тут мотив полягав не в тому, щоб отримати доступ до функцій lispy, а щоб уникнути процедур QA коду компанії (що додало три тижні затримки до кожного виправлення помилок. XML вважався "даними" та виключався з процесу).

На жаль ні!

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

Проекти, які "кодують все", мають значно більшу кількість модулів і стають непростими і негнучкими.