La Centjara Lingvo

Jen traduko de artikolo de Paul Graham. La originala en la angla estas ĉe http://www.paulgraham.com/hundred.html

Estas malfacile antaŭdiri tian kia estos vivo post centjaroj. Nur estas kelkajn aferojn ni povas diri certe. Ni scias ke ĉiuj stiros flugantajn aŭtojn, ke zonleĝoj malstriktiĝos por permesi konstruaĵojn centetaĝajn, ke mallumas plejmulte da tempo kaj ke ĉiu virino spertas pri la sindefendaj artoj. Ĉi tie mi volas trakti unu detalon de ĉi tiu bildo. Kia programlingvo ili uzos por verki la programaron kiu regas la flugantajn aŭtojn.

Valoras pripensi tion ne ĉar ni fakte uzos tiujn lingvojn, sed se ni bonŝancas, ni uzos lingvojn survoje al tiu.

Mi opinias ke, kiel specoj, lingvoj formos evoluajn arbojn, kie neutilaj branĉoj foriĝos. Ni jam povas vidi tion. Cobol, por ties iama populareco, ŝajne ne havas intelektajn idojn. Ĝi estas evolua neutilaĵo-- neandertala lingvo.

Mi antaŭvidas similan sorton por Ĝavo. Homoj foje retpoŝtas min diranta, "Kiel vi povas diri ke Ĝavo ne sukcesos? Ĝi jam estas sukcesa lingvo." Kaj mi konfesas ke ĝi ja sukcesis, se vi mezuras sukceson per la bretarspacon dediĉatan al ĝi (certe pri unuopaj libroj pri ĝi), aŭ per la nombro de universitataj studantoj kiu kredas ke ili bezonas lerni ĝin por gajni laboron. Kiam mi diras ke Ĝavo ne sukcesos je la fino, mi intencas ion pli specifan: Ĝavo estos evolue senida, kiel Cobol.

Tio nur estas konjekto. Mi eble malpravas. Mia punkto ne estas insulti Ĝavon, sed montrigi la temon de evoluaj arboj kaj demandigi homojn, kie sur la arbo estas lingvo X? La kialo por demandi ne estas por ke mia fantomo povas, post cent jaroj, diri ke mi pravas. La kialo estas ĉar resti proksima al la ĉefaj branĉoj estas utila medoto por trovi lingvojn uzindajn nun.

Je iu tempo, vi verŝajne estas la plej feliĉa sur la ĉefaj branĉoj de la evolua arbo. Kvankam eĉ kiam estis multaj de neandertaloj, aĉas esti unu el ili. La homoj de Kro Magnon ade venus kaj elbatus vin kaj ŝtelus viajn manĝaĵojn.

Kial mi nun volas scii kiaj estos lingvoj post jarcento estas por ke mi sciu je kiu branĉo de la arbo mi devas veti nun.

La evoluo de lingvoj malsimilas de la evoluo de specoj ĉar branĉoj povas konverĝi. La Fortran branĉo, ekzemple, ŝajnas konverĝi kun la idoj de Algol. Teorie tio ankaŭ eblas por specoj, sed neverŝajnas por io pli granda ol ĉelo.

Unuiĝo estas pli kutima por lingvoj parte ĉar la spaco de eblecoj estas pli malgranda, kaj parte ĉar ŝanĝoj ne estas hazardaj. Lingvaj kreantoj intence enmetas ideojn el aliaj lingvoj.

Estas specife uzeme por lingvaj kreantoj pripensi kie la evoluo de programlingvoj verŝajne gvidas, ĉar ili povas direkti sin tiel. Tiukaze, "restu sur la ĉefbranĉo" fariĝas pli ol bona metodo elekti lingvon. Ĝi farigas solvilon por pli bone elekti decidojn pri lingva kreado.

Oni povas disigi programlingvon en du partoj: ia aro de fundamentaj operacioj servanta kiel aksiomoj, kaj la cetera de la lingvo, kiun oni povas verki precipe per la fundamentaj operacioj.

