Ръководна философия
1. Програмни езици за хората
Програмните езици са начинът, по който хората общуват с компютрите. Компютърът с радост ще разговаря на всеки език, който не е двусмислен. Причината, поради която имаме езици с високо ниво, е че хората не могат да се справят с машинния език. Същността на програмните езици е да предотвратят пренатоварването на нашия крехък човешки мозък с твърде много детайли.
Архитектите знаят, че някои проектантски проблеми са по-приземени от други. Някои от най-ясните и абстрактни проектантски проблеми са проектирането на мостове. В този случай работата ви е да покриете необходимото разстояние с възможно най-малко материал. В другия спектър е проектирането на столове. Проектантите на столове трябва да влагат време в размисли за човешките задници.
Разработването на софтуер има подобно разграничение. Проектирането на алгоритми за маршрутизиране на данни през мрежа е добра, абстрактна задача, подобно на проектирането на мостове. Докато проектирането на програмни езици е като проектирането на столове: необходимо е да се справим с човешките слабости.
На повечето от нас ни е трудно да го осъзнаем. Проектирането на елегантни математически системи звучи много по-привлекателно за повечето от нас, отколкото да се съобразяваме с човешките слабости. Ролята на математическата елегантност е в това, че известна степен на елегантност прави програмите по-лесни за разбиране. Но елегантността не е всичко.
И когато казвам, че езиците трябва да бъдат проектирани с оглед на човешките слабости, не имам предвид, че те трябва да бъдат проектирани за слаби програмисти. Всъщност, трябва да проектирате софтуера за най-добрите програмисти, но дори и най-добрите програмисти имат своя предел. Не мисля, че някой би искал да програмира на език, където всички променливи са обозначени с буквата „x“ с цели числени индекси.
2. Проектирайте за себе си и вашите приятели
Ако погледнете историята на програмиращите езици, повечето от най-добрите езици са проектирани да се използват от техните създатели, а повечето от най-лошите – за други хора.
Когато езиците се проектират за други хора, това винаги е конкретна група: хората не са толкова умни, колкото създателите на езика. Така получавате език, който говори с вас снизходително. Cobol е ярък пример, но повечето езици са пронизани от този дух.
Това няма нищо общо с това колко високо е нивото на езика. C е достатъчно ниско ниво, но той е създаден за използване от неговите автори, затова хакерите го обичат.
Аргументът в полза на проектирането на езици за лоши програмисти е, че лошите програмисти са повече от добрите. Вероятно е така. Но малкото добри програмисти пишат непропорционално повече софтуер.
Интересува ме въпросът как да създадем език, който ще хареса на най-добрите хакери? Намирам, че този въпрос е идентичен на въпроса как да създадем добър програмиращ език?, но дори и ако не е, това е поне интересен въпрос.
3. Дайте на програмиста толкова контрол, колкото е възможно
Много езици (особено тези, които са създадени за други хора) се държат като детегледачки: те се опитват да ви предпазят от неща, които смятат, че няма да ви полезни. Аз стоя на противоположната позиция: дайте на програмиста толкова контрол, колкото можете.
Когато за първи път учех Lisp, най-много ми хареса, че разговаряхме на равноправна основа. В другите езици, които бях изучил до този момент, имаше език и имаше моята програма на този език, и те съществуваха доста отделно. Но в Lisp функциите и макросите, които написах, бяха същите, с които беше написан и самият език. Можех да презапиша самия език, ако поисках. Той имаше същата привлекателност, както и софтуера с отворен код.
4. Краткостта е сестра на таланта
Краткостта е недооценена и дори презирана. Но ако надникнете в сърцата на хакерите, ще видите, че те много обичат краткостта. Колко пъти сте чували как хакерите с любов говорят за това, че, да речем, в APL могат да правят удивителни неща с помощта само на няколко реда код? Смятам, че наистина умните хора всъщност обичат да обръщат внимание на това.
Смятам, че почти всичко, което позволява програмите да бъдат по-кратки — е добре. Трябва да има множество библиотечни функции, всичко, което може да бъде неявно — трябва да бъде такова; синтаксисът трябва да бъде в голяма степен кратък; дори имената на съществата трябва да са кратки.
И не само програмите трябва да са кратки. Ръководствата също трябва да са кратки. Огромна част от ръководствата е изпълнена с разяснения, уточнения, предупреждения и специални случаи. Ако ви се наложи да съкратите ръководство, най-добрият вариант е да поправите езика, който изисква толкова много обяснения.
5. Признайте какво е хакерство
Много хора биха искали хакерството да бъде математика или поне нещо, подобно на естествените науки. Аз считам, че хакерството по-скоро прилича на архитектура. Архитектурата е свързана с физиката в смисъла, че архитектът трябва да проектира сграда, която да не се срути, но истинската цел на архитекта е да създаде велико здание, а не да направи открития в областта на статика.
Какво хакерите обичат, е да създават велики програми. И смятам, че, поне в собствените ни мисли, трябва да помним, че писането на забележителни програми е прекрасно, дори когато тази работа не се преобразува лесно в обикновена интелектуална валута на научните трудове. От интелектуална гледна точка не е по-малко важно как да се разработи език, който програмистите ще обикнат, така и да се създаде ужасна, материализираща идеята, за която можете да публикувате статия.
Отворени проблеми
1. Как да организираме големи библиотеки?
Библиотеките стават важна част от езиците за програмиране. Те стават толкова големи, че това може да бъде опасно. Ако отнема повече време да намерите функция в библиотеката, която прави това, от което имате нужда, отколкото да напишете функцията сами, то целият код не прави нищо друго, освен да утежнява вашия мануал. (Ръководствата на Symbolics бяха пример за това.) Затова ще трябва да решим проблема с организацията на библиотеките. В идеалния случай, трябва да ги проектираме така, че програмистът да може да се досети коя функция от библиотеката е подходяща.
2. Хората наистина ли са изплашени от префиксната синтаксис?
Това е открит проблем в смисъл, че мислех над него няколко години и все още не знам отговора. Префиксният синтаксис ми се струва абсолютно естествен, освен може би в употребата му в математиката. Но може да е така, че голяма част от непопулярността на Lisp-овете е просто заради непознатия синтаксис... Дали е необходимо нещо да се направи по този въпрос, ако това е вярно, е друг въпрос.
3. Какво е необходимо за сървърен софтуер?
Мисля, че повечето приложения, които ще бъдат написани през следващите двадесет години, ще бъдат уеб приложения, в смисъл, че програмите ще бъдат разположени на сървъра и ще комуникират с вас чрез уеб браузър. И за да напишем такива приложения, ни трябват нови неща.
Една от тези неща е поддръжката на нов начин за освобождаване на сървърни приложения. Вместо един или два големи релиза на година, както е при десктоп софтуера, сървърният софтуер ще бъде освобождаван в серия от малки промени. Може да имате пет или десет релиза на ден. И всички винаги ще имат последната версия.
Знаете ли как да проектирате програми, така че да са поддържани? Сървърният софтуер трябва да бъде проектиран така, че да е способен на промени. Трябва да имате възможност да го променяте лесно или поне да знаете какво означава малка промяна и какво е важно.
Още нещо, което може да бъде полезно в сървърния софтуер, е, изведнъж, непрекъснатост на доставките. В уеб приложение можете да използвате нещо като , за да получите ефекта от подпрограмите в stateless света на уеб сесиите. Може да си струва непрекъснатостта на доставките, ако тази възможност не е твърде скъпа.
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
