Viis küsimust programmeerimiskeelte projekteerimise kohta

Juhtiv filosoofia

1. Programmeerimiskeeled inimeste jaoks

Programmeermiskeeled on viis, kuidas inimesed suhtlevad arvutitega. Arvuti rõõmustab, kui räägitakse ükskõik millises keeles, mis ei ole mitmeti tõlgendatav. Põhjus, miks meil on kõrgema taseme keeled, on see, et inimesed ei suuda masinakeelega toime tulla. Programmeerimiskeelte olemus on vältida, et meie haprad inimmeelelised ajud ületaksid koormust detailide hulgast.

Arhitektid teavad, et teatud projekteerimisprobleemid on praktilisemad kui teised. Üks kõige selgemaid ja abstraktsemaid projekteerimisse seotud küsimusi on sildade projekteerimine. Sellisel juhul on teie töö, et katta vajalik kaugus võimalikult väheste materjalide abil. Teisel pool spektrit on toolide projekteerimine. Toolide projekteerijad peavad pühendama oma aega inimeste istumisega seotud küsimustele.

Tarkvaraarendusel on sarnane erinevus. Andmete suunamise algoritmide projekteerimine võrgu kaudu on hea, abstraktne probleem nagu sildade projekteerimine. Samas on programmeerimiskeelte projekteerimine sarnane toolide projekteerimisega: peab arvestama inimlike nõrkustega.

Enamik meist leiab selle tunnustamise keeruliseks. Elegantsete matemaatiliste süsteemide projekteerimine kõlab paljudele meist palju atraktiivsemalt kui inimeste nõrkuste rahuldamine. Matemaatilise elegantsi roll on selles, et teatud määral elegantsus muudab programmid arusaadavamaks. Kuid elegants ei ole ainus asi.

Ja kui ma ütlen, et keeled peavad olema projekteeritud arvestama inimlike nõrkustega, siis ei tähenda see, et keeled peaksid olema projekteeritud halva programmeerimise jaoks. Tegelikult peaksite projekteerima tarkvara parimatele programmeerijatele, kuid isegi parimad programmeerijad ulatuvad lõpuni. Ma ei usu, et keegi sooviks programmeerida keeles, kus kõik muutujad oleksid tähistatud tähega „x” ja tervikindeksitega.

2. Projekteeri endale ja oma sõpradele

Kui vaadata programmeerimiskeelte ajalugu, siis enamik parimaid keeli on loodud nende autorite enda kasutamiseks, samas kui enamik halvimaid on loodud teiste inimeste jaoks.

Kui keeled on kavandatud teistele inimestele, on see alati mõnele kindlale inimgrupile: inimesed ei ole nii targad kui keele loojad. Nii saadakse keel, mis räägib sinuga alandavalt. Cobol on kõige silmatorkavam näide, kuid enamiku keelte vaim on sellega läbipõimunud.

See ei ole seotud sellega, kui kõrge tasemega keel on. C on piisavalt madala tasemega, kuid see loodi selle autorite kasutamiseks, seetõttu armastavad häkkerid seda.

Argument keelte projekteerimise poolt halvadele programmeerijatele on see, et halvemaid programmeerijaid on rohkem kui häid. Jõudumööda tõsi. Kuid see väike hulk häid programmeerijaid kirjutab ebaproportsionaalselt rohkem tarkvara.

Mind huvitab küsimus, kuidas luua keel, mis meeldib parimatele häkkeritele? Minu arvates on see küsimus samasugune kui küsimus, kuidas luua head programmeerimiskeelt?, kuid isegi kui see ei ole nii, on see vähemalt huvitav küsimus.

3. Andke programmeerijale nii palju kontrolli kui võimalik

Paljud keeled (eriti need, mis on loodud teistele inimestele) käituvad nagu lapsehoidjad: nad püüavad teid hoiatada asjadest, mis nende arvates teile kasuks ei tule. Mina olen vastupidisel arvamusel: andke programmeerijale nii palju kontrolli kui saate.

