Filozofia udhëheqëse
1. Gjuhët e programimit për njerëzit
Gjuhët e programimit janë mënyra se si njerëzit flasin me kompjuterët. Kompjuteri do të gëzohej të fliste në çdo gjuhë që nuk është e paqartë. Arsyeja pse kemi gjuhë të larta është sepse njerëzit nuk mund ta përballojnë gjuhën e makinerive. Thelbi i gjuhëve të programimit është të parandalojë trurin tonë të brishtë nga mbingarkesa me shumë detaje.
Arkitektët e dinë se disa probleme të dizajnit janë më të thjeshta se të tjera. Një nga problemet më të qarta dhe abstracte të dizajnit është ndërtimi i urave. Në këtë rast, detyra juaj është të përshkruani distancën e kërkuar me sa më pak material të jetë e mundur. Në anën tjetër të spektit është dizajni i karrigeve. Dizajnerët e karrigeve duhet të kalojnë kohën e tyre duke menduar për pasqyrat njerëzore.
Zhvillimi i softuerëve ka një diversitet të ngjashëm. Projektimi i algoritmeve për ruterimin e të dhënave përmes një rrjeti është një problem i mirë, abstrakt, ashtu siç është projektimi i urave. Ndërsa projektimi i gjuhëve të programimit është si të projektosh karrige: duhet të merresh me dobësitë njerëzore.
Më shumë e vështirë për shumicën e nesh të kuptojmë këtë. Projektimi i sistemeve matematike elegante tingëllon shumë më tërheqëse për shumicën e nesh sesa përkëdhelja e dobësive njerëzore. Roli i elegancës matematike është që një shkallë e caktuar elegancë e bën programet më të lehta për t'u kuptuar. Por eleganca nuk është gjëja e vetme që ka rëndësi.
Dhe kur them se gjuhët duhet të projektohen në mënyrë që të marrin parasysh dobësitë njerëzore, nuk kam parasysh se gjuhët duhet të projektohen për programuesit e dobët. Në të vërtetë, ju duhet të projektoni softuer për programuesit më të mirë, por edhe programuesit më të mirë kanë kufijtë e tyre. Nuk mendoj se dikush do të donte të programonte në një gjuhë ku të gjitha variablat do të ishin të emëruar me shkronjën 'x' me indekse të numrave të plotë.
2. Projektoni për veten dhe për miqtë tuaj
Nëse e shikoni historinë e gjuhëve të programimit, shumica e gjuhëve më të mira janë projektuar për t'u përdorur nga autorët e tyre, ndërsa shumica e atyre më të këqijave janë projektuar për njerëz të tjerë.
Kur gjuhët projektohen për njerëz të tjerë, gjithmonë ka një grup të caktuar njerëzish: njerëzit nuk janë aq të mençur sa krijuesit e gjuhës. Kështu merrni një gjuhë që ju flet me përbuzje. Cobol është shembulli më i dukshëm, por shumica e gjuhëve janë ngopur me këtë frymë.
Kjo nuk ka të bëjë me sa të avancuar është gjuha. C është mjaft e ulët në nivel, por është krijuar për t'u përdorur nga autorët e saj, kjo është arsyeja pse hakerat e duan atë.
Argumenti për projektimin e gjuhëve për programuesit e dobët është se ka më shumë programues të dobët sesa të mirë. Ndoshta, është e vërtetë. Por kjo pakicë e programuesve të mirë shkruan një sasi të paproportionalisht më të madhe software.
Më intereson një pyetje, si të krijoj një gjuhë që do të pëlqehej nga hakerat më të mirë? Më duket se kjo pyetje është e barabartë me pyetjen, si të krijoj një gjuhë të mirë programimi?, por edhe nëse nuk është kështu, është të paktën një pyetje interesante.
3. Jepni programuesit sa më shumë kontroll të jetë e mundur
Shumë gjuhë (sidomos ato që janë krijuar për njerëz të tjerë) silen si kujdestarë: përpiqen t'ju paralajmërojnë për gjëra që ata mendojnë se nuk do t'ju jenë të dobishme. Unë kam qëndrim të kundërt: jepni programuesit sa më shumë kontroll që të mundeni.
Kur fillova të studioj Lisp, më pëlqeu më së shumti se ne flisnim si të barabartë. Në gjuhët e tjera që kisha studiuar deri në atë pikë, kishte një gjuhë, dhe kishte programin tim në atë gjuhë, dhe ato ekzistonin mjaft gjithnjë të ndara. Por në Lisp, funksionet dhe makros që shkrova ishin po aq të njëjta me ato mbi të cilat ishte shkruar vetë gjuha. Mund ta riprogramoja vetë gjuhën nëse doja. Ai kishte të njëjtin tërheqje si softi me kod të hapur.
4. Shkurtësia është motra e talentit
Shkurtësia nënvlerësohet dhe madje përbuzet. Por nëse shikoni në zemrat e hakerëve, do të shihni se ata e duan shumë shkurtësinë. Sa herë keni dëgjuar hakerët të flasin me dashuri për atë që, për shembull, në APL ata mund të bëjnë gjëra të mrekullueshme me vetëm disa rreshta kodi? Mendoj se njerëzit e vërtetë të mençur në fakt e duan të bëjnë vëmendje të tillë.
Mendoj se pothuajse çdo gjë që e bën programin më të shkurtër është e mirë. Duhet të ketë shumë funksione biblioteke, gjithçka që duhet të jetë e nënkuptuar — duhet të jetë e tillë; sintaksa duhet të jetë më shumë e shkurtër; madje emrat e entiteteve duhet të jenë të shkurtër.
Dhe jo vetëm programet duhet të jenë të shkurtra. Manualet gjithashtu duhet të jenë të shkurtra. Një pjesë e mirë e manualeve është e mbushur me shpjegime, rezervime, paralajmërime dhe raste të veçanta. Nëse ju nevojitet të shkurtoni një manual, opsioni më i mirë është të korrigjoni gjuhën që kërkon kaq shumë shpjegime.
5. Pranojeni se çfarë është hakerizmi
Shumë njerëz do të dëshironin që hakerizmi të ishte matematikë ose, të paktën, diçka e ngjashme me shkencat natyrore. Unë mendoj se hakerizmi është më shumë si arkitektura. Arkitektura është e lidhur me fizikën, në kuptimin që arkitekti duhet të projektojë një ndërtesë që nuk do të bjerë, por qëllimi i vërtetë i arkitektit është të krijojë një ndërtesë të madhe, e jo të bëjë zbulime në fushën e statikës.
Ajo që hakerët e duan, është të krijojnë programe të mëdha. Dhe unë mendoj se, të paktën në mendjet tona, duhet të kujtojmë se shkruajtja e programeve të shkëlqyera është e mrekullueshme, edhe kur kjo punë nuk përkthehet lehtësisht në valutën intelektuale të punimeve shkencore. Nga pikëpamja intelektuale, po aq e rëndësishme është zhvillimi i një gjuhe që do të dashurohet nga programuesit, dhe krijimi i një ideje të frikshme, mbi të cilën mund të publikoni një artikull.
Problemet e hapura
1. Si të organizoni biblioteka të mëdha?
Bibliotekat pojnë të bëhen një pjesë e rëndësishme e gjuhëve të programimit. Ato po bëhen kaq të mëdha saqë mund të jenë të rrezikshme. Nëse kërkohet më shumë kohë për të gjetur një funksion në bibliotekë që bëni atë që ju nevojitet sesa të shkruani këtë funksion vetë, atëherë e gjithë kodi nuk bën tjetër veçse e mbush manualin tuaj. (Manualet e Symbolics ishin një shembull i tillë.) Pra, do të duhet të zgjidhim problemin e organizimit të bibliotikave. Idealja është t'i projektojmë ato në mënyrë që programuesi të mund të kuptojë se cili funksion i bibliotekës do të përshtatet.
2. A ndihen njerëzit vërtet të frikësuar nga sintaksa prefiks?
Kjo është një problem i hapur në sensin që kam menduar për të për disa vite dhe ende nuk e di përgjigjen. Sintaksa prefiks më duket krejtësisht e natyrshme, ndoshta përveç përdorimit të saj në matematikë. Por ndoshta kaq shumë nga pakënaqësia ndaj Lisp-it është thjesht për shkak të sintaksës së panjohur... A duhet të bëjmë diçka me këtë, nëse është e vërtetë, është një Pyetje tjetër.
3. Çfarë ju nevojitet për softuerin e serverit?
Mendoj se shumica e aplikacioneve që do të shkruhen në dvjet e ardhshme do të jenë aplikacione web, në kuptimin që programet do të jenë të vendosura në server dhe do të komunikojnë me ju përmes shfletuesit të internetit. Dhe për të shkruar këto aplikacione na nevojiten gjëra të reja.
Një nga këto gjëra është mbështetje për një mënyrë të re të lëshimit të aplikacioneve serverike. Në vend që të ketë një ose dy lëshime të mëdha në vit, siç ndodh me softin desktop, softi serverik do të lëshohet përmes një serie ndryshimesh të vogla. Mund të keni pesë ose dhjetë lëshime në ditë. Dhe të gjithë do të kenë gjithmonë versionin më të fundit.
A e dini si të dizajni programet në mënyrë që ato të jenë të mbështetura? Softi serverik duhet të dizajnohet për t'u bërë i ndryshueshëm. Ju duhet të keni mundësinë ta ndryshoni lehtësisht, ose të paktën të dini se çfarë do të thotë një ndryshim i vogël dhe çfarë është e rëndësishme.
Një tjetër gjë që mund të jetë e dobishme në softin serverik është, papritur, continuiteti i dërgesës. Në një aplikacion web ju mund të përdorni diçka si , për të marrë efektin e nënprogrameve në botën stateless të sesioneve të uebit. Mund të ketë një vazhdimësi të ofrimit që ia vlen, nëse kjo mundësi nuk do të ishte shumë e shtrenjtë.
4. Çfarë abstraksionesh të reja kanë mbetur për t'u zbuluar?
Nuk jam i sigurt se sa e arsyeshme është një shpresë e tillë, por personalisht do të doja shumë të zbulonim një abstraksion të ri — diçka që mund të kishte një rëndësi të madhe, si funksionet e klasës së parë, rekursioni, ose të paktën parametrat me vlera default. Ndoshta kjo është një ëndërr e pamundur. Gjëra të tilla shpesh nuk zbulohen. Por nuk e humbas shpresën.
Sekretet e panjohura
1. Mund të përdorni çdo gjuhë që dëshironi
Më parë, krijimi i aplikacioneve nënkuptonte krijimin e softuerit për desktop. Dhe në softuerin për desktop kishte një tendencë të madhe drejt shkruarjes së aplikacioneve në të njëjtën gjuhë si sistemi operativ. Kështu, dhjetë vjet më parë, zhvillimi i softuerit në përgjithësi nënkuptonte zhvillimin e softuerit në C. Me kalimin e kohës, tradita evoluoi: aplikacionet nuk duhet të shkruhen në gjuhë të pazakonta. Dhe kjo traditë u zhvillua për kaq shumë kohë, saqë njerëzit jo teknikë, si menaxherët dhe kapitalistët e riskut, e mësuan gjithashtu këtë.
Programimi i serverëve e eliminon plotësisht këtë model. Me programimin e serverëve, mund të përdorësh cilindo gjuhë që dëshiron. Pothuajse askush nuk e kupton akoma këtë (veçanërisht menaxherët dhe kapitalistët e rrezikut). Por disa hakerë e kuptojnë, prandaj kemi dëgjuar për gjuhë si Perl dhe Python. Ne nuk dëgjojmë për Perl dhe Python, sepse njerëzit i përdorin ato për të shkruar aplikacione për Windows.
Çfarë do të thotë kjo për ne, njerëzit e interesuar në projektimin e gjuhëve të programimit, është se ekziston një audiencë potenciale për punën tonë.
2. Shpejtësia vjen nga profailuesit
Zhvilluesit e gjuhës, ose të paktën ata që e realizojnë, duan të shkruajnë kompilatorë që gjenerojnë kod të shpejtë. Por mendoj se nuk është kjo ajo që i bën gjuhët të shpejta për përdoruesit. Knuth vuri në dukje që shpejtësia varet vetëm nga disa ngushtica. Dhe kushdo që ka provuar të përshpejtojë një program e di që nuk mund të hamendëshësh se ku është ngushtica. Profailuesi është përgjigjja.
Zhvilluesit e gjuhës po zgjidhin një problem të gabuar. Përdoruesit nuk kanë nevojë që benchmark-et të funksionojnë shpejt. Atëherë ata kanë nevojë për një gjuhë që mund të tregojë se cilat pjesë të programit të tyre duhet të rishkruhen. Në këtë moment, shpejtësia është e nevojshme në praktikë. Ndoshta do të ishte më mirë nëse realizuesit e gjuhës do të shpenzonin gjysmën e kohës që ata harxhojnë për optimizimin e kompilatorit dhe ta kalonin atë në krijimin e një profiler-i të mirë.
3. Ju nevojitet një aplikacion që motivon zhvillimin e gjuhës tuaj.
Mund të mos jetë e vërteta e fundit, por duket se gjuhët më të mira janë zhvilluar së bashku me aplikacionet ku janë përdorur. C u shkrua nga njerëzit që kishin nevojë për programim sistemor. Lisp u zhvillua pjesërisht për diferencimin simbolik, dhe McCarthy ishte kaq i padurueshëm sa që filloi të shkruante programe diferencuese madje në dokumentin e parë të Lisp-it në vitin 1960.
Kjo është veçanërisht e mirë nëse aplikacioni juaj zgjidh disa probleme të reja. Kjo shtyn gjuhën tuaj të ketë disa funksionalitete të reja që i nevojiten programuesve. Personalish, jam i interesuar të shkruaj një gjuhë që do të jetë e mirë për aplikacionet server.
[Gjatë diskutimit, Guy Steele gjithashtu shprehu këtë mendim, duke shtuar se aplikacioni nuk duhet të jetë një kompilator për gjuhën tuaj, përveç nëse gjuha juaj është e destinuar për të shkruar kompilatorë.]
4. Gjuha duhet të jetë e përshtatshme për të shkruar programe njëherë.
Ju e dini se çfarë do të thotë një program njëherë: është kur ju nevojitet të zgjidhni shpejt një problem të kufizuar. Unë besoj se nëse shikoni rreth, do të zbuloni shumë programe serioze që kanë filluar si programe njëherë. Nuk do të më befasonte nëse shumica e programeve kanë filluar si njëherësh. Prandaj, nëse doni të krijoni një gjuhë që do të ishte e përshtatshme për të shkruar softuer në përgjithësi, ajo duhet gjithashtu të jetë e përshtatshme për të shkruar programe njëherë, sepse kjo është faza fillestare e shumë programeve.
5. Sintaksa është e lidhur me semantikën
Tradicionalisht besohet se sintaksa dhe semantika janë gjëra të ndryshme. Mund të duket e habitshme, por nuk është kështu. Mendoj se ajo që dëshironi të merrni në programin tuaj është e lidhur me mënyrën se si e shprehni atë.
Së fundi kam biseduar me Robert Morrisin, dhe ai vuri në dukje se mbingarkimi i operatorëve është një përfitim i madh në fitoren e gjuhëve me sintaksë infiksore. Në gjuhët me sintaksë prefiksore, çdo funksion që ju përcaktoni në të vërtetë është një operator. Nëse doni të shtoni një tip të ri numri që e keni shpikur, mund të përcaktoni thjesht një funksion të ri për ta shtuar atë. Nëse e bëni këtë në një gjuhë me sintaksë infiksore, do të vini re se ka një diferencë të madhe midis përdorimit të operatorit të mbingarkuar dhe thirrjes së funksionit.
Idetë që rikthehen me kalimin e kohës
1. Gjuha të reja programuese
Duke u kthyer pas në vitet 1970, ishte në modë të zhvillohej gjuhë të reja programuese. Tani nuk është më kështu. Megjithatë, mendoj se softueri serverik do të sjellë përsëri modën për krijimin e gjuhëve të reja. Me softuerin serverik mund të përdorni çfarëdo gjuhe që dëshironi, kështu që nëse dikush krijon një gjuhë që duket më e mirë se të tjerat, do të ketë njerëz që do të vendosin ta përdorin atë.
2. Ndërprerja e kohës
Richard Kelsey e paraqitur këtë ide, koha e së cilës ka ardhur përsëri, dhe unë e mbështes plotësisht. Mendoj se (dhe Microsoft gjithashtu) shumë llogaritje do të kalojnë nga desktopët në serverat e largët. Në fjalë të tjera, ndarja e kohës ka rikthyer. Mendoj se do të nevojitet mbështetje për këtë në nivelin e gjuhës. Për shembull, Richard dhe Jonathan Rees kanë bërë shumë punë për të implementuar planifikimin e procesit në Scheme 48.
3. Efikasiteti
Së fundmi, dukej se kompjuterët ishin mjaft të shpejtë. Po dëgjojmë gjithnjë e më shumë për bytecode, që për mua do të thotë se kemi fuqi në rezervë. Por mendoj se me softin e serverëve, nuk e kemi atë. Diku duhet të paguhet për falas. Kjo është vetëm një nga shumë privilegjet që ofrojmë për klientët tanë të rinj të web-hosting., mbi të cilat punon softi, dhe numri i përdoruesve që serveri mund të mbajë për çdo makinë do të jetë ndarësi i shpenzimeve të tyre kapitale.
Mendoj se efikasiteti do të ketë rëndësi, të paktën në ngushticat e llogaritjeve. Kjo do të jetë veçanërisht e rëndësishme për operacionet e hyrje-daljes, sepse aplikacionet e serverëve prodhojnë shumë nga këto operacione.
Mund të ndodhë që bytecode të mos jetë zgjidhja. Sun dhe Microsoft duket se po luftojnë ballë për ballë në fushën e bytecode. Por ata e bëjnë këtë, sepse bytecode është një vend i përshtatshëm për t'u përfshirë në proces, jo sepse bytecode vetë është një ide e mirë. Mund të ndodhë që e gjithë kjo luftë të kalojë pa u vënë re. Do të ishte qesharake.
Kapakët dhe kurthe
1. Klientët
Kjo është vetëm një supozim, por është se do të fitojnë vetëm ato aplikacione që do të jenë plotësisht serverike. Duke projektuar softuer që funksionon me supozimin se çdo kush do të ketë klientin tuaj, duket sikur po krijoni një shoqëri të bazuar në supozimin se të gjithë do të jenë të ndershëm. Kjo do të ishte padyshim e përshtatshme, por ju do të duhet të pranoni se kjo kurrë nuk do të ndodhë.
Mendoj se do të ketë një rritje të shpejtë të pajisjeve me qasje në internet, dhe mund të supozoj se ato do të mbështesin HTML bazik dhe forma. A keni një shfletues në telefonin tuaj? A do të jetë telefoni në PalmPilot-in tuaj? A do të ketë ekran më të madh blackberry juaj? A do të keni mundësi të lidheni në internet nga Gameboy-i juaj? Nga orët tuaja? Nuk e di. Dhe nuk do të duhet ta di, nëse bëj një bast se gjithçka do të jetë në server. Është thjesht shumë më e sigurt të kesh të gjithë mendjen në server.
2. Programimi i orientuar në objekte
E kuptoj se kjo është një deklaratë e kundërt, por nuk mendoj se OOP është diçka e rëndësishme. Mendoj se është një paradigëm i përshtatshëm për aplikacione të caktuara që kanë nevojë për struktura specifike të dhënash, si sistemet e dritareve, simulimet, sistemet CAD. Por nuk e kuptoj se pse ajo duhet të jetë e përshtatshme për të gjitha programet.
Mendoj se njerëzit në kompanitë e mëdha e duan OOP-në, pjesërisht sepse ajo ofron shumë nga ajo që duket si punë. Ajo që natyrshëm mund të përfaqësohet si, le të themi, një listë e numrave të plotë, tani mund të përfaqësohet si një klasë me të gjitha llojet e strukturave për ndihmë, me zhurmë e trazira.
Një tjetër karakteristikë tërheqëse e OOP është se metodet ju ofrojnë një lloj efekti të funksioneve të klasës së parë. Por kjo nuk është një lajm për programuesit e Lisp-it. Kur keni funksione të vërteta të klasës së parë, mund t'i përdorni ato në çdo mënyrë që i përshtatet detyrës në vend të shtytjes së gjithçkaje për t'u përfshirë në një model të klasave dhe metodave.
Mendoj se kjo do të thotë për dizajnin e gjuhës që nuk duhet të integroni OOP shumë thellë brenda saj. Ndoshta përgjigja është të ofroni gjëra më të përgjithshme, bazike, dhe t'u lejoni njerëzve të projektuan çdo sistem objektesh si biblioteka.
3. Projektimi nga një komitet
Nëse gjuha juaj projektuot nga një komitet, atëherë jeni në një kurth, dhe jo vetëm për arsyet që janë të njohura për të gjithë. Të gjithëve u dihet se komitetet kanë prirjen të krijojnë një dizajn të gjuhës të trashë dhe të papajtueshëm. Por mendoj se rreziku më i madh është se ata nuk kanë guximin të marrin rreziqe. Kur një individ qëndron në krye, ai merr rreziqet që një komitet kurrë nuk do të pranojë.
A duhet të rrezikoni për të krijuar një gjuhë të mirë? Shumë njerëz mund të dyshojnë se projektimi i gjuhës është diçka ku duhet të mbahesh shumë afër mençurisë tradicionale. Unë mund të argumentoj se nuk është kështu. Në të gjithë aspektet e tjera që bëjnë njerëzit, shpërblimi është proporcionale me rrezikun. Pse duhet të jetë ndryshe në projektimin e gjuhëve?
Burimi: habr.com
