30 април 2009

Корицата на Java

Оригинално есе - Java`s Cover .
Април 2001
Това есе е резултат от разговори, които съм провел с няколко други програмисти, чудейки се защо Java изглежда съмнително. Това не е критика за Java. Това е изследване на хакерския радар .
С времето хакерите развиха усет за добрите ( и лошите ) технологии. Мисля, че може да е интересно да опитам да напиша защо Java ми изглежда подозрителна.
Някои хора, които прочетоха това, мислят, че е интересен опитът да се пише за нещо, за което не е писано досега . Други казват, че мога да имам неприятности заради желанието да пиша за неща, които не разбирам. Затова искам да изясня, че аз не пиша за Java (която никога не съм използвал ), а за хакерския радар (върху който съм мислел доста).

Афоризмът "не може да съдиш за книгата по корицата й" произлиза от времената, когато книгите се продаваха с картонени корици, които могат да се променят според вкуса на купувача. Тогава не можеше да се съди за книгата по корицата. Но от тогава издателите се развиха много - сега те се опитват да направят корицата "говореща" за самата книга.
Прекарал съм доста време в книжарници и чувствам, че се научих да разбирам всичко, което издателите се опитват да кажат за някоя книга. През времето, в което не бях в книжарниците , бях пред компютри и чувствам, че се научих да преценявам технологиите според тяхната корица. Може да е било случайност, но се спасих от някои технологии, които се оказаха наистина кофти.
Засега Java ми изглежда кофти. Никога не съм писал програма на Java и само съм прелиствал книги за нея, но усещам , че няма да е много успешен език . Може и да греша; предсказването е опасно. Но нищо не пречи да напиша защо не харесвам корицата на Java :
1. Java се рекламира много енергично. На истинските стандарти не им се налага да се промотират. Никой не е "рекламирал" C или Юникс, или HTML. Истинските стандарти са установени, преди повечето хора да ги чуят . На екрана на хакерския радар Perl е голям Java, дори по-голям , само заради своите заслуги.
2. Прицелена е много ниско. В оригиналните публикации за Java Гослинк подчертава, че тя е проектирана да не е толкова трудна за програмистите на C. Тя беше проектирана да бъде друг C++ : С плюс някои идеи от по-развитите езици. Също като ситкомите или полуготовата храна, създателите на Java умишлено са проектирали продукт за не толкова умни хора. Историческо погледнато езиците за други хора са били лоши: Cobol, PL/I, Ada, C++ . Добрите езици са били тези, които са проектирани за създателите си : С, Perl, Smalltalk, Lisp.
3. Има тъмни мотиви. Някой беше казал, че света ще е по-добро място, ако хората пишат книги само когато имат нещо за казване, а не защото са искали да напишат книга. Причината да слушаме постоянно за Java не е в това, че тя допринася за езиците за програмиране. Слушаме постоянно за нея, защото това е част от плана на Sun да прецака Microsoft.
4.Никой не я обича. Програмистите на C, Perl, Python и Lisp обичат тези езици. Не съм чул някой да казва, че обича Java.
5. Хората са принудени да я използват . Много от хората, за които знам че използват Java, го правят, защото трябва да го направят. Tрябва да го направят, за да ги финансират, или клиентите го изискват, или така са им казали мениджърите. Те са умни хора и щяха доброволно да използват тази технология, ако беше добра .
6. Има прекалено много "родители". Най- добрите езици за програмиране са създадени от малки групи. Java изглежда като управлявана от комитет. Ако тя излезе добър език това ще е първият подобен случай.
7. Тя е бюрократична. От малкото което знам за Java, изглежда , че има много протоколи за правенето на неща. Наистина добрите езици не са такива. Те ти позволяват да направиш каквото ти трябва и след това не те занимават.
8. Sun претендира , че Java е създадена от усилията на обществото на отворения код , както Perl или Python. Но тя е контролирана от гигантска компания и езика вероятно ще е същият, като обичайната продукция на големите компании.
9. Java е проектирана за големи организации. Големите организации имат различни цели от хакерите . Те искат езици, които са подходящи(или поне така се надяват) за използване от големи екипи, съставени от посредствени програмисти - езици, които могат да ограничават глупаците от правенето на прекалени глупости. Хакерите не искат езици, които да ги поучават. Хакерите искат просто мощ. Исторически погледнато езиците за големи организации(Pl/I, Ada) са се изгубили, а хакерските езици(C, Perl) победиха. Причината за това е че днешните хакери младежи утре ще са ръководители на развойната дейност.
10. Харесват я неподходящи хора. Програмистите , които уважавам , като цяло не са завладяни от Java. Кой харесва Java ? Костюмари, които не различават езиците, но чуват за Java от пресата; програмистите в големите компании, които са изненадани като разберат , че има нещо, което е по-добро и от C++; и току-що завършилите младежи, които харесват всичко, което може да им намери работа (това ли ще е на теста ? ). Мнението на тези хора се променя с всяко ново течение .
11.Собственикът й е притиснат . Бизнес моделът на Sun се проваля на две места. Евтините процесори на Intel вече са достатъчно бързи, за да работят на сървъри. А FreeBSD изглежда е подходяща за сървъри поне колкото Solaris. Рекламата на Sun настоява, че имате нужда от Sun за индустриални приложения. Ако това беше истина Yahoo щяха да са от първите клиенти на Sun, но докато работех там всички сървъри бяха само Интелски машини с FreeBSD. Това не вещае добро за Sun в бъдеще. А ако Sun има проблеми може и Java да потъне заедно с тях .
12. Военните я харесват . Министерството на отбраната съветва програмистите да използват Java. За мен това е най - страшния знак. Министерството на отбраната върши добра (и скъпа) работа за охраната на страната, но те обичат плановете и процедурите, и протоколите. Тяханата култура е противоположна на хакерската и по въпросите относно софтуера обикновенно грешат . Последният език, който Министерството на отбраната наистина харесваше, беше Ada.

Имайте предвид, че тоав не е критика към Java, а към корицата й. Не познавам добре Java за да я харесвам или не. Това е само обяснение защо не не намирам за необходимо да я изуча.

Може да изглежда неетично да отстраниш език преди дори да се опиташ да напишеш нещо на него. Но това трябва програмистите да го правят. Има прекалено много технологии, за да се изучат всички . Трябва да се научиш да преценяваш кои си заслужават времето и усилията. По подобен начин пропуснах Cobol, Ada, Visual Basic, IBM As400 , VRML , ISO 9000 , протокола SET , VMS, Novell Netware и CORBA. Те просто намирисваха.

Може да се окаже, че греша за Java. Може да се окаже, че език, създаден от една компания , за да провали друга, проектиран от комитет за "широка" публика, превъзнесен до небесата и обичан от МО, е чист, красив и мощен език, на който бих искал да програмирам. Може и да стане, но е много малко вероятно .
   

09 април 2009

Да победиш средняците

Април 2001, ревизиран Април 2003
(Тази статия е следствие на лекция от Franz Developer Symposium 2001)
Оригинал -> Beating the Averages

С моя приятел Робърт Морис стартирахме начинанието си Viaweb през лятото на 1995 година. Планът ни беше да напишем софтуер, който да позволява на крайните потребители да си правят онлайн магазини. Новото в нашият софтуер беше, че той работеше на наш сървър, използвайки за интерфейс обикновени Web страници.
Сигурно доста хора са имали подобна идея по същото време, но доколкото знам Viaweb беше първото Уеб базирано приложение.Изглеждаше ни толкова новаторска идея, че нарекохме компанията си на нея : Viaweb , защото нашият софтуер работеше през мрежата (via the Web), а не на десктопен компютър.
Друго необичайно нещо беше, че нашият софтуер беше написан основно на език за програмиране, наречен Lisp. Това беше едно от първите големи приложения за крайните потребители, което е написано на Lisp, който дотогава се използваше основно в университети и изследоватески лаборатории. [1]

Тайното оръжие

Ерик Реймънд е написал есе, наречено "Как да станеш хакер" , в което освен другите неща, казва какъв език трябва да научат кандидат- хакерите. Той предлага да ссе започне с Python и Java, защото са лесни за учене. Сериозният хакер трябва да научи С, за Юникс , и Perl за системно администриране и cgi скриптове. Накрая, наистина сериозния хакер трябва да помисли за научаването на Lisp:
Lisp си заслужава ученето заради вдъхновяващия опит, който ще имате накрая; този опит ще ви направи по-добри програмисти занапред, дори никога да не изпозлвате самият Lisp.

Това е същото като Латинския език. Той няма да ти намери работа, освен като професор по класически езици, но ще подобри мисленето ти и ще те направи по- добър писател на езика, на който искаш, примерно английски.
Но ... почакайте. Тази метафора не е много точна. Причината за това, че латинския няма да ви намери работа е в това, че никой не го говори. Ако пишете на латински никой няма да ви разбере. Но Lisp е компютърен език, а компютрите разбират всеки език, който използват програмистите.
Ако Lisp наистина те прави по-добър програмист, защо няма да искате да го използвате ? Ако предложим на един художник четка, която ще го направи по-добър художник , той ще я използва за всичките си картини, нали ? Тук не се опитвам да се шегувам с Ерик Реймън. Като цяло неговият съвет е добър. Това , което той казва за Lisp е стандартна съвет. Но в него има противоречие : Lisp ще те направи по-добър програмист, но няма да го използвате .
Защо не ? Все пак езиците за програмиране са само инструменти. Ако Lisp допринася за по-добри програми , той трябва д асе използва. Кой ще има нужда от него , ако не помага ?
Това не е чисто теоретичен въпорс. Софтуерът е много състезателен бизнес, предразполагащ към естествен монопол. При други равни условия компания, която може да пише по-бързо по-добър софтуер ще извади от играта конкурентите си . Това се усеща най - добре при стартиране на компания. Обикновенно тогава въпросът е всичко или нищо . Или ставаш богат или не се получава нищо . Конкурентите ти ще те разбият ако заложиш на грешна технология .
Аз и Роберт познавахме добре Lisp и не виждахме причина да не се доверим на инстинктите си. Знаехме , че всички останали пишеха софтуера си на С++ или Perl . Също така знаехме, че това не означава нищо. Ако така се избираше технология всички щяхме да сме с Windows . При избора на технология трябва да се игнорират действията на останалите хора и да се преценява единствено въз основа на това какво ще работи най-добре. Това важи особено за стартиращите компании . Голяма компания може да прави каквото правят всички останали големи компании. Но ново начинание не може да прави както всички останали. Не мисля че много хори, дори от стартиращи компании, осъзнават това.
Средно големите компании отбелязват ръст с около десет процента на година. Ако управлявате голяма компания и правите всичко като средните компании може да очаквате и ръстът да е като на обикновенна голяма комапния - около десет процента .
Разбира се същото ще се случи и ако управлявате нова компания . Ако правите всички като средна нова компания ще получите средно представяне. Проблемът е , че средно представяне означава напускане на играта. Нивото на оцеляване на нови компании е доста под петдесет процента . Така че при управлението на нова компания е по-добре да се действа по-различно . Иначе се попада в беда.
През 1995 ние знаехме нещо, което и досега малко от нашите конкуренти разбират : когато софтуера се пуска на свой собствен сървър , може да използвате който си поискате език. Ако пишете софтуер за настолен компютър има полза да използвате езика на операционната система. Преди десет години разработка на приложение означаваше писане на С . С уеб базирания софтуер може да използвате език по желание.
Тази нова свобода е нож с две остриета . Когато можеш да избереш език , трябва да се обмислли кой точно да е . Компаниите, които се опитват да си заравят главата в пясъка пред този факт, поемат риск техните конкуренти да не направят така.
Ако може да си избираш език , кой би ползвал ? Ние избрахме Lisp. На първо време беше ясно , че ускорената разработка ще бъде важна на този пазар . Всички започваме от нулата и компанията, която вади нови възможности преди конкурентите си има голямо предимство. Знаехме, че Lisp е наистина добър език за бързо писане на софтуер и сървърно базираните приложения увеличават ефекта на ускорената разработка, защото софтуера влиза в употреба веднага.
Ако другите компании не искаха да използват Lisp , толкова по-добре за нас . Той можеше да ни даде крайна технология, а ние имахме нужда от всичко, което можеше да ни помогне. Ние нямахме опит в бизнеса, когато стартирахме Viaweb. Не знаехме нищо за маркетинга или набирането на персонал , или за събирането на пари, или намирането на клиенти. Никой от нас никога не беше имал истинска работа. Единственото нещо, в което бяхме добри беше разработката на софтуер. Надявахме се това да ни спаси. Използвахме всяко предимство, което можехме да имаме в софтуерно отношение .
Може да кажете, че използването на Lisp беше експеримент. Нашата хипотеза беше, че ако пишем нашия софтуер на Lisp , ще можем да изработваме допълнителни неща по-бързо от нашите конкуренти , също така ще можем да правим неща, които другите не могат. Ние не се нуждаехме от голям екип, защото Lisp е език от много високо ниво , а така разходите ни бяха малки. Ако нещата се случат така , щяхме да предлагаме по-добър продукт за по-малко пари и все пак да имаме печалба. Щяхме да привлечем всички потребители, а нашите конкуренти, останали без потребители, да напуснат бизнеса. На това се надявахме.
Резулатът от нашия експеримент, някак учудващо, беше , че работи . Имахме доста конкуренти, между двадесет и тридесет , но никой от техния софтуер не можеше да се сравнява с нашия. Ние прдлагахме WYSIWYG правене на онлайн магазини, което се правеше на сървъра, но приличаше на настолно приложение. Конкурентите ни имаха cgi скриптове. Ние винаги бяхме напред с допълнителните възможности. Понякога отчаяните конкуренти се опитваха да покажат възможност, която ние нямахме . Но нашият цикъл на разработка с Lisp беше толкова бърз, че понякога ние правехме същото допълнение за ден или за два след обявяването му от конкурентите. Ние предлагахме същата възможност преди журналистите да ни питат за реакцията ни от излизането й.
На конкурентите ни им е изглеждало така, сякаш имахме някакво тайно оръжие - че сме декодирали техния трафик или нещо подобно. Ние наистина имахме тайно оръжие, но то беше по-просто, отколкото си го представяха. Никой не ни издаваше техните тайни. Просто ние можехме да разработваме софтуер по- бързо, отколкото някой може да си помисли.
Когато бях на девет в ръцете ми попадна книгата "Денят на чакала" от Фредерик Форсайт(българска електронна версия ). Главният герой е наемен убиец, който е нает за убийството на рпезидента на Франция. Убиецът трябва да премине през полицаи, за да стигне до апартамента, от който има изглед към пътя на президента. Той минава директно през тях, дегизиран като старец с патерици.
Нашето тайно оръжие беше подобно . Ние пишехме софтуера си на странен език за ИИ с необичаен синтаксис и много скоби . Години наред чувах това описание на Lisp . Но това ни носеше предимство . В бизнеса няма нищо по-ценно от технологично предимство, което конкурентите не разбират. В бизнеса, както във война, изнендата е важна, колкото и силата .
Съгласно това, малко ме е срам да го призная , докато работехме по Viaweb не съм споменавал нищо за Lisp . Не сме го споменавали пред пресата, а ако търсите думата Lisp в нашия Уебсайт ще намерите само две заглавия книги в моята биография . Това е беше случайно . Стартиращата компания трябва да дава колкото се може по-малко информация на конкурентите си. Исках те да не знаят или да не се интересуват от езика, на който пишехме софтуера си. [2]
Хората, които най-добре разбираха технологията ни бяха клиентите. Те не се интересуваха на какъв език е наисан Viaweb, но забелязаха , че наистина работи добре. Той им позвляваше буквално за минути да правят великолепни онлайн магазини . Предавайки най -вече се от уста на уста ние имахме все повече и повече потребители. В края на 1996 имахме около 70 онлайн магазина. В края на 1997 - 500. Когато Yahoo ни купи шест месеца по-късно , ние имахме 1070 потребителя. Този софтуер доминира на пазара вече като Yahoo Store. Той е една от най- доходните компоненти на Yahoo, а магазините, направени с него са в основата на Yahoo Shoping. напуснах Yahoo през 1999 и не знам колко потребителя имат сега, но последното което чух беше за около 20 000 .

Парадоксът на Блъб

Какво е толкова специално в Lisp ? И защо ,ако наистина Lisp е толкова добър, никой не го използва ? Това не са реторични въпорси, а реални такива, които имат отговори . Lisp не е толкова велик заради няккава магическо качество, което е видимо само за просветените , а просто защото в момента той е най- мощният език . Причината за неизползването му е в това, че езиците за програмиране не са само технология, но и умствени навици, които се променят бавно. Разбира се тези отговори се нуждаят от обяснение.
Ще започна с шокиращо заявление : езиците за програмиране имат различна мощ.
Да почнем от това, което млако хора биха оспорили - езиците от високо ниво са по-мощни от машинните езици . Повечето програмисти биха се съгласили, че по принцип не искат да програмират на машинен език. Вместо това се пишат програми на езици от високо ниво , които се превеждат в машинен код от компилатор . Тази идея дори е вградена в хардуера : от осемдесетте инструкциите се проектират за компилаорите, а не за живи програмисти .
Всеки знае , че е грешно ръчно да се напише цяла програма на машинен код. По-малко разбиран е генералния принцип : ако има избор от няколко езика е грешно да не се програмира на най- мощният от тях , ако всички останали условия са еднакви. [3]
Разбира се има много изключения от отва правило . Ако пишете програма, която трябва да работи заедно с друга програма, написана на определен език , добре е да напишете новата програма на същия език. Ако пишете програма, която прави нещо просто като числови пресмятания или побитови манипулации, може да изберете език от по-ниско ниво , който ще е по-бърз. Ако пишете кратка програма за еднократна употреба е по-добре да се избере език, който има подходящи библиотечни функции. Но по принцип за приложен софтуер трябва да се използва най-мощния (и достатъчно ефективен ) език, а всички останало е грешно .
За всички машинният код е много ниско ниво . Но езиците на от високо ниво се гледа като на равнопоставени . Те не са . Технически погледнато терминът "език от високо ниво" не означава нищо определено . Няма разделителна линия между машинните езици и езиците от високо ниво. Езиците попадат в континиум [4] от абстракции, от най- мощният до машинните езици , които са с различна мощ.
Да вземем Cobol . Cobol е език от високо ниво, в смисъл че се компилира до машинен код. Някой ще спори ли сериозно, че Cobol е равнопоставен на Python ? Той вероятно е по-близк до машинен език, отколкото Python .
Или пък Perl 4 ? Преди да излезе Perl 5 към езика бяха добаввени лексикални затваряния (closures). Повечето Perl хакери биха се съгласили, че Perl 5 е по-мощен от Perl 4. Но ако се признае това, значи се признава това, че един език от високо ниво е по-мощен от друг. А това означава, че трябва да се използва най-мощният достъпен език .
Мисля, че рядко тази идея се олицетворява. След определена възраст програмистите рядко сменят езиците доброволно. Хората смятат, че езика който са използвали е достатъчно добър .
Програмистите се привързват много към любимите си езици и за да не обидя някого, ще използвам хипотетичен език, наречен Блъб. Блъб попада в средата на пространството от абстракции. Той не е най-мощния език, но е по-мощен от Cobol или машинен език.
Всъщност нашият хипотетичен Блъб програмист не би използвал никой от тях . Разбира се , че той няма да програмира на машинен език . За това си има компилатори. Относно Cobol - той не знае как някой може да направи нещо на него . Той дори няма х (Блъб възможност по избор).
В този момент нашият хипотетичен Блъб програмист осъзнава, че гледа надолу .Езиците са очевидно по-малко мощни от Блъб, защото им липсват някои възможности, които той използва. Но когато нашият хипотетичен Блъб програмист гледа в другата посока, към по-мощните езици, той не осъзнава това. Това, което вижда са някакви странни езици. Вероятно ги има за еквивалентни на Блъб, но с всякакви модерни добавки. Блъб е достатъчно добър за него, защото той мисли в Блъб.
Но ако погледнем от гледната точка на програмист, използващ някой от езиците, които са по-нагоре по скалата на мощта, ще видим , че той надилу гледа към Блъб. Как може да се направи нещо на Блъб. Та той дори няма y.
По индукция се достига до извода, че единствения програмист, който може да види разликите в мощта на различните езици, е този, който разбира най-мощният .(Вероятно затова Ерик Реймънд казва, че Lisp ще те направи по-добър програмист.) Заради парадокса на Блъб не може да разчитате на чуждите мненния, защото те са породени от това, че човек е доволен от езика, който използва , защото той формира начина му на мислене.
Знам това от собствен опит. В училище пишех програми на Basic. Този език дори не поддържа рекурсия . Трудно е да си шредставиш да пишеш програми без рекурсия, но тогава не ми липсваше. Бях фурия, господар на всичко .
Петте езика, които Ерик Реймънд препоръчва на хакерите, попадат на различни места по скалата на мощта. Къде попадат един спрямо друг e чувствителна тема. Мога само да кажа, че Lisp е на върха. В подкрепа на тази теза ще посоча едно от нещата, които липсват в останалите четири езика. Как може да направите нещо на тях без макроси ? [5]
Много езици имат нещо, наречено макрос, Но макросите на Lisp са уникални. Ако искайте вярвайте, но те са свързани със скобите. Проектантите на Lisp не са добавили в езика всички тези скоби само за да е различен . Lisp кодът изглежда странно за Блъб програмиста. Но тези скоби не са там случайно . Те са външното проявление на фундаменталната разлика между Lisp и останалите езици .
Кодът на Lisp е съставен от Lisp даннови обекти. И то не в тривиалния смисъл, че файловете с код съдъжат символи, а низовете са един от типовете данни на езика. Кодът на Lisp е съставен от стуктури от данни, които могат да се обхождат.
Ако разбирате как работят компилаторите, истината е че Lisp няма странен синтаксис, а че Lisp въобще няма синтасис. Програмите се пишат в синтактични дървета , които се генерират от компилатора.тези дървета са напълно достъпни за програмите. Могат да се напишат порграми, които ги манипулират . В Lisp тези програми се наричат макроси. Те са програми, които пишат програми .
Програми, които пишат програми ? Кога изобщо ще искаш да правиш това ? Не много чеесто, ако мислиш за Cobol. Постоянно, ако мислиш в Lisp. Ще бъде добре ако дам пример за мощен макрос . Но той ще исглежда безмислен за някой, който не познава Lisp; тук няма място за обясняване на всичко, което трябва да се знае, за да се разбере примера. В Ansi Common Lisp се опитах да минавам темите набързо, но дори и така не стигнах до макросите преди 160-та страница.
Все пак мога да посоча нещо, което може да е убеждаващо. Кодът на редактора на Viaweb беше около 20-25 % макроси. Макросите са по-трудни за писане от обикновени Lisp функции и е признак на лош стил да се използват без да са необходими . Поради тази причина всеки макрос беше в кода ни беше на мястото си, което означава, че поне 20-25% от кода на програмата прави неща, които е трудн ода се направят на друг език. На скептичния Блъб програмист са му смешни тези изявления за мистериозната сила на Lisp . Но ние не пишехме този код за забавление. Бяхме малка стартираща компания, която програмираше колкото може по-добре, за да постави технологическа граница между нас и конкурентите ни.
Подозрителният човек може да се зачуди дали няма някаква обвързаност. Голяма част от нашия код шравеше неща, които са доста трудни за другите езици. Нашият софтуер правеше неща, които не бяха по силите на софтуера на конкурентите ни. Може би наистина има някаква връзка . Съветвам ви да проследите тази линия. Може би в нея има повече неща, отколкото се забелязват на пръв поглед.

Айкидо за стартиращи

Не очаквам да убедя някого (над 25 ) да научи Lisp . Целта на тази статия не е да променям нечие мислене , а да подкрепя хората, които се интересуват от Lisp - хората, които знаят колко е мощен Lisp, но се притесняват, защото няма широко разпространение. Това е предимство при състезателните условия. Мощта на Lisp се увеличава поради факта, че конкурентите не го разбират.
Не се притеснявайте да използвате Lisp в стартираща компания. Трябва да се надявате да се запази сегашната ситуация. А тя вероятно ще се запази. Хардуера се променя много по-бързо от личните навици и програмирането се движи десет- двадесет години след процесорите. На места като MIT пишеха програми на езици от високо ниво в началото на шейсетте, но много компании продължаваха да пишат код на машинен език до осемдесетте. Предполагам , че много хора продължаваха да пишат на асемблер докато процеросите най-накрая не преминаха на RISC инструкции.
Обикновенно технологията се променя бързо. Но езиците за програмиране не са само технология, на тях мислят програмистите. Те са наполовина технология и наполовина религия [6]. Затова средния език, на който пише средния програмист, се променя бавно като айсберг. Въведеното в Lisp през началото на шейсетте години събиране на боклука сега вече е всеобщо признато. С нарастваща популярност е и типизирането по време на изпълнение. Лескикалните затваряния, които бяха въведени в Lisp през седемдесетте, сега са в края на познатите технологии. Макросите, въведени в Lisp през шейсетте, свсе още са terra incognita.
Очевидно средният език има огромна инерция. Не предлагам на никой да се бори с тази мощна сила. Предлагам точно обратното : използвайте я срещу противниците си , както се прави от практикуващите айкидо.
Това не е лесно за работник в голяма компания. Ще бъде трудно да убедите некомпетентния си шеф да ви остави да пишете на Lisp, защото той е прочел във вестниците , че някой друг език уверено ще презвеме света, както беше с Ada преди двадесет години. Но ако работите за млада компания вероятно няма да има шеф и можете да използвате парадоксът на Блъб, за да имате предимство - може да използвате технология, която вашите конкуренти никога няма да разберат, защото те са свързани за средните езици.
Ще дам и един ценен съвет за оценка на конкурентите на стартираща компания. Прочете списъка им с работни места. Всичко останало може да са приказки, но свободните работни места трябва да са точно такива, каквито искат или ще вземат грешни хора.
Прочетох доста описания на работа през годините работа върху Viaweb . Всеки месец се появяваше нов конкурент. Първото нещо, което правех след проверката дали имат онлайн демо, беше да погледна свободните места за работа. След няколко години мога да кажа за кои компании да се притеснявате и за кои не. Колкото повече общи ИТ неща има в обявите, толкова по-безопасна е компанията. Най- безопасните бяха тези, които искаха опит с Oracle. Никога не трябва да се притеснявате от тези. В безопасност сте и ако търсят C++ или Java разработчици. Ако търсят Perl или Python програмисти трябва да започнете да се притеснявате - това звучи сякаш в тази компания поне техническата част се ръководи от хакери. Щях да съм наистина разтревожен ако някога бях видял обява за работа за Lisp хакери.

Бележки
[1] Отначало Viaweb беше от две части : написан на Lisp редактор, използван от хората за създаване на сайтове , и система за поръчки, написана на C. Първата версия беше основно на Lisp , защото системата за поръчки беше малка. По-късно добавихме още два модула - написан на C генератор на изображения и написан на Perl back-office мениджър.
Януари 2003 Yahoo пусна нова версия на редактора, написана на C++ и Perl. Не е лесно да се каже, че програмата вече не е написана на Lisp, защото те, за да преведат тази програма на C++, буквално са написали Lisp интерпретатор : доколкото знам изходните файлове на всички шаблони за генериране на страници са все още написани на Lisp .(виж Десетото правило на Грийнспън)
[2] Робърт Морис казваше, че няма нужда да се крием , защото нашите конкуренти нямаше да разберат защо използваме Lisp : "Ако бяха толкова умни щяха да програмират на Lisp"
[3] Всички езици са равностойни, защото са павностойни на машина на Тюринг, но не от този смисъл се интересуват програмистите. (Никой не иска да програмира на машина на Тюринг) Типът мощ, от който се интересуват програмистите , не може да се дефинира, но един начин за обясняването й може да е това, че тя са възможностите, които могат да бъдат използвани в по-малко мощния език само ако на него се напише интерпретатор на по-мощния . Ако езикът А има оператор за премахвне на интервалите от низ , а езика Б го няма, това вероятно не означава, че А е по-мощен , защото може д асе напише функция, която да прави това в Б. Но ако А поддържа рекурсия, а Б - не, това трудно може да се поправи с написване на библиотечни функции .
[4] Бележка за зубрачите : може ние стълба, отиваща до най-горе. Не толкова формата е важна, колкото идея, че има няккаъв ред.
[5] Малко е объркващо макросите да се разглеждат като отделна възможност. На практика тяхната полза е много по-голяма във връзка с други от възможностите на Lisp.
[6] В резултат на това сравняването на програмните езици се превръща или в религиозна войни или в книги за ученици. Хората които искат спокойствие избягват тази тема. Но този въпрос е само наполовина религиозен, има какво да се изучава, особено от хората, които искат да проектират нови езици.

Някои технически подробности Японски превод

Турски превод Узбекски превод

Orbitz също използва Lisp Как да станеш хакер

Разказ за Scheme

01 април 2009

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- изрази за описанието на изображенията.