Kui ma esmakordselt Lisp'i õppisin, meeldis mulle kõige rohkem see, et me räägime võrdselt. Teistes keeltes, mida olin selleks ajaks õppinud, oli keel ja oli minu programm sellel keelel, ning need eksisteerisid üsna eraldi. Kuid Lisp'is olid funktsioonid ja makrod, mida ma kirjutasin, samasugused nagu see, millega keel ise oli kirjutatud. Ma sain keel põhjalikult ümber kirjutada, kui tahtsin. Sellel oli sama atraktiivne võlu kui avatud lähtekoodiga tarkvaral.

4. Lühidus on talendi õde

Lühidus on alahinnatud ja isegi põlatud. Kuid kui te vaatate häkkerite südamesse, näete, et nad armastavad lühidust väga. Kui sageli olete kuulnud, kuidas häkkerid armastusega räägivad, et näiteks APL-is saavad nad teha hämmastavaid asju vaid mõne koodireaga? Ma arvan, et tõeliselt nutikad inimesed armastavad tegelikult sellele tähelepanu pöörata.

Ma arvan, et peaaegu kõik, mis võimaldab programme lühendada, on hea. Peavad olema mitmed teegifunktsioonid, kõik, mis võib olla varjatud, peaks olema selline; süntaks peaks olema enamasti lühike; isegi olendite nimed peaksid olema lühikesed.

Ja mitte ainult programmid ei tohiks olla lühikesed. Ka manuaalid peaksid olema lühikesed. Suur osa manuaalitest on täidetud selgitustega, ettevaatuse, hoiatuste ja eranditega. Kui teil on vaja manuaali lühendada, on parim valik parandada keelt, mis nõuab nii palju selgitusi.

5. Tunnustage, mis on häkkerlus

Paljusid inimesi tahaks, et häkkerlus oleks matemaatika või vähemalt midagi sarnast loodusteadustega. Ma arvan, et häkkerlus on rohkem seotud arhitektuuriga. Arhitektuur on seotud füüsikaga, selle mõttes, et arhitekt peab projekteerima hoone, mis ei kuku kokku, kuid arhitekti tõeline eesmärk on luua suur hoone, mitte avastada staatika alal.

Mis häkkeritele meeldib, on luua suurepäraseid programme. Ja ma arvan, et vähemalt meie endi mõtetes peaksime meeles pidama, et suurepäraste programmide kirjutamine on imeline, isegi kui see töö ei tõlgendu kergesti tavapärases teadustööde intellektuaalses valuutas. Intellektuaalselt on sama oluline nii arendada keelt, mis meeldib programmeerijatele, kui ka luua kohutav, idee kehastama, millest võite artikli avaldada.

Avatud probleemid

1. Kuidas korraldada suuri teeke?

Raamatukogud muutuvad programmeerimiskeelte oluliseks osaks. Need kasvavad nii suureks, et see võib olla ohtlik. Kui kulub rohkem aega, et leida raamatukogust funktsioon, mis teeb seda, mida vajate, kui kirjutada see funktsioon ise, ei tee kogu kood muud, kui paksendab teie juhendit. (Symbolicsi juhendid olid selle kohta näide.) Nii et peame probleemiga, mis puudutab raamatukogude korraldamist, tegelema. Ideaalis tuleks need kujundada nii, et programmeerija saaks aimata, milline raamatukogu funktsioon sobib.

2. Kas inimesed on tõeliselt hirmul prefiksi süntaksi ees?

See on avatud probleem mõttes, et olen sellele mõelnud mitu aastat ja ei tea ikka veel vastust. Prefiksi süntaks tundub mulle täiesti loomulik, võib-olla välja arvatud selle kasutamine matemaatikas. Kuid võib olla, et suur osa Lispi populaarsuse puudumisest tuleneb lihtsalt tundmatust süntaksist… Kas tasub sellega midagi ette võtta, kui see on tõsi, on teine küsimus.

3. Mida vajate serveri tarkvara jaoks?

