Filosofia Gidatzailea
1. Pertsonentzako programazio-lengoaiak
Programazio lengoaiak jendeak ordenagailuekin hitz egiten duen modua dira. Ordenagailua pozik egongo da anbiguoa ez den edozein hizkuntza hitz egiten. Maila altuko hizkuntzak ditugun arrazoia jendeak ezin duelako makina hizkuntza kudeatu. Programazio lengoaien helburua gure giza garun pobre eta hauskor xehetasun gehiegiz gainezka ez izatea da.
Arkitektoek badakite diseinu arazo batzuk beste batzuk baino egunerokoagoak direla. Diseinu arazo argi eta abstraktuenetako batzuk zubien diseinua dira. Kasu honetan, zure lana behar den distantzia ahalik eta material gutxien egitea da. Espektroaren beste muturrean aulkiaren diseinua dago. Aulkien diseinatzaileek denbora eman behar dute jendearen ipurdietan pentsatzen.
Softwarearen garapenak antzeko aldea du. Datuak sare batean bideratzeko algoritmoak diseinatzea arazo polita eta abstraktua da, zubiak diseinatzea bezala. Programazio-lengoaiak diseinatzea aulkiak diseinatzea bezalakoa da: giza ahulguneei aurre egin behar diezu.
Gutako gehienentzat zaila da konturatzea. Sistema matematiko dotoreak diseinatzea askoz erakargarriagoa iruditzen zaigu gutako gehienentzat, giza ahulezietara jotzea baino. Dotorezia matematikoaren eginkizuna dotorezia mailaren batek programak ulertzea errazten duela da. Baina dena ez da dotorezia.
Eta hizkuntzak giza ahulezietara egokitzeko diseinatu behar direla esaten dudanean, ez dut esan nahi hizkuntzak programatzaile txarrentzat diseinatu behar direnik. Egia esan, programatzaile onenentzako softwarea diseinatu beharko zenuke, baina programatzaile onenek ere bere mugak dituzte. Ez dut uste inori gustatuko litzaiokeen hizkuntza batean programatzea non aldagai guztiak "x" hizkiarekin adierazten diren azpiindize osoekin.
2. Diseina ezazu zeuretzat eta zure lagunentzat
Programazio lengoaien historiari erreparatuz gero, hizkuntzarik onenak beren egileek erabiltzeko diseinatu ziren, eta txarrenak beste pertsona batzuek erabiltzeko diseinatu ziren.
Hizkuntzak beste pertsonentzat diseinatuta daudenean, beti pertsona talde zehatz bat da: pertsonak ez dira hizkuntzaren sortzaileak bezain adimentsuak. Honela lortzen duzu zurekin hitz egiten dizun hizkuntza. Cobol da adibiderik nabarmenena, baina hizkuntza gehienek izpiritu hori daukate.
Ez du zerikusirik hizkuntzaren maila altuarekin. C maila nahiko baxua da, baina bere egileek erabiltzeko sortu zen, horregatik hackerrek maite dute.
Programatzaile txarrentzako lengoaiak diseinatzeko argudioa da programatzaile txar gehiago daudela onak baino. Agian hala da. Baina programatzaile on kopuru txiki honek neurrigabeko software gehiago idazten du.
Nire galdera da, nola sortu hacker onenei erakartzen dien hizkuntza bat? Galdera hau programazio-lengoaia on bat nola sortu galderen berdina dela iruditzen zait?, baina hala ez bada ere, galdera interesgarria da behintzat.
3. Eman programatzaileari ahalik eta kontrol handiena
Hizkuntza askok (batez ere beste pertsonentzat diseinatutakoek) umezain bezala jokatzen dute: baliagarri izango ez zaizkizun gauzetatik urruntzen saiatzen dira. Alderantzizko ikuspegia hartzen dut: programatzaileari ahal duzun kontrol handiena eman.
Lisp ikasi nuenean, gehien gustatu zitzaidana berdintsu hitz egiten genuela izan zen. Ordurako ikasitako beste hizkuntzetan, hizkuntza bat zegoen, eta nire programa zegoen hizkuntza horretan, eta nahiko bereizita zeuden. Baina Lispen-en, nik idatzi nituen funtzioak eta makroak hizkuntza bera idatzita zegoen berberak ziren. Hizkuntza bera berridatzi nezake nahi izanez gero. Kode irekiko softwarearen erakargarritasun bera zuen.
4. Laburtasuna talentuaren arreba da
Laburtasuna gutxiesten da eta baita mespretxatua ere. Baina hackerren bihotzetara begiratzen baduzu, laburtasuna benetan gustatzen zaiela ikusiko duzu. Zenbat aldiz entzun al diezu hackerrei maitasunez hitz egiten, esate baterako, APL-n nola gauza harrigarriak egin ditzaketen kode lerro pare batekin? Uste dut oso adimendunak benetan arreta jartzea gustatzen zaiola honi.
Uste dut programak laburragoak egiten dituen ia gauza ona dela. Liburutegiko funtzio asko egon beharko luke, inplizitua izan daitekeen guztia hala izan beharko luke; sintaxia zehatzagoa izan beharko luke; entitateen izenak ere laburrak izan behar dira.
Eta ez programak bakarrik laburrak izan behar. Eskuliburuek ere laburrak izan behar dute. Eskuliburuen zati handi bat azalpenez, ezeztapenez, abisuz eta kasu bereziz beteta dago. Eskuliburua laburtu behar baduzu, hainbeste azalpen eskatzen duen hizkuntza zuzentzea da aukerarik onena.
5. Hacking-a zer den ezagutzea
Jende askok hacking matematika izatea gustatuko litzaioke, edo zientziaren antzeko zerbait behintzat. Uste dut hacking-a arkitekturaren antzekoa dela. Arkitektura fisika da, izan ere, arkitekto batek eroriko ez den eraikin bat diseinatu behar du, baina arkitekto baten benetako helburua eraikin handi bat sortzea da, ez estatikaren alorrean aurkikuntzak egitea.
Hackerrek maite dutena programa bikainak sortzea da. Eta uste dut, gure pentsamenduetan behintzat, gogoratu beharko genukeela programa bikainak idaztea gauza zoragarria dela, nahiz eta lan hori ez den erraz itzultzen artikulu zientifikoen ohiko dirutza intelektualean. Ikuspuntu intelektualetik, programatzaileei gustatuko zaien lengoaia bat diseinatzea bezain garrantzitsua da artikulu bat argitara dezakezun ideia bat jasotzen duen ikaragarri bat diseinatzea.
Arazo irekiak
1. Nola antolatu liburutegi handiak?
Liburutegiak programazio lengoaien zati garrantzitsu bat bihurtzen ari dira. Hain handitzen dira arriskutsua izan daitekeela. Behar duzuna egiten duen liburutegi batean funtzio bat aurkitzeko denbora gehiago behar bada funtzio hori zeuk idazteko baino, orduan kode guztiak zure eskuliburua loditzea baino ez du egiten. (Symbolics eskuliburuak horren adibide izan ziren.) Beraz, liburutegiaren antolaketa arazoa konpondu beharko dugu. Egokiena, diseinatzea programatzaileak liburutegiko funtzio egokia den asma dezan.
2. Jendeak benetan beldur al dio aurrizkiaren sintaxiari?
Arazo irekia da hau, hainbat urte daramatzat horretan pentsatzen eta oraindik erantzuna ez dakidala. Aurrizkien sintaxia guztiz naturala iruditzen zait, agian matematikan erabiltzeagatik izan ezik. Baina baliteke Lispen ezezagunaren zati handi bat sintaxi ezezagunari zor zaiola besterik gabe... Horri buruz ezer egin behar dugun, egia bada, beste kontu bat da.
3. Zer behar duzu zerbitzariaren softwarerako?
Datozen hogei urteetan idatziko diren aplikazio gehienak web aplikazioak izango direla uste dut, programak zerbitzari batean biziko direla eta zurekin web arakatzaile baten bidez komunikatuko direlako. Eta horrelako aplikazioak idazteko gauza berriak behar ditugu.
Gauza horietako bat zerbitzariaren aplikazioak askatzeko modu berri baten laguntza da. Urtean bertsio handi bat edo bi izan beharrean, mahaigaineko softwarea bezala, zerbitzariaren softwarea aldaketa txiki batzuetan kaleratuko da. Egunean bost edo hamar kaleratze izan ditzakezu. Eta guztiek izango dute beti azken bertsioa.
Ba al dakizu nola diseinatzen diren programak mantendu ahal izateko? Zerbitzariaren softwarea aldagarria izateko diseinatu behar da. Erraz aldatzeko gai izan beharko zenuke, edo behintzat aldaketa txiki batek zer esan nahi duen eta zer den garrantzitsua jakin.
Zerbitzariaren softwarean erabilgarria izan daitekeen beste gauza bat da, bat-batean, entregaren jarraipena. Web aplikazio batean antzeko zerbait erabil dezakezu web saioen estaturik gabeko munduan errutinen eragina lortzeko. Horniduraren jarraipena izateak merezi izan dezake funtzioa oso garestia ez bada.
4. Zein abstrakzio berri geratzen dira aurkitzeko?
Ez nago ziur itxaropen hori zenbaterainokoa den, baina pertsonalki oso gustatuko litzaidake abstrakzio berri bat aurkitzea, lehen mailako funtzioak edo errekurtsioa edo gutxienez parametro lehenetsiak bezain esanguratsua izan daitekeena. Agian hau ezinezko ametsa da. Horrelako gauzak askotan ez dira deskubritzen. Baina ez dut itxaropena galtzen.
Ezagutzen diren sekretuak
1. Nahi duzun hizkuntza erabil dezakezu
Aurretik, aplikazioak sortzeak mahaigaineko softwarea sortzea suposatzen zuen. Eta mahaigaineko softwarean aplikazioak sistema eragilearen hizkuntza berean idazteko joera handia dago. Beraz, duela hamar urte, softwarea idazteak orokorrean C-n idaztea esan nahi zuen. Azkenean, tradizioa eboluzionatu zen: aplikazioak ez ziren hizkuntza ezohikoetan idatzi behar. Eta tradizio hori hainbeste denboran eboluzionatu da, ezen teknikariak ez diren pertsonek, esaterako, kudeatzaileak eta arrisku kapitalistak ere ikasi dute.
Zerbitzariaren softwareak eredu hau erabat suntsitzen du. Zerbitzariaren softwarearekin nahi duzun hizkuntza erabil dezakezu. Ia inork ez du hori ulertzen oraindik (batez ere kudeatzaileek eta arrisku kapitalistek). Baina hacker batzuek hori ulertzen dute, horregatik Perl eta Python bezalako indy hizkuntzei buruz entzuten dugu. Ez dugu Perl eta Python-i buruz entzuten jendeak Windows aplikazioak idazteko erabiltzen dituelako.
Zer esan nahi du horrek guretzat, programazio-lengoaiaren diseinuan interesa duten pertsonentzat, gure lanerako entzule potentzial bat dagoela.
2. Abiadura profileretatik dator
Hizkuntzen garatzaileek, edo, gutxienez, hizkuntza inplementatzaileek, kode azkarra sortzen duten konpilatzaileak idaztea gustatzen zaie. Baina uste dut ez dela hori hizkuntzak erabiltzaileentzat azkar egiten dituena. Knuth-ek aspaldi adierazi zuen abiadura botila gutxi batzuen araberakoa dela. Eta programa bat bizkortzen saiatu denak badaki ezin duzula asmatzen non dagoen botila-lepoa. Profiler da erantzuna.
Hizkuntza-garatzaileak arazo okerra konpontzen ari dira. Erabiltzaileek ez dute erreferentziarik behar azkar exekutatzeko. Beren programaren zein zati berridatzi behar diren erakusteko hizkuntza behar dute. Une honetan, abiadura behar da praktikan. Beraz, agian hobe litzateke hizkuntza inplementatzaileek konpilatzailea optimizatzen ematen duten denboraren erdia pasatzea eta profilera on bat idazten gastatzea.
3. Zure hizkuntza eboluzionatzen duen aplikazio bat behar duzu
Baliteke hau ez izatea azken egia, baina badirudi hizkuntzarik onenak erabili ziren aplikazioekin batera eboluzionatu zutela. C sistemen programazioa behar zuten pertsonek idatzi zuten. Lisp bereizketa sinbolikorako diseinatu zen neurri batean, eta McCarthy oso irrikaz zegoen hasteko, ezen 1960an lehen Lisp paperean bereizketa programak idazten hasi baitzen.
Hau bereziki ona da zure aplikazioak arazo berri batzuk konpontzen baditu. Horrek zure hizkuntza bultzatzen du programatzaileek nahi dituzten ezaugarri berriak izan ditzaten. Pertsonalki, zerbitzariko aplikazioetarako ona izango den hizkuntza bat idaztea interesatzen zait.
[Eztabaida garaian, Guy Steelek ere puntu hau adierazi zuen, eta gehitu zuen aplikazioak ez lukeela zure hizkuntzarako konpilatzaile bat idaztean izan behar, zure hizkuntza konpiladoreak idazteko diseinatuta badago behintzat.]4. Hizkuntza egokia izan behar da behin-behineko programak idazteko.
Badakizu zer esan nahi duen bakarkako programa batek: arazo mugatu bat azkar konpondu behar duzunean da. Uste dut inguruan begiratuz gero, programa serio asko aurkituko dituzula behin-behinean hasi zirenak. Ez nintzateke harrituko programa gehienak behin-behineko moduan hastea. Horrela, orokorrean softwarea idazteko egokia izango den hizkuntza bat sortu nahi baduzu, programa puntualak idazteko ere egokia izan beharko luke, programa askoren hasierako etapa baita.
5. Sintaxia semantikarekin lotuta dago
Tradizionalki sintaxia eta semantika gauza oso desberdinak direla uste da. Hau harrigarria dirudi, baina ez da. Uste dut zure programan lortu nahi duzuna nola adierazten duzunarekin zerikusia duela.
Duela gutxi Robert Morris-ekin hitz egin nuen eta adierazi zuen operadoreak gainkargatzea abantaila handia dela sintaxia infixa duten hizkuntzen garaipena lortzeko. Aurrizkiaren sintaxia duten hizkuntzetan, definitzen duzun edozein funtzio operadore bat da. Osatutako zenbaki-mota berri bat gehitu nahi baduzu, gehitzeko funtzio berri bat defini dezakezu. Sintaxia infixa duen hizkuntza batean egiten baduzu, ikusiko duzu alde handia dagoela gainkargatutako operadore bat erabiltzearen eta funtzio bat deitzearen artean.
Denborarekin itzultzen diren ideiak
1. Programazio-lengoaia berriak
1970eko hamarkadara begira, modan zegoen programazio lengoaia berriak garatzea. Orain ez da horrela. Baina uste dut zerbitzariaren softwareak berriro itzuliko duela hizkuntza berriak sortzeko moda. Zerbitzariaren softwarearekin nahi duzun hizkuntza erabil dezakezu, beraz, norbaitek gainerakoak baino hobea dirudien hizkuntza bat sortzen badu, jendea egongo da erabiltzea erabakiko duena.
2. Denbora partekatzea
Richard Kelseyk ideia hau bururatu zuen, zeinaren garaia berriro heldu den eta guztiz onartzen dut. Nire ustez (eta Microsoftena ere) da informatika asko mahaigainetik urruneko zerbitzarietara mugituko dela. Beste era batera esanda, denbora partekatzea itzuli da. Honek hizkuntza mailan laguntza beharko duela uste dut. Adibidez, Richard eta Jonathan Reeves-ek lan handia egin dute 48. eskeman prozesuen programazioa ezartzeko.
3. Eraginkortasuna
Duela gutxi bazirudien ordenagailuak nahikoa azkarrak zirela jada. Gero eta gehiago entzuten ari gara bytekodeari buruz, eta horrek esan nahi du, behintzat, boterea erreserbatuta dugula. Baina zerbitzariaren softwarearekin ez dugula uste dut. Norbaitek softwarea exekutatzen duten zerbitzariengatik ordaindu beharko du, eta zerbitzariak makina bakoitzeko onar dezakeen erabiltzaile kopurua beren kapital-kostuen zatitzailea izango da.
Uste dut eraginkortasunak garrantzia izango duela, informatika-botoietan behintzat. Hau bereziki garrantzitsua izango da I/O eragiketetarako, zerbitzariaren aplikazioek eragiketa asko egiten dituztelako.
Azkenean, gerta daiteke bytecode ez dela erantzuna. Sun eta Microsoft badirudi buruz buru ari direla bytecode eremuan momentuz. Baina hau egiten dute bytecode prozesu batean txertatzeko leku erosoa delako, ez bytecode bera ideia ona delako. Gerta liteke borroka hori guztia oharkabean pasatzea. Dibertigarria izango litzateke.
Lazoak eta amarruak
1. Bezeroak
Hau asmakizun bat besterik ez da, baina onura aterako duten aplikazio bakarrak zerbitzariaren aldetik daudenak dira. Pertsona orok bezeroa izango duela kontuan hartuta funtzionatzen duen softwarea diseinatzea gizarte bat diseinatzea bezalakoa da, denak zintzoak izango direlakoan oinarrituta. Erosoa izango litzateke zalantzarik gabe, baina inoiz ez dela gertatuko suposatu behar duzu.
Uste dut sarean gaitutako gailuen igoera azkarra izango dela, eta oinarrizko html eta inprimakiak onartzen dituztela pentsa dezakegu. Zure telefonoan arakatzailerik al duzu? Zure PalmPilot-ek telefonorik izango al du? Zure masustak pantaila handiagoa izango al du? Zure gameboy-etik Internetera sartzeko gai izango zara? Zure erlojutik? Ez dakit. Eta ez dut jakin beharko dena zerbitzarian egongo dela apustu egiten dudan. Askoz fidagarriagoa da garun guztiak zerbitzarian edukitzea. .
2. Objektuetara zuzendutako programazioa
Konturatzen naiz adierazpen polemikoa dela, baina ez dut uste OOP horren garrantzitsua denik. Uste dut paradigma egokia dela datu-egitura zehatzak behar dituzten aplikazio zehatzetarako, hala nola leiho-sistemak, simulazioak, CAD sistemak. Baina ez dut ulertzen zergatik izan behar duen egokia programa guztietarako.
Nire ustez, enpresa handietako jendeak OOP maite du, neurri batean, lan itxura duten gauza asko egiten dituelako. Berez irudika daitekeena, esate baterako, zenbaki osoen zerrenda gisa, orain ikasgela gisa irudika daiteke era guztietako aldamioak, zalapartak eta zalapartak.
OOPren beste ezaugarri erakargarri bat metodoek lehen mailako funtzioen efekturen bat ematen dizutela da. Baina hau ez da albistea Lisp programatzaileentzat. Benetako lehen mailako funtzioak dituzunean, esku artean duzun zereginari egokitzen zaion moduan erabil ditzakezu, dena klase eta metodo multzo batean sartu beharrean.
Uste dut horrek hizkuntza-diseinurako esan nahi duena ez duzula OOP-a oso sakon txertatu behar. Agian erantzuna gauza orokorragoak, oinarrizkoak eskaintzea eta jendeari edozein objektu-sistema liburutegi gisa diseinatzea da.
3. Batzordearen diseinua
Zure hizkuntza batzorde batek diseinatu badu, orduan harrapatuta zaude, eta ez denek ezagutzen dituzten arrazoiengatik bakarrik. Denek daki batzordeek hizkuntza diseinu koherenteak eta koherenteak sortzeko joera dutela. Baina uste dut arrisku handia ez dutela arriskurik hartzen. Pertsona bat arduraduna denean, batzordeak bere gain hartzea onartuko ez lituzkeen arriskuak hartzen ditu.
Arriskatu behar al duzu hizkuntza on bat sortzeko? Jende askok susma dezake hizkuntza-diseinua tradizionalaren jakituritik nahiko hurbil egon behar dela. Apustu dut ez dela horrela. Jendeak egiten duen beste guztian, saria arriskuarekiko proportzionala da. Beraz, zergatik izan behar da desberdina hizkuntza-diseinua?
Iturria: www.habr.com