Mi pensas ke la fundamentaj operacioj estas la plej gravaj aferoj pri la vivdaŭro de lingvo. La ceteron oni povas ŝanĝi. Similas al la regulo ke kiam oni aĉetas domon la loko estas la plej grava. Ĉio alia oni povas ŝanĝi poste, sed oni ne povas ŝanĝi la lokon.

Mi pensas ke estas grave ne nur ke la aksiomoj estas bone elektitaj, sed ankaŭ estas la plej malmulte de ili kiel ebla. Matematikistoj ĉiam sentis tiel pri aksiomoj-- ju malpli multo des pli bone-- kaj mi pensas ke ili traktas ĝin bone.

Almenaŭ, estas bona ekzerco atente rigardi la kernon de lingvo por vidi ĉu ekzistas nebezonajn aksiomojn. Mi trovas en mia longa kariero kiel mallaboremulo ke neutilaĵoj naskas neutilaĵojn, kaj mi rimarkis tion en programado same kiel sub litoj kaj en anguloj de ĉambroj.

Mi antaŭsentas ke la ĉefaj branĉoj de la evolua arbo trairas la lingvojn kiu havas la pli malgrandajn kaj pli purajn kernojn. Ju pli de la lingvo vi povas verki per si mem, des pli bone.

Kompreneble, mi faras grandan supozon eĉ demandante kiajn programlingvojn ni uzos post jarcento. Ĉu ni eĉ verkos programojn post jarcento? Ĉu ni ne nur diri al komputiloj tion kion vi volas.

Ne estis multa da progreso tiel ĝis nun. Mia supozo estas ke post jarcento homoj ankoraŭ diros al komputiloj tion kio faru per programoj rekoneblaj al ni. Estas taskoj nun solvataj per programverkado por kiuj post jarcento ni ne verkos por solvi, sed mi pensas ke estos multa da programado tia kian ni faras hodiaŭ.

Eble ŝajnas antaŭsupozema pensi ke oni povas antaŭvidi kiel teknologio aspektos post jarcento, sed memoru ke ni jam havas preskaŭ kvindek jarojn da historio malantaŭ ni. Antaŭrigardi jarcenton estas realiga ideo kiam ni konsideras kiel malrapide lingvoj evoluis dum la pasintajn kvindek jarojn.

Lingvoj evoluas malrapide ĉar ili ne vere estas teknologioj. Lingvoj estas sintakso. Programo estas formala priskribo de la problemo kiun vi volas la komputilon solvi. Do la rapideco de evoluado en programlingvoj estas pli simila al la rapideco de matematika sintakso ol transportado aŭ komunikado. Matematika sintakso ja evoluas, sed ne kun la grandaj saltoj vi vidas je teknologio.

El kio ajn ni kreas komputiloj post jarcento, ŝajnas senriska antaŭdiri ke ili estas multe pli rapida ol nun. Se la leĝo de Moore daŭras, ili estos 74 triliono (73,786,976,294,838,206,464) foje pli rapida. Estas malfacile imagi. Kaj ja, la plej verŝajna antaŭdiro en la rapideco eble estas ke la leĝo de Moore ĉesos. Io ajn kiu devas duobliĝi ĉiujn dekok monatojn ŝajnas probable trafi iun fundamentan limon iam. Sed mi facile kredas ke komputiloj estos multe pli rapide. Eĉ se ili nur estas malsignifa miliono pli rapidaj, tio devas ŝanĝi la bazregulojn por programlingvoj multe. Interalie, estos pli da ebleco por kion ni nun konsideras malrapidaj lingvoj, kiu signifas lingvojn kiu ne generas tre efikan kodon.

Tamen iaj programoj postulos rapidecon. Iu el la problemoj ni volas solvi per komputiloj kreiĝas per komputiloj; ekzemple, la rapido por procezi filmbildojn dependas de la rapido kiun alia komputilo povas generi ilin. Kaj estas alia klaso de problemoj kiuj esence havas eblecon eluzi komputilciklojn: bildigado, ĉifrigado, simulado, etc.

