(Бұл эссе Гарвардта оқылған қонақ дәрісіне негізделген, ол өз кезегінде Солтүстік-Шығыс университетіндегі бұрынғы баяндаманы қамтыған болатын.)
Мен компьютерлік ғылымдар бойынша магистратураны бітірген соң, кескіндемені оқу үшін өнер мектебіне түстім. Компьютерге қызығатын адамның кескіндемеге де қызығуы мүмкін екеніне көпшілік таңғалғандай болды. Олардың ойынша, хакерлік пен суретшілік мүлде екі түрлі кәсіп сияқты көрінді: хакерлік — суық, нақты әрі жүйелі, ал кескіндеме — қандай да бір ішкі түрткінің аласұрған көрінісі.
Бұл екі ұғым да қате. Хакерлік пен кескіндеменің ортақ тұстары өте көп. Шындығында, мен таныған әртүрлі адамдардың ішінде хакерлер мен суретшілер бір-біріне ең қатты ұқсайтындар қатарына жатады.
Хакерлер мен суретшілердің ортақ тұсы — олардың екеуі де жасампаздар (makers). Сазгерлер, сәулетшілер және жазушылар сияқты, хакерлер мен суретшілердің де мақсаты — жақсы дүниелер жасау. Олар өздігінен ғылыми зерттеумен айналыспайды, бірақ жақсы дүние жасау барысында қандай да бір жаңа тәсіл тауып жатса, тіпті жақсы.
Маған «компьютерлік ғылым» (computer science) деген термин ешқашан ұнаған емес. Ұнамауының басты себебі — ондай нәрсенің шын мәнінде жоқ болуында. Компьютерлік ғылым — тарихтың кездейсоқтығынан, дәл Югославия сияқты, бір жерге тоғыстырылған, өзара әлсіз байланысқан салалардың жиынтығы. Бір шетінде іс жүзінде математик болып табылатын, бірақ DARPA гранттарын алу үшін істеп жатқан ісін компьютерлік ғылым деп атайтын адамдар отыр. Ортасында компьютерлердің «жаратылыстану тарихы» сияқты нәрсемен айналысатындар бар — мысалы, желілер арқылы деректерді бағыттау алгоритмдерінің әрекетін зерттейді. Ал екінші шетінде қызықты бағдарламалық жасақтама жазуға тырысатын және сәулетшілер үшін бетон, суретшілер үшін бояу қандай болса, компьютер олар үшін де жай ғана өзін-өзі көрсету құралы болып табылатын хакерлер тұр. Бұл математиктер, физиктер және сәулетшілер бір ғана кафедрада болуға мәжбүр болғандай жағдай.
Кейде хакерлердің істейтін ісін «бағдарламалық инженерия» деп атайды, бірақ бұл термин де дәл солай жаңылыстырады. Бағдарламалық жасақтаманың жақсы дизайнерлері сәулетшілерден артық инженер емес. Сәулет пен инженерия арасындағы шекара айқын сызылмаған, бірақ ол бар. Ол не және қалай арасында жатыр: сәулетшілер нені жасау керегін шешеді, ал инженерлер оны қалай жасау керектігін анықтайды.
«Не» мен «қалай» арасын тым алшақтатуға болмайды. Қалай жасау керектігін түсінбей тұрып, нені жасау керегін шешуге тырыссаңыз, басыңыз бәлеге қалады. Бірақ хакерлік — әлдебір техникалық тапсырманы (спецификацияны) қалай жүзеге асыруды шешуден әлдеқайда көп нәрсе екені сөзсіз. Ең жақсы жағдайда, ол сол техникалық тапсырманы жасау болып табылады, дегенмен мұны істеудің ең жақсы жолы — оны тікелей жүзеге асыру екені байқалады.
Мүмкін, бір күні «компьютерлік ғылым» да, Югославия сияқты, өзінің құрамдас бөліктеріне ыдырап кетер. Бұл жақсы нәрсе болуы да мүмкін. Әсіресе, бұл менің туған өлкем — хакерлік үшін тәуелсіздік әкелетін болса.
Осы әртүрлі жұмыс түрлерін бір бөлімге біріктіру әкімшілік тұрғыдан ыңғайлы болуы мүмкін, бірақ зияткерлік тұрғыдан шатастырады. Маған «компьютерлік ғылым» атауының ұнамауының тағы бір себебі осы. Шамасы, ортадағы адамдар эксперименттік ғылымға ұқсас нәрсемен айналысатын шығар. Бірақ екі шетіндегі адамдар, яғни хакерлер мен математиктер, іс жүзінде ғылыммен айналыспайды.
Бұл математиктерді аса алаңдатпайтын сияқты. Олар математика бөліміндегі басқа математиктер сияқты теоремаларды дәлелдеуге қуана кіріседі және көп ұзамай өздері жұмыс істейтін ғимараттың сыртында «computer science» деп жазылып тұрғанын байқауды қоятын шығар. Бірақ хакерлер үшін бұл атау — үлкен мәселе. Егер олардың істеп жатқаны ғылым деп аталса, бұл оларға өзін ғылыми тұрғыда ұстауы керек сияқты сезім тудырады. Сондықтан университеттер мен ғылыми-зерттеу зертханаларындағы хакерлер шын мәнінде қалайтын ісімен — әдемі бағдарламалық жасақтама жасаумен айналысудың орнына, ғылыми мақалалар жазуымыз керек деп есептейді.
Ең жақсы жағдайда, ғылыми мақалалар жай ғана ресмилік болып табылады. Хакерлер керемет бағдарлама жазады, содан кейін ол туралы мақала жазады, ал мақала сол бағдарламамен қол жеткізілген жетістіктің баламасына айналады. Бірақ көбінесе бұл сәйкессіздік мәселелер туғызады. Әдемі нәрселерді жасаудан алыстап, ғылыми мақалаларға қолайлырақ тақырып болатын ұсқынсыз дүниелерді жасауға қарай ойысып кету оңай.
Өкінішке қарай, әдемі дүниелер әрқашан мақалалар үшін ең жақсы тақырып бола бермейді. Біріншіден, зерттеу түпнұсқа болуы керек — PhD диссертациясын жазған кез келген адам білетіндей, тың аумақты зерттеп жатқаныңызға көз жеткізудің жолы — ешкімге керегі жоқ жер телімін иелену. Екіншіден, зерттеу салмақты болуы керек — ал қолайсыз жүйелер мазмұны мол мақалаларға жол ашады, өйткені мақсатқа жету үшін қандай кедергілерді еңсеруге тура келгені туралы жаза аласыз. Қате жорамалдардан бастау сияқты мазмұнды мәселелер тудыратын ештеңе жоқ. AI саласының көп бөлігі — осы ереженің мысалы; егер сіз білімді аргументтері абстрактілі ұғымдарды білдіретін предикаттық логикалық өрнектер тізімі ретінде ұсынуға болады деп есептесеңіз, мұны қалай жұмыс істету керектігі туралы көптеген мақалалар жазуға тура келеді. Рики Рикардо айтқандай: «Люси, саған көп нәрсені түсіндіруге тура келеді».
Әдемі нәрсені жасаудың жолы көбінесе бұрыннан бар нәрсеге нәзік түзетулер енгізу немесе бар идеяларды сәл жаңаша тәсілмен біріктіру болып табылады. Мұндай жұмысты ғылыми мақалада жеткізу қиын.
Ендеше неліктен университеттер мен ғылыми зертханалар хакерлерді жарияланымдарына қарап бағалауды жалғастыра береді? «Оқуға қабілеттілік» қарапайым стандартталған тесттермен немесе бағдарламашылардың өнімділігі код жолдарымен өлшенетін себеппен бірдей. Бұл тесттерді қолдану оңай, ал шамалы болса да жұмыс істейтін оңай сынақтан тартымды ештеңе жоқ.
Хакерлердің шын мәнінде не істеуге тырысатынын, яғни әдемі бағдарламалық жасақтама жасауды өлшеу әлдеқайда қиын болар еді. Жақсы дизайнды бағалау үшін жақсы дизайн талғамы қажет. Ал адамдардың жақсы дизайнды тани білу қабілеті мен оны тани алатынына деген сенімділігі арасында ешқандай байланыс жоқ, бәлкім, тіпті кері байланыс бар шығар.
Жалғыз сыртқы сынақ — уақыт. Уақыт өте келе әдемі дүниелер өркендейді, ал ұсқынсыз дүниелер шетке ысырылады. Өкінішке қарай, бұған кететін уақыт адам өмірінен ұзағырақ болуы мүмкін. Сэмюэл Джонсон жазушының беделі тұрақталуы үшін жүз жыл керек деп айтқан. Сізге жазушының ықпалды достарының дүниеден өтуін, содан кейін олардың барлық ізбасарларының дүниеден өтуін күтуге тура келеді.
Менің ойымша, хакерлер өз беделінде кездейсоқтық үлесінің үлкен болатынымен келісуі керек. Бұл жағынан олар басқа жасампаздардан еш айырмашылығы жоқ. Шын мәнінде, солармен салыстырғанда олардың жолы болған. Сәннің ықпалы хакерлікте кескіндемедегідей күшті емес.
Адамдардың сіздің жұмысыңызды түсінбеуінен де жаман нәрселер бар. Одан да қауіптісі — өз жұмысыңызды өзіңіз дұрыс түсінбеуіңіз. Идеяларды іздеу үшін сіз сабақтас салаларға барасыз. Егер сіз компьютерлік ғылым бөлімінде болсаңыз, мысалы, хакерлік — теориялық компьютерлік ғылым теориясының қолданбалы нұсқасы деп сенуге табиғи азғырылу пайда болады. Мен магистратурада оқып жүргенде, менде көбірек теория білуім керек еді және қорытынды емтиханнан кейін үш аптаның ішінде сол нәрселердің барлығын ұмытып қалғаным үлкен жауапсыздық болды деген жайсыз ой сана түкпірінде үнемі мазалайтын.
Енді ғана қателескенімді түсіндім. Хакерлерге есептеу теориясын түсіну суретшілерге бояу химиясын түсіну қаншалықты қажет болса, шамамен соншалықты қажет. Сізге уақыт пен кеңістік күрделілігін есептей білу және Тьюринг толықтығы туралы білу жеткілікті. Егер парсер немесе тұрақты өрнектер кітапханасын жазу керек болса, кем дегенде күй машинасы (state machine) тұжырымдамасын есте сақтағыңыз келуі мүмкін. Суретшілерге іс жүзінде бояу химиясы туралы бұдан әлдеқайда көп нәрсені есте сақтауға тура келеді.
Мен идеялардың ең жақсы көзі атауында «компьютер» деген сөзі бар басқа салалар емес, жасампаздар мекендейтін басқа салалар екенін байқадым. Кескіндеме мен үшін есептеу теориясына қарағанда идеяларға әлдеқайда бай қайнаркөз болды.
Мысалы, колледжде маған компьютерге жақындамас бұрын бағдарламаны қағаз бетінде толығымен ойластырып алу керектігін үйретті. Мен бұлай бағдарлама жазбайтынымды байқадым. Маған қағаз парағының алдында емес, компьютер алдында отырып бағдарламалау ұнайтынын түсіндім. Одан да сорақысы, толық бағдарламаны сабырмен жазып шығып, оның дұрыстығына көз жеткізудің орнына, мен мүлде істемейтін былық кодты жаза салатынмын да, оны біртіндеп жөнге келтіретінмін. Мені оқытқандай, дебагтау (debugging) қателер мен жаңсақтықтарды түзейтін соңғы кезең болуы керек еді. Ал менің жұмыс істеу мәнерімде бағдарламалау түгелдей дерлік дебагтаудан тұратын сияқты көрінетін.
Ұзақ уақыт бойы мен бастауыш сыныпта қарындашты олар үйреткендей ұстамағаныма бір кездері қысылғанымдай, бұл үшін де өзімді кінәлі сезініп жүрдім. Егер мен басқа жасампаздарға, суретшілерге немесе сәулетшілерге көз жүгірткенімде, менің істеп жүрген ісімнің атауы бар екенін түсінер едім: нобай салу (sketching). Байқағанымдай, колледжде маған бағдарламалауды үйреткен тәсіл мүлде қате болған. Бағдарламаларды жазушылар, суретшілер мен сәулетшілер сияқты, оларды жазу барысында ойластыру керек.
Мұны түсіну бағдарламалық жасақтама дизайны үшін нақты мәнге ие. Бұл бағдарламалау тілінің, ең алдымен, икемді болуы керектігін білдіреді. Бағдарламалау тілі бұрыннан ойластырылған бағдарламаларды білдіру үшін емес, бағдарламаларды ойлап табу үшін арналған. Ол қалам емес, қарындаш болуы керек. Егер адамдар шынымен бағдарламаларды маған колледжде үйреткендей жазатын болса, статикалық типтеу тамаша идея болар еді. Бірақ мен танитын хакерлердің ешқайсысы бағдарламаларды олай жазбайды. Бізге тізеге типтер толы кесені қойып алып, қатал кәрі компилятор тәтеймен сыпайы әңгіме-дүкен құрып отыратын тіл емес, шимайлауға, жағуға және бояуды былғауға мүмкіндік беретін тіл керек.
Статикалық типтеу тақырыбын қозғаған екенбіз, өзімізді жасампаздармен теңестіру бізді ғылымдарды мазалайтын тағы бір мәселеден құтқарады: математикаға деген қызғаныш. Ғылымдағы әрбір адам іштей математиктердің өздерінен ақылдырақ екеніне сенеді. Меніңше, математиктер де бұған сенеді. Қалай болғанда да, нәтижесінде ғалымдар өз жұмыстарын барынша математикалық етіп көрсетуге тырысады. Физика сияқты салада бұл аса зиян келтірмеуі мүмкін, бірақ жаратылыстану ғылымдарынан алыстаған сайын бұл үлкен мәселеге айналады.
Формулаларға толы бет өте әсерлі көрінеді. (Кеңес: одан да зор әсер қалдыру үшін грек айнымалыларын қолданыңыз.) Сондықтан, мәселен, маңызды мәселелермен айналысудың орнына, формальды түрде өңдеуге болатын мәселелермен айналысуға деген үлкен азғырылу пайда болады.
Егер хакерлер өздерін жазушылар мен суретшілер сияқты басқа жасампаздармен теңестірсе, оларда бұған деген азғырылу болмас еді. Жазушылар мен суретшілер математикаға деген қызғаныштан зардап шекпейді. Олар өздерін мүлде басқа нәрсемен айналысып жатқандай сезінеді. Хакерлер де солай, меніңше.
Егер университеттер мен ғылыми-зерттеу зертханалары хакерлерге өздері қалайтын жұмысты істеуге кедергі келтірсе, мүмкін олардың орны компанияларда шығар. Өкінішке қарай, компаниялардың көпшілігі де хакерлерге қалағанын істеуге мүмкіндік бермейді. Университеттер мен зертханалар хакерлерді ғалым болуға мәжбүрлейді, ал компаниялар оларды инженер болуға мәжбүрлейді.
Мұны мен жақында ғана білдім. Yahoo Viaweb-ті сатып алғанда, олар менен не істегім келетінін сұрады. Маған бизнестің бұл жағы ешқашан аса ұнаған емес, сондықтан жай ғана хакпен айналысқым келетінін айттым. Yahoo-ға келгенімде, олар үшін хакерлік бағдарламалық жасақтаманы жобалау емес, оны жүзеге асыру (кодтау) дегенді білдіретінін көрдім. Бағдарламашыларға өнім менеджерлерінің пайымын (егер бұған бұл сөз келетін болса) кодқа аударатын техниктер ретінде қарады.
Бұл ірі компаниялардағы әдепкі жоспар сияқты. Олар мұны нәтиженің стандартты ауытқуын азайту үшін жасайды. Хакерлердің аз ғана пайызы ғана бағдарламалық жасақтаманы шынымен жобалай алады және компанияны басқаратын адамдар үшін оларды анықтау қиын. Сондықтан бағдарламалық жасақтаманың болашағын бір дарынды хакерге сеніп тапсырудың орнына, көптеген компаниялар оны комитет жобалайтындай, ал хакерлер тек сол дизайнды жүзеге асыратындай етіп ұйымдастырады.
Егер сіз бір күні ақша тапқыңыз келсе, осыны есте сақтаңыз, өйткені стартаптардың жеңіске жетуінің бір себебі осы. Ірі компаниялар апаттардың алдын алу үшін дизайн нәтижелерінің стандартты ауытқуын азайтқысы келеді. Бірақ тербелістерді бәсеңдеткен кезде, төменгі нүктелермен қатар жоғарғы шыңдарды да жоғалтасыз. Бұл ірі компаниялар үшін проблема емес, өйткені олар керемет өнімдер жасау арқылы жеңбейді. Ірі компаниялар басқа ірі компанияларға қарағанда азырақ сорлы болу арқылы жеңеді.
Сондықтан бағдарламалық жасақтамасын өнім менеджерлері жобалайтын үлкен компаниямен дизайн соғысына түсудің жолын тапсаңыз, олар сізге ешқашан ілесе алмайды. Дегенмен, мұндай мүмкіндіктерді табу оңай емес. Үлкен компанияны дизайн соғысына тарту, қамал ішіндегі қарсыласты қоян-қолтық ұрысқа шақыру қандай қиын болса, сондай қиын. Мысалы, Microsoft Word-тан жақсырақ мәтіндік редактор жазу оңай болар еді, бірақ Microsoft өзінің операциялық жүйе монополиясы қамалында отырып, сіз оны жасасаңыз да, байқамауы да мүмкін.
Дизайн соғыстарын жүргізетін жер — әлі ешкім бекініс салып үлгермеген жаңа нарықтар. Дизайнға батыл қадам жасап, өнімді бір адамдардың жобалауына да, жүзеге асыруына да мүмкіндік беру арқылы үлкен жеңіске жететін жер осы. Microsoft-тың өзі басында солай істеді. Apple де солай істеді. Hewlett-Packard та. Меніңше, кез келген табысты стартап солай жасаған.
Сондықтан керемет бағдарламалық жасақтама жасаудың бір жолы — өз стартапыңызды бастау. Дегенмен мұның екі мәселесі бар. Біріншісі — стартапта бағдарламалық жасақтама жазудан басқа да көптеген жұмыстарды істеуге тура келеді. Viaweb-те уақытымның төрттен бір бөлігін хакерлікке арнасам, өзімді бақытты санайтынмын. Ал қалған үш бөлігінде істеуге тура келген нәрселер жалықтырарлықтан бастап қорқыныштыға дейін болатын. Менде бұған қатысты бір өлшем бар: бірде маған тіс емдету үшін директорлар кеңесінің отырысынан кетуге тура келді. Тіс дәрігерінің креслосына жайғасып, бұрғыны күтіп отырғанда, өзімді демалыста жүргендей сезінгенім есімде.
Стартаптардың тағы бір мәселесі — ақша әкелетін бағдарламалық жасақтама мен жазуға қызықты бағдарламалық жасақтама арасында ортақ нәрсенің аздығы. Бағдарламалау тілдерін жазу қызықты, және Microsoft-тың алғашқы өнімі іс жүзінде сондай болды, бірақ қазір бағдарламалау тілдері үшін ешкім ақша төлемейді. Егер сіз ақша тапқыңыз келсе, ешкім тегін шешкісі келмейтін тым жиіркенішті мәселелермен айналысуға мәжбүр боласыз.
Барлық жасампаздар бұл мәселеге тап болады. Бағалар сұраныс пен ұсыныс арқылы анықталады және жұмыс істеуге қызықты нәрселерге сұраныс жеке тұтынушылардың күнделікті мәселелерін шешетін нәрселерге қарағанда әлдеқайда аз. Бродвейден тыс қойылымдарда ойнау сауда көрмесінде біреудің стендінде горилла костюмін киіп жүру сияқты көп төленбейді. Романдар жазу қоқыс үккіштерге жарнамалық мәтін жазу сияқты көп төленбейді. Ал бағдарламалау тілдерін хак жасау қандай да бір компанияның ескірген дерекқорын олардың веб-серверіне қалай қосу керектігін табу сияқты табыс әкелмейді.
Менің ойымша, бағдарламалық жасақтамаға қатысты бұл мәселенің жауабы — барлық жасампаздарға таныс тұжырымдама: күндізгі жұмыс (day job). Бұл тіркес түнде өнер көрсететін музыканттардан басталған. Жалпы алғанда, бұл ақша үшін істейтін бір жұмысыңыз, ал жан қалауы үшін істейтін басқа жұмысыңыз бар дегенді білдіреді.
Барлық дерлік жасампаздардың мансабының басында күндізгі жұмыстары болады. Суретшілер мен жазушылар осылай істейтіні бәріне мәлім. Егер жолыңыз болса, негізгі жұмысыңызбен тығыз байланысты күндізгі жұмыс таба аласыз. Музыканттар көбінесе пластинкалар дүкенінде жұмыс істейтін сияқты. Бағдарламалау тілімен немесе операциялық жүйемен айналысатын хакер де дәл солай оны пайдаланатын күндізгі жұмыс таба алады. [1]
Бұл мәселенің шешімі — хакерлердің күндізгі жұмысы болуы және олардың қосымша уақытта әдемі бағдарламалық жасақтамамен айналысуы деп айтқанда, мен мұны жаңа идея ретінде ұсынып отырған жоқпын. Ашық бастапқы кодты (open-source) хакерліктің бүкіл мәні осында. Менің айтқым келгені, ашық бастапқы код — дұрыс үлгі болуы мүмкін, өйткені мұны басқа барлық жасампаздар дербес түрде растаған.
Кез келген жұмыс берушінің хакерлерге ашық бастапқы кодты жобалармен айналысуға рұқсат бергісі келмейтіні маған таңғаларлық болып көрінеді. Viaweb-те біз мұны істемейтін кез келген адамды жұмысқа алуға құлықсыз болар едік. Бағдарламашылармен сұхбат жүргізгенде, бізді ең алдымен олардың бос уақытында қандай бағдарламалық жасақтама жазатыны қызықтырды. Егер сіз оны жақсы көрмесеңіз, ешнәрсені шын мәнінде жақсы істей алмайсыз, ал егер сіз хакерлікті жақсы көрсеңіз, сөзсіз өзіңіздің жеке жобаларыңызбен айналысатын боласыз. [2]
Хакерлер ғалымдар емес, жасампаздар болғандықтан, метафораларды ғылымнан емес, жасампаздардың басқа түрлерінен іздеген дұрыс. Кескіндеме бізге хакерлік туралы тағы нені үйрете алады?
Кескіндеме мысалынан үйренуге немесе кем дегенде растауға болатын бір нәрсе — хак жасауды қалай үйрену керектігі. Сіз кескіндемені негізінен оны салу арқылы үйренесіз. Хакерлік те дәл солай. Көптеген хакерлер бағдарламалауды колледж курстарына қатысу арқылы үйренбейді. Олар он үш жасында өздерінің бағдарламаларын жазу арқылы үйренеді. Тіпті колледжде де хак жасауды негізінен хак жасау арқылы үйренесіз. [3]
Суретшілер өздерінен кейін жұмыстарының ізін қалдыратындықтан, олардың тәжірибе арқылы қалай үйренетінін бақылай аласыз. Егер сіз суретшінің туындыларына хронологиялық ретпен қарасаңыз, әрбір картинаның алдыңғыларынан үйренген нәрселерге негізделгенін көресіз. Картинада бір нәрсе өте сәтті шыққан кезде, әдетте оның 1-нұсқасын одан ертерек салынған шағын картинадан табуға болады.
Менің ойымша, көптеген жасампаздар осылай жұмыс істейді. Жазушылар мен сәулетшілер де солай сияқты. Мүмкін, хакерлерге де бір жобада жылдар бойы жұмыс істеп, барлық кейінгі идеяларын түзетулер ретінде енгізуге тырысудың орнына, суретшілер сияқты әрекет етіп, үнемі бәрін нөлден қайта бастаған жақсы болар еді.
Хакерлердің хак жасауды оны істеу арқылы үйренуі — хакерліктің ғылымнан қаншалықты ерекшеленетінінің тағы бір белгісі. Ғалымдар ғылымды оны істеу арқылы емес, зертханалық жұмыстар мен есептер жинағын орындау арқылы үйренеді. Ғалымдар біреудің өздері үшін жасап қойған жұмысын жай ғана қайталауға тырысатындықтан, мінсіз жұмыс жасаудан бастайды. Ақыр соңында олар түпнұсқалық жұмыс жасай алатын деңгейге жетеді. Ал хакерлер, керісінше, басынан бастап түпнұсқалық жұмыстар жасайды; тек ол өте нашар болады. Осылайша хакерлер түпнұсқадан бастап, жақсара түседі, ал ғалымдар жақсыдан бастап, түпнұсқаға жетеді.
Жасампаздардың үйренуінің тағы бір жолы — мысалдардан үйрену. Суретші үшін мұражай — техникалардың анықтамалық кітапханасы. Ұлы шеберлердің жұмыстарын көшіріп салу жүздеген жылдар бойы суретшілердің дәстүрлі білімінің бір бөлігі болды, өйткені көшіру картинаның қалай жасалғанына мұқият қарауға мәжбүрлейді.
Жазушылар да осылай істейді. Бенджамин Франклин Эддисон мен Стилдің эсселеріндегі ойларды жинақтап, содан кейін оларды қайта жаңғыртуға тырысу арқылы жазуды үйренді. Реймонд Чандлер детективтік хикаялармен дәл осылай жасады.
Хакерлер де дәл солай жақсы бағдарламаларға — тек олардың не істейтініне ғана емес, сонымен бірге бастапқы кодына да қарап, бағдарламалауды үйрене алады. Ашық бастапқы код қозғалысының кеңінен жарияланбаған артықшылықтарының бірі — ол бағдарламалауды үйренуді жеңілдетті. Мен бағдарламалауды үйренген кезде, бізге көбінесе кітаптардағы мысалдарға сүйенуге тура келетін. Ол кезде қолжетімді жалғыз үлкен код бөлігі Unix болды, бірақ тіпті оның өзі ашық бастапқы кодты емес еді. Бастапқы кодты оқыған адамдардың көпшілігі оны Джон Лайонстың кітабының жасырын көшірмелерінен оқыды, ол кітап 1977 жылы жазылғанымен, 1996 жылға дейін жариялануға рұқсат етілмеген еді.
Кескіндемеден ала алатын тағы бір мысалымыз — суреттердің біртіндеп өңделу арқылы жасалу тәсілі. Суреттер әдетте нобайдан басталады. Біртіндеп бөлшектер толтырылады. Бірақ бұл жай ғана толтыру процесі емес. Кейде бастапқы жоспарлар қате болып шығады. Рентген арқылы қараған кезде сансыз картиналардың қол-аяқтары жылжытылғаны немесе бет-әлпеті қайта түзелгені анықталады.
Міне, бұл біз кескіндемеден үйрене алатын жағдай. Меніңше, хакерлік те осылай жұмыс істеуі керек. Бағдарламаның спецификациялары мінсіз болады деп күту — шындыққа жанаспайды. Мұны алдын ала мойындап, бағдарламаларды техникалық талаптарды жұмыс барысында өзгертуге мүмкіндік беретіндей етіп жазғаныңыз жөн.
(Ірі компаниялардың құрылымы оларға мұны істеуді қиындатады, сондықтан бұл — стартаптардың тағы бір артықшылығы.)
Қазіргі кезде мезгілсіз оңтайландырудың (premature optimization) қаупі туралы бәрі білетін шығар. Менің ойымша, біз дәл солай мезгілсіз дизайннан да — бағдарламаның не істеу керектігін тым ерте шешіп қоюдан да сақтануымыз керек.
Дұрыс құралдар бұл қауіптен аулақ болуға көмектеседі. Жақсы бағдарламалау тілі майлы бояу сияқты өз ойыңызды өзгертуді жеңілдетуі керек. Мұнда динамикалық типтеу ұтымды, өйткені сізге деректердің нақты көріністерін алдын ала бекітіп тастаудың қажеті жоқ. Бірақ икемділіктің кілті, меніңше, тілді өте абстрактілі етуде жатыр. Өзгертуге ең оңай бағдарлама — бұл өте қысқа бағдарлама.
Бұл парадокс сияқты естіледі, бірақ ұлы картина оған қажетті деңгейден де жақсырақ болуы керек. Мысалы, Леонардо Ұлттық галереядағы Джиневра де Бенчидің портретін салғанда, оның басының артына арша бұтасын қойған. Онда ол әрбір жеке жапырақты мұқият салып шыққан. Көптеген суретшілер: бұл жай ғана оның басын қоршап тұру үшін артқы фонға қойылатын нәрсе, оған ешкім соншалықты мұқият қарамайды деп ойлауы мүмкін еді.
Леонардо олай ойламаған. Оның картинаның бір бөлігіне қаншалықты күш жұмсағаны оған біреудің қаншалықты мұқият қарайтынына мүлде байланысты болмаған. Ол Майкл Джордан сияқты болды. Аяусыз қажымас.
Қажымастық жеңеді, өйткені тұтастай алғанда байқалмайтын бөлшектер көрінетін болады. Адамдар Джиневра де Бенчидің портретінің қасынан өткенде, олар этикеткаға қарап, оның Леонардо да Винчи екенін байқамай тұрып-ақ, олардың назарын бірден сол туынды жаулап алады. Осы көрінбейтін бөлшектердің барлығы бірдей үнмен ән салған мыңдаған әрең естілетін дауыстар сияқты, таңғажайып бір дүниені құрайды.
Ұлы бағдарламалық жасақтама да дәл солай сұлулыққа берілген фанатикалық адалдықты талап етеді. Егер сіз жақсы бағдарламалық жасақтаманың ішіне үңілсеңіз, ешкім ешқашан көрмеуі тиіс бөліктерінің де әдемі екенін көресіз. Мен керемет бағдарламалық жасақтама жазамын деп айта алмаймын, бірақ кодқа келгенде, егер мен күнделікті өмірге солай қарайтын болсам, рецептпен берілетін дәрі-дәрмектерге мұқтаж болар едім. Нашар шегіністері бар немесе ұсқынсыз айнымалы атауларын қолданатын кодты көру менің жыныма тиеді.
Егер хакер техникалық тапсырманы кодқа айналдыратын жай ғана орындаушы болса, онда ол ор қазып жатқан адам сияқты оны басынан аяғына дейін ретімен орындай берер еді. Бірақ егер хакер жаратушы болса, біз шабытты ескеруіміз керек.
Хакерлікте, кескіндеме сияқты, жұмыс циклдармен жүреді. Кейде сіз қандай да бір жаңа жобаға шабыттанып, күніне он алты сағат жұмыс істегіңіз келеді. Басқа уақытта ештеңе қызық көрінбейді.
Жақсы жұмыс істеу үшін сіз осы циклдарды ескеруіңіз керек, өйткені олар сіздің оларға қалай әсер ететініңізге байланысты өзгереді. Механикалық беріліс қорабы бар көлікті төбеге қарай айдап бара жатқанда, қозғалтқышты сөндіріп алмау үшін кейде іліністі (муфтаны) босатуға тура келеді. Дәл сол сияқты, қарқынды сәл бәсеңдету ұмтылысыңыздың сөніп қалуына жол бермейді. Кескіндемеде де, хакерлікте де өте батыл, қорқынышты тапсырмалар бар, сондай-ақ көңілге тыныштық беретін үйреншікті міндеттер де бар. Тоқтап қалуыңыз мүмкін сәттерге арнап бірнеше оңай тапсырмаларды сақтап қойған дұрыс.
Хакерлікте бұл тура мағынасында қателерді (багтарды) жинап қоюды білдіруі мүмкін. Маған дебагтау ұнайды: бұл — хакерлік адамдар ойлағандай қарапайым болатын жалғыз уақыт. Сізде толық шектелген мәселе бар және бар болғаны оны шешуіңіз керек. Бағдарламаңыз x әрекетін орындауы керек. Оның орнына ол y әрекетін орындайды. Қай жерде қате кетті? Соңында жеңетініңізді білесіз. Бұл қабырғаны бояғандай тыныштандырады.
Кескіндеме өнерінің мысалы бізге өз жұмысымызды қалай басқару керектігін ғана емес, сонымен қатар бірлесіп қалай жұмыс істеу керектігін де үйрете алады. Өткен заманның көптеген ұлы өнер туындылары бірнеше адамның қолынан шыққан, бірақ мұражайда олардың жанындағы қабырғада тек бір ғана есім тұруы мүмкін. Леонардо Верроккьоның шеберханасында шәкірт болып жүріп, оның Христостың шоқынуы атты туындысындағы періштелердің бірін салған. Мұндай жағдай ерекшелік емес, қалыпты құбылыс болатын. Ал Микеланджело Сикстин капелласының төбесіндегі барлық бейнелерді өзі саламын деп табандылық танытқаны үшін ерекше берілген жан ретінде бағаланды.
Менің білуімше, суретшілер бір сурет үстінде бірлесіп жұмыс істегенде, олар ешқашан бір бөлшекті қатар салған емес. Шебердің негізгі тұлғаларды, ал көмекшілердің басқаларын және артқы көріністі салуы үйреншікті жағдай еді. Бірақ бір адамның басқаның салғанының үстінен қайта бояуы ешқашан болған емес.
Меніңше, бұл бағдарламалық жасақтама саласындағы ынтымақтастық үшін де дұрыс модель. Тым шектен шықпаңыз. Кодтың бір бөлігін үш немесе төрт түрлі адам жазып, олардың ешқайсысы оған шын мәнінде иелік етпесе, ол жатақхананың ортақ бөлмесі сияқты болып шығады. Ондай жер сүреңсіз әрі қараусыз қалып, қоқысқа тола бастайды. Бірлесіп жұмыс істеудің дұрыс жолы, менің ойымша, жобаларды нақты анықталған модульдерге бөлу, әрқайсысына нақты бір ие тағайындау және олардың арасындағы интерфейстерді барынша мұқият жобалап, мүмкіндігінше бағдарламалау тілдері сияқты айқын ету.
Кескіндеме сияқты, бағдарламалық жасақтаманың да басым бөлігі адамдар аудиториясына арналған. Сондықтан хакерлер де, суретшілер сияқты, шынымен керемет жұмыс жасау үшін эмпатияға ие болуы керек. Сіз мәселеге пайдаланушының көзімен қарай білуіңіз қажет.
Бала кезімде маған үнемі мәселеге басқа адамның көзімен қарау керектігі айтылатын. Іс жүзінде бұл әрқашан өзім қалаған нәрсені емес, басқа біреудің қалағанын істеуді білдіретін. Бұл, әрине, эмпатияның атын былғады, сондықтан мен оны бойымда дамытпауға тырыстым.
Қалай ғана қателескенмін десеңізші! Мәселеге басқа адамдардың көзімен қарау, шын мәнінде, табыстың басты құпиясы болып шықты. Бұл міндетті түрде өзіңді құрбан етуді білдірмейді. Одан мүлде аулақ. Басқа біреудің заттарды қалай көретінін түсіну оның мүддесі үшін әрекет етесіз деген сөз емес; кейбір жағдайларда — мысалы, соғыста — сіз керісінше әрекет еткіңіз келеді. [4]
Жаратушылардың көбі заттарды адамдар аудиториясы үшін жасайды. Ал аудиторияның назарын аудару үшін оларға не қажет екенін түсінуіңіз керек. Мысалы, ең ұлы картиналардың барлығы дерлік адамдарды бейнелейді, өйткені адамдарды ең алдымен адамдар қызықтырады.
Эмпатия — жақсы хакер мен ұлы хакердің арасындағы ең маңызды айырмашылық шығар, бәлкім. Кейбір хакерлер өте ақылды, бірақ эмпатияға келгенде іс жүзінде солипсист болып шығады. Мұндай адамдарға тамаша бағдарламалық жасақтама жасау қиын [5], өйткені олар заттарға пайдаланушының көзімен қарай алмайды.
Адамдардың эмпатияға қаншалықты қабілетті екенін білудің бір жолы — олардың техникалық білімі жоқ адамға техникалық сұрақты қалай түсіндіретінін бақылау. Біздің бәріміз де басқа жағынан ақылды болғанымен, бұл істе күлкілі дәрежеде дәрменсіз адамдарды білетін шығармыз. Егер біреу кешкі ас үстінде олардан бағдарламалау тілінің не екенін сұраса, олар: «О, жоғары деңгейлі тіл — бұл компилятор объектілік кодты генерациялау үшін кіріс ретінде пайдаланатын нәрсе» сияқты бірдеңе айтады. Жоғары деңгейлі тіл? Компилятор? Объектілік код? Бағдарламалау тілінің не екенін білмейтін адам, әрине, бұл терминдердің де не екенін білмейді.
Бағдарламалық жасақтаманың бір міндеті — өзін-өзі түсіндіре алуы. Сондықтан жақсы бағдарламалық жасақтама жазу үшін пайдаланушылардың қаншалықты аз түсінетінін ұғынуыңыз керек. Олар бағдарламаға ешқандай дайындықсыз келеді, сондықтан ол бағдарлама олар қалай ойласа, дәл солай жұмыс істегені абзал, себебі олар нұсқаулықты оқымайды. Бұл тұрғыда мен көрген ең үздік жүйе 1985 жылғы түпнұсқа Macintosh болды. Ол бағдарламалық жасақтамаларда өте сирек кездесетін нәрсені істеді: ол жай ғана мінсіз жұмыс істеп тұрды. [6]
Бастапқы код та өзін-өзі түсіндіре білуі керек. Егер мен адамдардың бағдарламалау туралы бір ғана дәйексөзді есте сақтауына қол жеткізе алсам, ол Structure and Interpretation of Computer Programs кітабының басындағы дәйексөз болар еді.
Бағдарламалар адамдар оқуы үшін жазылуы керек, ал олардың машиналар тарапынан орындалуы — тек жанама құбылыс.
Сізге тек пайдаланушыларыңызға ғана емес, сонымен қатар оқырмандарыңызға да эмпатия таныту қажет. Бұл сіздің өз мүддеңізге сай, өйткені олардың бірі өзіңіз боласыз. Талай хакер бағдарлама жазып, алты айдан кейін оған қайта оралғанда, оның қалай жұмыс істейтінін мүлде түсінбей қалған. Мен осындай тәжірибеден кейін Perl тілінен біржола бас тартқан бірнеше адамды білемін. [7]
Эмпатияның жоқтығы интеллектпен байланыстырылып жатады, тіпті кейбір ортада бұл өзіндік сәнге айналған. Бірақ мен олардың арасында қандай да бір байланыс бар деп ойламаймын. Сіз эмпатияны үйренбей-ақ математика мен жаратылыстану ғылымдарында жақсы жетістіктерге жете аласыз, ал бұл салалардағы адамдар әдетте ақылды келеді, сондықтан бұл екі қасиет өзара байланысты болып көріне бастаған. Бірақ эмпатиядан мақұрым ақымақ адамдар да өте көп. Ток-шоуларға телефон шалып сұрақ қоятын адамдарды тыңдап көріңізші. Олар өздерінің сұрайын дегенін соншалықты орағытып жеткізеді, тіпті жүргізушілерге сұрақты олар үшін қайта тұжырымдауға тура келеді.
Сонымен, егер хакерлік өнер кескіндеме мен жазушылық сияқты жұмыс істесе, ол да солар сияқты керемет пе? Ақыр соңында, сізге бір-ақ рет өмір беріледі. Оны ұлы бірдеңемен айналысуға арнаған дұрыс қой.
Өкінішке қарай, бұл сұраққа жауап беру қиын. Абырой-бедел мәселесінде әрқашан үлкен уақыт алшақтығы болады. Бұл алыстағы жұлдыздың жарығы сияқты. Кескіндеменің қазіргі абыройы — адамдардың бес жүз жыл бұрын жасаған ұлы еңбегінің нәтижесі. Сол кезде ешкім бұл картиналарды бүгінгі біз сияқты маңызды деп санамаған. Ол замандағы адамдарға Урбино герцогы Федерико да Монтефельтро бір күні Пьеро делла Франческаның картинасындағы таңқаларлық мұрны бар адам ретінде ғана танымал болады десе, өте оғаш көрінер еді.
Сондықтан қазір хакерлік кескіндеме сияқты керемет болып көрінбейтінін мойындасам да, біз кескіндеменің өзі де өзінің шарықтау дәуірінде қазіргідей беделді көрінбегенін есте ұстауымыз керек.
Біз толық сеніммен айта алатын нәрсе — қазір хакерліктің шарықтау дәуірі. Көптеген салаларда ұлы жұмыстар алғашқы кезеңде жасалады. 1430 бен 1500 жылдар аралығында салынған картиналардан әлі күнге ешкім асып түсе алған жоқ. Шекспир кәсіби театр жаңадан пайда болып жатқан кезде келді және бұл өнер түрін соншалықты биікке көтерді, содан бергі әрбір драматург оның көлеңкесінде өмір сүруге мәжбүр болды. Альбрехт Дюрер гравюрамен, ал Джейн Остин романмен дәл осылай істеді.
Біз бұл заңдылықты қайта-қайта көреміз. Жаңа орта немесе бағыт пайда болады және адамдар оған соншалықты қызығатыны сонша, оның барлық мүмкіндіктерін алғашқы екі ұрпақта толық зерттеп үлгереді. Хакерлік қазір дәл осы кезеңде тұрған сияқты.
Леонардоның кезінде кескіндеме оның туындылары алып келген деңгейдей керемет болып саналмаған еді. Хакерліктің қаншалықты керемет болатыны біздің осы жаңа бағытта не істей алатынымызға байланысты болады.
Ескертпелер
[1] Фотографияның кескіндемеге тигізген ең үлкен залалы — оның ең жақсы күнделікті күнкөріс көзін жойып жіберуі болуы мүмкін. Тарихтағы ұлы суретшілердің көпшілігі портрет салу арқылы күнелткен.
[2] Маған Microsoft компаниясы қызметкерлеріне тіпті бос уақытында да бастапқы коды ашық (open-source) жобаларға үлес қосуға тыйым салады деп айтты. Бірақ қазір ең жақсы хакерлердің көбі бастапқы коды ашық жобаларда жұмыс істейтіндіктен, бұл саясаттың негізгі нәтижесі — олардың бірінші дәрежелі бағдарламашыларды жұмысқа ала алмауына әкелуі мүмкін.
[3] Колледжде бағдарламалау туралы үйренетін нәрсеңіз кітаптар, киімдер немесе кездесулер туралы үйренетініңізге өте ұқсас: жоғары сыныпта талғамыңыздың қаншалықты нашар болғанын түсінесіз.
[4] Міне, қолданбалы эмпатияның бір мысалы. Viaweb-те екі балама нұсқаның арасында таңдау жасай алмағанда, біз: «Бәсекелестерімізді ең қатты ашындыратын нәрсе не?» деп сұрайтынбыз. Бір күні бәсекелесіміз өз бағдарламалық жасақтамасына негізінен пайдасыз бір функция қосты, бірақ ол бізде жоқ, оларда ғана бар аз ғана функциялардың бірі болғандықтан, олар салалық баспасөзде бұл туралы көп жарнамалады. Біз бұл функцияның пайдасыз екенін түсіндіруге тырысуымызға болар еді, бірақ оны өзіміз тез жасап алсақ, бәсекелесіміздің жүйкесіне көбірек тиеміз деп шештік, сөйтіп сол күні түстен кейін оның өз нұсқамызды кодтап шықтық.
[5] Мәтіндік редакторлар мен компиляторларды қоспағанда. Хакерлерге оларды жобалау үшін эмпатия қажет емес, өйткені олардың өздері типтік пайдаланушылар болып табылады.
[6] Шынын айтқанда, толық дерлік. Олар қолжетімді жедел жад (RAM) көлемін тым асырып бағалап, дискілерді үнемі ыңғайсыз ауыстыруға мәжбүр етті, бірақ мұны бірнеше айдың ішінде қосымша диск жетегін сатып алу арқылы түзетуге болатын еді.
[7] Бағдарламаларды оқуды жеңілдетудің жолы — оларды түсіндірмелермен (comments) толтырып тастау емес. Мен Абельсон мен Сассманның сөзін бір қадам ілгері апарар едім. Бағдарламалау тілдері алгоритмдерді сипаттау үшін жобалануы керек, ал олардың компьютерлерге қалай орындау керектігін айтуы — тек жанама құбылыс. Жақсы бағдарламалау тілі бағдарламалық жасақтаманы түсіндіру үшін ағылшын тілінен де жақсырақ болуы тиіс. Түсіндірмелер тек оқырмандарға қандай да бір шикі тәсіл (kludge) туралы ескерту қажет болғанда ғана керек болуы тиіс, дәл жолдағы күтпеген шұғыл бұрылыстарда ғана бағыттауыш белгілер болатыны сияқты.
Осы мәтіннің нобайларын оқып шыққаны үшін Тревор Блэквеллге, Роберт Морриске, Дэн Гиффинге және Лиза Рэндаллға, сондай-ақ сөз сөйлеуге шақырғаны үшін Генри Лейтнер мен Ларри Финкельштейнге алғыс айтамын.