Vadošā filozofija
1. Programmēšanas valodas cilvēkiem
Programmēšanas valodas ir veids, kā cilvēki runā ar datoriem. Dators ar prieku runās jebkurā valodā, kas nav viennozīmīga. Iemesls, kāpēc mums ir augsta līmeņa valodas, ir tas, ka cilvēki nevar rīkoties ar mašīnvalodu. Programmēšanas valodu mērķis ir novērst to, ka mūsu nabadzīgās, trauslās cilvēka smadzenes tiek nomāktas ar pārāk daudzām detaļām.
Arhitekti zina, ka dažas dizaina problēmas ir ikdienišķākas nekā citas. Dažas no skaidrākajām un abstraktākajām dizaina problēmām ir tiltu projektēšana. Šajā gadījumā jūsu uzdevums ir veikt nepieciešamo attālumu, izmantojot pēc iespējas mazāk materiālu. Spektra otrā galā ir krēslu dizains. Krēslu dizaineriem vajadzētu pavadīt laiku, domājot par cilvēku dibeniem.
Programmatūras izstrādei ir līdzīga atšķirība. Algoritmu izstrāde datu maršrutēšanai tīklā ir jauka, abstrakta problēma, piemēram, tiltu projektēšana. Savukārt programmēšanas valodu projektēšana ir kā krēslu projektēšana: jātiek galā ar cilvēka vājībām.
Lielākajai daļai no mums to ir grūti saprast. Elegantu matemātisko sistēmu projektēšana lielākajai daļai no mums izklausās daudz pievilcīgāka nekā cilvēku vājo vietu pielāgošana. Matemātiskās elegances loma ir tāda, ka zināma elegance padara programmas vieglāk saprotamas. Bet tas nav viss par eleganci.
Un, kad es saku, ka valodas ir jāveido tā, lai tās atbilstu cilvēka vājībām, es nedomāju, ka valodām jābūt izstrādātām sliktiem programmētājiem. Patiesībā jums vajadzētu izstrādāt programmatūru labākajiem programmētājiem, taču pat labākajiem programmētājiem ir savas robežas. Nedomāju, ka kādam patiktu programmēšana valodā, kurā visi mainīgie būtu apzīmēti ar burtu "x" ar veseliem skaitļu apakšindeksiem.
2. Dizains sev un draugiem
Ja paskatās uz programmēšanas valodu vēsturi, lielākā daļa labāko valodu bija paredzētas to autoriem, un lielākā daļa sliktāko bija paredzētas citiem cilvēkiem.
Kad valodas ir paredzētas citiem cilvēkiem, tā vienmēr ir noteikta cilvēku grupa: cilvēki nav tik gudri kā valodas radītāji. Tādā veidā jūs iegūstat mēli, kas runā ar jums. Kobols ir visievērojamākais piemērs, taču lielākā daļa valodu ir piesātinātas ar šo garu.
Tam nav nekāda sakara ar valodas līmeni. C līmenis ir diezgan zems, taču tas tika izveidots, lai to izmantotu tā autori, tāpēc hakeriem tas patīk.
Arguments valodu izstrādei sliktiem programmētājiem ir tāds, ka sliktu programmētāju ir vairāk nekā labu. Varbūt tas tā ir. Bet šis mazais labo programmētāju skaits raksta nesamērīgi vairāk programmatūras.
Mans jautājums ir, kā izveidot valodu, kas patīk labākajiem hakeriem? Man šķiet, ka šis jautājums ir identisks jautājumam par to, kā izveidot labu programmēšanas valodu?, bet pat ja tā nav, tas ir vismaz interesants jautājums.
3. Dodiet programmētājam pēc iespējas lielāku kontroli
Daudzas valodas (īpaši tās, kas paredzētas citiem cilvēkiem) darbojas kā auklītes: tās cenšas jūs brīdināt no lietām, kuras, viņuprāt, jums nebūs noderīgas. Man ir pretējs viedoklis: dodiet programmētājam tik daudz kontroles, cik varat.
Kad es pirmo reizi uzzināju Lispu, man visvairāk patika tas, ka mēs runājām kā līdzvērtīgi. Citās valodās, kuras es līdz tam biju iemācījies, bija valoda, un tajā bija mana programma, un tās pastāvēja diezgan atsevišķi. Bet programmā Lisp funkcijas un makro, ko es uzrakstīju, bija tās pašas, kurās tika rakstīta pati valoda. Es varētu pārrakstīt pašu valodu, ja es gribētu. Tam bija tāda pati pievilcība kā atvērtā pirmkoda programmatūrai.
4. Īsums ir talanta māsa
Īsums ir nenovērtēts un pat nicināts. Bet, ja ieskatīsies hakeru sirdīs, redzēsi, ka viņiem ļoti patīk īsums. Cik reižu esat dzirdējuši, ka hakeri mīļi runā par to, kā, piemēram, APL, viņi var paveikt pārsteidzošas lietas, izmantojot tikai dažas koda rindiņas? Es domāju, ka patiešām gudriem cilvēkiem patīk tam pievērst uzmanību.
Es uzskatu, ka gandrīz viss, kas padara programmas īsākas, ir laba lieta. Bibliotēkas funkcijām vajadzētu būt daudzām, visam, kas var būt netiešs, tā jābūt; sintaksei jābūt kodolīgākai; pat entītiju nosaukumiem jābūt īsiem.
Un ne tikai programmām jābūt īsām. Rokasgrāmatām arī jābūt īsām. Liela daļa rokasgrāmatu ir piepildīta ar paskaidrojumiem, atrunām, brīdinājumiem un īpašiem gadījumiem. Ja jums ir jāsaīsina rokasgrāmata, vislabākais risinājums ir labot valodu, kas prasa tik daudz paskaidrojumu.
5. Atzīstiet, kas ir uzlaušana
Daudzi cilvēki vēlētos, lai uzlaušana būtu matemātika vai vismaz kaut kas līdzīgs zinātnei. Es domāju, ka uzlaušana ir vairāk kā arhitektūra. Arhitektūra ir par fiziku tādā ziņā, ka arhitektam ir jāprojektē ēka, kas nekritīs, bet arhitekta patiesais mērķis ir radīt lielisku ēku, nevis veikt atklājumus statikas jomā.
Hakeriem patīk radīt lieliskas programmas. Un es domāju, ka vismaz mūsu pašu domās mums vajadzētu atcerēties, ka lielisku programmu rakstīšana ir brīnišķīga lieta, pat ja šo darbu nav viegli pārvērst parastajā zinātnisko rakstu intelektuālajā valūtā. No intelektuālā viedokļa ir tikpat svarīgi izstrādāt valodu, kas programmētājiem patiks, kā arī izstrādāt šausmīgu valodu, kas iemieso ideju, par kuru varat publicēt rakstu.
Atvērt problēmas
1. Kā organizēt lielas bibliotēkas?
Bibliotēkas kļūst par svarīgu programmēšanas valodu sastāvdaļu. Tie kļūst tik lieli, ka var būt bīstami. Ja ir nepieciešams ilgāks laiks, lai bibliotēkā atrastu funkciju, kas dara to, kas jums nepieciešams, nekā pašam rakstīt šo funkciju, viss kods nedara neko citu, kā tikai padara rokasgrāmatu biezāku. (Simbolikas rokasgrāmatas bija piemērs tam.) Tātad mums būs jāatrisina bibliotēkas organizācijas problēma. Ideālā gadījumā noformējiet tos tā, lai programmētājs varētu uzminēt, kura bibliotēkas funkcija ir piemērota.
2. Vai tiešām cilvēki baidās no prefiksu sintakses?
Tā ir atklāta problēma tādā ziņā, ka es par to domāju jau vairākus gadus un joprojām nezinu atbildi. Prefiksu sintakse man šķiet pilnīgi dabiska, izņemot varbūt tās izmantošanu matemātikā. Bet var gadīties, ka liela daļa Lispa nepopularitātes ir vienkārši nepazīstamās sintakses dēļ... Vai mums kaut kas būtu jādara lietas labā, ja tā ir taisnība, tas ir cits jautājums.
3. Kas nepieciešams servera programmatūrai?
Es domāju, ka lielākā daļa lietojumprogrammu, kas tiks rakstītas nākamo divdesmit gadu laikā, būs tīmekļa lietojumprogrammas tādā nozīmē, ka programmas atradīsies serverī un sazināsies ar jums, izmantojot tīmekļa pārlūkprogrammu. Un, lai rakstītu šādus pieteikumus, mums ir vajadzīgas jaunas lietas.
Viena no šīm lietām ir atbalsts jaunam servera lietojumprogrammu izlaišanas veidam. Viena vai divu lielu izlaidumu vietā gadā, piemēram, galddatoru programmatūra, servera programmatūra tiks izlaista ar virkni nelielu izmaiņu. Jums var būt pieci vai desmit izlaidumi dienā. Un visiem vienmēr būs jaunākā versija.
Vai jūs zināt, kā izveidot programmas, lai tās būtu apkopjamas? Servera programmatūra ir jāveido tā, lai tā būtu maināma. Jums vajadzētu būt iespējai to viegli mainīt vai vismaz zināt, ko nozīmē nelielas izmaiņas un kas ir svarīgi.
Vēl viena lieta, kas var būt noderīga servera programmatūrā, pēkšņi ir piegādes nepārtrauktība. Tīmekļa lietojumprogrammā varat izmantot kaut ko līdzīgu lai iegūtu rutīnas efektu tīmekļa sesiju bezvalstniecības pasaulē. Piegādes nepārtrauktība var būt tā vērta, ja funkcija nav pārāk dārga.
4. Kādas jaunas abstrakcijas vēl ir jāatklāj?
Es neesmu pārliecināts, cik saprātīga ir šī cerība, bet personīgi es patiešām vēlētos atklāt jaunu abstrakciju - kaut ko tādu, kas varētu būt tikpat nozīmīgs kā pirmās klases funkcijas vai rekursija vai vismaz noklusējuma parametri. Varbūt tas ir neiespējams sapnis. Tādas lietas bieži netiek atklātas. Bet es nezaudēju cerību.
Maz zināmi noslēpumi
1. Varat izmantot jebkuru valodu, kuru vēlaties
Iepriekš lietojumprogrammu izveide nozīmēja darbvirsmas programmatūras izveidi. Un galddatoru programmatūrā ir liela nosliece uz lietojumprogrammu rakstīšanu tajā pašā valodā kā operētājsistēma. Tātad pirms desmit gadiem programmatūras rakstīšana kopumā nozīmēja programmatūras rakstīšanu C valodā. Galu galā tradīcija attīstījās: lietojumprogrammas nedrīkst rakstīt neparastās valodās. Un šī tradīcija ir attīstījusies tik ilgi, ka arī netehniskie cilvēki, piemēram, vadītāji un riska kapitālisti, to ir apguvuši.
Servera puses programmatūra pilnībā iznīcina šo modeli. Ar servera puses programmatūru var izmantot jebkuru valodu, kuru vēlaties. Gandrīz neviens to vēl nesaprot (īpaši vadītāji un riska kapitāla investori). Taču daži hakeri to saprot, tāpēc mēs dzirdam par tādām indy valodām kā Perl un Python. Mēs nedzirdam par Perl un Python, jo cilvēki tos izmanto, lai rakstītu lietojumprogrammas. Windows.
Ko tas nozīmē mums, programmēšanas valodas dizaina interesentiem, ka mūsu darbam ir potenciālā auditorija.
2. Ātrums nāk no profilētājiem
Valodu izstrādātājiem vai vismaz valodas ieviesējiem patīk rakstīt kompilatorus, kas ģenerē ātru kodu. Bet es domāju, ka tas nav tas, kas padara valodas lietotājiem ātras. Knuts jau sen atzīmēja, ka ātrums ir atkarīgs tikai no dažām vājajām vietām. Un ikviens, kurš ir mēģinājis paātrināt programmu, zina, ka jūs nevarat uzminēt, kur ir vājā vieta. Profiler ir atbilde.
Valodu izstrādātāji risina nepareizu problēmu. Lietotājiem nav nepieciešami etaloni, lai tie darbotos ātri. Viņiem ir vajadzīga valoda, kas var parādīt, kuras viņu programmas daļas ir jāpārraksta. Šajā brīdī praksē ir nepieciešams ātrums. Tāpēc varbūt būtu labāk, ja valodas ieviesēji pusi no laika veltītu kompilatora optimizēšanai un tērētu to laba profilētāja rakstīšanai.
3. Jums ir nepieciešama lietotne, kas attīsta jūsu valodu
Tā var nebūt galīgā patiesība, taču šķiet, ka labākās valodas attīstījās kopā ar lietojumprogrammām, kurās tās tika izmantotas. C rakstīja cilvēki, kuriem bija nepieciešama sistēmu programmēšana. Lisp daļēji bija paredzēts simboliskai diferencēšanai, un Makartijs tik ļoti vēlējās sākt darbu, ka viņš pat sāka rakstīt diferenciācijas programmas pirmajā Lisp dokumentā 1960. gadā.
Tas ir īpaši labi, ja jūsu lietojumprogramma atrisina dažas jaunas problēmas. Tas liek jūsu valodai iegūt jaunas funkcijas, kuras vēlas programmētāji. Man personīgi interesē uzrakstīt valodu, kas derēs servera lietojumprogrammām.
[Diskusijas laikā Gajs Stīls arī norādīja uz šo punktu, piebilstot, ka lietojumprogramma nedrīkst sastāvēt no kompilatora rakstīšanas jūsu valodai, ja vien jūsu valoda nav paredzēta kompilatoru rakstīšanai.]
4. Valodai jābūt piemērotai vienreizēju programmu rakstīšanai.
Jūs zināt, ko nozīmē vienreizēja programma: tas ir tad, kad jums ātri jāatrisina kāda ierobežota problēma. Es uzskatu, ka, palūkojoties apkārt, jūs atradīsit daudzas nopietnas programmas, kas sākās kā vienreizējas. Es nebūtu pārsteigts, ja lielākā daļa programmu tiktu sāktas kā vienreizējas. Tādējādi, ja vēlaties izveidot valodu, kas būs piemērota programmatūras rakstīšanai kopumā, tad tai vajadzētu būt piemērotai arī vienreizēju programmu rakstīšanai, jo tas ir daudzu programmu sākuma posms.
5. Sintakse ir saistīta ar semantiku
Tradicionāli tiek uzskatīts, ka sintakse un semantika ir ļoti dažādas lietas. Tas var izklausīties šokējoši, bet tā nav. Es domāju, ka tas, ko vēlaties sasniegt savā programmā, ir saistīts ar to, kā jūs to paužat.
Es nesen runāju ar Robertu Morisu, un viņš atzīmēja, ka operatora pārslodze ir liels pluss valodu uzvarai ar infix sintaksi. Valodās ar prefiksa sintaksi jebkura jūsu definētā funkcija faktiski ir operators. Ja vēlaties pievienot jauna veida numuru, ko izdomājāt, varat vienkārši definēt jaunu funkciju, lai to pievienotu. Ja to darāt valodā ar infix sintaksi, jūs redzēsit, ka pastāv liela atšķirība starp pārslogota operatora izmantošanu un funkcijas izsaukšanu.
Idejas, kas laika gaitā atgriežas
1. Jaunas programmēšanas valodas
Atskatoties uz 1970. gadiem, modē bija izstrādāt jaunas programmēšanas valodas. Tagad tas tā nav. Bet es uzskatu, ka serveru programmatūra atkal atgriezīs jaunu valodu radīšanas modi. Izmantojot servera programmatūru, jūs varat izmantot jebkuru valodu, kuru vēlaties, tāpēc, ja kāds izveido valodu, kas šķiet labāka par pārējām, būs cilvēki, kas izlems to izmantot.
2. Laika dalīšana
Ričards Kelsijs nāca klajā ar šo ideju, kuras laiks atkal ir pienācis, un es to pilnībā atbalstu. Mans minējums (un arī Microsoft) ir tāds, ka liela daļa skaitļošanas tiks pārvietota no darbvirsmas uz attāliem serveriem. Citiem vārdiem sakot, laika dalīšana ir atgriezusies. Es domāju, ka tam būs nepieciešams atbalsts valodu līmenī. Piemēram, Ričards un Džonatans Rīvi ir paveikuši daudz darba, lai ieviestu procesa plānošanu shēmā 48.
3. Efektivitāte
Nesen šķita, ka datori ir pietiekami ātri. Arvien vairāk dzirdam par baitkodu, kas, vismaz manuprāt, nozīmē, ka mums ir pāri jaudai. Bet es domāju, ka ar serveru programmatūru mums tādas nav. Kādam par to būs jāmaksā. serveriServeru skaits, kuros programmatūra darbojas, un lietotāju skaits, ko serveris var apstrādāt katrā iekārtā, būs to kapitāla izmaksu dalītājs.
Es domāju, ka efektivitātei būs nozīme, vismaz skaitļošanas vājajās vietās. Tas būs īpaši svarīgi I/O operācijām, jo serveru lietojumprogrammas veic ļoti daudz šādu darbību.
Galu galā var izrādīties, ka baitkods nav risinājums. Šķiet, ka Sun un Microsoft šobrīd sadarbojas baitkoda laukā. Taču viņi to dara tāpēc, ka baitkods ir ērta vieta, kur sevi iegult procesā, nevis tāpēc, ka pats baitkods ir laba ideja. Var izrādīties, ka visa šī cīņa paliks nepamanīta. Tas būtu smieklīgi.
Lamatas un lamatas
1. Klienti
Tas ir tikai minējums, taču vienīgās lietojumprogrammas, kas gūs labumu, ir tās, kuras ir pilnībā servera puses. Programmatūras izstrāde, kas darbojas, pamatojoties uz pieņēmumu, ka ikvienam būs klients, ir kā veidot sabiedrību, pamatojoties uz pieņēmumu, ka visi būs godīgi. Tas noteikti būtu ērti, bet jāpieņem, ka tas nekad nenotiks.
Es domāju, ka strauji pieaugs tīmekļa ierīču skaits, un mēs varam pieņemt, ka tās atbalstīs pamata html un formas. Vai jūsu tālrunī ir pārlūkprogramma? Vai jūsu PalmPilot būs tālrunis? Vai jūsu Blackberry būs lielāks ekrāns? Vai jūs varēsiet piekļūt internetam no sava spēlētāja? No jūsu pulksteņa? es nezinu. Un man nebūs jānoskaidro, ja es derēšu, ka viss būs serverī. Ir tikai daudz uzticamāk, ja visas smadzenes atrodas serverī. .
2. Objektorientētā programmēšana
Es saprotu, ka tas ir pretrunīgs paziņojums, bet es nedomāju, ka OOP ir tik svarīgs. Es domāju, ka šī ir piemērota paradigma konkrētām lietojumprogrammām, kurām nepieciešamas noteiktas datu struktūras, piemēram, logu sistēmas, simulācijas, CAD sistēmas. Bet es nesaprotu, kāpēc tai vajadzētu būt piemērotai visām programmām.
Es domāju, ka cilvēkiem lielos uzņēmumos daļēji patīk OOP, jo tas padara daudzas lietas, kas izskatās pēc darba. To, ko dabiski varētu attēlot kā, teiksim, veselu skaitļu sarakstu, tagad var attēlot kā klasi ar visdažādākajām sastatnēm, kņadu un burzmu.
Vēl viena pievilcīga OOP iezīme ir tā, ka metodes sniedz daļu no pirmās klases funkciju efekta. Bet tas nav jaunums Lisp programmētājiem. Ja jums ir patiesas pirmās klases funkcijas, varat tās vienkārši izmantot jebkurā veidā, kas atbilst konkrētajam uzdevumam, tā vietā, lai visu ievietotu klašu un metožu kopsavilkumā.
Es domāju, ka valodas dizainam tas nozīmē, ka nevajadzētu tajā pārāk dziļi iegult OOP. Varbūt atbilde ir piedāvāt vispārīgākas, pamata lietas un ļaut cilvēkiem veidot jebkuras objektu sistēmas kā bibliotēkas.
3. Komitejas dizains
Ja jūsu valodu ir izstrādājusi komiteja, jūs esat iesprostoti, un ne tikai iemeslu dēļ, ko visi zina. Ikviens zina, ka komitejas mēdz veidot nevienmērīgus, nekonsekventus valodas dizainus. Bet es domāju, ka liela bīstamība ir tajā, ka viņi neriskē. Kad viena persona ir atbildīga, viņš uzņemas riskus, ko komiteja nekad nepiekristu uzņemties.
Vai jums ir jāuzņemas risks, lai izveidotu labu valodu? Daudziem cilvēkiem varētu būt aizdomas, ka valodas dizains ir vieta, kur jums ir jāpaliek diezgan tuvu tradicionālajai gudrībai. Varu derēt, ka tas tā nav. Visā pārējā, ko cilvēki dara, atlīdzība ir proporcionāla riskam. Tātad, kāpēc valodas dizainam vajadzētu atšķirties?
Avots: www.habr.com
