(Бұл эссе PyCon 2003 конференциясындағы негізгі баяндамаға негізделген.)
Жүз жылдан кейін өмірдің қандай болатынын болжау қиын. Біз тек санаулы нәрселерді ғана сеніммен айта аламыз. Барлығы ұшатын көліктерді айдайтынын, жүздеген қабатты ғимараттар салуға рұқсат беру үшін аймақтарға бөлу ережелері жеңілдетілетінін, көп жағдайда қараңғы болатынын және барлық әйелдер жекпе-жек өнеріне машықтанатынын білеміз. Мұнда мен осы көріністің бір ғана егжей-тегжейіне назар аударғым келеді. Сол ұшатын көліктерді басқаратын бағдарламалық жасақтаманы жазу үшін олар қандай бағдарламалау тілін қолданады?
Бұл туралы ойлануға тұрарлық, өйткені біз ол тілдерді нақты қолданатын болғандықтан емес, егер жолымыз болса, дәл қазіргі нүктеден сол нүктеге баратын жолдағы тілдерді қолданатын боламыз.
Менің ойымша, биологиялық түрлер сияқты тілдер де жан-жаққа тұйық бұтақтары кететін эволюциялық ағаштарды құрайды. Мұның орын алып жатқанын қазірдің өзінде көруге болады. Cobol бір кездері қаншалықты танымал болғанына қарамастан, оның ешқандай интеллектуалды ұрпағы жоқ сияқты. Бұл — эволюциялық тұйық, неандертальдық тіл.
Мен Java үшін де осындай тағдырды болжаймын. Адамдар кейде маған: «Java сәтті тіл болмайды деп қалай айта аласыз? Ол қазірдің өзінде сәтті тіл ғой», — деп хат жазады. Егер сіз сәттілікті ол туралы кітаптар алатын сөре кеңістігімен (әсіресе оған арналған жеке кітаптармен) немесе жұмысқа орналасу үшін оны үйренуім керек деп есептейтін студенттер санымен өлшесеңіз, мен мұнымен келісемін. Мен Java сәтті тіл болмайды дегенде, нақтырақ бір нәрсені айтамын: Java да Cobol сияқты эволюциялық тұйыққа айналады.
Бұл тек болжам ғана. Мен қателесуім мүмкін. Менің мақсатым — Java-ны жамандау емес, эволюциялық ағаштар мәселесін көтеріп, адамдарды «Х тілі бұл ағаштың қай жерінде?» деп ойландыру. Бұл сұрақты қоюдың себебі жүз жылдан кейін аруағымыз: «Мен сендерге айтқанмын», — деп айтуы үшін ғана емес. Негізгі бұтақтарға жақын болу — қазіргі уақытта бағдарламалауға ыңғайлы тілдерді табудың пайдалы эвристикасы.
Кез келген уақытта сіз эволюциялық ағаштың негізгі бұтақтарында болсаңыз, өзіңізді ең бақытты сезінетін шығарсыз. Неандертальдар көп болған кездің өзінде олардың бірі болу жағымсыз болған шығар. Кроманьондар үнемі келіп, сізді сабап, тамағыңызды тартып алып отырар еді.
Тілдердің жүз жылдан кейін қандай болатынын білгім келетінінің себебі — дәл қазір ағаштың қай бұтағына бәс тігу керектігін білу.
Тілдердің эволюциясы түрлердің эволюциясынан ерекшеленеді, өйткені олардың бұтақтары тоғыса алады. Мысалы, Fortran бұтағы Algol-дың ұрпақтарымен бірігіп жатқан сияқты. Теориялық тұрғыдан бұл түрлер үшін де мүмкін, бірақ жасушадан үлкен ешбір ағзада орын алған болуы екіталай.
Тілдерде тоғысудың ықтималдығы жоғарырақ, себебі мүмкіндіктер кеңістігі кішірек және мутациялар кездейсоқ емес. Тіл құрастырушылары басқа тілдердегі идеяларды саналы түрде енгізеді.
Тіл құрастырушылар үшін бағдарламалау тілдерінің эволюциясы қайда апаратынын ойлану өте пайдалы, өйткені олар бағытты соған сәйкес түзей алады. Мұндай жағдайда «негізгі бұтақта қалу» тек жақсы тілді таңдау тәсілінен де асып түседі. Бұл тіл дизайнына қатысты дұрыс шешім қабылдаудың эвристикасына айналады.
Кез келген бағдарламалау тілін екі бөлікке бөлуге болады: аксиомалар рөлін атқаратын іргелі операторлар жиынтығы және теориялық тұрғыдан осы іргелі операторлар арқылы жазылуы мүмкін тілдің қалған бөлігі.
Менің ойымша, іргелі операторлар — тілдің ұзақ мерзімді өмір сүруіндегі ең маңызды фактор. Қалғанын өзгертуге болады. Бұл үй сатып алғанда ең алдымен оның орналасқан жерін ескеру керек деген ереже сияқты. Қалғанның бәрін кейін жөндеуге болады, бірақ орналасқан жерін түзей алмайсыз.
Аксиомалардың жақсы таңдалуы ғана емес, олардың аз болуы да маңызды деп ойлаймын. Математиктер әрқашан аксиомалар туралы осылай ойлаған — неғұрлым аз болса, соғұрлым жақсы — және олардың бұл пікірі орынды.
Ең болмағанда, артық аксиомалар бар-жоғын көру үшін тілдің өзегіне мұқият қарау — пайдалы жаттығу. Менің салақтықтағы ұзақ мансабым көрсеткендей, қоқыс жаңа қоқысты тудырады, және мен мұны төсек астында немесе бөлме бұрыштарында ғана емес, бағдарламалық жасақтамада да көрдім.
Менің ішкі түйсігім бойынша, эволюциялық ағаштың негізгі бұтақтары ең шағын әрі ең таза өзегі бар тілдер арқылы өтеді. Тілдің неғұрлым көп бөлігін оның өзінде жаза алсаңыз, соғұрлым жақсы.
Әрине, бағдарламалау тілдері жүз жылдан кейін қандай болады деп сұраудың өзінде мен үлкен болжам жасап отырмын. Жүз жылдан кейін біз тіпті бағдарлама жазамыз ба? Біз компьютерлерге не істеу керектігін жай ғана айта салмаймыз ба?
Әзірге бұл салада айтарлықтай ілгерілеушілік болған жоқ. Менің ойымша, жүз жылдан кейін де адамдар компьютерлерге не істеу керектігін біз бағдарлама деп танитын нәрселер арқылы айтатын болады. Біз қазір бағдарлама жазу арқылы шешетін, бірақ жүз жылдан кейін оны шешу үшін бағдарлама жазудың қажеті болмайтын міндеттер болуы мүмкін, бірақ біз бүгінде жасайтын бағдарламалау түрі әлі де көп мөлшерде қалады деп ойлаймын.
Кез келген технологияның жүз жылдан кейін қалай көрінетінін біреу болжай алады деп ойлау тәкаппарлық сияқты көрінуі мүмкін. Бірақ біздің артымызда елу жылға жуық тарих бар екенін есте сақтаңыз. Соңғы елу жылда тілдердің қаншалықты баяу дамығанын ескерсек, жүз жыл алға қарау — ақылға қонымды идея.
Тілдер баяу дамиды, өйткені олар шын мәнінде технология емес. Тілдер — бұл нотация. Бағдарлама — бұл компьютер сіз үшін шешуін қалайтын мәселенің ресми сипаттамасы. Сондықтан бағдарламалау тілдерінің эволюция қарқыны, айталық, көлік немесе байланыс саласына қарағанда, математикалық нотацияның эволюция қарқынына көбірек ұқсайды. Математикалық нотация дамиды, бірақ технологиядағыдай алып секірістермен емес.
Жүз жылдан кейін компьютерлер неден жасалса да, олардың қазіргіден әлдеқайда жылдам болатынын болжау сенімді болып көрінеді. Егер Мур заңы өз жұмысын жалғастыра берсе, олар 74 квинтиллион (73 786 976 294 838 206 464) есе жылдам болады. Мұны елестету өте қиын. Және шынында да, жылдамдық саласындағы ең ықтимал болжам — Мур заңының жұмысын тоқтатуы болуы мүмкін. Әр он сегіз ай сайын екі есеге артуы тиіс кез келген нәрсе түбінде қандай да бір іргелі шектеуге тап болуы мүмкін. Бірақ компьютерлердің әлдеқайда жылдам болатынына сену маған қиын емес. Олар тіпті мардымсыз бір миллион есе жылдам болған күннің өзінде, бұл бағдарламалау тілдерінің негізгі ережелерін айтарлықтай өзгертуі керек. Сонымен қатар, қазір баяу тілдер деп саналатын, яғни онша тиімді код бермейтін тілдерге көбірек орын болады.
Дегенмен кейбір қолданбалар әлі де жылдамдықты талап ететін болады. Біз компьютерлер арқылы шешкіміз келетін кейбір мәселелер компьютерлердің өздері арқылы жасалады; мысалы, бейне кескіндерді өңдеу жылдамдығы басқа компьютердің оларды қандай жылдамдықпен жасай алатынына байланысты. Сондай-ақ есептеу циклдарын шексіз жұту мүмкіндігі бар тағы бір есептер класы бар: кескінді рендерингтеу, криптография, симуляциялар.
Егер кейбір қолданбалар барған сайын тиімсіз бола алса, ал басқалары жабдық бере алатын барлық жылдамдықты талап етуді жалғастырса, жылдамырақ компьютерлер тілдердің тиімділіктің одан да кең ауқымын қамтуы керек екенін білдіреді. Біз мұның орын алып жатқанын қазірдің өзінде көріп отырмыз. Кейбір танымал жаңа тілдердің қазіргі жүзеге асырылуы алдыңғы онжылдықтардың стандарттарымен салыстырғанда таңқаларлықтай ысырапшыл болып келеді.
Бұл тек бағдарламалау тілдерінде ғана болатын нәрсе емес. Бұл — жалпы тарихи үрдіс. Технологиялар жақсарған сайын, әрбір ұрпақ алдыңғы ұрпақ ысырапшылдық деп санаған нәрселерді жасай алады. Осыдан отыз жыл бұрынғы адамдар біздің қалааралық телефон қоңырауларын қаншалықты еркін шалатынымызға таңғалар еді. Жүз жыл бұрынғы адамдар сәлемдеменің бір күні Бостоннан Нью-Йоркке Мемфис арқылы баратынына одан да қатты таңғалар еді.
Алдағы жүз жылда жылдамырақ жабдық бізге беретін сол қосымша есептеу циклдарының барлығына не болатынын мен қазір-ақ айтып бере аламын. Олардың барлығы дерлік босқа жұмсалады.
Мен компьютердің қуаты тапшы кезде бағдарламалауды үйрендім. Basic бағдарламаларым 4K TRS-80 жадына сыюы үшін олардағы барлық бос орындарды алып тастағаным есімде. Бір нәрсені қайта-қайта жасай отырып, есептеу циклдарын босқа құртатын осы керемет тиімсіз бағдарламалық жасақтама туралы ой маған жиіркенішті көрінеді. Бірақ менің бұл түйсігім қате деп ойлаймын. Мен кедей болып өскен, тіпті дәрігерге бару сияқты маңызды нәрсеге де ақша жұмсауға дәті бармайтын адам сияқтымын.
Ысыраптың кейбір түрлері шынымен де жиіркенішті. Мысалы, жол талғамайтын көліктер (SUV) ешқашан таусылмайтын және ластанбайтын отынмен жүрсе де, жиіркенішті болып қала берер еді. Олар жиіркенішті, өйткені олар жиіркенішті мәселенің шешімі болып табылады. (Минивэндерді қалай еркекке тән етіп көрсетуге болады). Бірақ ысыраптың бәрі бірдей жаман емес. Енді оны қолдайтын инфрақұрылымымыз болғандықтан, қалааралық қоңыраулардың минуттарын санау ұсақ-түйек болып көріне бастайды. Егер ресурстарыңыз болса, екінші адамның қайда екеніне қарамастан, барлық телефон қоңырауларын бірдей нәрсе ретінде қарастыру әлдеқайда талғампаз.
Жақсы ысырап бар және жаман ысырап бар. Мені жақсы ысырап қызықтырады — көбірек жұмсау арқылы қарапайым дизайнға қол жеткізуге болатын түрі. Біз жаңа, жылдамырақ жабдықтан алатын есептеу циклдарын босқа жұмсау мүмкіндіктерін қалай пайдаланамыз?
Біздің әлсіз компьютерлерімізбен жылдамдыққа деген құштарлық бойымызға соншалықты терең сіңіп кеткен, оны жеңу үшін саналы күш-жігер қажет болады. Тіл дизайнында біз ыңғайлылықты шамалы болса да арттыру үшін тиімділікті құрбан ете алатын жағдайларды саналы түрде іздеуіміз керек.
Көптеген деректер құрылымдары жылдамдық үшін ғана бар. Мысалы, бүгінгі күні көптеген тілдерде жолдар (strings) да, тізімдер (lists) де бар. Семантикалық тұрғыдан жолдар дегеніміз — элементтері таңбалар болып табылатын тізімдердің ішкі жиыны. Ендеше, сізге неліктен бөлек деректер түрі қажет? Шын мәнінде, қажет емес. Жолдар тек тиімділік үшін ғана бар. Бірақ бағдарламаларды жылдамырақ орындау үшін жасалған амалдармен (hacks) тілдің семантикасын былғау — дәрменсіздік. Тілде жолдардың болуы мезгілсіз оңтайландырудың бір мысалы сияқты.
Егер біз тілдің өзегін аксиомалар жиынтығы деп қарастырсақ, тек тиімділік үшін ғана ешқандай өрнектеу қуатын қоспайтын қосымша аксиомалардың болуы, сөзсіз, дөрекілік болып табылады. Тиімділік маңызды, бірақ оған қол жеткізудің дұрыс жолы бұл емес деп ойлаймын.
Бұл мәселені шешудің дұрыс жолы — бағдарламаның мәнін оны жүзеге асыру егжей-тегжейлерінен бөлу. Тізімдерді де, жолдарды да қатар ұстаудың орнына, қажет болған жағдайда компиляторға жолдарды үздіксіз байттар ретінде орналастыруға мүмкіндік беретін оңтайландыру кеңестерін беру жолы бар тек тізімдерді ғана қалдыру керек.
Бағдарламаның көп бөлігінде жылдамдық маңызды емес болғандықтан, әдетте сізге мұндай микроменеджментпен айналысудың қажеті болмайды. Компьютерлер жылдамдаған сайын бұл барған сайын айқынырақ болады.
Жүзеге асыру туралы азырақ айту бағдарламаларды неғұрлым икемді етуі керек. Бағдарлама жазылып жатқан кезде спецификациялар өзгереді, және бұл сөзсіз ғана емес, сонымен бірге құптарлық жайт.
«Эссе» сөзі француздың «essayer» деген етістігінен шыққан, ол «байқап көру» дегенді білдіреді. Бастапқы мағынасындағы эссе — бір нәрсені түсінуге тырысу үшін жазатын дүниеңіз. Бұл бағдарламалық жасақтамада да болады. Менің ойымша, кейбір ең жақсы бағдарламалар эссе сияқты болды, яғни авторлар бастаған кезде нені жазуға тырысып жатқанын нақты білмеген.
Lisp хакерлері деректер құрылымдарымен икемді болудың құндылығын біледі. Біз бағдарламаның бірінші нұсқасын бәрін тізімдер арқылы жасайтындай етіп жазуға бейімбіз. Бұл бастапқы нұсқалар соншалықты таңқаларлықтай тиімсіз болуы мүмкін, сондықтан олардың не істеп жатқаны туралы ойламау үшін саналы күш-жігер қажет, дәл мен үшін стейк жеу оның қайдан келгенін ойламау үшін саналы күш-жігерді қажет ететіні сияқты.
Жүз жылдан кейінгі бағдарламашылар ең алдымен бағдарламаның керемет тиімсіз 1-нұсқасын мүмкіндігінше аз күш жұмсап тез жинай алатын тілді іздейтін болады. Кем дегенде, біз мұны қазіргі терминдермен осылай сипаттар едік. Олар болса бағдарламалауға оңай тілді қалайтындарын айтады.
Тиімсіз бағдарламалық жасақтама жиіркенішті емес. Бағдарламашыларды қажетсіз жұмыс істеуге мәжбүр ететін тіл жиіркенішті. Машина уақытын босқа жұмсау емес, бағдарламашының уақытын босқа өткізу — нағыз тиімсіздік. Компьютерлер жылдамдаған сайын бұл одан да анық бола түседі.
Менің ойымша, жолдардан бас тарту — біз қазірдің өзінде ойлана алатын мәселе. Біз мұны Arc тілінде жасадық және бұл ұтыс болған сияқты; жүйелі өрнектер ретінде сипаттау қиын болатын кейбір операцияларды рекурсивті функциялар ретінде оңай сипаттауға болады.
Деректер құрылымдарын осылайша жеңілдету қаншалықты алысқа барады? Мен тіпті өзімді де таңғалдыратын мүмкіндіктерді ойлай аламын, ал менің көзқарасым саналы түрде кеңейтілген. Мысалы, біз массивтерден арыламыз ба? Өйткені, олар — кілттері бүтін сандар векторлары болып табылатын хэш-кестелердің ішкі жиыны ғана. Біз хэш-кестелердің өзін тізімдермен алмастырамыз ба?
Бұдан да таңқаларлық болашақ бар. Мысалы, Маккарти 1960 жылы сипаттаған Lisp-те сандар болмаған. Логикалық тұрғыдан алғанда, сізге сандар туралы бөлек түсініктің қажеті жоқ, өйткені оларды тізім ретінде көрсетуге болады: n бүтін санын n элементтен тұратын тізім ретінде ұсынуға болады. Математиканы осылай жасауға болады. Бұл жай ғана төзгісіз тиімсіз.
Іс жүзінде сандарды тізім ретінде енгізуді ешкім ұсынған жоқ. Шындығында, Маккартидің 1960 жылғы мақаласы сол кезде мүлде жүзеге асыруға арналмаған еді. Бұл теориялық жаттығу, Тьюринг машинасына неғұрлым талғампаз балама жасау әрекеті болатын. Біреу күтпеген жерден осы мақаланы алып, оны жұмыс істейтін Lisp интерпретаторына айналдырғанда, сандар тізім ретінде емес, кез келген басқа тілдегідей екілік жүйеде көрсетілді.
Бағдарламалау тілі сандардан негізгі деректер түрі ретінде бас тарта алатындай деңгейге жете ала ма? Мен бұл сұрақты байыпты сауал ретінде емес, болашақпен тәуекел ойынын ойнау тәсілі ретінде қойып отырмын. Бұл тоқтатуға келмейтін күштің қозғалмайтын нысанмен кездесуі сияқты гипотетикалық жағдайға ұқсайды — бұл жерде елестету мүмкін емес тиімсіз жүзеге асыру елестету мүмкін емес орасан зор ресурстармен кездеседі. Неге болмасқа? Болашақ өте ұзақ. Егер негізгі тілдегі аксиомалар санын азайту үшін жасай алатын бірдеңе болса, t шексіздікке ұмтылған сайын дәл осы жаққа бәс тігу дұрыс сияқты көрінеді. Егер бұл идея жүз жылдан кейін әлі де шыдамсыз болып көрінсе, бәлкім, мың жылдан кейін олай болмас.
Түсінікті болу үшін айта кетейін, мен барлық сандық есептеулер нақты тізімдер арқылы жүзеге асырылады деп ұсынып отырған жоқпын. Мен тілдің өзегі, оны жүзеге асыруға қатысты кез келген қосымша белгілерден бұрын, осылай анықталсын деп ұсынамын. Іс жүзінде белгілі бір көлемде математикалық амалдарды орындағысы келетін кез келген бағдарлама сандарды екілік жүйеде көрсететін шығар, бірақ бұл негізгі тіл семантикасының бір бөлігі емес, оңтайландыру ғана болады.
Есептеу циклдарын босқа жұмсаудың тағы бір жолы — қолданба мен жабдық арасында бағдарламалық жасақтаманың көптеген қабаттарын ұстау. Бұл да қазірдің өзінде болып жатқан үрдіс: көптеген соңғы тілдер байт-кодқа компиляцияланады. Билл Вудс бірде маған тәжірибелік ереже ретінде интерпретацияның әрбір қабаты жылдамдықты 10 есе азайтатынын айтқан еді. Бұл қосымша шығын сізге икемділік береді.
Arc-тың ең бірінші нұсқасы осындай көпдеңгейлі баяулықтың тиісті артықшылықтары бар төтенше мысалы болды. Бұл Common Lisp үстіне жазылған, Маккартидің бастапқы Lisp мақаласында анықталған eval функциясына белгілі бір туыстық ұқсастығы бар классикалық «метациклдік» интерпретатор еді. Барлық нәрсе бірнеше жүз жол кодтан ғана тұрды, сондықтан оны түсіну және өзгерту өте оңай болды. Біз қолданған Common Lisp, яғни CLisp, өзі байт-код интерпретаторының үстінде жұмыс істейді. Осылайша бізде екі деңгейлі интерпретация болды, олардың біреуі (жоғарғысы) таңқаларлықтай тиімсіз еді, соған қарамастан тілді қолдануға болатын еді. Зорға қолдануға болатын еді, мойындаймын, бірақ қолдануға келетін.
Бағдарламалық жасақтаманы бірнеше қабат ретінде жазу — тіпті қолданбалардың өз ішінде де күшті әдіс. «Төменнен жоғарыға» бағдарламалау бағдарламаны қабаттар тізбегі ретінде жазуды білдіреді, олардың әрқайсысы жоғарыдағысы үшін тіл ретінде қызмет етеді. Бұл тәсіл кішірек, икемді бағдарламалар жасауға бейім. Бұл сонымен қатар басты арман болған қайта пайдалану мүмкіндігіне апаратын ең жақсы жол. Тіл, анықтамасы бойынша, қайта пайдалануға жарамды. Сіз өз қолданбаңыздың неғұрлым көп бөлігін сол типтегі қолданбаларды жазуға арналған тілге қарай ысыра алсаңыз, бағдарламалық жасақтамаңыздың соғұрлым көп бөлігі қайта пайдалануға жарамды болады.
Қайта пайдалану мүмкіндігі идеясы 1980 жылдары әйтеуір объектіге бағытталған бағдарламалауға жабысып қалды, және оған қарсы қаншама дәлелдер болса да, бұл ұғымнан арылу мүмкін болмай тұрған сияқты. Бірақ кейбір объектіге бағытталған бағдарламалар қайта пайдалануға жарамды болғанымен, оларды қайта пайдалануға жарамды ететін нәрсе — олардың объектіге бағытталғандығы емес, «төменнен жоғарыға» құрылымы. Кітапханаларды қарастырыңыз: олар объектіге бағытталған стильде жазылған ба, жоқ па, бәрібір қайта пайдалануға жарамды, өйткені олар — тіл.
Айтпақшы, мен объектіге бағытталған бағдарламалау жойылады деп болжамаймын. Менің ойымша, ол белгілі бір мамандандырылған салаларды қоспағанда, жақсы бағдарламашыларға көп нәрсе ұсына алмайтынына қарамастан, үлкен ұйымдар үшін өте тартымды. Объектіге бағытталған бағдарламалау шатасқан «спагетти» кодты жазудың тұрақты әдісін ұсынады. Ол бағдарламаларды патчтар тізбегі ретінде өсіруге мүмкіндік береді. Ірі ұйымдар әрқашан бағдарламалық жасақтаманы осылай жасауға бейім, және бұл бүгінгідей жүз жылдан кейін де орын алады деп күтемін.
Болашақ туралы айтып жатқандықтан, параллель есептеулер туралы да айтқанымыз жөн, өйткені бұл идея дәл сол жерде өмір сүретін сияқты. Яғни, қай уақытта айтсаңыз да, параллель есептеулер — әрқашан болашақта болатын нәрсе сияқты көрінеді.
Болашақ оған жете ала ма екен? Адамдар параллель есептеулер туралы кем дегенде 20 жыл бойы таяу арада келетін нәрсе ретінде айтып келеді, бірақ ол әзірге бағдарламалау тәжірибесіне онша әсер еткен жоқ. Әлде әсер етті ме? Чип құрастырушылар қазірдің өзінде бұл туралы ойлануға мәжбүр, және көп процессорлы компьютерлерде жүйелік бағдарламалық жасақтама жазуға тырысатын адамдар да ойлануы керек.
Негізгі сұрақ: параллелизм абстракция баспалдағымен қаншалықты жоғары көтеріледі? Жүз жылдан кейін ол тіпті қолданбалы бағдарламашыларға да әсер ете ме? Әлде ол компилятор жазушылар ойланатын, бірақ қолданбалардың бастапқы кодында әдетте көрінбейтін нәрсе бола ма?
Ықтимал болып көрінетін бір нәрсе — параллелизмнің көптеген мүмкіндіктері босқа кетеді. Бұл бізге берілетін қосымша компьютерлік қуаттың көп бөлігі босқа кетеді деген менің жалпы болжамымның жеке бір жағдайы. Менің ойымша, негізгі жабдықтың орасан зор жылдамдығы сияқты, параллелизм де сіз оны анық сұраған кезде қолжетімді болатын, бірақ әдетте пайдаланылмайтын нәрсе болады. Бұл жүз жылдан кейін бізде болатын параллелизм түрі, арнайы қолданбаларды қоспағанда, жаппай параллелизм болмайтынын білдіреді. Менің ойымша, қарапайым бағдарламашылар үшін бұл бәрі параллель орындалатын процестерге тармақталу (fork) мүмкіндігі сияқты болады.
Және бұл, деректер құрылымдарының нақты жүзеге асырылуын сұрау сияқты, бағдарламаның өмірлік циклінің соңына қарай, сіз оны оңтайландыруға тырысқан кезде жасайтын нәрсе болады. 1-нұсқалар әдетте деректердің нақты көріністерінен алынатын артықшылықтарды елемейтіні сияқты, параллель есептеулерден алынатын кез келген артықшылықтарды да елемейтін болады.
Қолданбалардың арнайы түрлерін қоспағанда, параллелизм жүз жылдан кейін жазылатын бағдарламалардың барлық бөлігін қамтымайды. Егер қамтитын болса, бұл мезгілсіз оңтайландыру болар еді.
Жүз жылдан кейін қанша бағдарламалау тілі болады? Соңғы кездері жаңа бағдарламалау тілдері өте көп шығып жатқан сияқты. Мұның бір себебі — жылдамырақ жабдық бағдарламашыларға қолданбаға байланысты жылдамдық пен ыңғайлылық арасында әртүрлі ымыраға келуге мүмкіндік берді. Егер бұл шынайы үрдіс болса, бізде жүз жылдан кейін болатын жабдық оны одан сайын арттыра түсуі керек.
Дегенмен жүз жылдан кейін кеңінен қолданылатын бірнеше ғана тіл болуы мүмкін. Менің бұлай деуімнің бір себебі — оптимизм: егер сіз шынымен жақсы жұмыс істесеңіз, баяу 1-нұсқаны жазу үшін өте қолайлы, бірақ компиляторға дұрыс оңтайландыру кеңестерін бере отырып, қажет болған жағдайда өте жылдам код беретін тіл жасай аласыз деп ойлаймын. Сонымен, мен оптимист болғандықтан, жүз жылдан кейінгі бағдарламашыларда қолайлы және максималды тиімділік арасындағы үлкен алшақтыққа қарамастан, оның басым бөлігін қамти алатын тілдер болады деп болжаймын.
Бұл алшақтық ұлғайған сайын профайлерлердің маңызы арта түседі. Қазір профильдеуге аз көңіл бөлінеді. Көптеген адамдар жылдам қолданбаларды алудың жолы — жылдам код жасайтын компиляторларды жазу деп әлі де сенетін сияқты. Қолайлы және максималды өнімділік арасындағы алшақтық кеңейген сайын, жылдам қолданбаларды жасаудың жолы — бірінен екіншісіне апаратын жақсы бағыттаушыға ие болу екені барған сайын айқындала түседі.
Тек бірнеше тіл болуы мүмкін дегенде, мен белгілі бір салаға арналған «шағын тілдерді» қосып отырған жоқпын. Менің ойымша, мұндай кірістірілген тілдер — тамаша идея және олардың көбейетінін күтемін. Бірақ мен олардың пайдаланушылар астындағы әмбебап тілді көре алатындай жеткілікті жұқа қабық ретінде жазылатынын күтемін.
Болашақтың тілдерін кім жобалайды? Соңғы он жылдағы ең қызықты үрдістердің бірі — Perl, Python және Ruby сияқты ашық бастапқы кодты тілдердің өркендеуі болды. Тіл дизайнын хакерлер өз қолдарына алуда. Нәтижелер әзірге бейберекет, бірақ жігерлендіреді. Мысалы, Perl-де таңқаларлықтай тың идеялар бар. Көбі таңқаларлықтай нашар, бірақ бұл өршіл талпыныстар үшін әрқашан тән құбылыс. Қазіргі мутация қарқынымен, Құдай біледі, жүз жылдан кейін Perl не нәрсеге айналатынын.
«Қолынан келмегендер оқытады» деген сөз шындыққа жанаспайды (мен білетін ең жақсы хакерлердің кейбірі — профессорлар), бірақ оқытатындардың қолынан келмейтін көптеген нәрселер бар екені рас. Зерттеулер шектеуші касталық шеңберлерді орнатады. Кез келген академиялық салада айналысуға болатын және болмайтын тақырыптар бар. Өкінішке қарай, рұқсат етілген және тыйым салынған тақырыптар арасындағы айырмашылық көбінесе жақсы нәтижелерге қол жеткізу үшін қаншалықты маңызды екеніне емес, зерттеу мақалаларында сипатталғанда жұмыстың қаншалықты интеллектуалды естілетініне негізделеді. Ең шектен шыққан жағдай әдебиет шығар; әдебиетті зерттейтін адамдар оны шығаратындар үшін титімдей болса да пайдалы болатын нәрсені сирек айтады.
Ғылымда жағдай жақсырақ болғанымен, сізге істеуге рұқсат етілген жұмыс пен жақсы тілдерді беретін жұмыс түрлерінің арасындағы қиылысу өкінішке қарай өте аз. (Олин Шиверс бұл туралы шешен түрде кейіген болатын.) Мысалы, типтер зерттеу мақалаларының сарқылмас қайнар көзі болып көрінеді, ал шын мәнінде статикалық типтеу нағыз макростарға кедергі келтіретін сияқты — онсыз, менің ойымша, ешқандай тілді пайдалануға тұрмайды.
Үрдіс тілдердің тек «зерттеу» емес, ашық бастапқы кодты жобалар ретінде дамуына ғана емес, сонымен бірге оларды компилятор жазушылар емес, оларды пайдалануды қажет ететін қолданбалы бағдарламашылардың жобалауына қарай бағытталған. Бұл жақсы үрдіс сияқты және ол жалғасады деп күтемін.
Болжау мүмкін емес дерлік жүз жылдан кейінгі физикаға қарағанда, жүз жылдан кейін пайдаланушыларға ұнайтын тілді қазір жобалау теориялық тұрғыдан мүмкін деп ойлаймын.
Тілді жобалаудың бір тәсілі — оны аудара алатын компилятор немесе оны іске қоса алатын жабдық бар-жоғына қарамастан, өзіңіз жазғыңыз келетін бағдарламаны жай ғана қағазға түсіру. Мұны істегенде сіз шексіз ресурстар бар деп есептей аласыз. Біз жүз жылдан кейінгі сияқты бүгін де шексіз ресурстарды елестете алуымыз керек сияқты.
Адам қандай бағдарлама жазғысы келер еді? Қайсысы ең аз еңбекті талап етсе, соны. Дәлірек айтсақ: егер бағдарламалау туралы түсініктеріңізге қазір қолданып жүрген тілдеріңіз әсер етпегенде, не ең аз еңбекті талап етер еді, соны жазғыңыз келер еді. Мұндай ықпалдың соншалықты терең болатыны сонша, оны жеңу үшін үлкен күш қажет. Біз сияқты жалқау жаратылыстар үшін бағдарламаны ең аз күш жұмсап қалай сипаттау керектігі ап-айқын болуы тиіс сияқты көрінеді. Шын мәнінде, біз ойлайтын тіл ненің мүмкін екендігі туралы түсініктерімізді соншалықты шектейтіні сонша, бағдарламалардың оңайырақ тұжырымдалуы таңқаларлық болып көрінеді. Олар өздігінен келетін нәрсе емес, іздеп табуды қажет ететін дүние.
Бұл жердегі пайдалы бір әдіс — бағдарламаны жазуға қанша еңбек кететінін шамалау үшін оның ұзындығын өлшем ретінде алу. Әрине, таңбалар санындағы ұзындық емес, жеке синтаксистік элементтер санындағы ұзындық — негізінен, синтаксистік талдау ағашының (parse tree) көлемі. Ең қысқа бағдарламаны жазу ең аз еңбекті талап етеді деген тұжырым толықтай шындыққа жанаспауы мүмкін, бірақ бұл шама «ең аз еңбек» деген бұлдыр ұғымға қарағанда, қысқалық сияқты нақты мақсатқа ұмтылуға жеткілікті дәрежеде жақын. Сонда тілді жобалау алгоритмі мынаған айналады: бағдарламаға қарап, мұны одан да қысқарақ жазудың қандай да бір жолы бар ма деп сұрау.
Іс жүзінде, қиялдағы жүз жылдық тілде бағдарламалар жазу оның өзегіне қаншалықты жақын екеніңізге байланысты әртүрлі дәрежеде нәтиже береді. Сұрыптау функцияларын сіз қазір де жаза аласыз. Бірақ жүз жылдан кейін қандай кітапханалар қажет болатынын қазір болжау қиын. Шамасы, көптеген кітапханалар әлі тіпті пайда болмаған салалар үшін арналатын шығар. Егер SETI@home нәтиже берсе, мысалы, бізге бөтен ғаламшарлықтармен байланысуға арналған кітапханалар қажет болады. Әрине, егер олар соншалықты дамып кетіп, қазірдің өзінде XML арқылы сөйлеспейтін болса.
Ал екінші жағынан алғанда, меніңше, тілдің өзегін дәл бүгін жобалауға болады. Шын мәнінде, кейбіреулер оның негізгі бөлігі 1958 жылы-ақ жобаланып қойған деп дауласуы мүмкін.
Егер жүз жылдық тіл бүгін қолжетімді болса, біз онымен бағдарлама жазғымыз келер ме еді? Бұл сұраққа жауап берудің бір жолы — өткенге көз тастау. Егер бүгінгі бағдарламалау тілдері 1960 жылы қолжетімді болғанда, біреу оларды қолданғысы келер ме еді?
Кей жағынан алғанда, жауап — жоқ. Бүгінгі тілдер 1960 жылы болмаған инфрақұрылымды талап етеді. Мысалы, Python сияқты шегініс маңызды рөл атқаратын тіл принтерлік терминалдарда жақсы жұмыс істемес еді. Бірақ мұндай проблемаларды ысырып қойғанда — айталық, барлық бағдарламалар жай ғана қағазға жазылған деп есептесек — 1960 жылдардағы бағдарламашылар біз қазір қолданатын тілдерде бағдарлама жазғанды ұнатар ма еді?
Меніңше, иә. Бағдарламаның не екендігі туралы түсініктеріне алғашқы тілдердің қалдықтары сіңіп қалған, қиялы аздау кейбір мамандар қиналуы мүмкін еді. (Көрсеткіштер арифметикасынсыз деректерді қалай басқаруға болады? goto операторларынсыз блок-схемаларды қалай іске асыруға болады?) Бірақ ең ақылды бағдарламашыларға қазіргі тілдер берілсе, олардың бар мүмкіндігін еш қиындықсыз пайдаланар еді деп ойлаймын.
Егер бізде жүз жылдық тіл қазір болса, ол кем дегенде керемет псевдокод болар еді. Ал оны бағдарламалық жасақтама жазу үшін қолдану туралы не деуге болады? Жүз жылдық тілге кейбір қолданбалар үшін жылдам код жасау қажет болатындықтан, ол біздің құрылғыларымызда жеткілікті деңгейде жақсы жұмыс істейтіндей тиімді код жасай алар еді. Бізге жүз жылдан кейінгі пайдаланушыларға қарағанда оңтайландыру бойынша көбірек нұсқаулар беруге тура келуі мүмкін, бірақ бұл бәрібір де үлкен ұтыс болар еді.
Енді бізде біріктірген жағдайда қызықты мүмкіндіктерді көрсететін екі идея бар: (1) жүз жылдық тілді, негізінде, бүгін де жобалауға болады, және (2) егер ондай тіл болса, бүгін де онымен бағдарлама жазу жақсы болар еді. Бұл идеялардың осылай жинақталғанын көргенде, жүз жылдық тілді неге қазір жазып көрмеске деген ойға еріксіз келесің.
Тілді жобалаумен айналысқан кезде осындай мақсаттың болғаны және оны үнемі есте сақтаған жөн деп ойлаймын. Көлік жүргізуді үйренген кезде, көлікті жолға салынған сызықтармен капотты туралау арқылы емес, алыстағы белгілі бір нүктеге бағыттау арқылы түзу ұстау керек деген қағиданы үйретеді. Сізді тек алдағы он қадам жерде не болатыны ғана алаңдатса да, дұрыс шешім — осы. Біз бағдарламалау тілдерімен де дәл солай істей аламыз және солай істеуіміз керек деп ойлаймын.
Ескертпелер
Меніңше, Lisp Machine Lisp — мәлімдемелер (динамикалық айнымалылардан басқалары) тек оңтайландыру кеңестері болып табылады және дұрыс бағдарламаның мәнін өзгертпейді деген қағиданы жүзеге асырған алғашқы тіл болды. Бұны ашық түрде нақты тұжырымдаған алғашқы тіл Common Lisp сияқты.
Осы мақаланың нобайларын оқып шыққаны үшін Тревор Блэквеллге, Роберт Морриске және Дэн Гиффинге, сондай-ақ мені PyCon конференциясында сөз сөйлеуге шақырғаны үшін Гвидо ван Россумға, Джереми Хилтонға және қалған Python командасына алғыс білдіремін.