Se iuj programoj povas esti plie neefike kiel aliaj ankoraŭ postulas tiom rapidecon kiom la maŝino povas doni, pli rapidaj komputiloj signifas ke lingvoj bezonas trakti pli kaj pli vasta aro de efikaĵoj. Ni jam vidis tion. Aktualaj realigoj de iuj popularaj novaj lingvoj estas frape malefikaj kompara al la kutimoj de antaŭaj jardekoj.

Tio ne nur okazas en programlingvoj. Ĝi estas ĝenerala historia modo. Kiel teknologio pliboniĝas, ĉiu generacio povas fari aĵojn la antaŭ generacio konsiderus malŝparema. Antaŭ 30 jaroj homoj mirus kiel ordinare ni telefonvokis malloke. Antaŭ jarcento homoj eĉ pli mirus ke pakaĵo vojaĝus el Bostono al Novjorkio per Memfiso.

Mi jam povas diri al vi tion kio okazos al tiaj kromcikloj donitaj al ni per pli rapidaj maŝinoj post jarcento. Ili malŝparos.

Mi lernis programi kiam komputila povo estis maloftaĵo. Mi povas memori forpreni la spacsignojn el miaj BASIC programoj do mi povas meti ilin en la memoro de 4K TRS-80. La penso de ĉi ĉiom miregindajn neefikajn programojn uzas la ciklojn por fari la samajn aferojn denove kaj denove estas malalloga al mi. Sed mi pensas ke mia intuicio malpravas. Mi estas kiel tiu kiu plenkreskis malriĉa, kaj ne povas akcepti elspezi monon eĉ por io grava, kiel viziti kuraciston.

Iaj malŝparoj estas abomenaj. Sportutilaj aŭtoj, ekzemple, estus aĉa eĉ se ili uzis energifonton kiu neniam eluziĝos kaj ne malpurigas la medion. sportutilaj aŭtoj estas aĉaj ĉar ili estas solvo por aĉa problemo. (Kiel aspektigi familiajn kamionetojn pli virecaj). Sed ne ĉia malŝparo estas malbona. Nun ke ni havas la bazstrukturon apogitan, nombri la minutojn de viaj mallokaj telefonvokoj ekŝajnas harfendema. Se vi havas la rimedojn, estas pli elegante pripensi ĉiajn telenfojvokojn kiel unu aferon, sendepende de kie la alia homo estas.

Estas bona malŝparo kaj malbona malŝparo. Mi interesiĝas en bona malŝparo-- tia kie, per elspezi plu, ni povas havi pli simplajn projektojn. Kiel ni utiligas la oportunojn por malŝpari ciklojn havantajn de novaj kaj plirapidaj maŝinoj?

La deziro por rapideco estas tiom profunde en ni, kun niaj malfortikaj komputiloj, ke oni bezonas konscian strebon por superigi ĝin. En lingvo konstruado, ni devas serĉi konscie tiajn situaciojn kiaj ni povas interŝanĝi efikecon por eĉ la plej eta plialtiĝo en uzebleco.

La plejmulto de datumstrukturoj ekzistas pro rapideco. Ekzemple, multaj lingvoj hodiaŭ havas kaj ĉenojn kaj listojn. Semantike, ĉenoj estas pli/malpli subaro de listoj kie la eroj estas literoj. Do kial ni bezonas apartan datumtipon? Nenial, vere. Ĉenoj nur ekzistas pro efikeco. Sed estas malgracia malordigi la semantikojn de lingvo kun fitrajtoj por plirapidigi programojn. Havi ĉenojn en lingvo ŝajnas esti kazo de trofrua optimumado.

Se ni pensas pri la kerno de lingvo kiel aro de aksiomoj, certe estas malbela havi aldonajn aksiomojn neesprimeblajn simple por efikeco. Efikeco gravas, sed tio ne estas la ĝusta maniero por havigi ĝin.

