Filozofia udhëheqëse
1. Gjuhët e programimit për njerëzit
Gjuha e programimit është mënyra si flasin njerëzit me kompjuterët. Kompjuteri do të jetë i lumtur të flasë në çdo gjuhë që nuk është e paqartë. Arsyetimi pse kemi gjuhë të nivelit të lartë është sepse njerëzit nuk mund të përballojnë gjuhën e makinave. Qëllimi i gjuhëve të programimit është të parandalojnë trurin tonë të brishtë nga mbingarkesa e detajeve.
Arkitektët dinë se disa probleme projektimi janë më të zakonshme se të tjerat. Një nga problemet më të qarta dhe më abstrakte të projektimit është ndërtimi i urave. Në këtë rast, puna juaj është të mbuloni distancën që kërkohet me sa më pak material. Në anën tjetër të spektrit është projektimi i karrigeve. Projektuesit e karrigeve duhet të kalojnë kohën e tyre duke u menduar për prapavijën e njerëzve.
Zhvillimi i softuerit ka një dallim të ngjashëm. Projektimi i algoritmeve për orientimin e të dhënave përmes një rrjeti është një problem i mirë, abstrakt, si ndërtimi i urave. Ndërsa projektimi i gjuhëve të programimit është si projektimi i karrigeve: duhet të merremi me dobësitë njerëzore.
Shumicës prej nesh i vështirësohet ta kuptojë këtë. Projektimi i sistemeve matematikore elegante tingëllon shumë më tërheqëse për shumicën e nesh sesa t'i japim përparësi dobësive njerëzore. Roli i elegancës matematikore është që një shkallë e caktuar elegance e bën programin më të lehtë për t'u kuptuar. Por eleganca nuk është gjithçka.
Dhe kur them se gjuhët duhet të projektohen duke marrë parasysh dobësitë njerëzore, nuk kam në mendje që gjuhët duhet të projektohen për programues të këqij. Në të vërtetë, ju duhet të projektoni softuer për programuesit më të mirë, por edhe programuesit më të mirë kanë kufijtë e tyre. Nuk mendoj se dikush do të dëshiron të programojë në një gjuhë ku të gjitha variablat do të quheshin 'x' me indekse numërorë.
2. Projektoni për veten dhe miqtë tuaj
Nëse e shihni historinë e gjuhëve të programimit, shumica e gjuhëve më të mira janë dizajnuar për t'u përdorur nga autorët e tyre, ndërsa shumica e atyre më të këqija janë dizajnuar për njerëz të tjerë.
Kur gjuhët dizajnohen për njerëz të tjerë, gjithmonë është një grup specifik njerëzish: njerëzit nuk janë aq të mençur sa krijuesit e gjuhës. Kështu merrni një gjuhë që ju flet me përbuzje. Cobol është shembulli më i dukshëm, por shumica e gjuhëve janë të mbushura me këtë frymë.
Kjo nuk ka të bëjë me nivelin e lartë të gjuhës. C është mjaft nivel i ulët, por është krijuar për t'u përdorur nga autorët e tij, prandaj shpërthyesit e pëlqejnë atë.
Argumenti në favor të dizajnimit të gjuhëve për programues të dobët është se ka më shumë programues të dobët sesa të mirë. Mund të jetë kështu. Por ky numër i vogël i programuesve të mirë shkruan një sasi disproporcionale më shumë softueri.
Më intereson pyetja, si të krijojmë një gjuhë që do të pëlqehej nga hakerët më të mirë? Më duket se kjo pyetje është e barabartë me pyetjen, si të krijojmë një gjuhë të mirë programimi?, por përveç nëse nuk është kështu, të paktën është një pyetje interesante.
3. Jepni programuesit sa më shumë kontroll që është e mundur
Shumë gjuhë (veçanërisht ato që janë krijuar për njerëz të tjerë) veprojnë si kujdestarë: ato përpiqen t'ju paralajmërojnë për gjëra që ato mendojnë se nuk do t'ju ndihmojnë. Unë mbaj një mendim të kundërt: jepni programuesit sa më shumë kontroll që mundeni.
Kur studioja për herë të parë Lisp, më pëlqente më shumë se gjithçka që ne flisnim si të barabartë. Në gjuhët e tjera që kisha studiuar deri në atë kohë, kishte një gjuhë dhe kishte programin tim në këtë gjuhë, dhe ato ekzistonin mjaft veçmas. Por në Lisp, funksionet dhe makrotë që kam shkruar ishin të njëjtat me ato mbi të cilat ishte shkruar vetë gjuha. Mund të rishkruaja vetë gjuhën, nëse do. Ajo kishte të njëjtën tërheqje si softi me kod të hapur.
4. Shkurtësia është motra e talentit
Këto janë të nënvlerësuara dhe madje përbuzur. Por nëse shikoni në zemrat e hakerëve, do të shihni se ata e duan shumë shkurtësinë. Sa herë keni dëgjuar hakerët të flasin me dashuri për atë që, le të themi, në APL ata mund të bëjnë gjëra të mrekullueshme me vetëm disa rreshta kodi? Mendoj se njerëzit e vërtetë inteligjentë në të vërtetë e vlerësojnë këtë.
Mendoj se pothuajse gjithçka që e bën programet më të shkurtra është e mirë. Duhet të ketë shumë funksione bibliotekash, gjithçka që mund të jetë implicite duhet të jetë e tillë; sintaksa duhet të jetë më shumë e shkurtër; madje emrat e entiteteve duhet të jenë të shkurtër.
Dhe jo vetëm programet duhet të jenë të shkurtra. Manualet gjithashtu duhet të jenë të shkurtra. Një pjesë e madhe e manualeve është e mbushur me sqarime, kufizime, paralajmërime dhe raste të veçanta. Nëse ju nevojitet të shkurtoni një manual, opsioni më i mirë është të përmirësoni gjuhën që kërkon kaq shumë shpjegime.
5. Pranoni se çfarë është hakerizmi
Disa njerëz do të donin që hakerizmi të ishte matematikë ose, të paktën, diçka e ngjashme me shkencat natyrore. Mendoj se hakerizmi është më shumë si arkitektura. Arkitektura lidhet me fizikën, në kuptimin që arkitekti duhet të projektuara një ndërtesë që nuk do të bjerë, por qëllimi i vërtetë i arkitektit është të krijojë një ndërtesë të madhe, përveç se të bëjë zbulime në fushën e statikës.
Ajo që hakerët e duan, është të krijojnë programe të mëdha. Dhe mendoj se, të paktën në mendjet tona, duhet të kujtojmë se shkrimi i programeve të shkëlqyera është e mrekullueshme, madje edhe kur ky punë nuk përkthehet lehtësisht në valutat intelektuale të punimeve shkencore. Nga pikëpamja intelektuale, po aq e rëndësishme është si zhvillohet një gjuhë që do të pëlqehet nga programuesit, ashtu si të krijosh një koncept të tmerrshëm, për të cilin mund të publikosh një artikull.
Problemet e hapura
1. Si të organizoni biblioteka të mëdha?
Bibliotekat po bëhen një pjesë e rëndësishme e gjuhëve të programimit. Ato po bëhen kaq të mëdha sa që mund të jenë të rrezikshme. Nëse ju nevojitet më shumë kohë për të gjetur një funksion në bibliotekë që bën atë që ju nevojitet, sesa ta shkruani vetë atë funksion, atëherë gjithë kodi nuk bën tjetër veçse trashëse manualin tuaj. (Udhëzimet e Symbolics ishin një shembull i tillë.) Kështu që na duhet të zgjidhim problemin e organizimit të bibliotekave. Në mënyrë ideale, ato duhet të jenë të dizajnuara në një mënyrë që programuesi mund të gjejë lehtësisht se cili funksion i bibliotekës do t'i përshtatet.
2. A janë vërtet njerëzit të frikësuar nga sintaksisi prefix?
Kjo është një problem i hapur në atë kuptim që kam menduar për të për disa vite dhe ende nuk e di përgjigjen. Sintaksisi prefix më duket krejt natyral, ndoshta përveç përdorimit të tij në matematikë. Por ndoshta kështu, pjesa më e madhe e papopullaritetit të Lisp-ve është thjesht për shkak të sintaksës së panjohur... A ia vlen të bëhet diçka për këtë, nëse kjo është e vërtetë, është një pyetje tjetër.
3. Çfarë ju nevojitet për softuerin e serverit?
Mendoj se shumica e aplikacioneve që do të shkruhen në 20 vitet e ardhshme do të jenë aplikacione web, në kuptimin se programet do të ndodhen në server dhe do të komunikojnë me ju përmes shfletuesit të internetit. Dhe për të shkruar këto aplikacione na duhen gjëra të reja.
Një nga këto gjëra është mbështetja e një mënyre të re për të lëshuar aplikacione serveri. Në vend të një apo dy lëshimeve të mëdha në vit, si softueri i desktopit, softueri i serverit do të lëshohet përmes një serie ndryshimesh të vogla. Mund të keni pesë ose dhjetë lëshime në ditë. Dhe të gjithë gjithmonë do të kenë versionin e fundit.
A dini si të projektoni programe që janë të mbështetshme? Softueri i serverit duhet të jetë projektuar në një mënyrë që të jetë i aftë për ndryshime. Duhet të keni mundësinë për ta ndryshuar atë lehtësisht, ose të paktën të dini çfarë do të thotë një ndryshim i vogël dhe çfarë është e rëndësishme.
Një gjë tjetër që mund të jetë e dobishme në softuerin e serverit është, papritmas, kontinuiteti i dërgimit. Në një aplikacion web mund të përdorni diçka si , për të arritur efektin e nënprogrameve në botën stateless të seancave web. Mund të ketë kontinuitet të dërgimit që ia vlen nëse kjo mundësi nuk do të ishte shumë e shtrenjtë.
4. Cilat janë abstraksionet e reja që mbeten për t'u zbuluar?
Nuk e di sa e arsyeshme është një shpresë e tillë, por personalisht do të më pëlqente të hap një abstraksion të ri — diçka që mund të ketë po aq rëndësi sa funksionet e klasës së parë ose rekursioni ose të paktën parametrat me default. Ndoshta kjo është një ëndërr e pamundur. Gjëra të tilla shpesh nuk zbulohen. Por nuk e humbas shpresën.
Sekretet e panjohura
1. Mund të përdorni çdo gjuhë që dëshironi
Më parë, krijimi i aplikacioneve nënkuptonte krijimin e softuerit desktop. Dhe në softuerin desktop ka një tendencë të madhe për të shkruar aplikacione në të njëjtën gjuhë si sistemi operativ. Pra, dhjetë vjet më parë, krijimi i softuerit në përgjithësi nënkuptonte krijimin e softuerit në C. Në fund të fundit, tradita ka evoluar: aplikacionet nuk duhet të shkruhen në gjuhë të pazakonta. Dhe kjo traditë është zhvilluar për aq kohë sa njerëzit jo-teknikë, si menaxherët dhe investitorët e riskut, e kanë mësuar gjithashtu.
Softueri server shkatërron plotësisht këtë model. Me softuerin server, mund të merrni çdo gjuhë që dëshironi. Pjesa më e madhe e njerëzve ende nuk e kupton këtë (sidomos menaxherët dhe investitorët e riskut). Por disa hacker e kuptojnë këtë, prandaj kemi dëgjuar për gjuhë të tilla indie si Perl dhe Python. Ne nuk dëgjojmë për Perl dhe Python, sepse njerëzit i përdorin ato për të shkruar aplikacione për Windows.
Çfarë do të thotë kjo për ne, njerëzit e interesuar për projektimin e gjuhëve të programimit, është se ka një audiencë potenciale për punën tonë.
2. Shpejtësia vjen nga profiler-ët
Zhvilluesit e gjuhës, ose të paktën ata që e realizojnë atë, e duan të shkruajnë kompilatorë që gjenerojnë kod të shpejtë. Por mendoj se nuk është kjo ajo që i bën gjuhët të shpejta për përdoruesit. Knuth kohë më parë vuri re se shpejtësia varet vetëm nga disa ngushtësi. Dhe kushdo që ka provuar të përshpejtojë një program e di se nuk do të mund të parashikosh se ku është ngushtica. Profiler është përgjigjja.
Zhvilluesit e gjuhës po zgjidhin një problem të gabuar. Përdoruesve nuk u nevojitet që benchmark-t të punojnë shpejt. Ata kanë nevojë për një gjuhë që mund të tregojë se cilat pjesë të programit të tyre duhen ri-shkruar. Në këtë moment, shpejtësia është e nevojshme praktike. Ndoshta do të ishte më mirë nëse implementuesit e gjuhës do të shpenzonin gjysmën e kohës që po e investojnë në optimizimin e kompilatorit dhe do ta shpenzonin atë në shkruajturjen e një profiler-i të mirë.
3. Ju nevojitet një aplikacion që e shtyn gjuhën tuaj të zhvillohet
Ndoshta kjo nuk është e vërteta përfundimtare, por duket se gjuhët më të mira janë zhvilluar së bashku me aplikacionet ku janë përdorur. C u shkrua nga njerëz që kishin nevojë për programim sistemesh. Lisp u zhvillua pjesërisht për diferencimin simbolik, McCarthy ishte aq i padurueshëm që të fillonte, saqë filloi të shkruante programe diferenciale që në dokumentin e parë për Lisp në vitin 1960.
Kjo është veçanërisht e mirë, nëse aplikacioni juaj zgjidh disa probleme të reja. Kjo e shtyn gjuhën tuaj të ketë mundësi të reja që i duhen programuesve. Personalish, jam i interesuar të shkruaj një gjuhë që do të jetë e mirë për aplikacionet server.
[Gjatë diskutimit, Guy Steele shprehu gjithashtu këtë mendim, duke shtuar se aplikacioni nuk duhet të përbëhet nga shkruajtja e një kompilatori për gjuhën tuaj, përveçse nëse gjuhë tuaj është e destinuar për shkruajturjen e kompilerëve.]
4. Gjuha duhet të jetë e përshtatshme për shkruajturjen e programeve njëherëshi.
Ju e dini se çfarë do të thotë një program njëherësh: është kur ju nevojitet për të zgjidhur shpejt një detyrë të kufizuar. Unë mendoj se nëse e shikoni rreth, do të gjeni shumë programe të rëndësishme që kanë filluar si njëherësh. Nuk do të befasohesha nëse shumica e programeve kanë filluar si njëherësh. Pra, nëse doni të krijoni një gjuhë që do të jetë e përshtatshme për të shkruar software në përgjithësi, atëherë ajo duhet të jetë e përshtatshme për të shkruajtur programe njëherësh, sepse kjo është faza fillestare e shumë programeve.
5. Sintaksa lidhet me semantikën
Tradicionalisht, besohet se sintaksa dhe semantika janë dy gjëra shumë të ndryshme. Ndoshta kjo mund të tingëllojë e habitshme, por nuk është kështu. Unë mendoj se ajo që dëshiron të arrish në programin tuaj lidhet me mënyrën se si e shpreh atë.
Kohë më parë bisedova me Robert Morris dhe ai vuri në dukje se mbingarkesa e operatorëve është një avantazh i madh për fitimin e gjuhëve me sintaksë infiksale. Në gjuhët me sintaksë prefiksale, çdo funksion që ju përcaktoni në thelb është një operator. Nëse dëshironi të përmbledhni një lloj të ri numri që e keni shpikur, mund të përcaktoni thjesht një funksion të ri për ta shtuar atë. Nëse e bëni këtë në një gjuhë me sintaksë infiksale, do të shihni se ka një diferencë të madhe midis përdorimit të operatorëve të mbingarkuar dhe thirrjes së funksionit.
Idetë që kthehen me kalimin e kohës
1. Gjuhët e reja të programimit
Duke u kthyer pas në vitet 1970, ishte në modë të zhvillonit gjuhë të reja programimi. Tani nuk është kështu. Por mendoj se softi në server do të rikthejë modën për krijimin e gjuhëve të reja. Me softin në server, mund të përdorni çdo gjuhë që dëshironi, prandaj nëse dikush krijon një gjuhë që duket më mirë se të tjerat, do të ketë njerëz që do të vendosin ta përdorin atë.
2. Ndava e kohës
Richard Kelsey solli këtë ide, koha e së cilës ka ardhur përsëri, dhe unë e mbështes plotësisht atë. Paraqitja ime (po ashtu edhe e Microsoft), është se shumë llogaritje do të kalojnë nga desktop në servera të largët. Në fjalë të tjera, ndava e kohës ka rikthyer. Mendoj se do të ketë nevojë për mbështetje në nivelin e gjuhës. Për shembull, Richard dhe Jonathan Reeves bënë shumë punë për të implementuar planifikimin e proceseve në Scheme 48.
3. Efikasiteti
Kohët e fundit dukej se kompjuterët ishin tashmë mjaft të shpejtë. Po dëgjojmë gjithnjë e më shumë për kodin e byte-ve, që për mua, të paktën, do të thotë se kemi fuqi të rezervuar. Por mendoj se me softin në server, ne nuk e kemi atë. Diku dikush do të duhet të paguajë për serverët, mbi të cilët funksionon softi, dhe numri i përdoruesve që serveri mund të mbajë për një makinë do të jetë pjesa ndarëse e shpenzimeve të tyre kapitale.
Mendoj se efikasiteti do të ketë rëndësi, të paktën në ngushticat e llogaritjeve. Kjo do të jetë veçanërisht e rëndësishme për operacionet e hyrjes-daljes, sepse aplikacionet në server prodhojnë shumë nga ato operatorë.
Në fund të fundit, mund të rezultojë se bytecode nuk është një zgjidhje. Sun dhe Microsoft tani duket se po luftojnë ballë për ballë në fushën e bytecode. Por ata po e bëjnë këtë sepse bytecode është një vend i përshtatshëm për t'u integruar në proces, dhe jo sepse bytecode vetë është një ide e mirë. Mund të ndodhë që e gjithë kjo luftë të kalojë pa u vënë re. Do të ishte e çuditshme.
Kurthe dhe kapje
1. Klientët
Kjo është vetëm një supozim, por mbetet se do të fitojnë vetëm ato aplikacione që do të jenë plotësisht serverike. Kur dizajnoni softuerin që funksionon nën supozimin se të gjithë do të kenë klientin tuaj, duket si të krijoni një shoqëri të bazuar në supozimin se të gjithë do të jenë të ndershëm. Kjo do të ishte padyshim e përshtatshme, por do t'ju duhet të pranoni se ky realitet kurrë nuk do të ndodhë.
Mendoj se do të ketë një rritje të shpejtë të pajisjeve me akses në internet, dhe është e arsyeshme të supozojmë se ato do të mbështesin HTML-në bazë dhe formularët. A keni një shfletues në telefonin tuaj? A do të ketë telefoni juaj në PalmPilot-in tuaj? A do të ketë BlackBerry juaj një ekran më të madh? A do të keni mundësinë të lidheni në internet me gameboy tuaj? Me orën tuaj? Nuk e di. Dhe nuk do të më duhet ta di, nëse unë bastoj se gjithçka do të jetë në server. Thjesht është shumë më e besueshme të kesh të gjitha mendjen në server.
2. Programimi Objektor
E kuptoj se kjo është një deklaratë kontradiktore, por nuk besoj se OOP është diçka e rëndësishme. Mendoj se është një paradigmë e përshtatshme për aplikacione specifike që kanë nevojë për strukturat e dhënave specifike, si sistemet e dritareve, simulimet, sistemet CAD. Por nuk e kuptoj pse ajo duhet të jetë e përshtatshme për të gjithë programet.
Mendoj se njerëzit në kompanitë e mëdha e duan OOP-në, pjesërisht sepse ajo ofron shumë nga ajo që duket si punë. Ajo që natyrshëm mund të paraqitet si, le të themi, një listë e numrave të plotë, tani mund të përfaqësohet si një klasë me të gjitha llojet e strukturave, me zhurma e ngatërrime.
Një tjetër veçori atraktive e OOP-së është se metodat ju japin një efekt të funksioneve të klasës së parë. Por kjo nuk është një lajm për programuesit e Lisp-it. Kur keni funksione të vërteta të klasës së parë, mund t’i përdorni ato në çdo mënyrë që i përshtatet detyrës në vend që të shtyni gjithçka në një model të klasave dhe metodave.
Mendoj se kjo do të thotë për dizajnin e gjuhëve, që nuk duhet ta integroni shumë thellë OOP në të. Ndoshta përgjigja është të ofroni gjëra më të përgjithshme, themelore, dhe të lejoni njerëzit të projektorin çdo sistem objektesh si biblioteka.
3. Projektimi nga një komitet
Nëse gjuhën tuaj e projektton një komitet, atëherë jeni në një kurth, jo vetëm për arsyet që janë të njohura për të gjithë. Të gjithë e dinë se komitetet kanë tendencë të krijojnë një dizajn gjuhësor të ngjashëm, të papërshtatshëm. Por unë mendoj se rreziku më i madh është se ata nuk marrin përsipër rreziqe. Kur një person është në krye, ai merr rreziqe që një komitet kurrë nuk do të pranojë t'i marrë.
A duhet të rrezikosh për të krijuar një gjuhë të mirë? Shumë njerëz mund të dyshojnë se projektimi i gjuhës është një vend ku duhet të qëndrosh mjaft afër mençurisë tradicionale. Mund të argumentoj se nuk është kështu. Në çdo gjë tjetër që bëjnë njerëzit, shpërblimi është proporcionale me rrezikun. Pse, atëherë, duhet që projektimi i gjuhëve të jetë ndryshe?
Burimi: habr.com
