Пет прашања за дизајн на програмски јазик

Водечка филозофија

1. Програмски јазици за луѓе

Програмските јазици се како луѓето разговараат со компјутерите. Компјутерот со задоволство ќе зборува на кој било јазик што не е двосмислен. Причината поради која имаме јазици на високо ниво е затоа што луѓето не можат да се справат со машинскиот јазик. Поентата на програмските јазици е да се спречи нашиот сиромашен, кревок човечки мозок да биде обземен од премногу детали.

Архитектите знаат дека некои проблеми со дизајнот се поприземни од другите. Некои од најјасните и апстрактните проблеми во дизајнот се дизајнот на мостовите. Во овој случај, вашата работа е да го поминете потребното растојание со што е можно помалку материјал. На другиот крај од спектарот е дизајнот на столот. Дизајнерите на столици треба да го поминуваат своето време размислувајќи за задникот на луѓето.

Развојот на софтвер има слична разлика. Дизајнирањето алгоритми за рутирање на податоци низ мрежа е убав, апстрактен проблем, како дизајнирање мостови. Додека дизајнирањето програмски јазици е како дизајнирање столчиња: треба да се справите со човечките слабости.

Ова е тешко за повеќето од нас да го сфатат. Дизајнирањето на елегантни математички системи звучи многу попривлечно за повеќето од нас, отколку погрчувањето на човечките слабости. Улогата на математичката елеганција е дека одреден степен на елеганција ги прави програмите полесни за разбирање. Но, не е сè до елеганцијата.

И кога велам дека јазиците треба да бидат дизајнирани да одговараат на човечките слабости, не мислам дека јазиците треба да бидат дизајнирани за лоши програмери. Во реалноста, треба да дизајнирате софтвер за најдобрите програмери, но и најдобрите програмери имаат свои граници. Мислам дека никој не би уживал во програмирање на јазик каде што сите променливи се означени со буквата „x“ со цели броеви.

2. Дизајн за себе и вашите пријатели

Ако ја погледнете историјата на програмските јазици, повеќето од најдобрите јазици беа дизајнирани да ги користат нивните сопствени автори, а повеќето од најлошите беа дизајнирани за други луѓе да ги користат.

Кога јазиците се дизајнирани за други луѓе, тоа е секогаш одредена група на луѓе: луѓето не се толку паметни како креаторите на јазикот. Така добивате јазик што ви зборува. Кобол е најистакнатиот пример, но повеќето јазици се проткаени со овој дух.

Нема врска со тоа колку е на високо ниво јазикот. C е прилично ниско ниво, но е создаден за да го користат неговите автори, па затоа хакерите го сакаат.

Аргументот за дизајнирање јазици за лоши програмери е дека има повеќе лоши програмери отколку добри. Можеби ова е така. Но, овој мал број добри програмери пишуваат несразмерно повеќе софтвер.

Моето прашање е, како да креирате јазик кој им се допаѓа на најдобрите хакери? Ми се чини дека ова прашање е идентично со прашањето како да се создаде добар програмски јазик?, но и да не е, тоа е барем интересно прашање.

3. Дајте му на програмерот што е можно поголема контрола

Многу јазици (особено оние наменети за други луѓе) се однесуваат како дадилки: тие се обидуваат да ве предупредат настрана од работи за кои мислат дека нема да ви користат. Имам спротивен став: дајте му на програмерот колку што можете повеќе контрола.

Кога првпат го научив Лисп, најмногу ми се допадна тоа што разговаравме како еднакви. Во другите јазици што ги научив до тој момент, имаше јазик, и имаше мојата програма на тој јазик, и тие постоеја сосема одделно. Но, во Лисп, функциите и макроата што ги напишав беа истите на кои беше напишан самиот јазик. Можев да го препишам самиот јазик ако сакам. Ја имаше истата привлечност како софтверот со отворен код.

4. Бревити е сестра на талентот

Краткоста е потценета, па дури и презирана. Но, ако погледнете во срцата на хакерите, ќе видите дека тие навистина сакаат краткост. Колку пати сте слушнале како хакерите со задоволство зборуваат за тоа како, да речеме, во APL, можат да направат неверојатни работи со само неколку линии код? Претпоставувам дека навистина паметните луѓе сакаат да обрнат внимание на ова.