La ĝusta maniero solvigi tiun problemon, mi pensas, estas apartigi la signifo de programo de la plenumaj detaloj. Anstantaŭ havi kaj ĉenojn kaj listojn, simple havi listojn, kun iel maniero doni al la tradukilo optimumiga konsilo kiu permesas ĝin sterni la ĉenojn kiel daŭrigataj bajtoj se necesese.

Ĉar rapideco ne gravas en la plejmulto de programo, vi ne kutime bezonas trakti ĉi tian etmastrumado. Estos plu kaj plu vere kiel komputiloj plirapidiĝos.

Specifi malpli pri plenumado devas ankaŭ permesi pli fleksiblaj programoj. Priskriboj ŝanĝiĝas dum la verkado de programo kaj tio ne nur estas neevitebla, sed dezirinda.

La vorto "eseo" venas el la franca verbo "essayer", kiu signifas "provi". Eseo, ĝenerale, estas ion vi verkas por provi ellerni. Tio okazas ankaŭ en programado. Mi pensas ke iuj el la plej bonaj programoj estis eseoj, tiusence ke la verkistoj ne sciis komence prezice tion kion ili provis verki.

LISPaj kodemuloj jam scias pri la valoro de fleksebleco pri datumstrukturoj. Ni emas verki la unua versio de programo do ĝi plenumas ĉion per listoj. Tiuj unuaj versioj povas esti tiom ŝoke neefika ke oni bezonas konscie ne pensi pri tio kion ili faras, simile al mi ke por manĝi bovaĵon mi bezonas provi konscie ne pripensi de kie ĝi venis.

Kion programistoj post jarcento priserĉas, plejparte, estas lingvo kie vi povas kunĵeti nekredebla neefika versio 1 de programo kun la malplej da peno. Almenaŭ, tiel ni priskribu ĝin nuntempe. Kion ili diros estos ke ili volas programlingvo kiu estas facile uzi.

Neefikaj programoj ne malbelas. Kio malbelas estas lingvo kiu igas programistoj fari neutilan laboron. Malŝpari programistan tempon estas la vera neefikeca, ne la malŝparo de maŝina tempo. Tio klariĝos kiel komputiloj prirapidiĝas.

Mi pensas ke forigi ĉenojn jam estas pensinda. Ni faris ĝin en Arc, kaj ŝajnas esti gajno; iuj operacioj kiuj estus malgracia kiel regula esprimo estas facili esprimi per rekursiva funkcio.

Ĝis kiom ni platigas la datumstrukturojn? Mi pripensas eblecojn kiuj ŝokas eĉ mi, kun mia diliginte plilarĝigita menso. Ĉu ni forigos tabelojn, ekzemple? Je la fino, ili nur estas subaro de hakettabelo kie la ŝlosiloj estas entjeroj. Ĉu ni anstantaŭigos hakettabelojn per listoj?

Estas pli ŝokaj ebloj ol tiu. La LISP priskrita de McCarthy en 1960, ekzemple, ne havis nombrojn. Logike, vi ne bezonas havi apartan ideon de nombroj, ĉar vi povas prezentigi ilin per listoj: la entjero n povas esti prezentigata kiel listo da n eroj. Vi povas plenumi matematikon tiel. Ĝi nur estas treege malefika.

Neniu fakte proponis plenumi nombrojn kiel listoj en praktiko. Fakte, la 1960-a paperon de McCarthy oni ne intencis, tiutempe, plenumi iel. Ĝi estis teoria ekzerco, provo krei pli eleganta alternativo al la Maŝino de Turing. Kiam iu, neantaŭvidite, prenis la paperon kaj tradukis ĝin al funkcia LISP tradukilo, nombroj certe ne estis prezentita kiel listoj; ili prezentiĝis en duuma, kiel en ĉiu alia lingvo.