Ma arvan, et enamik rakendusi, mis järgmise kahekümne aasta jooksul kirjutatakse, on veebirakendused, selles mõttes, et programmid asuvad serveris ja suhtlevad teiega läbi veebibrauseri. Ja nende rakenduste kirjutamiseks vajame uusi asju.

Üks selline asi on toe pakkumine uuele viisile serveri rakenduste väljalaskmiseks. Selle asemel, et välja anda üks või kaks suurt versiooni aastas, nagu lauaarvuti tarkvara puhul, välja antakse serveri tarkvara väikeste muudatuste seeriana. Teil võib olla viis või kümme versiooni päevas. Ja kõigil on alati viimane versioon.

Kas teate, kuidas programme kujundada nii, et need oleksid hooldatavad? Serveri tarkvara peaks olema kavandatud muutustele vastuvõtlikuks. Teil peaks olema võimalus seda lihtsalt muuta või vähemalt teada, mida tähendab väike muudatus ja mis on oluline.

Veel üks asi, mis võib serveri tarkvaras kasulik olla, on äkki pidev kohaletoimetamine. Veebirakenduses saate kasutada midagi sellist nagu CPS, et saavutada alamhulga mõju staateless maailmas veebiseansside puhul. Pidev kohaletoimetamine võib olla seda väärt, kui see võimalus ei ole liiga kallis.

4. Millised uued abstraktsioonid on veel avastamata?

Ma ei ole kindel, kui mõistlik on selline lootus, aga isiklikult sooviksin väga avada uue abstrahatsiooni — midagi, mis võiks tähendada sama palju kui klassi esimese astme funktsioonid või rekursioon või vähemalt vaikeparameetrid. Võib-olla on see teostamatu unistus. Sellised asjad ei ilmu just tihti. Kuid ma ei kaota lootust.

Vähem tuntud saladused

1. Sa saad kasutada ükskõik millist keelt, mida soovid

Varem pidas rakenduste loomine silmas lauaarvutite tarkvara väljatöötamist. Ja lauaarvutitarkvaras on suur kaldumine kirjutada rakendusi samas keeles, mis on operatsioonisüsteem. Nii et kümme aastat tagasi tähendas tarkvara kirjutamine peamiselt tarkvara kirjutamist C keeles. Aja jooksul on traditsioon evolveerunud: rakendusi ei pea olema kirjutatud eksootilistes keeltes. Ning see traditsioon on arenenud nii kaugele, et mitte-tehnilised inimesed, nagu juhid ja riskikapitali investeerijad, on seda samuti õppinud.

Serveritarkvara hävitab selle mudeli täielikult. Serveritarkvaraga saad kasutada ükskõik millist keelt, mida soovid. Peaaegu keegi ei mõista seda veel (eriti juhid ja riskikapitali investeerijad). Kuid mõned häkkerid mõistavad seda, seetõttu kuuleme sellistest indie-keeltest nagu Perl ja Python. Me ei kuule Perl'ist ja Python'ist, sest inimesed kasutavad neid Windowsi rakenduste kirjutamiseks.

Mida see tähendab meie, programmeerimiskeelte disainist huvitatud inimeste jaoks, on see, et meie töö jaoks on potentsiaalne publik olemas.

2. Kiirus tuleb profailijatelt

Keele arendajad või vähemalt selle rakendajad armastavad kirjutada kompilaatoreid, mis genereerivad kiiret koodi. Kuid ma arvan, et see ei ole see, mis teeb keeled kasutajate jaoks kiireks. Knuth on ammu märganud, et kiirus sõltub vaid mõnest kitsaskohast. Ja igaüks, kes on püüdnud programmi kiirusest kõrgemale viia, teab, et sa ei saa kunagi ära arvata, kus kitsaskoht on. Profiler on siin vastus.

Keele arendajad ei lahenda õiget probleemi. Kasutajad ei vaja, et mõõtmised töötaksid kiiresti. Neil on vaja keelt, mis suudab näidata, millised osad nende programmist tuleks ümber kirjutada. Selles olukorras on kiirus praktikas vajalik. Seega võiks olla parem, kui keele rakendajad kulutaksid poole ajast, mille nad kasutavad kompilaatori optimeerimisele, heade profiilide kirjutamiseks.