Верувам дека скоро сè што ги прави програмите пократки е добра работа. Треба да има многу библиотечни функции, сè што може да биде имплицитно треба да биде така; синтаксата треба да биде поконцизна; дури и имињата на ентитетите треба да бидат кратки.

И не само програмите треба да бидат кратки. Прирачниците исто така треба да бидат кратки. Добар дел од прирачниците се исполнети со објаснувања, одрекувања, предупредувања и посебни случаи. Ако треба да го скратите прирачникот, најдобрата опција е да го поправите јазикот кој бара толку многу објаснување.

5. Препознајте што е хакирање

Многу луѓе би сакале хакирањето да биде математика, или барем нешто слично на науката. Мислам дека хакирањето е повеќе како архитектура. Архитектурата е за физика со тоа што архитект треба да дизајнира зграда што нема да падне, но вистинската цел на архитектот е да создаде одлична зграда, а не да прави откритија во областа на статиката.

Она што хакерите го сакаат е да создаваат одлични програми. И мислам дека, барем во нашите сопствени мисли, треба да запомниме дека пишувањето одлични програми е прекрасна работа, дури и кога таа работа не се претвора лесно во вообичаената интелектуална валута на научни трудови. Од интелектуална гледна точка, исто толку е важно да се дизајнира јазик што ќе го сакаат програмерите, како и да се дизајнира ужасен јазик што отелотворува идеја за која можете да објавите труд.

Отворени прашања

1. Како да се организираат големи библиотеки?

Библиотеките стануваат важен дел од програмските јазици. Тие стануваат толку големи што може да биде опасно. Ако е потребно подолго време да се најде функција во библиотека што го прави она што ви треба, отколку сами да ја напишете таа функција, тогаш целиот код не прави ништо друго туку го прави вашиот прирачник подебел. (Прирачниците Symbolics беа пример за ова.) Значи, ќе треба да го решиме проблемот со организацијата на библиотеката. Идеално, дизајнирајте ги така што програмерот може да погоди која библиотечна функција е соодветна.

2. Дали луѓето навистина се плашат од синтаксата на префиксот?

Ова е отворен проблем во смисла дека размислувам за него веќе неколку години и сè уште не го знам одговорот. Синтаксата на префиксот ми изгледа сосема природна, освен можеби нејзината употреба во математиката. Но, можеби голем дел од непопуларноста на Лисп се должи едноставно на непознатата синтакса... Дали треба да направиме нешто во врска со тоа, ако е точно, е друго прашање.

3. Што ви е потребно за серверски софтвер?

Мислам дека повеќето апликации што ќе бидат напишани во следните дваесет години ќе бидат веб апликации, во смисла дека програмите ќе живеат на сервер и ќе комуницираат со вас преку веб-прелистувач. А за пишување вакви апликации ни требаат нови работи.

Една од тие работи е поддршката за нов начин за ослободување серверски апликации. Наместо едно или две големи изданија годишно, како што е десктоп софтверот, серверскиот софтвер ќе биде објавен во серија мали промени. Можеби ќе имате пет или десет изданија на ден. И секој секогаш ќе ја има најновата верзија.

Дали знаете како да дизајнирате програми за да се одржуваат? Серверскиот софтвер мора да биде дизајниран да биде променлив. Треба да можете лесно да го промените, или барем да знаете што значи мала промена и што е важно.

Друга работа што може да биде корисна во серверскиот софтвер е, одеднаш, континуитетот на испорака. Во веб-апликација можете да користите нешто како CPSза да го добиете ефектот на рутините во светот на веб-сесиите без државјанство. Можеби вреди да се има континуитет на снабдување ако функцијата не е премногу скапа.

4. Кои нови апстракции остануваат да се откријат?

Не сум сигурен колку е разумна таа надеж, но лично јас навистина би сакал да откријам нова апстракција - нешто што може да биде значајно како првокласните функции или рекурзија или барем стандардните параметри. Можеби ова е невозможен сон. Такви работи често не се откриваат. Но, не губам надеж.

Малку познати тајни

1. Можете да користите кој било јазик што сакате

Претходно, создавањето на апликации значеше создавање на десктоп софтвер. И во десктоп софтверот постои голема пристрасност кон пишување апликации на истиот јазик како и оперативниот систем. Така, пред десет години, пишувањето софтвер воопшто значеше пишување софтвер во C. На крајот, традицијата еволуираше: апликациите не треба да се пишуваат на необични јазици. И оваа традиција еволуираше толку долго што не-технички луѓе како менаџери и ризични капиталисти исто така ја научија.

