Juhtiv filosoofia
1. Programmeerimiskeeled inimestele
Programmeerimiskeeled on see, kuidas inimesed arvutiga räägivad. Arvuti räägib hea meelega mis tahes keelt, mis pole kahemõtteline. Põhjus, miks meil on kõrgetasemelised keeled, on see, et inimesed ei saa masinakeelega hakkama. Programmeerimiskeelte eesmärk on vältida meie vaeste, habraste inimajude ülekoormatust liiga paljude detailide tõttu.
Arhitektid teavad, et mõned disainiprobleemid on igapäevasemad kui teised. Mõned kõige selgemad ja abstraktsemad disainiprobleemid on sildade projekteerimine. Sel juhul on teie ülesanne läbida vajalik vahemaa võimalikult vähese materjaliga. Spektri teises otsas on toolide disain. Toolidisainerid peaksid veetma aega inimeste tagumikule mõeldes.
Tarkvaraarendusel on sarnane erinevus. Algoritmide kavandamine andmete võrgu kaudu suunamiseks on kena abstraktne probleem, nagu sildade kujundamine. Kusjuures programmeerimiskeelte kujundamine on nagu toolide kujundamine: tuleb tegeleda inimlike nõrkustega.
Seda on enamikul meist raske mõista. Elegantsete matemaatiliste süsteemide kujundamine kõlab enamikule meist palju atraktiivsemalt kui inimlike nõrkuste nuhtlemine. Matemaatilise elegantsi roll on see, et teatud elegants muudab programmid hõlpsamini mõistetavaks. Kuid see kõik ei seisne elegantses.
Ja kui ma ütlen, et keeled peaksid olema loodud inimlike nõrkuste jaoks, ei pea ma silmas seda, et keeled peaksid olema loodud halbade programmeerijate jaoks. Tegelikkuses peaksite tarkvara kujundama parimatele programmeerijatele, kuid ka parimatel programmeerijatel on oma piirid. Ma ei usu, et kellelegi meeldiks programmeerimine keeles, kus kõik muutujad oleksid tähistatud tähega "x" koos täisarvuliste alaindeksitega.
2. Disain endale ja oma sõpradele
Kui vaadata programmeerimiskeelte ajalugu, siis enamik parimaid keeli on mõeldud kasutamiseks nende endi autoritele ja enamik halvimaid on mõeldud teistele inimestele kasutamiseks.
Kui keeled on mõeldud teistele inimestele, on see alati kindel inimeste rühm: inimesed pole nii targad kui keele loojad. Nii saate keele, mis räägib teiega maha. Cobol on kõige silmapaistvam näide, kuid enamik keeli on sellest vaimust läbi imbunud.
Sellel pole midagi pistmist keele tasemega. C on üsna madal tase, kuid see on loodud selle autorite jaoks, mistõttu häkkerid seda armastavad.
Halbade programmeerijate jaoks keelte kujundamise argument on see, et halbu programmeerijaid on rohkem kui häid. Võib-olla on see nii. Aga see väike hulk häid programmeerijaid kirjutab ebaproportsionaalselt rohkem tarkvara.
Minu küsimus on, kuidas luua keelt, mis meeldib parimatele häkkeritele? Mulle tundub, et see küsimus on identne küsimusega, kuidas luua head programmeerimiskeelt?, kuid isegi kui see pole nii, on see vähemalt huvitav küsimus.
3. Andke programmeerijale nii palju kontrolli kui võimalik
Paljud keeled (eriti need, mis on mõeldud teistele inimestele) käituvad nagu lapsehoidjad: nad püüavad teid hoiatada asjade eest, mis nende arvates teile kasulikud ei ole. Olen vastupidisel seisukohal: andke programmeerijale nii palju kontrolli kui võimalik.
Kui ma Lispi esimest korda õppisin, meeldis mulle kõige rohkem see, et me rääkisime nagu võrdsed. Teistes keeltes, mida ma olin selleks hetkeks õppinud, oli keel ja selles keeles oli minu programm ja need eksisteerisid täiesti eraldi. Kuid Lispis olid minu kirjutatud funktsioonid ja makrod samad, milles keel ise oli kirjutatud. Soovi korral võiksin keele enda ümber kirjutada. Sellel oli sama atraktiivsus kui avatud lähtekoodiga tarkvaral.
4. Lühidus on andekuse õde
Lühidus on alahinnatud ja isegi põlatud. Kui aga vaatate häkkerite südamesse, näete, et neile meeldib väga lühidus. Kui palju kordi olete kuulnud häkkereid heldimusega rääkimas sellest, kuidas nad näiteks APL-is suudavad paari koodireaga hämmastavaid asju teha? Ma arvan, et tõeliselt tarkadele inimestele meeldib sellele tähelepanu pöörata.
Usun, et peaaegu kõik, mis programme lühemaks muudab, on hea. Raamatukogu funktsioone peaks olema palju, kõik, mis võib olla kaudne, peaks nii olema; süntaks peaks olema ülevaatlikum; isegi üksuste nimed peaksid olema lühikesed.
Ja mitte ainult programmid ei tohiks olla lühikesed. Ka juhendid peaksid olema lühikesed. Suur osa juhenditest on täidetud selgituste, lahtiütluste, hoiatuste ja erijuhtudega. Kui teil on vaja juhendit lühendada, on parim valik nii palju selgitusi nõudvat keelt parandada.
5. Tunnista, mis on häkkimine
Paljud inimesed sooviksid, et häkkimine oleks matemaatika või vähemalt midagi teadusega sarnast. Ma arvan, et häkkimine on rohkem nagu arhitektuur. Arhitektuur on seotud füüsikaga selles osas, et arhitekt peab projekteerima hoone, mis ei kuku, kuid arhitekti tegelik eesmärk on luua suurepärane hoone, mitte teha avastusi staatika vallas.
Häkkeritele meeldib luua suurepäraseid programme. Ja ma arvan, et vähemalt meie enda mõtetes peaksime meeles pidama, et suurepäraste programmide kirjutamine on suurepärane asi, isegi kui seda tööd ei saa kergesti üle kanda teaduslike tööde tavapäraseks intellektuaalseks valuutaks. Intellektuaalsest vaatenurgast on sama oluline kujundada programmeerijatele meeldiv keel kui ka kohutav keel, mis kehastab ideed, mille kohta saate artikli avaldada.
Avatud probleemid
1. Kuidas korraldada suuri raamatukogusid?
Teegid on muutumas programmeerimiskeelte oluliseks osaks. Need muutuvad nii suureks, et võivad olla ohtlikud. Kui teegist vajaliku funktsiooni leidmiseks kulub kauem aega, kui selle funktsiooni ise kirjutamiseks, ei tee kogu kood muud, kui muudab teie käsiraamatu paksemaks. (Selle näiteks olid Symbolics käsiraamatud.) Seega peame lahendama raamatukogu korralduse probleemi. Ideaalis kujundage need nii, et programmeerija saaks arvata, milline teegi funktsioon sobib.
2. Kas inimesed tõesti kardavad eesliidete süntaksit?
See on selles mõttes lahtine probleem, et olen sellele juba mitu aastat mõelnud ega tea siiani vastust. Prefiksi süntaks tundub mulle täiesti loomulik, välja arvatud ehk selle kasutamine matemaatikas. Kuid võib juhtuda, et suur osa Lispi ebapopulaarsusest tuleneb lihtsalt tundmatust süntaksist... Kas me peaksime sellega midagi ette võtma, kui see on tõsi, on teine teema.
3. Mida on vaja serveritarkvara jaoks?
Arvan, et enamik järgmise kahekümne aasta jooksul kirjutatavaid rakendusi on veebirakendused, selles mõttes, et programmid asuvad serveris ja suhtlevad teiega veebibrauseri kaudu. Ja selliste rakenduste kirjutamiseks vajame uusi asju.
Üks neist asjadest on serverirakenduste vabastamise uue viisi toetamine. Selle asemel, et üks või kaks suurt väljalaset aastas, nagu lauaarvutitarkvara, väljastatakse, avaldatakse serveritarkvara väikeste muudatustega. Teil võib olla viis või kümme väljaannet päevas. Ja kõigil on alati uusim versioon.
Kas teate, kuidas kujundada programme nii, et need oleksid hooldatavad? Serveritarkvara peab olema muudetav. Peaksite saama seda lihtsalt muuta või vähemalt teadma, mida väike muudatus tähendab ja mis on oluline.
Teine asi, mis võib serveritarkvaras kasulik olla, on ootamatult tarne järjepidevus. Veebirakenduses saate kasutada midagi sarnast et saada rutiinide mõju kodakondsuseta veebiseansside maailmas. Tarnimise järjepidevus võib olla seda väärt, kui funktsioon pole liiga kallis.
4. Milliseid uusi abstraktsioone tuleb veel avastada?
Ma pole kindel, kui mõistlik see lootus on, kuid isiklikult tahaksin väga avastada uut abstraktsiooni – midagi, mis võiks olla sama tähendusrikas kui esmaklassilised funktsioonid või rekursioon või vähemalt vaikeparameetrid. Võib-olla on see võimatu unistus. Selliseid asju sageli ei avastata. Aga ma ei kaota lootust.
Vähetuntud saladused
1. Võite kasutada mis tahes soovitud keelt
Varem tähendas rakenduste loomine töölauatarkvara loomist. Ja töölauatarkvaras on suur eelarvamus rakenduste kirjutamisel operatsioonisüsteemiga samas keeles. Nii et kümme aastat tagasi tähendas tarkvara kirjutamine üldiselt tarkvara kirjutamist C-keeles. Lõpuks traditsioon arenes: rakendusi ei tohiks kirjutada ebatavalistes keeltes. Ja see traditsioon on arenenud nii kaua, et ka mittetehnilised inimesed, nagu juhid ja riskikapitalistid, on seda õppinud.
Serveritarkvara hävitab selle mudeli täielikult. Serveritarkvaraga saate kasutada mis tahes soovitud keelt. Peaaegu keegi ei saa sellest veel aru (eriti juhid ja riskikapitalistid). Kuid mõned häkkerid mõistavad seda, mistõttu kuuleme india keeltest nagu Perl ja Python. Me ei kuule Perlist ja Pythonist, sest inimesed kasutavad neid Windowsi rakenduste kirjutamiseks.
Mida tähendab see meile, programmeerimiskeele disainist huvitatud inimestele, et meie tööl on potentsiaalne publik.
2. Kiirus tuleb profileerijatelt
Keelearendajatele või vähemalt keele juurutajatele meeldib kirjutada kompilaatoreid, mis genereerivad kiiret koodi. Kuid ma arvan, et see ei muuda keeli kasutajate jaoks kiireks. Knuth märkis juba ammu, et kiirus sõltub vaid mõnest kitsaskohast. Ja igaüks, kes on proovinud programmi kiirendada, teab, et te ei oska arvata, kus kitsaskoht on. Profiler on vastus.
Keelearendajad lahendavad vale probleemi. Kasutajad ei vaja kiireks töötamiseks võrdlusaluseid. Nad vajavad keelt, mis näitaks, millised nende programmi osad tuleb ümber kirjutada. Siinkohal on praktikas vaja kiirust. Nii et võib-olla oleks parem, kui keele rakendajad kulutaksid poole oma ajast kompilaatori optimeerimisele ja kulutaksid selle hea profileerija kirjutamisele.
3. Teil on vaja rakendust, mis paneb teie keele arenema
See ei pruugi olla lõplik tõde, kuid tundub, et parimad keeled arenesid koos rakendustega, milles neid kasutati. C kirjutasid inimesed, kes vajasid süsteemide programmeerimist. Lisp oli mõeldud osaliselt sümboolseks eristamiseks ja McCarthy oli nii innukalt alustanud, et hakkas isegi eristamisprogramme kirjutama esimeses Lispi artiklis 1960. aastal.
See on eriti hea, kui teie rakendus lahendab mõned uued probleemid. See sunnib teie keelele uusi funktsioone, mida programmeerijad soovivad. Isiklikult olen huvitatud sellise keele kirjutamisest, mis oleks hea serverirakenduste jaoks.
[Arutelu käigus tõi selle välja ka Guy Steele, lisades, et rakendus ei tohiks koosneda teie keele kompilaatori kirjutamisest, välja arvatud juhul, kui teie keel on mõeldud kompilaatorite kirjutamiseks.]4. Keel peab sobima ühekordsete saadete kirjutamiseks.
Teate, mida ühekordne programm tähendab: see on siis, kui teil on vaja kiiresti lahendada mõni piiratud probleem. Usun, et kui ringi vaadata, leiab palju tõsiseid programme, mis said alguse ühekordsetest. Ma ei oleks üllatunud, kui enamik programme algaks ühekordsetena. Seega, kui soovite luua keelt, mis sobiks tarkvara kirjutamiseks üldiselt, siis peaks see sobima ka ühekordsete programmide kirjutamiseks, sest see on paljude programmide algstaadium.
5. Süntaks on seotud semantikaga
Traditsiooniliselt arvatakse, et süntaks ja semantika on väga erinevad asjad. See võib tunduda šokeeriv, kuid see pole nii. Ma arvan, et see, mida soovite oma programmis saavutada, on seotud sellega, kuidas te seda väljendate.
Rääkisin hiljuti Robert Morrisega ja ta märkis, et operaatori ülekoormus on suur pluss infix süntaksiga keelte võidus. Eesliite süntaksiga keeltes on iga teie määratud funktsioon tegelikult operaator. Kui soovite lisada enda väljamõeldud uut tüüpi numbrit, saate selle lisamiseks lihtsalt määrata uue funktsiooni. Kui teete seda infixi süntaksiga keeles, näete, et ülekoormatud operaatori kasutamisel ja funktsiooni kutsumisel on suur erinevus.
Ideed, mis aja jooksul tagasi tulevad
1. Uued programmeerimiskeeled
Vaadates tagasi 1970. aastatele, oli moes välja töötada uusi programmeerimiskeeli. Praegu see nii ei ole. Kuid ma usun, et serveritarkvara toob taas moe uute keelte loomisel tagasi. Serveritarkvaraga saate kasutada mis tahes keelt, nii et kui keegi loob keele, mis tundub teistest parem, on inimesi, kes otsustavad seda kasutada.
2. Aja jagamine
Selle ideega tuli välja Richard Kelsey, mille aeg on jälle käes ja ma toetan seda täielikult. Minu (ja ka Microsofti) oletus on, et suur osa andmetöötlusest liigub töölaualt kaugserveritesse. Teisisõnu, aja jagamine on tagasi. Arvan, et see vajab tuge keeletasandil. Näiteks Richard ja Jonathan Reeves on teinud palju tööd protsesside ajastamise rakendamiseks skeemis 48.
3. Tõhusus
Hiljuti tundus, et arvutid on juba piisavalt kiired. Me kuuleme üha rohkem baitkoodist, mis vähemalt minu jaoks tähendab, et meil on võimsust varuks. Kuid ma arvan, et serveritarkvara puhul meil seda pole. Keegi peab maksma tarkvara käitavate serverite eest ja kasutajate arv, mida server suudab masina kohta toetada, jagab nende kapitalikulusid.
Ma arvan, et tõhusus on oluline, vähemalt andmetöötluse kitsaskohtade osas. See on eriti oluline I/O operatsioonide puhul, sest serverirakendused teevad palju selliseid toiminguid.
Lõpuks võib selguda, et baitkood pole lahendus. Tundub, et Sun ja Microsoft lähevad hetkel baitkoodiväljal vastamisi. Kuid nad teevad seda seetõttu, et baitkood on mugav koht protsessi manustamiseks, mitte sellepärast, et baitkood ise on hea mõte. Võib selguda, et kogu see lahing jääb märkamatuks. See oleks naljakas.
Püünised ja lõksud
1. Kliendid
See on vaid oletus, kuid kasu saavad ainult need rakendused, mis on täielikult serveripoolsed. Tarkvara kujundamine, mis töötab eeldusel, et kõigil on klient, on nagu ühiskonna kujundamine eeldusel, et kõik on ausad. See oleks kindlasti mugav, aga tuleb eeldada, et seda ei juhtu kunagi.
Arvan, et veebitoega seadmete arv kasvab kiiresti ja võib eeldada, et need toetavad põhilist HTML-i ja vorme. Kas teie telefonis on brauser? Kas teie PalmPilotil on telefon? Kas teie Blackberryl on suurem ekraan? Kas pääsete oma mängupoisist Internetti juurde? Sinu kellast? ma ei tea. Ja ma ei pea uurima, kas ma panen kihla, et kõik on serveris. See on lihtsalt palju usaldusväärsem, kui kõik ajud on serveris. .
2. Objektorienteeritud programmeerimine
Ma saan aru, et see on vastuoluline väide, kuid ma ei usu, et OOP on nii oluline. Ma arvan, et see on sobiv paradigma konkreetsete rakenduste jaoks, mis vajavad spetsiifilisi andmestruktuure, nagu aknasüsteemid, simulatsioonid, CAD-süsteemid. Aga ma ei saa aru, miks see peaks sobima kõikidele programmidele.
Ma arvan, et suurettevõtete inimesed armastavad OOP-i osaliselt seetõttu, et see muudab paljud asjad tööks. Seda, mida võib loomulikult kujutada näiteks täisarvude loendina, saab nüüd kujutada klassiruumina, kus on kõikvõimalikud tellingud, sagimine ja sagimine.
Teine OOP-i atraktiivne omadus on see, et meetodid annavad teile osa esmaklassilistest funktsioonidest. Kuid see pole Lispi programmeerijate jaoks uudis. Kui teil on tõelised esmaklassilised funktsioonid, saate neid lihtsalt kasutada mis tahes viisil, mis sobib käsiloleva ülesandega, selle asemel, et suruda kõik klasside ja meetodite komplekti.
Arvan, et keelekujunduse jaoks tähendab see seda, et te ei tohiks OOP-i sellesse liiga sügavale kinnistada. Võib-olla on vastus pakkuda üldisemaid, põhilisi asju ja lasta inimestel kujundada mis tahes objektisüsteeme teekidena.
3. Projekteerimine komisjoni poolt
Kui teie keele kujundab komisjon, siis olete lõksus ja mitte ainult põhjustel, mida kõik teavad. Kõik teavad, et komisjonid kipuvad looma tükiseid ja ebajärjekindlaid keelekujundusi. Aga ma arvan, et suur oht seisneb selles, et nad ei riski. Kui üks inimene juhib, võtab ta riske, mida komisjon poleks kunagi nõus võtma.
Kas peate hea keele loomiseks riskima? Paljud inimesed võivad kahtlustada, et keelekujundus on koht, kus peate traditsioonilisele tarkusele üsna lähedale jääma. Vean kihla, et see pole nii. Kõiges muus, mida inimesed teevad, on tasu proportsionaalne riskiga. Miks peaks keelekujundus olema teistsugune?
Allikas: www.habr.com