Viis küsimust programmeerimiskeelte projekteerimise kohta

Juhendav filosoofia

1. Programmeerimiskeeled inimestele

Programmeerimiskeeled on see, kuidas inimesed räägivad arvutitega. Arvuti on valmis rääkima mis tahes keeles, mida ei suuda tõlgendada mitmeti. Põhjus, miks meil on kõrgema taseme keeled, on see, et inimesed ei suuda masinakeelest aru saada. Programmeerimiskeelte olemus on vältida meie õrna ja hapra inimese aju ülekoormust detailidega.

Arhitektid teavad, et mõned projekteerimisprobleemid on rohkem käegakatsutavad kui teised. Üks selgemaid ja abstraktsemaid projekteerimisprobleeme on sildade projekteerimine. Sellisel juhul on teie ülesanne katta vajalik kaugus võimalikult väikese materjaliga. Teise poole spektris on toolide projekteerimine. Toolide projekteerijad peavad kulutama aega mõtlema inimeste tagumikutele.

Tarkvaraarendusel on sarnane erinevus. Andmete edastamise algoritmide projekteerimine võrgu kaudu on hea, abstraktne probleem, nagu sildade projekteerimine. Samas on programmeerimiskeelte projekteerimine sarnane toolide projekteerimisele: tuleb arvestada inimeste nõrkustega.

Enamik meist leiab selle mõistmise keeruliseks. Elegantsete matemaatiliste süsteemide projekteerimine kõlab enamikule meist palju atraktiivsemalt kui inimeste nõrkuste talumine. Matemaatilise elegantsuse roll seisneb selles, et teatud määral elegantsus teeb programmid arusaadavamaks. Kuid elegantsuse osas ei ole asjad sellega veel lõppenud.

Ja kui ma ütlen, et keeled peaksid olema projekteeritud, et arvestada inimeste nõrkustega, ei mõtle ma, et keeled peaksid olema projekteeritud halbadeks programmeerijateks. Tegelikult peaksite tarkvara projekteerima parematele programmeerijatele, kuid isegi parimatel programmeerijatel on oma piirid. Ma ei usu, et kellelegi meeldib programmeerida keeles, kus kõik muutujad on tähistatud tähega „x“ koos täisarvuliste indeksitega.

2. Kujundage endale ja oma sõpradele

Kui vaadata programmeerimiskeelte ajalugu, on enamik parimatest keeltest loodud nende autorite enda kasutamiseks, samas kui enamik halvematest on projekteeritud teiste inimeste jaoks.

Kui keeled on loodud teistele inimestele, siis see on alati mingi konkreetne inimgrupp: inimesed ei ole nii targad kui keele loojad. Nii saate keele, mis räägib teiega alandlikult. Cobol on selge näide, kuid enamik keeli on selle vaimuga läbi imbunud.

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

Argument, et keeled tuleks kujundada kehvadele programmeerijatele, on see, et kehvaid programmeerijaid on rohkem kui häid. Võib-olla on see tõsi. Kuid see väike arv häid programmeerijaid kirjutab proportsionaalselt rohkem tarkvara.

Mind teeb mind huvitavaks küsimus, kuidas luua keelt, mis meeldib parimatele häkkeritele? Minu arvates on see küsimus samaväärne küsimusega, kuidas luua head programmeerimiskeelt? Kuid isegi kui see pole nii, on see huvitav küsimus.

3. Andke programmeerijale nii palju kontrolli kui võimalik.

Paljud keeled (eriti need, mis on loodud teistele inimestele) käituvad nagu beebimonitorid: nad püüavad teid hoiatada asjade eest, mis nende arvates teile kasulikud ei ole. Mina olen teistsugusel arvamusel: andke programmeerijale nii palju kontrolli kui suudate.

Kui ma esmakordselt Lisp'i õppisin, meeldivad mulle kõige rohkem see, et me rääkisime võrdselt. Teistes keeltes, mida ma selleks ajaks olin õppinud, oli keel ja minu programm sellel keelel, ja need eksisteerisid üsna eraldi. Kuid Lisp'is olid kirjutatud funktsioonid ja makrod samad, millega oli kirjutatud keel ise. Ma oleksin võinud vajadusel keelt ümber kirjutada. Sellel oli sama atraktiivsus nagu avatud lähtekoodiga tarkvaral.

4. Üksus on anne õde.

Lühidus on alahinnatud ja isegi põlatud. Kuid kui vaatate häkkerite südamesse, näete, et nad armastavad lühidust. Kui mitu korda olete kuulnud, kuidas häkkerid armastusega räägivad sellest, et näiteks APL-is saavad nad teha hämmastavaid asju vaid paari koodi real? Arvan, et tõeliselt nutikad inimesed armastavad selle tähelepanu alla tuua.