Софтверот од страна на серверот целосно го уништува овој модел. Со софтверот од страна на серверот, можете да користите кој било јазик што го сакате. Речиси никој сè уште не го разбира ова (особено менаџерите и ризичните капиталисти). Но, некои хакери го разбираат, поради што слушаме за инди-јазици како Perl и Python. Не слушаме за Perl и Python затоа што луѓето ги користат за пишување апликации за Windows.

Што значи ова за нас, луѓето заинтересирани за дизајн на програмски јазик, дека постои потенцијална публика за нашата работа.

2. Брзината доаѓа од профилаторите

Развивачите на јазици, или барем имплементаторите на јазици, сакаат да пишуваат компајлери кои генерираат брз код. Но, мислам дека тоа не е она што ги прави јазиците брзи за корисниците. Кнут одамна забележа дека брзината зависи од само неколку тесни грла. И секој што се обидел да ја забрза програмата знае дека не можете да погодите каде е тесното грло. Профилерот е одговорот.

Развивачите на јазици го решаваат погрешниот проблем. На корисниците не им требаат репери за брзо да работат. Ним им треба јазик што може да покаже кои делови од нивната програма треба да се препишат. Во овој момент, брзината е потребна во пракса. Така, можеби би било подобро доколку јазичните имплементатори потрошат половина од времето што го поминуваат за оптимизирање на компајлерот и го потрошат на пишување добар профилатор.

3. Потребна ви е апликација која го прави вашиот јазик да се развива

Можеби ова не е крајната вистина, но се чини дека најдобрите јазици еволуирале заедно со апликациите во кои се користеле. C беше напишана од луѓе на кои им требаше системско програмирање. Лисп беше дизајниран делумно за симболична диференцијација, а Мекарти беше толку желен да започне што дури почна да пишува програми за диференцијација во првиот труд на Лисп во 1960 година.

Ова е особено добро ако вашата апликација решава некои нови проблеми. Ова го турка вашиот јазик да има нови функции што ги сакаат програмерите. Мене лично ме интересира да напишам јазик кој ќе биде добар за серверски апликации.

[За време на дискусијата, Гај Стил, исто така, ја истакна оваа поента, додавајќи дека апликацијата не треба да се состои од пишување компајлер за вашиот јазик, освен ако вашиот јазик е дизајниран за пишување компајлери.]

4. Јазикот мора да биде соодветен за пишување еднократни програми.

Знаете што значи еднократна програма: тоа е кога треба брзо да решите некој ограничен проблем. Верувам дека ако погледнете наоколу, ќе најдете многу сериозни програми кои започнаа како еднократни. Не би бил изненаден ако повеќето програми започнаа како еднократни. Така, ако сакате да креирате јазик што ќе биде соодветен за пишување софтвер воопшто, тогаш тој треба да биде погоден и за пишување еднократни програми, бидејќи ова е почетната фаза на многу програми.

5. Синтаксата е поврзана со семантиката

Традиционално се верува дека синтаксата и семантиката се многу различни работи. Ова можеби звучи шокантно, но не е. Мислам дека она што сакате да го постигнете во вашата програма е поврзано со тоа како го изразувате.

Неодамна разговарав со Роберт Морис и тој забележа дека преоптоварувањето на операторот е голем плус за победата на јазиците со инфикс синтакса. Во јазиците со префиксна синтакса, секоја функција што ќе ја дефинирате е всушност оператор. Ако сакате да додадете нов тип на број што сте го измислиле, можете едноставно да дефинирате нова функција за да ја додадете. Ако го направите ова на јазик со инфикс синтакса, ќе видите дека има голема разлика помеѓу користење на преоптоварен оператор и повикување функција.

Идеи кои се враќаат со текот на времето

1. Нови програмски јазици

Гледајќи наназад во 1970-тите, беше модерно да се развиваат нови програмски јазици. Сега не е така. Но, верувам дека серверскиот софтвер повторно ќе ја врати модата за создавање нови јазици. Со серверскиот софтвер можете да користите кој било јазик што сакате, па ако некој создаде јазик што изгледа подобар од останатите, ќе има луѓе кои ќе одлучат да го користат.

2. Споделување на време

