Lisp за Web приложения

Пол Греъм

(Това е част от разговор в BBN Labs в Cambridge, MA, през април 2001.)
Оригинал : Lisp in Web-Based Applications

Език по желание

Една от причините за използването на Lisp за написване на Web базирани приложения е че той *може* да се използва. Когато се пише софтуер, който ще се изпълнява на собствен сървър може да се използва който и да е език.
Дълго време програмистите нямаха голям избор на език за написването на приложни програми. Доскоро писането на приложни програми означаваше писане на софтуер, който се пуска на настолни компютри. Този софтуер се пише на езика на операционната система. Практически всички приложения се пишеха на С.
Това се промени от Web базираните приложения. Вие контролирате сървъра и може да пишете на който език си поискате.Може да се приеме, че имате едновременно изходния код на операционната система и компилатора. Може да оправите всеки проблем на езика с операционната система .
Обаче тази свобода е нож с две остриета. Наличието на избор принуждава да се мисли върху въпроса какво да се избере. Преди беше по-лесно . Ако отговаряхте за софтуерен проект и някой предложеше да се използва различен от обичайното език може просто да се каже, че това няма да е практично и да се сложи точка на разговора.
Сървърните приложения промениха всичко. Пазарните сили определят избора на език. Ако се правите, че нищо не станало,както повечето от конкурентите ни, и си използвате С и С++ , ще попаднете в собствения си капан. Малка стартираща компания използваща по-мощен език ще ви изяде пазара.

Инкрементална разработка

Програмирането на Lisp има специфичен стил. Една от основите му е инкременталната разработка : написва се колкото се може по-бързо програма, която не прави почти нищо. След това към нея постепенно се добавят елементи, като винаги има работещ код.
По мое мненние се произвеща по-бързо по-добър софтуер. Lisp програмистите работят вече тридесет години по този начин и всичко в Lisp е подчинено на този стил на програмиране.
Редакторът на Viaweb е краен пример за инкрементална разработка. В началото той беше 120 редова програма за генериране на Уеб сайтове, която бях използвал като пример в книга , която написах преди да се захванем с Viaweb. Постепенно този редактор нарастна до около 25 000 реда код. Нито веднъж не седнах да го пренапиша. Не мисля че е имало ден или два, без да променя нещо по кода. Цялата разработка беше дълга серия от постепенни промени.
Този стил на разработка се вписва добре в постоянните версии на Уеб базирания софтуер. Той е и по-бърз начин за писане на софтуер по принцип .

Интерактивна обвивка

Интерактивната обвивка на Lisp помага много при ускорената разработка на софтуер, но най-голямото ни предимство вероятно беше при намирането на бугове. Както споменах при Уеб базираните приложения имате всички потребителски данни на сървърите и обикновено бъговете могат да бъдат репродуцирани.
Когато някой потребител се обърнеше към мен, съобщавайки за грешка в редактора, зареждах кода му в Lisp интерпретатор и се логвах в потребителския акаунт. Ако можех да репродуцирам проблема го прихващах в цикъла за грешка, който показва точно какво се е обърклао. Често поправях кода и публикувах поправката веднага. Като казвам веднага имам предвид докато потребителя е все още на телефона.
Такова бързодействие при оправянето на бъгове ни предостави много изкушаваща възможност. Ако можехме да разберем и оправим проблем, докато потребителя е на линия, се изкушавахме да създадем впечатление , че никога не го е имало. И понякога хората от отдела за подръжка (за тяхна огромна радост) казваха на потебителя просто да опита да се логне отново и да види дали все още го има проблема . Естествено потребителя се логваше в новата версия на софтуера, в която е оправен проблемът, и всичко работи добре. Може би по този начин постъпвахме малко подло, но беше и доста забавно.

Макроси за HTML

Макросите на Lisp бяха друго голямо предимство за нас. Използвахме ги интезивно при редактова на Viaweb. Той може да бъде точно описан като един голям макрос. Това може да даде идея колко много зависихме от Lisp, защото нито един друг език няма макроси в същата степен като Lisp.
Ние използвахме макроси, за да генерираме HTML. Връзката между макросите и HTML е естествена - HTML и Lisp са с префиксна нотация и са рекурсивни. Въпреки че извиквахме макроси , вложени в други макроси , които генерираха най-сложният HTML код, процесът беше доста управляем.

Вградени езици