Arvan, et peaaegu kõik, mis võimaldab programme lühemaks teha — on hea. Peaks olema palju teegifunktsioone, kõik, mis võib olla varjatud — peaks olema; süntaks peaks olema enamasti lühike; isegi üksuste nimed peaksid olema lühikesed.

Ja mitte ainult programmid ei peaks olema lühikesed. Manuaalid peaksid samuti olema lühikesed. Suur osa manuaalidest on täis selgitusi, tingimusi, hoiatuseid ja erijuhtumeid. Kui peate manuaali lühendama, on parim viis parandada keelt, mis nõuab nii palju selgitusi.

5. Tunnustage, mis on häkkerlus

Paljusid inimesi sooviks, et häkkimine oleks matemaatika või vähemalt midagi sarnast loodusteadustele. Ma arvan, et häkkimine on rohkem nagu arhitektuur. Arhitektuur on seotud füüsikaga, kuna arhitekt peab projekteerima hoone, mis ei kuku kokku, kuid arhitekti tõeline eesmärk on luua suurepärane hoone, mitte avastada staatika valdkonnas.

Mida häkkerid armastavad, on suurepäraste programmide loomine. Ja ma arvan, et vähemalt meie enda mõtetes peaksime meeles pidama, et suurepäraste programmide kirjutamine on imeline, isegi kui see töö ei kandu kergesti tavaliseks teaduslike tööde vahetuseks. Intellektuaalses mõttes on sama oluline arendada keelt, millest arendajad armastavad, kui ka luua tohutu idee, millest saab artikli aluseks.

Avatud probleemid

1. Kuidas korraldada suuri teeke?

