Пет въпроса относно проектирането на езици за програмиране

Ръководна философия

1. Програмни езици за хората

Програмните езици представляват начина, по който хората комуникират с компютрите. Компютърът с радост ще говори на всеки език, който не е неясен. Причината, поради която имаме езици с високо ниво, е че хората не могат да се справят с машинния език. Същността на програмните езици е да предпази нашия уязвим човешки мозък от претоварване с твърде много детайли.

Архитектите знаят, че някои проекти са по-приземени от други. Едни от най-ясните и абстрактни дизайнерски проблеми са проектите за мостове. В този случай вашата задача е да покриете необходимото разстояние с възможно най-малко материал. В другия край на спектъра е проектирането на столове. Дизайнерите на столове трябва да инвестират време в размисли за човешките задни части.

Разработката на софтуер има сходна разлика. Проектирането на алгоритми за маршрутизация на данни в мрежата е добър абстрактен проблем, както и проектирането на мостове. Докато проектирането на програмни езици е подобно на проектирането на столове: необходимо е да се справите с човешките слабости.

На повечето от нас е трудно да осъзнаем това. Проектирането на елегантни математически системи звучи много по-привлекателно за повечето от нас, отколкото да отстъпваме на човешките слабости. Ролята на математическата елегантност е в това, че определена степен на елегантност прави програмите по-лесно разбираеми. Но елегантността не е единственото, което има значение.

И когато казвам, че езиците трябва да бъдат проектирани с оглед на човешките слабости, не искам да кажа, че езиците трябва да бъдат проектирани за лоши програмисти. Всъщност, вие трябва да проектирате софтуер за най-добрите програмисти, но дори и най-добрите програмисти имат своите ограничения. Не мисля, че някой би желал да програмира на език, в който всички променливи са обозначени с буквата «x» с целочислени индекси.

2. Проектирайте за себе си и за вашите приятели

Ако погледнете историята на програмните езици, повечето от най-добрите езици са проектирани за употреба от техните автори, а най-лошите — за други хора.

Когато езици се проектират за други хора, това винаги е конкретна група: хората не са толкова умни, колкото създателите на езика. Така получавате език, който ви говори с покровителственост. Cobol е най-яркият пример, но повечето езици са пронизани от този дух.

Това няма нищо общо с нивото на езика. C е сравнително нискоуровневен, но е създаден за използване от неговите автори, затова хакерите го обичат.

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

Интересно ми е как да създам език, който ще хареса на най-добрите хакери? Смятам, че този въпрос е идентичен на въпроса как да създадем добър език за програмиране?, но дори и да не е така, поне е интересен въпрос.

3. Дайте на програмистите колкото се може повече контрол

Много езици (особено тези, създадени за други хора) действат като детегледачки: те се опитват да ви предупреждават за неща, които смятат, че няма да ви бъдат полезни. Аз съм на противоположното мнение: дайте на програмистите колкото се може повече контрол.

Когато за пръв път изучавах Lisp, най-много ми харесваше, че разговаряхме на равни начала. В другите езици, които бях изучавал до този момент, имаше език и имаше моята програма на този език, и те съществуваха доста отделно. Но в Lisp функциите и макросите, които написах, бяха същите, на които беше написан самият език. Можех да пренапиша самия език, ако исках. Имаше същата привлекателност като софтуера с отворен код.

4. Краткостта е сестра на таланта

Краткостта е недооценена и дори презирана. Но ако погледнете в сърцата на хакерите, ще видите, че те много обичат краткостта. Колко пъти сте чували как хакерите с обич говорят за това, че например в APL могат да правят удивителни неща само с няколко реда код? Считам, че наистина интелигентните хора всъщност обичат да обръщат внимание на това.

Смятам, че почти всичко, което позволява да направите програмите по-кратки, е добре. Трябва да има множество библиотечни функции, всичко, което може да бъде неявно, трябва да бъде такова; синтаксисът следва да бъде повече кратък; дори имената на обектите трябва да бъдат кратки.