3. Teil on vaja rakendust, mis sunnib teie keelt arenema

See ei pruugi olla lõplik tõde, kuid tundub, et parimad keeled on arenenud koos rakendustega, milles neid kasutati. C kirjutati inimestele, kellel oli vaja süsteemitarkvara. Lisp töötati välja osaliselt sümboolseks diferentsiaaliks, McCarthy ei suutnud oodata, et alustada, ja hakkas kirjutama diferentsiaalprogramme juba 1960. aastal esimeses Lisp’i dokumendis.

See on eriti hea, kui teie rakendus lahendab mõned uued probleemid. See sunnib teie keelt omama uusi võimalusi, mida programmeerijad vajavad. Isiklikult on mul huvi kirjutada keel, mis sobib hästi serveri rakendustele.

[Arutelu käigus väljendas Guy Steele samuti seda mõtet, lisades, et rakendus ei tohiks koosneda teie keele kompilaatori kirjutamisest, kui teie keel ei ole mõeldud kompilaatorite kirjutamiseks.]

4. Keel peab olema sobiv ühekordsete programmide kirjutamiseks.

Teate, mida tähendab ühekordne programm: see on siis, kui peate kiiresti lahendama mingi piiratud ülesande. Arvan, et kui vaatate ringi, siis leiate palju tõsiseid programme, mis algasid kui ühekordsed. Ma ei üllatuks, kui enamik programme algas ühekordsetena. Seega, kui soovite luua keelt, mis sobib üldiselt tarkvara kirjutamiseks, peab see sobima ka ühekordsete programmide kirjutamiseks, kuna see on paljude programmide algstaadium.

5. Süntaks on seotud semantikaga

Traditsiooniliselt peetakse süntaksit ja semantikat tugevalt erinevateks asjadeks. See võib kõlada šokeerivalt, kuid see ei ole tõsi. Ma arvan, et see, mida te soovite oma programmis saavutada, on seotud sellega, kuidas te seda väljendate.

Hiljuti rääkisin Robert Morrisiga, kes märkis, et operaatorite ülekoormus on suur pluss infikssel süntaksil põhinevate keelte võitmiseks. Prefiksse süntaksi keeltel on iga defineeritud funktsioon tegelikult operaator. Kui soovite liita uue nummerduse, mille olete välja mõelnud, saate lihtsalt määratleda uue funktsiooni selle lisamiseks. Kui teete seda infikssel süntaksil põhinevas keeles, märkate, et ülekoormatud operaatori ja funktsiooni väljakutsumise vahel on suur erinevus.

Ideed, mis naasevad aja jooksul

1. Uued programmeerimiskeeled

Tagasi vaadates 1970ndates oli uusprogrammide loomine moes. Praegu pole see nii. Kuid ma usun, et serveritarkvara toob taas esile uute keelte loomise. Serveritarkvaraga saate kasutada ükskõik millist keelt, mida soovite, nii et kui keegi loob keele, mis tundub parem kui kõik teised, siis leidub inimesi, kes otsustavad seda kasutada.

2. Aja jagamine

Richard Kelsey esitas selle idee, mille aeg on taas käes, ja ma toetan seda täielikult. Minu arvates (ja ka Microsofti arvates) liiguvad paljud arvutused lauaarvutitelt eemalsetele serveritele. Teisisõnu, aja jagamine on tagasi. Ma arvan, et selle jaoks on vajalik keele tugi. Näiteks on Richard ja Jonathan Reeve teinud palju tööd protsessi ajakava rakendamiseks Scheme 48-s.

3. Tõhusus

Hiljuti näis, et arvutid on juba piisavalt kiired. Üha enam kuuleme byte-koodist, mis minu jaoks vähemalt tähendab, et meil on varu ressursse. Kuid ma arvan, et serveritarkvaraga ei ole meil seda. Keegi peab maksma selle eest, serverid, millega tarkvara töötab, ja kasutajate arv, keda server suudab ühe masina lõikes taluda, on nende kapitali kulutuste jagaja.

