(Бұл мақала 2001 жылғы Franz Developer Symposium симпозиумында сөйлеген сөзге негізделген.)
1995 жылдың жазында досым Роберт Моррис екеуміз Viaweb атты стартапты бастадық. Жоспарымыз бойынша, қарапайым пайдаланушыларға интернет-дүкендер жасауға мүмкіндік беретін бағдарламалық жасақтама жазуымыз керек еді. Сол кездегі бұл бағдарламаның жаңалығы — оның біздің серверде жұмыс істеп, интерфейс ретінде кәдімгі веб-парақшаларды қолдануында болатын.
Әрине, сол уақытта бұл идея көптеген адамның ойына келуі мүмкін еді, бірақ менің білуімше, Viaweb алғашқы Web-негізді қолданба болды. Бұл бізге соншалықты жаңа идея болып көрінгені сонша, біз компанияның атын соған байланысты қойдық: Viaweb, өйткені біздің бағдарлама дербес компьютерде емес, Web арқылы жұмыс істеді.
Бұл бағдарламалық жасақтаманың тағы бір ерекшелігі — ол негізінен Lisp атты бағдарламалау тілінде жазылған болатын. Бұл сол уақытқа дейін көбінесе университеттер мен ғылыми-зерттеу зертханаларында ғана қолданылып келген Lisp тілінде жазылған алғашқы ірі тұтынушылық қолданбалардың бірі еді. [1]
Құпия қару
Эрик Реймонд «Хакер болудың жолы» атты эссе жазған, сонда ол басқа да мәселелермен қатар, хакер болғысы келетіндерге қандай тілдерді үйрену керектігін айтады. Ол үйренуге оңай болғандықтан, Python мен Java-дан бастауды ұсынады. Байсалды хакерге Unix-ті бұзу үшін C тілін, ал жүйелік әкімшілендіру мен cgi скрипттері үшін Perl тілін үйрену қажет болады. Ақырында, шынайы байсалды хакер Lisp тілін үйренуді қарастыруы керек:
Lisp тілін үйренуге тұрарлық себеп — оны ақыры түсінген кезде бастан өткеретін терең танымдық тәжірибеңіз; сол тәжірибе сізді өміріңіздің соңына дейін жақсырақ бағдарламашы етеді, тіпті Lisp-тің өзін көп қолданбасаңыз да.
Бұл латын тілін үйренуге қатысты жиі айтылатын дәлелге ұқсайды. Ол сізге жұмыс табуға көмектеспейді, бәлкім, классикалық филология профессоры болуды қоспағанда, бірақ ой-өрісіңізді кеңейтеді және өзіңіз қолданғыңыз келетін ағылшын сияқты тілдерде жақсырақ жазуға септігін тигізеді.
Бірақ бір сәт күте тұрыңыз. Бұл метафораны тым ұзаққа созуға болмайды. Латын тілі арқылы жұмыс таба алмауыңыздың себебі — онда ешкім сөйлемейді. Егер сіз латынша жазсаңыз, сізді ешкім түсінбейді. Ал Lisp — компьютерлік тіл, ал компьютерлер сіз, яғни бағдарламашы қай тілде айтсаңыз, сонда сөйлейді.
Егер Lisp, ол айтқандай, сізді жақсырақ бағдарламашы етсе, неге оны қолданбасқа? Егер суретшіге оны жақсырақ суретші ететін қылқалам ұсынылса, ол оны барлық туындыларында қолданғысы келер еді емес пе? Мен бұл жерде Эрик Реймондты келемеждейін деп отырған жоқпын. Тұтастай алғанда, оның кеңесі орынды. Оның Lisp туралы айтқаны — көпшілік қабылдаған ортақ түсінік. Бірақ бұл қалыптасқан түсінікте қайшылық бар: Lisp сізді жақсырақ бағдарламашы етеді, соған қарамастан сіз оны қолданбайсыз.
Неге? Өйткені бағдарламалау тілдері — бар болғаны құрал ғана. Егер Lisp шынымен де жақсырақ бағдарламалар жасауға көмектессе, оны қолдануыңыз керек. Ал егер олай болмаса, онда оның кімге қажеті бар?
Бұл жай ғана теориялық сұрақ емес. Бағдарламалық жасақтама — табиғи монополияларға бейім, өте бәсекелі бизнес. Бағдарламаны тезірек әрі сапалырақ жазатын компания, басқа шарттар тең болғанда, бәсекелестерін нарықтан ығыстырып шығарады. Стартап бастаған кезде мұны өте қатты сезінесіз. Стартаптар көбінесе «не бәрі, не ештеңе» қағидаты бойынша жұмыс істейді. Сіз не байисыз, не құр алақан қаласыз. Стартапта қате технология таңдасаңыз, бәсекелестеріңіз сізді талқандайды.
Роберт екеуміз де Lisp-ті жақсы білетінбіз және өз түйсігімізге сенбей, Lisp-тен бас тартуға ешқандай себеп көре алмадық. Біз басқалардың бәрі өз бағдарламаларын C++ немесе Perl тілінде жазып жатқанын білдік. Бірақ бұл ештеңені білдірмейтінін де түсіндік. Егер технологияны солай таңдайтын болсаңыз, сіз тек Windows қолданып отырар едіңіз. Технология таңдағанда басқалардың не істеп жатқанына мән бермей, тек қайсысы ең жақсы нәтиже беретінін ғана ескеру керек.
Бұл әсіресе стартаптарға қатысты. Үлкен компанияда басқа барлық үлкен компаниялар не істесе, соны істей аласыз. Бірақ стартап басқа барлық стартаптардың істегенін істей алмайды. Меніңше, стартаптарда жүргендердің өзі мұны толық түсіне бермейді.
Орташа үлкен компания жылына шамамен он пайызға өседі. Сондықтан үлкен компанияны басқарып, бәрін орташа үлкен компания қалай істесе, солай істесеңіз, орташа үлкен компания сияқты нәтижеге — яғни жылына шамамен он пайыз өсуге үміттене аласыз.
Әрине, стартапты басқарсаңыз да дәл солай болады. Егер бәрін орташа стартап сияқты істесеңіз, орташа нәтиже күтуіңіз керек. Бұл жердегі мәселе мынада: орташа нәтиже — бизнесіңіздің күйрейтінін білдіреді. Стартаптардың аман қалу деңгейі елу пайыздан әлдеқайда төмен. Сондықтан егер стартапты басқарып отырсаңыз, әдеттен тыс бірдеңе жасағаныңыз жөн. Әйтпесе тығырыққа тірелесіз.
1995 жылы біз бәсекелестеріміз түсінбеген, тіпті қазір де аз ғана адам түсінетін бір нәрсені білдік: тек өз серверлеріңізде ғана жұмыс істейтін бағдарламалық жасақтама жазғанда, кез келген тілді қолдана аласыз. Ал дербес компьютерге арналған бағдарлама жазғанда, қолданбаларды операциялық жүйе жазылған тілде жазуға деген күшті бейімділік болады. Он жыл бұрын қолданба жазу — C тілінде жазу дегенді білдіретін. Бірақ Web-негізді бағдарламалық жасақтамада, әсіресе тілдің де, операциялық жүйенің де бастапқы коды қолыңызда болғанда, қалаған тіліңізді қолдана аласыз.
Алайда бұл жаңа еркіндік — екі жүзді қылыш сияқты. Енді кез келген тілді қолдана алатындықтан, қайсысын таңдау керектігі туралы ойлануға тура келеді. Ештеңе өзгермегендей кейіп танытуға тырысатын компаниялар бәсекелестерінің олай ойламайтынын байқап қалу қаупіне тап болады.
Егер кез келген тілді қолдануға болатын болса, қайсысын таңдайсыз? Біз 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 Shopping-тің негізін құрайды. Мен Yahoo-дан 1999 жылы кеттім, сондықтан қазір оларда қанша қолданушы бар екенін нақты білмеймін, бірақ соңғы естігенімде шамамен 20 000 болған еді.
Блаб парадоксы
Lisp-тің несі соншалық керемет? Егер Lisp соншалықты жақсы болса, неге оны бәрі қолданбайды? Бұл риторикалық сұрақтар сияқты көрінгенімен, шын мәнінде олардың нақты жауаптары бар. Lisp-тің кереметтігі тек оның жанкүйерлеріне ғана көрінетін қандай да бір сиқырлы қасиетінде емес, оның қолжетімді тілдердің ішіндегі ең қуаттысы болуында. Ал бәрінің оны қолданбауының себебі — бағдарламалау тілдері тек технология ғана емес, сонымен бірге ойлау дағдысы болып табылады, ал одан баяу өзгеретін ештеңе жоқ. Әрине, бұл жауаптардың екеуі де түсіндіруді қажет етеді.
Мен таңғаларлық даулы мәлімдемеден бастайын: бағдарламалау тілдерінің қуаты әртүрлі болады.
Жоғары деңгейлі тілдердің машиналық тілден гөрі қуаттырақ екеніне ешкім дауласа қоймас. Бүгінде бағдарламашылардың көпшілігі әдетте машиналық тілде бағдарлама жазғыңыз келмейтінімен келіседі. Оның орнына сіз жоғары деңгейлі тілде жазып, компилятор оны сіз үшін машиналық тілге аударып беруі керек. Бұл идея қазір тіпті аппараттық деңгейде енгізілген: 1980 жылдардан бастап командалар жүйесі адам-бағдарламашыларға емес, компиляторларға арналып жасалатын болды.
Бүкіл бағдарламаны қолмен машиналық тілде жазу қателік екенін бәрі біледі. Бірақ мұнда жалпылама қағида бар екені сирегірек түсініледі: егер сізде бірнеше тілдің таңдауы болса, басқа шарттар тең болғанда, ең қуаттысынан басқа тілде бағдарлама жазу — қателік. [3]
Бұл ереженің көптеген ерекшеліктері бар. Егер белгілі бір тілде жазылған бағдарламамен өте тығыз жұмыс істеуі керек бағдарлама жазып жатсаңыз, жаңа бағдарламаны сол тілде жазған дұрыс болуы мүмкін. Егер тек сандарды өңдеу немесе биттік манипуляциялар сияқты өте қарапайым нәрсені орындайтын бағдарлама жазып жатсаңыз, онда абстракциясы төмендеу тілді қолданған дұрыс шығар, әсіресе ол сәл жылдамырақ болуы мүмкін болғандықтан. Ал егер қысқа, бір реттік бағдарлама жазып жатсаңыз, осы тапсырмаға арналған ең жақсы кітапханалық функциялары бар кез келген тілді қолданған дұрысырақ болар. Бірақ жалпы алғанда, қолданбалы бағдарламалық жасақтама үшін қол жеткізуге болатын ең қуатты (жеткілікті деңгейде тиімді) тілді қолданғыңыз келеді, ал басқа кез келген тілді қолдану — машиналық тілде бағдарлама жазумен бірдей, бәлкім, дәрежесі төмендеу болса да, тура сондай қателік.
Машиналық тілдің өте төменгі деңгейде екенін байқауға болады. Бірақ, кем дегенде белгілі бір әлеуметтік шарттылық ретінде, жоғары деңгейлі тілдердің барлығы жиі бірдей деп есептеледі. Олай емес. Техникалық тұрғыдан алғанда, «жоғары деңгейлі тіл» термині аса нақты ештеңені білдірмейді. Бір жағында машиналық тілдер, екінші жағында барлық жоғары деңгейлі тілдер тұрғандай айқын бөлу сызығы жоқ. Тілдер абстракцияның бір үздіксіз шкаласында [4] орналасқан: ең қуаттысынан бастап, өздері де қуаты жағынан әртүрлі болатын машиналық тілдерге дейін төмендейді.
Cobol тілін алайық. Cobol — машиналық тілге компиляцияланатыны мағынасында жоғары деңгейлі тіл. Бірақ біреу шындап Cobol-ды, айталық, Python-мен қуаты жағынан бірдей деп айта алар ма еді? Ол, бәлкім, Python-ға қарағанда машиналық тілге жақынырақ.
Немесе Perl 4 ше? Perl 4 пен Perl 5 арасында тілге лексикалық тұйықталулар (lexical closures) қосылды. Көптеген Perl хакерлері Perl 5-тің Perl 4-тен қуаттырақ екенімен келіседі. Бірақ мұны мойындағаннан кейін, сіз бір жоғары деңгейлі тілдің екіншісінен қуаттырақ болуы мүмкін екенін де мойындайсыз. Ал бұдан сөзсіз шығатын қорытынды: ерекше жағдайларды қоспағанда, сіз қол жеткізе алатын ең қуатты тілді қолдануыңыз керек.
Алайда бұл идея сирек өз мәресіне дейін жеткізіледі. Белгілі бір жастан кейін бағдарламашылар тілді өз еркімен сирек ауыстырады. Адамдар қандай тілге үйреніп қалса, соны «жеткілікті түрде жақсы» деп санайтын болады.
Бағдарламашылар өздерінің сүйікті тілдеріне өте қатты бауыр басады, ал мен ешкімнің көңіліне қаяу салғым келмейді, сондықтан бұл жайтты түсіндіру үшін Blub деп аталатын шартты тілді қолданамын. Blub абстракция шкаласының дәл ортасында орналасқан. Ол ең қуатты тіл емес, бірақ Cobol немесе машиналық тілге қарағанда қуаттырақ.
Шындығында, біздің қиялымыздағы Blub бағдарламашысы бұл екеуінің де біреуін қолданбас еді. Әрине, ол машиналық тілде бағдарлама жазбайды. Компиляторлар соған арналған. Ал Cobol-ға келетін болсақ, ол онымен қалай бірдеңе жасауға болатынын түсінбейді. Онда тіпті x те (сіз таңдаған Blub мүмкіндігі) жоқ.
Біздің қиялымыздағы Blub бағдарламашысы қуат шкаласынан төмен қараған сайын, оның төмен қарап тұрғанын біледі. Blub-тан төменірек тілдер анық әлсіздеу, өйткені оларда өзі үйренген кейбір мүмкіндіктер жетіспейді. Бірақ қиялымыздағы Blub бағдарламашысы басқа бағытқа, қуат шкаласынан жоғары қарағанда, ол жоғары қарап тұрғанын аңғармайды. Оның көретіні — тек біртүрлі тілдер ғана. Ол оларды Blub-пен шамамен тең қуатта деп санайды, тек үстіне осы бір артық былдыр-батпақ қосылған деп ойлайды. Blub оған әбден жеткілікті, өйткені ол Blub тілінде ойлайды.
Алайда қуат шкаласында жоғарырақ тұрған кез келген тілді қолданатын бағдарламашының көзқарасына ауысқан кезде, оның өз кезегінде Blub-қа жоғарыдан төмен қарайтынын көреміз. Blub-пен қалай бірдеңе жасауға болады? Онда тіпті y та жоқ қой.
Индукция бойынша, түрлі тілдердің арасындағы қуат айырмашылығын толық көре алатын жалғыз бағдарламашылар — ең қуаттысын түсінетіндер. (Эрик Реймондтың Lisp сізді жақсырақ бағдарламашы етеді деген сөзінің астарында осы жатқан болар.) Басқалардың пікіріне сенуге болмайды, өйткені Blub парадоксы бар: олар кез келген қолданып жүрген тіліне қанағаттанады, өйткені ол тіл олардың бағдарлама туралы қалай ойлайтынын анықтап отырады.
Мұны мен мектеп кезінде Basic тілінде бағдарлама жазған өз тәжірибемнен білемін. Ол тіл тіпті рекурсияны да қолдамайтын. Рекурсияны қолданбай бағдарлама жазуды елестету қиын, бірақ ол кезде мен оның жоқтығын сезген де жоқпын. Мен Basic тілінде ойладым. Және оның шебері болдым. Көргенімнің бәріне билік жүргізгендей едім.
Эрик Реймонд хакерлерге ұсынатын бес тіл қуат шкаласының әртүрлі нүктелерінде орналасқан. Олардың бір-біріне қатысты қай жерде тұрғаны — нәзік тақырып. Менің айтарым — меніңше, Lisp ең басында тұр. Және бұл тұжырымды дәлелдеу үшін мен басқа төрт тілге қарағанда өзіме жетіспейтін бір нәрсе туралы айтып берейін. Оларда макростарсыз қалай бірдеңе жасауға болады, деп ойлаймын мен. [5]
Көптеген тілдерде макрос деп аталатын нәрсе бар. Бірақ Lisp макростары — ерекше. Сенсеңіз де, сенбесеңіз де, олардың атқаратын ісі жақшалармен байланысты. Lisp-ті жасаушылар осы жақшалардың барлығын тілге жай ғана басқалардан ерекшелену үшін салған жоқ. Blub бағдарламашысына Lisp коды оғаш көрінеді. Бірақ бұл жақшалар белгілі бір себеппен қойылған. Олар — Lisp пен басқа тілдер арасындағы түбегейлі айырмашылықтың сыртқы көрінісі.
Lisp коды Lisp деректер нысандарынан тұрады. Және бұл бастапқы файлдарда таңбалар бар, ал жолдар тіл қолдайтын деректер түрлерінің бірі деген қарапайым мағынада емес. Lisp коды парсермен оқылғаннан кейін, сіз аралап өтуге болатын деректер құрылымдарынан тұрады.
Егер компиляторлардың қалай жұмыс істейтінін түсінсеңіз, онда шын мәнінде болып жатқан нәрсе — Lisp-тің біртүрлі синтаксиске ие болуында емес, Lisp-те мүлдем синтаксистің жоқтығында. Сіз басқа тілдерді талдау кезінде компилятордың ішінде жасалатын талдау ағаштарында (parse trees) бағдарлама жазасыз. Ал бұл талдау ағаштары бағдарламаларыңызға толықтай қолжетімді. Сіз оларды басқаратын бағдарламалар жаза аласыз. Lisp-те бұл бағдарламалар макростар деп аталады. Олар — бағдарлама жазатын бағдарламалар.
Бағдарлама жазатын бағдарламалар? Оны қашан істегіңіз келуі мүмкін? Егер Cobol тілінде ойласаңыз — өте сирек. Ал Lisp тілінде ойласаңыз — үнемі. Осы тұста қуатты макростың мысалын келтіріп, «міне! бұған не дейсіз?» десем өте ыңғайлы болар еді. Бірақ егер мен олай істесем, Lisp-ті білмейтін адамға ол жай былдыр сөз болып көрінер еді; бұл нені білдіретінін түсіну үшін білуіңіз керек барлық нәрсені түсіндіруге мұнда орын жетпейді. Ansi Common Lisp кітабында мен мәселені барынша жылдам өтуге тырыстым, соның өзінде макростарға 160-бетке жетпей келген жоқпын.
Бірақ мен көңілге қонатын бір дәлел келтіре аламын деп ойлаймын. Viaweb редакторының бастапқы коды шамамен 20-25% макростардан тұрды. Макростарды жазу кәдімгі Lisp функцияларына қарағанда қиынырақ және оларды қажет болмаса қолдану жаман стиль болып саналады. Демек, сол кодтағы әрбір макрос сол жерде болуы міндетті болғандықтан тұр. Бұл дегеніміз — осы бағдарламадағы кодтың кем дегенде 20-25%-ы басқа ешбір тілде оңайлықпен істей алмайтын нәрселерді жасап жатыр деген сөз. Blub бағдарламашысы менің Lisp-тің жұмбақ қуаты туралы айтқандарыма қаншалықты күмәнмен қараса да, бұл оның қызығушылығын оятуы тиіс. Біз бұл кодты өз көңілімізді көтеру үшін жазған жоқпыз. Біз өзіміз бен бәсекелестеріміздің арасына техникалық кедергілер қою үшін بار күшімізбен бағдарламалаған шағын стартап едік.
Күдікшіл адам бұл жерде қандай да бір байланыс бар ма деп ойлана бастауы мүмкін. Біздің кодтың үлкен бөлігі басқа тілдерде жасау өте қиын нәрселерді істеді. Нәтижесінде шыққан бағдарламалық жасақтама бәсекелестеріміздің бағдарламалары жасай алмайтын нәрселерді жасады. Мүмкін, мұнда қандай да бір байланыс бар шығар. Мен сізге осы ойдың жетегіне еруді ұсынамын. Балдағына сүйеніп әрең келе жатқан әлгі қарт адамның көрінгенінен гөрі үлкен құпиясы бар болуы мүмкін.
Стартаптарға арналған айкидо
Бірақ мен ешкімді (25-тен асқан) барып Lisp-ті үйренуге көндіремін деп күтпеймін. Бұл мақаланың мақсаты — біреудің пікірін өзгерту емес, Lisp-ті қолдануға қызығушылық танытып жүрген адамдарды — яғни Lisp-тің қуатты тіл екенін білетін, бірақ оның кеңінен қолданылмайтынына алаңдайтын адамдарды сабырға шақыру. Бәсекелестік жағдайында бұл — артықшылық. Lisp-тің қуаты бәсекелестеріңіздің оны түсінбейтіндігімен еселене түседі.
Егер сіз стартапта Lisp қолдануды ойласаңыз, оның кең таралмағанына алаңдамауыңыз керек. Оның осылай қала беруіне үміттенуіңіз керек. Және оның солай қалуы әбден мүмкін. Бағдарламалау тілдерінің табиғаты сондай, олар адамдардың көпшілігін қазір не қолданып жүрсе, соған қанағаттандырады. Компьютерлік құрылғылар адамның жеке әдеттеріне қарағанда әлдеқайда жылдам өзгеретіні соншалық, бағдарламалау тәжірибесі процессордан әдетте он-жиырма жылға артта қалып қояды. MIT сияқты жерлерде 1960 жылдардың басында жоғары деңгейлі тілдерде бағдарлама жазса да, көптеген компаниялар 1980 жылдарға дейін машиналық тілде код жазуды жалғастырды. Көптеген адамдар процессор, үйіне қайтуға асыққан бармен сияқты, risc командалар жүйесіне ауысу арқылы оларды ақыры қуып шыққанша машиналық тілде жазуды жалғастырды деп бәс тіге аламын.
Әдетте технология тез өзгереді. Бірақ бағдарламалау тілдері басқаша: бағдарламалау тілдері жай ғана технология емес, сонымен бірге бағдарламашылардың ойлау құралы. Олар — жартылай технология және жартылай дін.[6] Сондықтан медианалық тіл, яғни орташа бағдарламашы қолданатын кез келген тіл айсберг сияқты баяу қозғалады. Шамамен 1960 жылы Lisp енгізген қоқыс жинау (Garbage collection) қазір кеңінен жақсы нәрсе деп саналады. Дәл солай, орындалу кезіндегі типтеу (runtime typing) де танымал болып келеді. 1970 жылдардың басында Lisp енгізген лексикалық тұйықталулар қазір ғана радар экранында әрең көрініп жатыр. Ал 1960 жылдардың ортасында Lisp енгізген макростар әлі күнге дейін terra incognita (беймәлім жер) болып қалуда.
Әрине, медианалық тілдің орасан зор инерциясы бар. Мен сізге бұл қуатты күшпен күресуді ұсынып отырған жоқпын. Менің ұсынып отырғаным — мүлдем керісінше: айкидо шебері сияқты, оны қарсыластарыңызға қарсы қолдануға болады.
Егер сіз үлкен компанияда жұмыс істесеңіз, бұл оңай болмауы мүмкін. Егер тік шашты бастығыңыз газеттен басқа бір тілдің, жиырма жыл бұрынғы Ada сияқты, әлемді жаулап алуға дайын тұрғанын жаңа ғана оқып алса, оны Lisp-те жоба жасауға көндіру өте қиын болады. Бірақ егер әлі тік шашты бастықтары жоқ стартапта жұмыс істесеңіз, сіз, біз сияқты, Блаб парадоксын өз пайдаңызға айналдыра аласыз: медианалық тілге мызғымастай жабысып қалған бәсекелестеріңіз ешқашан жете алмайтын технологияны қолдана аласыз.
Егер сіз стартапта жұмыс істеп қалсаңыз, бәсекелестерді бағалауға арналған ыңғайлы кеңес: олардың бос жұмыс орындары туралы хабарландыруларын оқыңыз. Олардың сайтындағы басқа барлық нәрсе фотобанк суреттері немесе соған пара-пар мәтін болуы мүмкін, бірақ бос орындар хабарландыруында не қажет екенін нақты көрсетуі керек, әйтпесе олар қате үміткерлерді тартады.
Viaweb-те жұмыс істеген жылдары мен жұмыс орындары туралы өте көп сипаттамаларды оқыдым. Әр ай сайын дерлік жаңа бәсекелес саңырауқұлақтай қаптап шығып жатқандай көрінетін. Оларда онлайн-демо бар-жоғын тексергеннен кейін жасайтын бірінші ісім — олардың бос жұмыс орындарына қарау болатын. Бірнеше жылдан кейін мен қай компаниялардан қауіптену керектігін және қайсысынан қорықпау керектігін ажырата алатын болдым. Жұмыс сипаттамасында IT элементі неғұрлым көп болса, компания соғұрлым қауіпсіз болды. Ең қауіпсіз түрі — Oracle тәжірибесін талап ететіндер еді. Олар туралы ешқашан алаңдамауға болатын. Сондай-ақ C++ немесе Java әзірлеушілері керек деп жазса да қауіпсіз едіңіз. Егер олар Perl немесе Python бағдарламашыларын іздесе, бұл сәл қорқынышты болар еді — бұл кем дегенде техникалық жағын нағыз хакерлер басқаратын компанияға ұқсай бастайды. Ал егер мен Lisp хакерлерін іздеген хабарландыруды көрсем, шындап қатты алаңдар едім.
Ескертпелер
[1] Алғашында Viaweb екі бөліктен тұрды: адамдар сайттарын жасау үшін пайдаланатын Lisp тілінде жазылған редактор және тапсырыстарды өңдейтін C тілінде жазылған тапсырыс беру жүйесі. Алғашқы нұсқасы негізінен Lisp болды, өйткені тапсырыс беру жүйесі шағын еді. Кейінірек біз тағы екі модуль қостық: C тілінде жазылған кескіндер генераторы және негізінен Perl тілінде жазылған бэк-офис менеджері.
2003 жылдың қаңтарында Yahoo редактордың C++ және Perl тілдерінде жазылған жаңа нұсқасын шығарды. Дегенмен, бұл бағдарламаны енді Lisp-те жазылмаған деп айту қиын, өйткені бұл бағдарламаны C++ тіліне көшіру үшін оларға Lisp интерпретаторын тура мағынасында жазып шығуға тура келді: беттерді жасайтын барлық үлгілердің бастапқы код файлдары, менің білуімше, әлі күнге дейін Lisp коды болып табылады. (Гринспеннің оныншы ережесін қараңыз.)
[2] Роберт Моррис маған құпия сақтаудың қажеті жоқ еді дейді, өйткені біздің бәсекелестеріміз Lisp-ті қолданып жатқанымызды білген күннің өзінде де, оның себебін түсінбес еді: «Егер олар соншалықты ақылды болса, әлдеқашан Lisp-те бағдарламалап жүрер еді».
[3] Барлық тілдер Тьюринг баламалылығы тұрғысынан бірдей қуатты, бірақ бағдарламашыларды алаңдататын мағына бұл емес. (Ешкім Тьюринг машинасын бағдарламалағысы келмейді.) Бағдарламашыларды қызықтыратын қуаттылық түрін ресми түрде анықтау мүмкін болмауы мүмкін, бірақ оны түсіндірудің бір жолы — бұл қуаттылығы төмен тілде неғұрлым қуатты тіл үшін интерпретатор жазу арқылы ғана қол жеткізуге болатын мүмкіндіктерді білдіреді деп айту. Егер А тілінде жолдардан бос орындарды жоюға арналған оператор болып, ал В тілінде болмаса, бұл А тілін әлдеқайда қуатты етпейтін шығар, өйткені В тілінде мұны істейтін қосалқы бағдарлама жаза аласыз. Бірақ егер А тілі, мысалы, рекурсияны қолдаса, ал В тілі қолдамаса, бұл кітапхана функцияларын жазу арқылы шеше алатын нәрсе болуы екіталай.
[4] Нердтерге ескертпе: немесе, бәлкім, жоғары қарай тарылатын тор (lattice); бұл жерде маңыздысы пішін емес, тым болмағанда жартылай реттіліктің бар екендігі идеясы.
[5] Макростарды жеке мүмкіндік ретінде қарастыру сәл жаңсақ түсінік тудырады. Іс жүзінде олардың пайдалылығы лексикалық тұйықталулар (lexical closures) және rest параметрлері сияқты Lisp-тің басқа мүмкіндіктерімен айтарлықтай арта түседі.
[6] Нәтижесінде, бағдарламалау тілдерін салыстыру не діни соғыстарға, не соншалықты бейтарап болып келетіндіктен шын мәнінде антропологиялық еңбекке айналған студенттерге арналған оқулықтарға ұқсайды. Тыныштығын бағалайтын немесе тұрақты профессорлық лауазым (tenure) алғысы келетін адамдар бұл тақырыптан аулақ жүреді. Бірақ бұл мәселе жартылай ғана діни мәселе; ол жерде зерттеуге тұрарлық нәрсе бар, әсіресе егер сіз жаңа тілдерді жобалағыңыз келсе.