И не само програмите трябва да бъдат кратки. Ръководствата също трябва да бъдат кратки. Добрата част от ръководствата е изпълнена с обяснения, уговорки, предупреждения и специални случаи. Ако трябва да съкратите ръководство, най-добрият вариант е да коригирате езика, който изисква толкова много обяснения.

5. Признайте какво е хакерство

Много хора биха искали хакерството да бъде математика или поне нещо подобно на естествените науки. Смятам, че хакерството повече прилича на архитектура. Архитектурата е свързана с физиката, в смисъл, че архитектът трябва да проектира сграда, която да не се срути, но истинската цел на архитекта е да създаде велика сграда, а не да направи открития в областта на статика.

Каквото хакерите обичат, е да създават велики програми. И смятам, че поне в собствените си мисли, трябва да помним, че писането на забележителни програми е невероятно, дори когато тази работа не се превежда лесно в обикновената интелектуална валута на научните изследвания. От интелектуална гледна точка, не по-малко важно е както да се разработи език, който програмистите ще обичат, така и да се създаде ужасен, олицетворяващ идеята, за която можете да публикувате статия.

Отворени проблеми

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

Библиотеките стават важна част от програмните езици. Те стават толкова големи, че това може да бъде опасно. Ако отнема повече време да се намери функция в библиотеката, която прави това, от което имате нужда, отколкото да напишете функцията сами, то целият код не прави нищо, освен да удебеляване вашето ръководство. (Например, ръководствата на Symbolics бяха такъв случай.) Така че ще трябва да решим проблема с организациите на библиотеките. В идеалния случай е добре да ги проектираме така, че програмистът да може да предположи коя функция от библиотеката би била подходяща.

2. Наистина ли хората се страхуват от префиксната синтаксис?

Това е открит проблем в смисъл, че мислех за него няколко години и все още не знам отговора. Префиксният синтаксис ми се струва абсолютно естествен, може би с изключение на използването му в математиката. Но може да е така, че голяма част от непопулярността на Lisp-ите е просто заради незапознатия синтаксис... Дали е необходимо да се прави нещо с това, ако е вярно, е друг въпрос.

3. Какво ви е необходимо за софтуера на сървъра?

Мисля, че повечето приложения, които ще бъдат написани през следващите двадесет години, ще бъдат уеб-приложения, в смисъл, че програмите ще бъдат разположени на сървъра и ще комуникират с вас през уеб браузър. И за да напишем такива приложения, нуждаем се от нови неща.

Едно от тези неща е поддръжката на нов начин за пускане на сървърни приложения. Вместо един или два големи релиза годишно, както е при настолния софтуер, сървърният софтуер ще бъде пускан в серия от малки промени. Можете да имате пет или десет релиза на ден. И всеки винаги ще има последната версия.

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

Още нещо, което може да бъде полезно в сървърния софтуер, е, внезапно, непрекъснатостта на доставките. В уеб-приложение можете да използвате нещо като CPS, за да постигнете ефекта от подпрограмите в бездържавния свят на уеб сесиите. Може би има смисъл непрекъснатостта на доставките, ако тази възможност не е твърде скъпа.

4. Какви нови абстракции остават да бъдат открити?

Не съм сигурен доколко е разумна такава надежда, но лично на мен ми се иска да открия нова абстракция — нещо, което би могло да има също толкова голямо значение, колкото функциите от първи клас или рекурсията, или поне параметрите по подразбиране. Може би това е неизпълнима мечта. Такива неща рядко се откриват. Но не губя надежда.

Малкоизвестни тайни

1. Можете да използвате всеки език, който желаете

