Яка з цих старих критичних зауважень до звичайної ліпи досі діє сьогодні

У "Критиці загальної Лісп", написаній Родні А. Бруксом та Річардом П. Габріелем зі Стенфорда в 1984 році, обговорюються деякі проектні рішення, збережені комітетом з питань нормалізації Лісп. Хоча велика частина дискусії залишається актуальною, є два твердження, які стосуються наявної на той час технології та можуть бути помилковими сьогодні.

Ці два твердження:

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

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

У COMMON LISP було занадто багато контролю над арифметикою з плаваючою комою. І звичайно, хоча можна досягти правильної поведінки інтенсивної програми з плаваючою комою, продуктивність може різко відрізнятися.

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

Це було тридцять років тому. Як я повинен сприймати це твердження сьогодні, якщо я готовий написати загальні програми Lisp для однієї з поширених програм вільного програмного забезпечення (CLISP, SBCL та ін.)?

Стаття цікава багато в чому.

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

Технічне обслуговування цього компілятора Lisp все ще доступне у LispWorks : його тепер називають Liquid Common Lisp .

Оптимізація компілятора Liquid CL задокументована у Розділі 3 Посібника для розширених користувачів : Оптимізація програм Lisp .

У Lucid CL було написано та розміщено декілька комерційних заявок. Наприклад, у моєму рідному місті перша система громадського транспорту для HVV (Hamburger Verkehrsverbund) була розгорнута за допомогою Lucid CL на SUN SPARCstation. Він був доступний для громадськості на вокзалах за допомогою великого сенсорного екрану та в кол-центрі.

Lucid CL виявився успішним, оскільки його компілятор режиму виробництва створив швидкі програми Common Lisp, головним чином для платформ Unix / RISC.

Брукс і Габріель пишуть про Lucid Common Lisp в 1986 році:

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

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

На сьогоднішній день більш просунуті впровадження роблять багато оптимізацій, але апаратне забезпечення також в 1000+ разів швидше, ніж у 1984 році. В VAX 11/780 тоді був один MIPS (мільйон інструкцій в секунду), а машина Lisp також була в що діапазон. Моторола 68000 мала тактову частоту 8 МГц.

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

Оскільки користувач / розробник не змушений писати портативний код і використовувати всі десять + підтримуваних на даний момент загальних систем Lisp. Використовуйте реалізацію, яка найкраще підходить до проблеми із додатком.

Коли цей документ був написаний у 1984 році, комп'ютер, що мав 1 мегабайт оперативної пам’яті та 20-мегабайтний жорсткий диск, здатний сидіти на вашому столі, був великою справою. Звичайно, виникнуть суперечки щодо практичності мови настільки високого рівня, як і Лісп щодо обладнання, яке спартанське. Удосконалення як апаратних, так і компіляторних технологій, що відбулися з того часу, значно спростили програми Lisp для написання та виконання, незалежно від будь-яких числових неефективностей, які можуть бути наявними в мові.

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

Вибір реалізації Lisp може сильно вплинути на профіль продуктивності ваших програм. Наприклад, CLISP легко визнає, що "Якщо ваш код сильно числовий, ви можете віддати перевагу CMUCL." Кілька сучасних реалізацій Lisp (та Scheme) дозволяють задавати підказки числового типу, що підвищить числові показники.

Коротше кажучи, ситуація сьогодні набагато краща, ніж тоді.