Ричард Келси дојде до оваа идеја чие време повторно дојде и јас целосно ја поддржувам. Мојата претпоставка (и на Мајкрософт исто така) е дека многу компјутери ќе се префрлат од работната површина на оддалечените сервери. Со други зборови, споделувањето на времето се врати. Мислам дека ова ќе треба поддршка на јазично ниво. На пример, Ричард и Џонатан Ривс направија многу работа за спроведување на распоредот на процесите во Шемата 48.

3. Ефикасност

Неодамна, се чинеше дека компјутерите се доволно брзи. Сè повеќе слушаме за бајткод, што, барем за мене, значи дека имаме резервна моќ. Но, мислам дека со серверскиот софтвер немаме. Некој ќе мора да плати за тоа. сервериБројот на сервери на кои работи софтверот и бројот на корисници на кои серверот може да се справи по машина ќе биде делител на нивните капитални трошоци.

Мислам дека ефикасноста ќе биде важна, барем во компјутерските тесни грла. Ова ќе биде особено важно за I/O операциите, бидејќи серверските апликации вршат многу такви операции.

На крајот, може да испадне дека бајт-кодот не е одговорот. Sun и Microsoft се чини дека одат глава до глава во полето бајтекод во моментот. Но, тие го прават тоа затоа што бајтекодот е погодно место за вградување во процес, а не затоа што самиот бајтекод е добра идеја. Може да испадне дека целата оваа битка ќе помине незабележано. Би било смешно.

Замки и замки

1. Клиенти

Ова е само претпоставка, но тоа е дека единствените апликации што ќе имаат корист се оние што се целосно серверски. Дизајнирањето софтвер кој работи со претпоставка дека секој ќе има клиент е како дизајнирање на општество засновано на претпоставката дека секој ќе биде искрен. Дефинитивно би било погодно, но мора да претпоставите дека никогаш нема да се случи.

Мислам дека ќе има брз пораст на уредите со овозможен веб, и можеме да претпоставиме дека тие ќе поддржуваат основни html и форми. Дали имате прелистувач на вашиот телефон? Дали вашиот PalmPilot ќе има телефон? Дали вашиот Blackberry ќе има поголем екран? Дали ќе можете да пристапите на Интернет од вашиот гејбој? Од твојот часовник? не знам. И нема да морам да дознаам дали се обложувам дека се ќе биде на серверот. Едноставно е многу посигурно да ги имаш сите мозоци на серверот. .

2. Објектно-ориентирано програмирање

Сфаќам дека ова е контроверзна изјава, но мислам дека ООП не е толку важен. Мислам дека ова е соодветна парадигма за специфични апликации кои имаат потреба од специфични структури на податоци, како што се системи за прозорци, симулации, CAD системи. Но, не разбирам зошто треба да одговара за сите програми.

Мислам дека луѓето во големите компании го сакаат OOP, делумно, бидејќи тоа прави многу работи што изгледаат како да функционираат. Она што природно би можело да биде претставено како, на пример, листа на цели броеви, сега може да се претстави како училница со секакви скелиња, гужва и врева.

Друга атрактивна карактеристика на OOP е тоа што методите ви даваат дел од ефектот на првокласните функции. Но, ова не е новост за програмерите на Lisp. Кога имате вистински првокласни функции, можете едноставно да ги користите на кој било начин што одговара на задачата, наместо да туркате сè во чинија со класи и методи.

Мислам дека тоа значи за јазичниот дизајн е дека не треба да го вметнувате OOP премногу длабоко во него. Можеби одговорот е да се понудат поопшти, основни работи и да им се дозволи на луѓето да дизајнираат какви било објектни системи како библиотеки.

3. Дизајн од комисија

Ако вашиот јазик е дизајниран од комисија, тогаш сте заробени, а не само од причини што сите ги знаат. Секој знае дека комитетите имаат тенденција да создаваат грутки, неконзистентни јазични дизајни. Но, мислам дека големата опасност е што тие не ризикуваат. Кога едно лице е одговорно, тој презема ризици што комисијата никогаш не би се согласила да ги преземе.

Дали треба да ризикувате за да создадете добар јазик? Многу луѓе може да се сомневаат дека јазичниот дизајн е местото каде што треба да останете прилично блиску до традиционалната мудрост. Се обложувам дека не е така. Во сè друго што луѓето прават, наградата е пропорционална на ризикот. Па, зошто дизајнот на јазикот треба да биде поинаков?

Извор: www.habr.com