Ma arvan, et tõhusus on oluline, vähemalt arvutuste kitsaskohtades. See on eriti oluline sisendi- ja väljundoperatsioonide jaoks, kuna serverirakendused genereerivad palju selliseid operatsioone.

Lõpuks võib selguda, et bytecode ei ole lahendus. Sun ja Microsoft näivad praegu silmitsi seisvat bytecode'i maailmas. Nad teevad seda, kuna bytecode on mugav viis end protsessi integreerida, mitte seetõttu, et bytecode oleks iseenesest hea mõte. Võib-olla läheb kogu see lahing tähelepanuta. See oleks naljakas.

Nõksud ja lõksud

1. Klientide

See on ainult oletus, kuid tundub, et võidavad ainult need rakendused, mis on täielikult serveripõhised. Tarkvara kavandamine, mille põhjal on eeldus, et kõigil on teie klient, on nagu sellise ühiskonna loomine, mille põhjal eeldada, et kõik on ausad. See oleks kindlasti mugav, kuid peate tunnistama, et seda kunagi ei juhtu.

Ma arvan, et seadmete hulk, mis pääsevad veebisse, suureneb kiiresti, ja võib oletada, et nad toetavad baashtml-i ja vorme. Kas teil on oma telefonis brauser? Kas telefon saab olema teie PalmPilot'iga? Kas teie blackberry'l on suurem ekraan? Kas saate oma gameboy'st internetti minna? Kuidas oma kelladest? Ma ei tea. Ja mul ei pea seda teadma, kui ma arvestan, et kõik on serveris. Lihtsalt on palju usaldusväärsem, kui kõik mõtted on serveris.

2. Objektorienteeritud programmeerimine

Ma mõistan, et see on vastuoluline väide, kuid ma ei arva, et OOP on midagi olulist. Minu arvates on see sobiv paradigma teatud rakenduste jaoks, mis vajavad spetsiifilisi andmestruktuure, nagu aknasüsteemid, simulatsioonid, CAD-süsteemid. Kuid ma ei saa aru, miks see peaks olema sobiv kõigile programmidele.

Ma arvan, et suurtel ettevõtetel meeldib OOP osaliselt seetõttu, et see pakub palju seda, mis näeb välja nagu töö. See, mis võiks loomulikult olla esitatud näiteks täisarvude loendina, saab nüüd esitada klassina koos igasuguste toestustega, müra ja saginaga.

Teine atraktiivne omadus OOP-s on see, et meetodid annavad teile teatud efekti esimese klassi funktsioonidena. Kuid see ei ole Lisp-programmeerijatele midagi uut. Kui teil on tõelised esimese klassi funktsioonid, võite neid kasutada igasugustel viisidel, mis vastavad antud ülesandele, selle asemel, et suruda kõik klasside ja meetodite mallidesse.

Ma arvan, et see tähendab keelekujunduse jaoks, et te ei tohiks liiga sügavale OOP-sse sukelduda. Võib-olla on vastus pakkuda üldisemaid, põhialuseid ja lasta inimestel projekteerida kõik objektisüsteemid raamatukogude kaudu.

3. Komitee kujundamine

Kui teie keelt disainib komitee, siis olete lõksus, ja mitte ainult kõigile tuntud põhjustel. Kõigile on teada, et komiteed kipuvad looma tükilist ja järjepidevat keelekujundust. Kuid ma arvan, et suurem oht on see, et nad ei võta riske. Kui eesotsas on üks inimene, siis ta riskib, millega komitee kunagi nõus ei oleks.

Kas riski tuleb võtta, et luua hea keel? Paljud inimesed võivad kahtlustada, et keele kujundamine on koht, kus peate üsna lähedal hoidma traditsioonilistele tarkustele. Ma võiksin väita, et see pole nii. Kõiges muus, mida inimesed teevad, on tasu proportsionaalne riskiga. Miks peaks siis keelte kujundamises olema teisiti?

Allikas: habr.com