Ĉu programlingvo povas klopodi forigi nombrojn kiel baza datumtipo? Mi demandas tion ne kiel serioza demando sed kiel metodo vetludi kun la estonteco. Similas la kazon de nerezistebla povo kontraŭ nemovebla aĵo-- ĉi tie, neimagebla neefika plenumo kontraŭ neimagebla granda rimedo. Mi ne povas imagi kial ne. La estonteco estas tre longa. Se estas ion ni povas fari malpliigi la nombro de aksiomoj en la kerna lingvo, tiu ŝajnas esti la gajna flanko kiel t proksimas al nefino. Se la ideo ankoraŭ ŝajnas neeltenebla post cent jaroj, eble ĝi ne estos post jarmilo.

Por klarigi, mi ne proponas ke ĉiuj nombraj kalkuloj plenumas per listoj. Mi proponas ke la kerna lingvo, antaŭ iuj aldonaj notacioj pri plenumado, definiĝus tiel. En praktiko iu programo kiu volas fari iom da kalkulo verŝajne prezentus nombrojn en duuma, sed tiu estus optimigado, ne parto de la kerna semantiko de lingvo.

Alia metodo por malŝpari ciklojn estas havi multajn tavolojn de programoj inter la uzantprogramo kaj la maŝino. Tio ankaŭ estas progreso ni jam vidas: multaj lastatempaj lingvoj tradukiĝas al bitoka kodo. Bills Woods foje diris min ke, kiel ĝenerala regulo, ĉiu tavolo de interpretado kostas dekopon da rapideco. La aldona kosto donas al vi flekseblecon.

La unua versio de Arc estis granda kazo de tia multnivela malrapicedo, kune kun avantaĝoj. Ĝi estis klasika "supercirkla" interpretilo verkita sur Common Lisp, kun certa familia simileco al la eval funkcio definita en la originala LISP papero de McCarthy. La tuto estas nur kelkcent linioj longaj do ĝi estis tre facila kompreni kaj ŝanĝi. La Common Lisp uzata, CLisp, meme kuras sur bitoka koda intrepretilo. Do ni havis du tavolojn de intrepretado, unu el ili (la supra) ŝoke neefika, tamen la lingvo uzeblas. Apenaŭ uzebla, mi konfesas, sed uzebla.

Verki programojn per pluraj tavoloj estas povema tekniko eĉ ene de programoj. Demalsupra programado signifas verki programon kiel serio de tavoloj, ĉiuj kiuj servas kiel lingvo por la pli supra nivelo. Ĉi tiu metodo emas liveri kaj pli malgrandajn kaj pli flekseblajn programojn. Ĝi ankaŭ estas la plej bona vojo al tiu sankta gralo, reuzebleco. Lingvo per difino estas reuzebla. Ju pli de via programo vi povas lingvigi por verki tian programon des pli de via programaro estos reuzebla.

Iel la idea de reuzebleco alkroĉis al objekteca programado dum la 1980aj jaroj, kaj neniom da kontraŭa pruvo povas skuiĝi tion libera. Kvankam iom da okjekteca programaro estas uzebla, uzebligas ĝin ĝia demalsupreco ne gia objekteco. Rigardi kodotekojn, ili reuzeblas ĉar ili estas lingvo, se ili verkiĝis objektece aŭ ne.

Mi ne antaŭdivenas la malaperon de objektema programado. Almenaŭ mi opinias ke ĝi ofertas multon al bonaj programistoj, krom en certaj specialigitaj fakoj, ĝi estas allogega al grandaj organizoj. Objektema programado ofertas daŭrigeblan metodon verki spageta kodo. Ĝi instigas vin daŭre kreski programojn kiel serio de flikaĵoj. Grandaj organizoj ĉiam kreskas disvolvi programojn tiel, kaj mi suspektas tion estos tiom vera post cent jaroj kiom nun.

Tiel longe kiel ni parolas pri la estonteco, ni devas priparoli samtempan komputadon, ĉar tie estas kie ĉi tiu idea ŝajnas loĝi. Tio signifas, kie ajn vi parolas, samtempa komputado ŝajnas esti ion kio okazos en la estonteco.