Друга полза от макросите беше използването на езика ни за описване на страници, наречен Rtml .(Имаше различни обяснения за значението на Rtml, в действителност го нарекох на съоснователя на Viaweb Робърт Морис, неговото потребителско име е Rtm.)
Всяка страница беше генерирана от програма, написана на Rtml. Нарекохме тези програми темплейти, за да ги направим по-малко плашещи, но те бяха истински програми. Програми на Lisp. Rtml беше комбинация от макроси и вградени в Lisp оператори.
Потребителите можеха да правят техни собствени Rtml шаблони, в които да описват как да изглеждат страниците им. За редактирането на шаблоните използвахме структурен редактор, приличащ много на този от InterLisp. Заменихме писането на свободен текст с копиране и поставяне на цели части код. Така се избегнаха синтактичните грешки. Също така избегнахме показването на скобите на s-изразите, които се получават от кода - показвахме стуктурата му чрез отместване и форматиране. С всичко това езикът ни изглеждаше доста по-малко заплашителен.
Rtml беше проектиран да не дава никакви грешки - всяка програма на Rtml генерираше някаква Уеб страница и чрез дебъг може да се достигне до вида на страницата, който искаме.
Отначало очаквахме потребителите ни да са Уеб консултанти, които да използват често Rtml. Осигурихме няколко прости шаблона за секциите и страниците на продуктите, като идеята беше потребителите да ги променят по собствено желание.
Оказа се , че Уеб консултантите не харесаха Viaweb. По принцип те харесват продукти, които са прекалено сложни за техните клиенти, като по този начин си гарантират постоянно наемане. Консултантите посещаваха сайта ни, в който навсякъде е казано, че софтуерът ни е толкова лесен за употреба и всеки може сам да си направи онлайн магазин за пет минути, и си казваха , че няма начин да използват това. Така нямаше много интерес от страна на консултанти. Вместо това потребителите ни бяха същинските търговци. Те харесаха идеята да контролират техните Уеб сайтове. Този тип потребители не искаха да програмират каквото и да е. Те просто използваха готовите шаблони.
По тази причина Rtml не стана основен интерфейс към програмата. Той изпълняваше две други функции. На първо място той беше вариант за наистина напредналите потребители, които искаха нещо, които липсва в нашите шаблони. Някой ми беше дал ценен съвет : потребителите винаги искат да има възможност за подобрения, дори и никога не ги правят. Нашата възможност за подобрения беше Rtml. Може да поемеш абсолютен контрол върху страниците си, стига да искаш.
Само един от няколко стотин потребители написаха свои шаблони действително. Това води до второто предимство на Rtml. Наблюдавайки какво променят тези потребители в нашите шаблони, знаехме какво да добавим в тях. Дори си поставихме цел никой да няма нужда да използва Rtml . Нашите вградени шаблони трябва да вършат всичко, което искат хората. При този нов подход Rtml служеше като сигнал, че нещо липсва в нашия софтуер.
Третата и най-голяма полза от използването на Rtml беше предимството, което ни донесе. Дори и ние да бяхме единствените хора, които го използват, това се отплащаше достатъчно. Този нов слой абстракция в софтуера ни ни донесе голяма предимство пред конкурентите. От една страна дизайна на софтуера ни стана много по-чист. Нашите Уеб страници се генерираха от език от много високо ниво, вместо от истински С или Perl код. Това направи кода много по-чист и лесен за модифициране. Вече споменах , че Уеб базираните приложения са поредица от множество малки модификации. За да се прави това трябва да се знае колко сериозна е дадена модификация. Това се определя по-лесно след разделянето на кода на слоеве. Модификации на ниско ниво (смаият Rtml) се правеха рядко и след голямо обмисляне. Модификациите в по-горните нива(кода на шаблоните) бяха нещо, което може да се направи бързо и без много притеснения за последиците.
Rtml беше продължение на Lisp. На първо време той беше основно Lisp макроси. Онлайн редактора обабротваше s-изрази. А когато хората стартираха шаблон той се компилираше в Lisp функции чрез извикване на компилация по време на изпълнението.
Rtml дори зависеше силно от ключови думи, зададени като параметри, което до тогава смятах за една от най - съмнителните особености на Common Lisp. Но поради начина на обнновяване на Уеб базирания софтуер той трябва да е проектиран за лесни промени. Rtml трябваше да е лесен за променяне, както всяка друга част от софтуера. Повечето от операторите в Rtml бяха проектирани да приемат като параметър ключова дума и това беше от голяма полза. За да добавя ново измерение в действието на някой оператор трябваше само да добавя нов параметър, като съществуващите шаблони продължаваха да работят. Малко от операторите в Rtml не приемаха ключови думи като параметри, защото не мислех че някога ще се налага да се променят, и горчиво съжалявах за това впоследствие. Едно от нещата, които щях да променя ако можех да върна времето назад и да започна всичко отначало , щеше да е това, че всеки Rtml оператор да приема ключови думи като параметри.
Всъщност ние имахем няколко езика в редактора. Друг, който не беше директно за потребителите, беше за описание на изображения. Viaweb съдържаше написан на С генератор на изображения , който приема описание на изображение, създава самото изображени и връща неговият адрес. Отново използвахме s- изрази за описанието на изображенията.