Raamatukogud on muutumas programmeerimiskeelte oluliseks osaks. Need kasvavad nii suureks, et see võib olla ohtlik. Kui võtab rohkem aega, et leida funktsioon raamatukogust, mis teeb seda, mida vajad, kui selle funktsiooni ise kirjutamine, siis kogu kood ei tee midagi muud kui paksendab sinu käsiraamatut. (Symbolics'i juhendite näide.) Nii et meil tuleb lahendada raamatukogude korraldamise probleem. Ideaalis tuleks need projekteerida nii, et programmeerijal oleks võimalik mõista, milline raamatukogu funktsioon sobib.

2. Kas inimesed on tõeliselt hirmunud prefix-süntaksist?

See on avatud probleem selles mõttes, et olen selle üle mõelnud mitme aasta jooksul ja ikka ei tea vastust. Prefiksisüntaks tundub mulle täiesti loomulik, välja arvatud selle kasutamine matemaatikas. Kuid võib-olla on enamus Lispide ebapopulaarsusest lihtsalt tingitud tundmatust süntaksist... Kas peaks midagi selle nimel ette võtma, kui see on tõsi, on teine küsimus.

3. Mida vajate serveritarkvara jaoks?

Ma arvan, et enamik rakendusi, mis järgmise kahekümne aasta jooksul kirjutatakse, on veebirakendused, mõistes, et programmid asuvad serveris ja suhtlevad teiega veebibrauseri kaudu. Selliste rakenduste kirjutamiseks on meil vaja uusi lahendusi.

Üks selline lahendus on uue lähenemise toetamist serverirakenduste vabastamiseks. Erinevalt üksikest või kahest suurest versioonist aastas, nagu töölauatarkvara puhul, vabastatakse serveritarkvara väikeste muudatuste seeria kaudu. Teil võib olla viis või kümme väljalaset päevas. Ja kõikidel on alati kõige uuem versioon.

Kas teate, kuidas projekteerida programmid, et need oleksid hooldatavad? Serveritarkvara peab olema projekteeritud selliselt, et see oleks muudatustele avatud. Teil peab olema võimalus seda kergesti muuta või vähemalt teadma, mida tähendab väike muudatus ja mis on oluline.

Veel üks asi, mis võib serveritarkvaras kasulik olla, on ootamatult pidev kohaletoimetamine. Veebirakenduses võite kasutada midagi sellist nagu CPS, et saada mõju subtrogrammide stateless maailmas veebi seansside jaoks. Tarne pidevus võib olla seda väärt, kui see võimalus ei ole liiga kallis.

4. Millised uued abstraktsioonid on avastamata?

Ma ei ole kindel, kui mõistlik selline lootus on, kuid isiklikult sooviksin avastada uut abstraktsiooni — midagi, mis võiks olla sama olulise tähendusega nagu esmaklassilised funktsioonid või rekursioon või vähemalt vaikimisi parameetrid. Võib-olla on see saavutatav unistus. Selliseid asju ei avastata sageli. Aga ma ei kaota lootust.

Vähe tuntud saladused

1. Saate kasutada ükskõik millist keelt, mida soovite

Kuna rakenduste loomist peeti varem arvutitarkvara loomise alla. Arvutitarkvaras on suur kallak suunatud rakenduste kirjutamisele samas keeles, mis on operatsioonisüsteem. Nii et kümme aastat tagasi tähendas tarkvara kirjutamine üldiselt tarkvara kirjutamist C keeles. Lõppkokkuvõttes on traditsioon evolutsiooniliselt muutunud: rakendusi ei pea kirjutama haruldastes keeltes. Ja see traditsioon on arenenud nii pikaks, et mitte-tehnilised inimesed, nagu juhid ja riskikapitalistid, on selle samuti ära õppinud.

Serveri tarkvara hävitab täielikult selle mudeli. Serveri tarkvaraga saate valida mis tahes keele, mida soovite. Peaaegu keegi ei mõista seda veel (eriti juhid ja riskikapitalistid). Kuid mõned häkkerid mõistavad seda, just seetõttu oleme kuulnud sellistest indie-keeltest nagu Perl ja Python. Me ei kuule Perlist ja Pythonist, sest inimesi kasutavad neid Windowsi rakenduste kirjutamiseks.

Mida see tähendab meile, inimestele, kes on huvitatud programmeerimiskeelte kavandamisest, et meie tööl on potentsiaalne sihtrühm.

2. Kiirus tuleb profailijatelt.

Programmeerimiskeele arendajad või vähemalt selle teostajad armastavad kirjutada kompilaatoreid, mis genereerivad kiiret koodi. Kuid ma arvan, et see ei tee keeltest kasutajatele kiireid. Knuth on ammu märganud, et kiirus sõltub vaid mõnest kitsaskohast. Ja igaüks, kes on proovinud programmi kiirendada, teab, et te ei saa kunagi arvata, kus kitsaskoht on. Profilera on siin vastus.

Arendajate probleem on vale. Kasutajad ei vaja, et protsessorid töötaksid kiiresti. Nad vajavad keelt, mis suudab näidata, millised osad nende programmist peaksid ümber kirjutama. Sellel hetkel on kiirus tegelikult vajalik. Nii et võib-olla oleks parem, kui keele teostajad kulutaksid pool aega, mille nad veedavad kompilaatori optimeerimisele, head profailijat kirjutades.

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

See ei pruugi olla tõsi, aga tundub, et parimad keeled on arenenud koos rakendustega, milles neid kasutati. C loodud inimestele, kellele oli vajalik süsteemne programmeerimine. Lisp loodi osaliselt sümboolse diferentsiaalvõtmise jaoks. McCarthy ei suutnud oodata ja hakkas kirjutama diferentsieerimisprogramme isegi esimeses dokumentis Lispist 1960. aastal.

See on eriti hea, kui teie rakendus lahendab uusi probleeme. See paneb teie keelele uusi võimalusi, mida programmeerijad vajavad. Isiklikult on mul huvi kirjutada keel, mis sobib hästi serverirakendustele.

[Diskussiooni käigus väljendas Guy Steele ka seda mõtet, lisades, et rakendus ei pea koosnema kompilaatori kirjutamisest teie keele jaoks, 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. Usun, et kui vaatate ringi, leiate palju tõsiseid programme, mis algasid kui ühekordsed. Ma ei jääks üllatunud, kui enamik programme oleks alguses olnud ühekordsed. Seega, kui soovite luua keelt, mis sobib tarkvara kirjutamiseks üldiselt, peab see olema sobiv 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. Võib-olla kõlab see šokeerivalt, kuid nii see ei ole. Usun, et see, mida soovite oma programmis saavutada, on seotud sellega, kuidas te seda väljendate.

Hiljuti rääkisin Robert Morrisiga ja ta tõi välja, et operaatorite ülekasutamine on suur pluss infiks-süntaksiga keeltes. Prefiks-süntaksiga keeltes on iga defineeritud funktsioon tegelikult operaator. Kui soovite liita uut numbrit, mille olete välja mõelnud, võite lihtsalt määratleda uue funktsiooni selle lisamiseks. Kui teete sedasi infiks-süntaksiga keeles, näete, et ülekoormatud operaatori ja funktsiooni kutsumise vahel on suur erinevus.

Ideed, mis naasevad ajaga

1. Uued programmeerimiskeeled

Vaadates tagasi 1970. aastatesse, oli uus programmeerimiskeelte arendamine väga moes. Tänapäeval ei ole see enam nii. Kuid ma usun, et serveritarkvara toob jälle tagasi uute keelte loomise moe. Serveritarkvaraga saate kasutada ükskõik millist keelt, mis teile meeldib, seega, kui keegi loob keele, mis tundub parem kui teised, siis leidub inimesi, kes otsustavad seda kasutada.

2. Aja jaotamine

Richard Kelsi esitas selle idee, mille aeg on taas käes, ja ma toetan seda täielikult. Minu arvates (ja ka Microsofti arvates) liiguvad paljud arvutused töölaualt kaugserveritesse. Teisisõnu, ajajaotus on tagasi. Arvan, et selle toetuseks on vajalik keele tasemel tugi. Näiteks on Richard ja Jonathan Reeves teinud palju tööd protsessi haldamise rakendamiseks Scheme 48-s.

3. Tõhusus

Hiljuti tundus, et arvutid on juba piisavalt kiired. Üha rohkem kuuleme byte-koodist, mis vähemalt minu jaoks tähendab, et meil on veel varuks jõud. Kuid ma arvan, et serveri tarkvaraga pole seda. Keegi peab tasuma serveritesse, millel tarkvara töötab, ja kasutajate arv, keda server suudab ühe masina kohta taluda, on nende kapitalikulude jagaja.

Usun, et tõhusus on oluline, vähemalt arvutuste kitsaskohtades. See on eriti tähtis sisend-väljund operatsioonide puhul, kuna serverirakendused teevad nende käigus palju selliseid toiminguid.

Lõpuks võib juhtuda, et byte-kood ei ole lahendus. Sun ja Microsoft näivad hetkel võitlevat otseselt byte-koodi valdkonnas. Kuid nad teevad seda, kuna byte-kood on mugav viis end protsessi integreerida, mitte seetõttu, et byte-kood iseenesest oleks hea idee. Võib juhtuda, et kogu see lahing jääb märkamatuks. See oleks kindlasti naljakas.

Lõksud ja karid

1. Kliendid

See on vaid oletus, kuid see seisneb selles, et võidavad ainult need rakendused, mis on täielikult serveripõhised. Tarkvara projekteerimine, mis põhineb oletusel, et igaühel on teie klient, on nagu ühiskonna loomine, mis põhineb oletusel, et kõik on ausad. See oleks kindlasti mugav, kuid peate arvestama, et seda kunagi ei toimu.

Usun, et veebipääsuga seadmete arv suureneb kiiresti ning võib eeldada, et need toetavad põhistasemel HTML-i ja vorme. Kas su telefonil on brauser? Kas su PalmPilot'i telefon toetab seda? Kas su Blackberry'l on suurem ekraan? Kas sul on võimalus minna internetti oma Gameboy'st? Kuidas on lood su kellaga? Ma ei tea. Ja ma ei pea seda teada saama, kui ma panustan, et kõik on serveris. Lihtsalt on palju usaldusväärsem hoida kogu töötlemine serveris.

2. Objektorienteeritud programmeerimine

Ma mõistan, et see on vastuoluline väide, kuid ma ei arva, et OOP on midagi olulist. Mulle tundub, et see on sobiv paradigmasteemade jaoks, mis vajavad spetsiifilisi andmestruktuure, nagu aknasüsteemid, simulatsioonid ja CAD-süsteemid. Kuid ma ei saa aru, miks see peaks kõikide programmide jaoks sobiv olema.

Ma arvan, et suurtel ettevõtetel meeldib OOP, osaliselt sellepärast, et see annab palju sellist, mis näeb välja nagu töö. See, mis loomulikult võiks olla esitatud, näiteks, täisarvude loendina, võib nüüd olla esitatud klassina, koos kõigi ehitusmaterjalide, müraga ja sagimisega.

Teine tõhus omadus OOP-s on see, et meetodid annavad teile mingisuguse esimese klassi funktsioonide efekti. Kuid see pole uudsus Lisp-programmeerijatele. Kui teil on tõelised esimese klassi funktsioonid, saate neid kasutada igasuguste ülesannete lahendamiseks, selle asemel et kõik klasside ja meetodite šablooni suruda.

Arvan, et see tähendab keele disaini osas, et te ei tohiks OOP-d liiga sügavalt sisse ehitada. Võib-olla on vastus pakkuda üldisemaid, põhialuste aspekte ja lasta inimestel kujundada mingeid objektite süsteeme teekidena.

3. Komitee poolt projekteerimine

Kui teie keelt kujundab komitee, siis olete lõksus, mitte ainult kõigile teadaolevatel põhjustel. Kõigile on teada, et komiteed kipuvad looma killustatud ja ebajärjekindlat keeledisaini. Kuid arvan, et suurem oht on see, et nad ei võta riske. Kui eesotsas on üks inimene, siis võtab ta riske, mida komitee kunagi ei nõustu endale võtma.

Kas tasub riske võtta, et luua hea keel? Paljud inimesed võivad arvata, et keele kujundamine on midagi, kus peaks kinni hoidma traditsioonilisest tarkusest. Ma väidan, et see pole nii. Kõikides muudest asjadest, mida inimesed teevad, on tasu riskiga proportsionaalne. Miks peaks keelekujundamises olema teisiti?

Allikas: habr.com