Ĉu la estonteco iam renkontos ĝin? Homoj parolas pri samtempa komputado kiel ion tujan dum almenaŭ 20 jarojn kaj ĝi ne jam influis la pragramadan praktikon. Aŭ ĉu? Jam ĉipaj faristoj bezonas pripensi ĝin kaj ankaŭ programistoj kiuj verkas sistemajn programojn por multĉipaj komputiloj.

La vera demando estas, kiom supre de la ŝtupetaro de abstrakeco iros samtempeco? Post jarcento ĉu ĝi eĉ influas aplikaĵajn programistojn? Aŭ ĉu estos io kion tradukilaj programistoj pripensas, sed estas kutime nevidebla en la fontkodo de aplikaĵoj?

Unu ŝajnaĵo estas ke la plejparto de oportunoj por samtempeco malŝparos. Tio estas speciala kazo de mia pli ĝenerala antaŭvido ke la plejparto de la komputpova donata al ni malŝparos. Mi antaŭvidas ke, kiel kun la grandega rapideco de la suba maŝino, samtempeco disponiĝas se vi peti por ĝin malimplice, sed ordinare ne uzatas. Tio implicas ke tia samtempeco kiun ni havos post jarcento, krom en specialaj aplikaĵoj, ne estos grandega samtempeco. Mi anticipas ke por ordinaraj programistoj ĝi pli similos al forki procezojn kiuj samtempe kuras.

Kaj tio estos, kiel elekti specifajn datumstruktojn, io kion vi faras malfrue en la vivo de programo, kiam vi provas optimigi ĝin. La unuaj versioj kutime neatentas iujn avantaĝojn de samtempeco, same kiel ili neatentas avantaĝojn de specifaj prezentaĵoj de datumo.

Krom specialaj specoj de aplikaĵoj, samtempeco ne penetras la programojn verkoto post jarcento. Ĝi estus trofrua optimumado.

Kiom da programlingvoj ni havos post jarcento? Ŝajnas esti grandega nombro de novaj programlingvoj lastatempe. Parto de la kialo estas ke pli rapidaj maŝinoj ebligas programistojn fari malsamajn elektojn inter rapideco kaj uzebleco, depende de la aplikaĵo. Se tio estas vera emo, la maŝinoj ni havos post jarcento nur pliigos ĝin.

Kaj tamen estos nur kelkaj multuzataj lingvoj post jarcento. Parto de la kialo mi diras tion pro optimismo: ŝajnas ke, se vi faras bone, vi povas fari lingvon kiu estas ideala por malrapida versio unu, kaj tamen kun la ĝusta optimiga konsilo al la tradikilo, liveri la tre rapidan kodon kiam necese. Do, ĉar mi estas optimisma, mi antaŭdiras ki malgraŭ la grandega spaco inter akceptebla kaj maksimuma efikeco, programistoj post jarcento havos lingvojn kiu povas pritrakti la plejmulton de ĝi.

Kiel tiu spaco plilarĝiĝas tiel profililoj pli graviĝas. Oni malgrande atentas al profilado nun. Multaj homoj ŝajne opinias ke la metodo por krei rapidajn programojn estas verki tradukilojn kiu generas rapidan kodon. Kiel la spaco pligrandiĝas inter akceptebla kaj maksimuma plenumo plilarĝigas, estas plie klara ke la metodo krei rapidajn programojn estas havi bonan gvidon de unu al la alia.

Kiam mi diras ke eblas nur malmultaj lingvoj, mi ne enigas fakecajn "lingvetojn". Mi opinias ke tiaj enmetitaj lingvoj estas bonega ideo, kaj mi antaŭvidas ke ili multiĝos. Sed mi antaŭvidas ilin verkitajn kiel sufiĉe maldikajn tavolojn ke uzantoj povas vidi la ĝeneralcelan lingvon sube.