Преди, когато се говореше за създаване на приложения, се имаше предвид разработване на десктоп софтуер. А в десктоп софтуера имаше сериозен уклон към писането на приложения на същия език, който е операционната система. Преди десет години разработването на софтуер означаваше да пишете софтуер на C. В крайна сметка традицията се е развила: приложенията не трябва да бъдат написани на необичайни езици. И тази традиция се развива толкова дълго, че нетехнически хора, като мениджъри и рискови капиталисти, също са я усвоили.

Сървърният софтуер напълно унищожава тази модел. Със сървърен софтуер можете да вземете всеки език, който желаете. Почти никой все още не го разбира (особено мениджерите и рисковите капиталисти). Но някои хакери го разбират, затова сме чували за такива инди езици като Perl и Python. Не чуем за Perl и Python, защото хората ги използват за създаване на приложения за Windows.

Какво означава това за нас, хората, които се интересуват от проектиране на езици за програмиране, че съществува потенциална аудитория за нашата работа.

2. Скоростта идва от профайлерите

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

Разработчиците на езика решават неправилният проблем. Потребителите не се нуждаят бенчмарковете да работят бързо. Им трябва език, който може да покаже кои части от тяхната програма трябва да бъдат преписани. В този момент, скоростта е важна в практиката. Може би би било по-добре, ако реализаторите на езика прекарат половината от времето, което отделят за оптимизация на компилатора, в писане на добър профайлер.

3. Нужно ви е приложение, което да кара вашия език да се развива.

Може би това не е последната инстанция, но изглежда, че най-добрите езици се развиват заедно с приложенията, в които се използват. C е бил написан от хора, на които им е било нужно системно програмиране. Lisp е разработен отчасти за символна диференциация, а Маккартни е бил толкова нетърпелив, че е започнал да пише програми за диференциация още в първия документ за Lisp през 1960 година.

Това е особено добре, ако вашето приложение решава нови проблеми. Това подтиква вашия език да създава нови възможности, които са нужни на програмистите. Лично на мен ми е интересно да пиша език, който ще е добър за сървърни приложения.

[По време на дискусията Гай Стил също изрази тази мисъл, добавяйки, че приложението не трябва да се състои в написването на компилатор за вашия език, освен ако вашият език не е предназначен за написване на компилатори.]

4. Езикът трябва да е подходящ за писане на програми за еднократна употреба.

Знаете какво означава програма за еднократна употреба: когато трябва бързо да решите някаква ограничена задача. Мисля, че ако погледнете около себе си, ще откриете много сериозни програми, които са започнало като еднократни. Не бих се учудил, ако повечето програми са започнали като еднократни. Така че, ако искате да създадете език, който ще е подходящ за писане на софтуер като цяло, той също трябва да е подходящ за написване на еднократни програми, защото това е началният етап за много програми.

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

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

Наскоро говорих с Робърт Мори, който отбеляза, че презареждането на операторите е голям плюс за печалбата на езици с инфиксен синтаксис. В езици с префиксен синтаксис всяка функция, която дефинирате, всъщност е оператор. Ако искате да съберете нов тип число, което сте измислили, можете просто да дефинирате нова функция за него. Ако направите така в език с инфиксен синтаксис, ще видите, че между използването на презареден оператор и извикването на функция има голяма разлика.

Идеи, които се завръщат с времето

1. Нови програмиращи езици

Връщайки се назад към 70-те години, беше модно да се разработват нови програмиращи езици. Сега не е така. Но смятам, че софтуерът на сървъри отново ще върне модата на създаването на нови езици. Със софтуера на сървъри можете да използвате какъвто и да е език, който пожелаете, така че ако някой създаде език, който изглежда по-добре от останалите, ще има хора, които ще решат да го използват.

2. Разделение на времето

Ричард Келси предложи тази идея, времето на която отново е дошло, и напълно я подкрепям. Моето предположение (и на Microsoft също) е, че много изчисления ще преминат от настолни компютри към отдалечени сървъри. С други думи, разделението на времето се е завърнало. Смятам, че за това ще е нужна поддръжка на ниво език. Например, Ричард и Джонатан Рийвс направиха много работа за внедряване на планиране на процеси в Scheme 48.

