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

Водеща философия

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

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

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

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

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

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

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

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

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

Няма нищо общо с високото ниво на езика. 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. Нови езици за програмиране

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

2. Споделяне на времето

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

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

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

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

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

Примки и примки

1. Клиенти

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

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

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

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

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

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

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

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

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

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

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