Kiu desegnos la lingvojn de la estonteco? Unu el la plej ekscitaj emo de la pasintaj jardeko estis la evoluo de liberfontaj lingvoj kiel Perl, Pitono, kaj Rubeno. Lingva desegnado ekregiĝas de kodemuloj. La rezultoj ĝis nun estas malordaj, sed kuraĝigaj. Multaj estas ŝoke malbonaj, sed tio ĉiam veras pri ambiciaj streboj. Ĉe ties nuna rapideco de ŝanĝado, nur Dio scias en kion Perl evoluus post jarcento.

Ne veras ke tiuj kiu ne povas fari, instruas (iujn el la plej bonaj kodemuloj mi konas estas profesoroj), sed ja veras ke estas multaj aferoj ke tiuj kiu instruas ne rajtas fari. Esplorado surmetas kastajn limigojn. En iuj universitataj fakoj estas decaj kaj maldecaj temoj por prilabori. Bedaŭrinde la distingo inter akcepteblaj kaj malakcepteblaj temoj estas kutime bazita sur kiel intelekta la temo ŝajnas kiam priverkata en esploradaj paperoj, anstantaŭ kiom grava la temo estas por fari bonajn rezultojn. Grandega ekzemplo verŝajne estas literaturo; homoj studantaj literaturo malofte diras iun ajn uzindan por tiu kiu faras ĝin.

Kvankam la situacio estas pli bona en la sciencoj, la samaĵo inter tia akcepta laboro permesata kaj tia laboro kiu faras bonajn lingvojn estas aĉe malgranda. (Olin Shivers grumblis elokvente pri tio.) Ekzemple, datumtipoj ŝajnas esti nefina fonto de esplorpaperoj, malgraŭ la fakto ke maldinamikaj tipoj ŝajnas malhelpi verajn makroojn-- sen kiu miaopinie neniu lingvo estas uzinda.

La emo ne nur estas al lingvoj disvolviĝita kiel liberkodaj projektoj ol "esplorada", sed al lingvoj desvolviĝinto de la aplikaĵaj programistoj kiu bezonas uzi ilin, ol tradukilaj verkistaj. Tio ŝajnas esti bona emo kaj mi antaŭvidas ke ĝi daŭriĝas.

Malkiel fizikscienco post jarcento, kiu estas preskaŭ neebla antaŭdiri, mi pensas ke eblas principe desegni lingvon nun kiu allogus uzantojn post jarcento.

Unu metodo desegni lingvo estas verki la programon kiun vi ŝatus verki, sendepende de ĉu ekzistas tradikilon kiu povas traduki ĝin aŭ maŝino kiu povas plenumi ĝin. Kiam vi faras ĉi tion vi povas antaŭsupozi nelimigajn rimedojn. Ŝajnas ke ni povus imagi nelimigaj rimedojn tiel bone nun kiel post jarcento.

Kian programon oni ŝatus verki? Kia ajn estas la malplej da labaro. Sed ne prezice: kian ajn estus la malplej da labaro se viaj ideoj pri programado ne jam influiĝis per la lingvoj kiujn vi jam alkutimiĝas. Tiaj influoj povas esti tiom satura ke postulas grandan penon superforti ilin. Vi pensus ke estus memevidenta por estuloj kiel mallaborema kiel ni espremi programan kun la malpli da provo. Fakte, niaj ideoj pri kio eblas emas esti tiom limigata de kiu ajn lingvo ni enpensas ke pli facilaj esprimoj de programoj ŝajnas tre suprizaj. Ili estas io malkovrenda, ne ion vi nature enmoviĝas.

Unu helpema lertaĵo estas uzi la longeco de programo kiel konjekto por kiom da laboro oni bezonis por verki ĝin. Ne la nombro de literoj, sed la nombro de apartaj sintaksaj elementoj-- baze la grandeco de la sintaksa arbo. Ne necesas ke la plej malgranda programo estas la malplej laboro por verki, sed ĝi estas sufiĉe celo de mallongeco ol la apuda celo de malpli da laboro. Tiam la algoritmo por lingvo desegno iĝas: rigardu la programo kaj demandi, ĉu ekzistas iel verki la programon pli malgranda?