3. Ефективност

Наскоро изглеждаше, че компютрите вече са достатъчно бързи. Все по-често чуваме за байт-код, което за мен означава, че имаме мощност в запас. Но смятам, че със софтуера на сървъри не я притежаваме. Някой трябва да плати за сървъри, на които работи софтуерът, и броят на потребителите, които сървърът може да обслужва на една машина, ще бъде делител на техните капиталови разходи.

Смятам, че ефективността ще има значение, поне във възловите точки на изчисленията. Особено важна ще бъде за операции с вход-изход, защото сървърните приложения извършват множество такива операции.

В крайна сметка може да се окаже, че байт-кодът не е решение. Sun и Microsoft в момента изглежда се борят лице в лице на полето на байт-кода. Но те го правят, защото байт-кодът е удобно място за вграждане в процеса, а не защото сам по себе си е добра идея. Може да се окаже, че цялата тази битка ще премине незабелязано. Би било забавно.

Капани и уловки

1. Клиенти

Това е само предположение, но е такова, че ще спечелят само тези приложения, които ще бъдат напълно сървърни. Проектирането на софтуер с предположението, че всеки ще има ваш клиент, прилича на създаването на общество, основано на предположението, че всички ще бъдат честни. Това със сигурност би било удобно, но ще трябва да допуснете, че това никога няма да се случи.

Смятам, че ще има бързо нарастване на устройствата с достъп до интернет и можем да предположим, че те ще поддържат основен HTML и форми. Имате ли браузър на телефона си? Ще ли телефонът да е на вашия PalmPilot? Ще има ли вашият blackberry по-голям екран? Ще можете ли да влезете в интернет от своя gameboy? От вашите часовници? Не знам. И не ми е нужно да знам, ако заложа, че всичко ще бъде на сървъра. Просто е много по-надеждно да имате всички ресурси на сървъра.

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

Разбирам, че това е противоречиво твърдение, но не смятам, че ООП е нещо важно. Мисля, че това е подходяща парадигма за конкретни приложения, които се нуждаят от специфични структури от данни, като системи за интерфейси, симулации и CAD системи. Но не разбирам, защо трябва да е подходяща за всички програми.

Смятам, че хората в големите компании харесват ООП, отчасти защото предлага много от това, което изглежда като работа. Това, което естествено може да бъде представено като, да кажем, списък от цели числа, сега може да бъде представено като клас с всякакви видове строителни конструкции, включително шум и суета.

Друга привлекателна черта на ООП е, че методите ви предоставят ефект на функции от първи клас. Но това не е новина за програмистите на Lisp. Когато имате истински функции от първи клас, можете просто да ги използвате по всякакъв начин, който отговаря на задачата, вместо да натъпквате всичко в шаблон от класове и методи.

Смятам, че това означава за езиковия дизайн, че не трябва да внедрявате ООП твърде дълбоко в него. Може би отговорът е да предлагате по-общи, основополагаещи концепции и да позволите на хората да проектират всякакви обектни системи под формата на библиотеки.

3. Проектиране от комитет

Ако вашият език се проектира от комитет, то вие сте в капан, и не само по причини, които всички знаят. Всички знаят, че комитетите имат склонност да създават нееднороден, непоследователен езиков дизайн. Но смятам, че голямата опасност е, че те не поемат рискове. Когато начело е един човек, той поема рисковете, които комитетът никога не би се съгласил да поеме.

Трябва ли да рискувате, за да създадете добър език? Много хора биха могли да подозират, че проектирането на език е нещо, при което трябва да се придържате доста близо до традиционната мъдрост. Мога да поспоря, че не е така. Във всичко останало, което правят хората, наградата е пропорционална на риска. Та защо проектирането на езици трябва да бъде различно?

Източник: habr.com