Praktike, verki programojn en imaga centjara lingvo funkcios pli/malpli depende de kiom proksima vi estas al la kerno. Malgrandaj funkcioj vi povas verki nun. Sed estas malfacile antaŭdiri nun kiaj kodotekoj estos bezonata post jarcento. Supozeble multaj kodotekoj estos por fakoj kiu ne jam ekzistas. Se SETI@home sukcesos, ekzemple, ni bezonos kodotekojn por komunikado kun ekstermonduloj. Krom kaze ke ili estas sufiĉe inteligentaj ke ili jam komunikas per XML.

Je la alia flanko, mi pensas ke vi eble povas desegni la kerna lingvo hodiaŭ. Fakte, iu eble argumentas ke ĝi jam desegniĝis en 1958.

Se la centjara lingvo ekzistus hodiaŭ, ĉu ni volus programi per ĝi? Metodo por respondi al la demando estas rigardi malantaŭen. Se la nuntagaj lingvoj ekzistis dum 1960, ĉu iu volis uzi ilin?

Iel, la respondo estas ne, lingvoj hodiaŭ supozas infrastrukturon, kiu ne ekzistis en 1960. Ekzemple, spacsignifa lingvo, kiel Pitono, ne funkcias tre bone je presa terminalo. Sed metante tiajn problemojn flanke -- supozante ke ĉiuj programaj estas verkate papere -- ĉu programistoj de la 1960-aj jaroj ŝatus verki programojn en la lingvoj nun uzataj?

Mi opinias ke jes. Iuj neimagemaj programistoj, kiu havis partojn de fruaj lingvoj ligita al siaj ideojn de kio estas programo, eble luktas multe (Kiel oni povas manipuli datumon sen adresmontrila matematiko? Kiel oni povas plenumi stirfluajn diagramojn sen la goto operacio?) Sed mi opinias ke la plej inteligentaj programistoj tute ne luktas uzi la nuntempajn lingvojn, se ili havus ilin.

Se ni havus la centjaran lingvon nun, ĝi farus bonegan kvazaŭkodon. Kio pri uzi ĝin por verki programaron? Ĉar la centjara lingvo bezonas krei rapidan kodon por iuj programaj, supozante ĝi generus kodon sufiĉe efikan por funkcii sufiĉe je nia maŝinoj. Eble ne bezonas doni al ĝi pli da optimumigaj instrukcioj ol post jarcento, sed ankoraŭ estus pliboniĝo.

Nun, ni havas du ideojn ke, se vi kombinas ilin, sugestas interesajn eblaĵojn: (1) la centjara lingvo povas, principe, esti desajnata hodiaŭ (2) tia lingvo, se ĝi ekzistus, eble bonus uzi hodiaŭ. Kiam vi vidas la ideojn espremita tiel, malfacilas ne pensi, kiel ne klopodi desegni la centjaran lingvon nun?

Kiam vi prilaboras lingvan desegnon, mi opinias ke estas bona havi tian celon kaj tenu ĝin konscience enmense. Kiam vi lernis kiel kondukti aŭton, unu el la principoj ili instruas vin estas laŭlinigi la aŭton ne per celante la kapoto kun la koridoraj markiloj sur la vojo, sed per celante je iu punkto en la malproksimo. Eĉ se vi nur zorgas pri la antaŭa dek metroj, ĉi tio estas la prava metodo. Mi opinias ke ni povas kaj devas fari la saman kun programaj lingvoj.

Notoj

Mi opinias ke LISPa Maŝina LISP estas la unua lingvo enhavigi la principon ke deklaroj (krom tiuj de dinamikaj variablaĵoj) estis nur optimumigaj instrukcioj, kaj ne ŝanĝus la signifon de prava programo. Common Lisp ŝajnas esti la unua lingvo diri tion malkaŝe.

Dankon al Trevor Blackwell, Robert Morris, kaj Dan Giffin por siaj legadoj de la malnetoj, kaj al Guido van Rossum, Jeremy Hylton, kaj la ceteraj de la Pitona skipo por la invito por antaŭparoli ĉe PyCon