Керівна філософія
1. Мови програмування для людей
Мови програмування це те, як люди говорять із комп'ютерами. Комп'ютер буде радий поговорити будь-якою мовою, яка не буде двозначною. Причина чому ми маємо високорівневі мови — тому що люди не можуть впоратися з машинною мовою. Суть мов програмування в тому, щоб запобігти нашому бідному тендітному людському мозку від навантаження масою деталей.
Архітектори знають, деякі проблеми проектування більш приземлені, ніж інші. Одні з найяскравіших та абстрактніших проблем проектування це проектування мостів. У цьому випадку ваша робота в тому, щоб охопити потрібну відстань якомога меншою кількістю матеріалу. На іншому кінці спектру – проектування стільців. Проектувальники стільців повинні витрачати свій час на роздуми про людські дупи.
Розробка софту має схожу різницю. Проектування алгоритмів маршрутизації даних через мережу — хороша, абстрактна проблема, як проектування мостів. Тоді як проектування мов програмування подібно до проектування стільців: потрібно справлятися з людськими слабкостями.
Більшості з нас це важко усвідомлювати. Проектування елегантних математичних систем звучить набагато привабливіше для більшості з нас, ніж потурання людським слабкостям. Роль математичної елегантності полягає в тому, що певний ступінь елегантності робить програми простішими для розуміння. Але елегантністю все не обмежується.
І коли я кажу, що мови мають бути спроектовані, щоб враховувати людські слабкості, я не маю на увазі, що мови мають бути спроектовані для поганих програмістів. Насправді ви повинні проектувати софт для кращих програмістів, але навіть кращі програмісти мають свою межу. Я не думаю, що хоч комусь сподобається програмувати мовою, де всі змінні позначалися б буквою «x» із цілими індексами.
2. Проектуйте для себе та для своїх друзів
Якщо ви подивитеся на історію мов програмування, більшість із найкращих мов були спроектовані для використання своїми ж авторами, а більшість із найгірших — спроектовані для інших людей.
Коли мови проектуються іншим людям, це завжди якась конкретна група людей: люди такі розумні, як творці мови. Так ви отримуєте мову, яка говорить з вами поблажливо. Cobol – найяскравіший приклад, але більшість мов пронизані цим духом.
Це не має нічого спільного з тим, наскільки високорівневою є мова. C - досить низькорівневий, але він був створений для використання його авторами, тому хакери люблять його.
Аргумент на користь проектування мов для поганих програмістів у тому, що поганих програмістів більше, ніж добрих. Мабуть, це так. Але це невелика кількість хороших програмістів пише непропорційно більше за софт.
Мене цікавить питання, як створити мову, яка сподобається найкращим хакерам? Мені здається це питання ідентичне питанню, як створити хорошу мову програмування?, але навіть якщо це не так, то принаймні це цікаве питання.
3. Дайте програмісту стільки контролю, скільки можливо
Багато мов (особливо ті, які створені для інших людей) поводяться як няньки: вони намагаються застерегти вас від речей, які, на їхню думку, будуть вам не корисні. Я дотримуюсь протилежної думки: дайте програмісту стільки контролю, скільки можете.
Коли я вперше вивчав Lisp, мені найбільше сподобалося те, що ми розмовляли на рівних. В інших мовах, які я на той момент вивчив, була мова, а була моя програма цією мовою, і вони існували досить окремо. Але в Lisp'і функції та макроси, які я написав, були такими ж якими була написана сама мова. Я міг би переписати саму мову, якби захотів. Він мав таку ж привабливість, як і софт з відкритим кодом.
4. Короткість – сестра таланту
Короткість недооцінена і навіть зневажається. Але якщо ви загляньте в серця хакерів, ви побачите, що вони дуже люблять стислість. Скільки разів ви чули, як хакери з любов'ю говорять про те, що, скажімо, в APL вони можуть робити дивовижні речі за допомогою лише кількох рядків коду? Я вважаю, що по-справжньому розумні люди дійсно люблять звертати увагу на це.
Я вважаю, що майже все, що дозволяє зробити програми коротшими, — добре. Має бути безліч бібліотечних функцій, все, що може бути неявним — має бути таким; синтаксис має бути більшою мірою коротким; навіть імена сутностей мають бути короткими.
І не лише програми мають бути короткими. Мануали теж мають бути короткими. Добра частина мануалів наповнена роз'ясненнями, застереженнями, попередженнями та особливими випадками. Якщо вам потрібно скоротити мануал, найкращий варіант це виправити мову, яка вимагає багато пояснень.
5. Визнайте, що таке хакерство
Багатьом людям хотілося б, щоб хакерство було математикою чи, хоча б, чимось схожим на природничі науки. Я думаю, що хакерство більше схоже на архітектуру. Архітектура пов'язана з фізикою, у тому плані, що архітектору потрібно проектувати будівлю, яка не впаде, але справжня мета архітектора в тому, щоб створити велику будівлю, а не зробити відкриття в галузі статики.
Що хакери люблять, то це створювати великі програми. І я думаю, що принаймні у наших власних думках ми повинні пам'ятати, що писати чудові програми — це чудово, навіть коли ця робота нелегко переводиться у звичайну інтелектуальну валюту наукових праць. З інтелектуальної точки зору, не менш важливо як розробляти мову, яку полюблять програмісти, так і створювати жахливий, що втілює ідею, про яку ви можете опублікувати статтю.
Відкриті проблеми
1. Як організувати великі бібліотеки?
Бібліотеки є важливою частиною мов програмування. Вони стають настільки великими, що це може бути небезпечним. Якщо потрібно більше часу, щоб знайти функцію в бібліотеці, яка робить те, що вам потрібно, ніж написати цю функцію самому, весь код не робить нічого, крім потовщення вашого мануалу. (Посібники Symbolics були прикладом.) Тож нам доведеться вирішити проблему з організацією бібліотек. В ідеалі спроектувати їх так, щоб програміст міг би здогадатися, яка бібліотека підійде.
2. Люди справді налякані префіксним синтаксисом?
Це відкрита проблема в тому сенсі, що я думав над нею кілька років, і все ще не знаю відповіді. Префіксний синтаксис здається мені абсолютно природним, можливо, крім використання його в математиці. Але може так, що більшість непопулярності Lisp'ів просто через незнайомий синтаксис... Чи варто щось із цим робити, якщо це правда, це інше питання.
3. Що потрібно для серверного софта?
Я думаю, що більшість додатків, які будуть написані в наступні двадцять років будуть веб-застосунками, в тому сенсі, що програми будуть розташовані на сервері і будуть спілкуватися з вами через веб-браузер. І щоб написати такі програми нам потрібні нові штуки.
Одна з таких речей – це підтримка нового способу випуску серверних додатків. Замість одного або двох великих релізів на рік, як десктопний софт, серверний софт випускатиметься серією дрібних змін. У вас може бути п'ять чи десять релізів на день. І у всіх завжди буде остання версія.
Ви знаєте, як проектувати програми, щоб вони були підтримуваними? Серверний софт має бути спроектований здатним до змін. У вас має бути можливість змінювати його легко, або хоча б знати, що означає дрібна зміна і що є важливим.
Ще одна річ, яка може бути корисною в серверному софті, це раптово безперервність поставки. У веб-застосунку ви можете використовувати щось на зразок , щоб отримати ефект від підпрограм у stateless світі веб-сесій. Може мати безперервність поставки вартий того, якщо ця можливість не буде занадто дорогою.
4. Які нові абстракції лишилося відкрити?
Я не впевнений, наскільки розумна така надія, але особисто мені дуже хотілося б відкрити нову абстракцію — щось таке, що могло б мати таке ж велике значення, як функції першого класу чи рекурсія або хоча б параметри за умовчанням. Може це нездійсненна мрія. Такі речі часто не відчиняють. Але я не втрачаю надії.
Маловідомі секрети
1. Ви можете використовувати будь-яку мову, якій забажаєте
Раніше під створенням програм малося на увазі створення десктопного софту. А в десктопному софті є великий ухил у бік написання додатків тією ж мовою, що й операційна система. Так десять років тому, написання софту в цілому означало написання софту на C. Зрештою традиція еволюціонувала: додатки не повинні бути написані незвичайними мовами. І ця традиція так довго розвивалася, що нетехнічні люди, як менеджери і венчурні капіталісти, теж це вивчили.
Серверний софт знищує цю модель повністю. З серверним софтом ви можете взяти будь-яку мову, якою забажаєте. Майже ніхто цього ще не розуміє (особливо менеджери і венчурні капіталісти). Але деякі хакери розуміють це, тому ми чули про такі indy-мови як Perl і Python. Ми не чуємо про Perl і Python, тому що люди використовують їх для написання програм для Windows.
Що це означає для нас, людей, зацікавлених у проектуванні мов програмування, що є потенційною аудиторією для нашої роботи.
2. Швидкість приходить від профайлерів
Розробники мови або принаймні його реалізатори люблять писати компілятори, які генерують швидкий код. Але я думаю, що це не робить мови швидкими для користувачів. Кнут давно помітив, що швидкість залежить лише від кількох вузьких місць. І будь-хто, хто намагався прискорити програму знає, що ви не зможете вгадати, де вузьке місце. Профайлер ось відповідь.
Розробники мови вирішують не проблему. Користувачам не потрібно, щоби бенчмарки працювали швидко. Їм потрібна мова, яка може показати які частини їхньої програми мають бути переписані. У цей момент швидкість потрібна практично. Так може бути краще, якщо реалізатори мови витратять половину часу, який вони витрачають на оптимізацію компілятора, і витратить його написання хорошого профайлера.
3. Вам потрібна програма, яка змушує вашу мову розвиватися
Може це не істина в останній інстанції, але, здається, найкращі мови розвивалися разом із додатками, в яких їх використовували. C був написаний людьми, яким потрібне було системне програмування. Lisp був розроблений частково для символьного диференціювання, Маккарті так не терпілося розпочати, що він почав писати програми диференціювання навіть у першому документі про Lisp у 1960 році.
Це особливо добре, якщо ваша програма вирішує деякі нові проблеми. Це підштовхує вашу мову мати нові можливості, які потрібні програмістам. Особисто мені цікаво писати мову, яка буде гарна для серверних програм.
[Під час дискусії Гай Стіл також висловив цю думку, додавши, що програма не повинна складатися з написання компілятора для вашої мови, якщо тільки ваша мова не призначена для написання компіляторів.]4. Мова має бути придатною для написання одноразових програм.
Ви знаєте, що означає одноразова програма: це коли вам потрібно швидко вирішити якесь обмежене завдання. Я вважаю, що якщо ви подивіться довкола, то виявите безліч серйозних програм, які починалися як одноразові. Я не здивуюся, якщо більшість програм починалися як одноразові. Таким чином, якщо ви хочете створити мову, яка буде придатною для написання софту в цілому, то він повинен і підходити для одноразових програм, тому що це початкова стадія багатьох програм.
5. Синтаксис пов'язаний із семантикою
Традиційно вважається, що синтаксис і семантика — речі, які дуже відрізняються. Може це прозвучить шокуючим, але це не так. Я думаю, що те, що ви хочете отримати у вашій програмі, пов'язане з тим, як ви це виражаєте.
Нещодавно я розмовляв з Робертом Моррісом, і він зауважив, що навантаження операторів це великий плюс у перемогу мов з інфіксним синтаксисом. У мовах із префіксним синтаксисом будь-яка функція, яку ви визначаєте, фактично є оператором. Якщо ви хочете скласти новий тип числа, який ви придумали, ви можете просто визначити нову функцію для його додавання. Якщо ви зробите так у мові з інфікованим синтаксисом, ви побачите, що між використанням перевантаженого оператора та викликом функції існує велика різниця.
Ідеї, які згодом повертаються
1. Нові мови програмування
Озираючись у 1970-ті, було модно розробляти нові мови програмування. Нині це не так. Але я вважаю, що серверний софт знову поверне моду створення нових мов. З серверним софтом ви можете використовувати будь-яку мову, якою побажаєте, так якщо хтось створить мову, яка здаватиметься кращою за інші, то будуть люди, які зважаться її використовувати.
2. Поділ часу
Річард Келсі подав цю ідею, час якої знову настав, і я її повністю підтримую. Моє припущення (і Microsoft теж) багато обчислень перемістяться з десктопу на віддалені сервери. Інакше кажучи, поділ часу повернулося. Я думаю, знадобиться підтримка цього на рівні мови. Наприклад, Річард та Джонатан Рівз проробили багато роботи для впровадження планування процесу у Scheme 48.
3. Ефективність
Нещодавно здавалося, що комп'ютери вже досить швидкі. Дедалі більше ми чуємо про байт-код, що принаймні для мене означає, що у нас є потужність у запасі. Але я думаю, що із серверним софтом, у нас її немає. Хтось повинен буде заплатити за сервери, на яких працює софт, і кількість користувачів, яких сервер може витримати з розрахунку на одну машину, буде дільником їх капітальних витрат.
Думаю, що ефективність матиме значення принаймні у вузьких місцях обчислень. Особливо важливим це буде для операцій введення-виводу, тому що серверні програми виробляють безліч таких операцій.
Зрештою, може виявитися, що байт-код це не вихід. Sun і Microsoft в даний момент схоже борються віч-на-віч на байт-код полі. Але вони це роблять, тому що байт-код це зручне місце для вбудовування себе в процес, а не тому, що байт-код сам по собі гарна ідея. Може виявитися, що вся ця битва пройде непоміченою. Було б кумедно.
Пастки та пастки
1. Клієнти
Це лише припущення, але воно в тому, що виграють лише ті програми, які будуть повністю серверними. Проектуючи софт, який працює на припущенні, що у кожного буде ваш клієнт, схоже на створення суспільства, заснованого на припущенні, що всі будуть чесними. Це було б безперечно зручно, але вам доведеться припустити, що цього ніколи не буде.
Я думаю буде швидке збільшення девайсів з доступом до Інтернету, і можна припустити, що вони будуть підтримувати базовий HTML і форми. Ви маєте браузер на телефоні? Чи буде телефон у вашому PalmPilot'e? У вашого Blackberry буде більший екран? Чи матиме ви можливість вийти в інтернет зі свого gameboy? З вашого годинника? Я не знаю. І мені не доведеться це дізнатися, якщо зроблю ставку, що все буде на сервері. Просто набагато надійніше мати всі мізки на сервері. .
2. Об'єктно-орієнтоване програмування
Я розумію, що це суперечливе твердження, але я не вважаю, що ОВП це щось важливе. Я думаю, що це підходяща парадигма для конкретних додатків, які потребують специфічних структур даних, на кшталт віконних систем, симуляцій, САПР-систем. Але я не розумію, чому вона має бути придатною для всіх програм.
Я думаю, що люди у великих компаніях люблять ОВП, частково, тому що воно дає багато того, що виглядає як робота. Те, що, природно, може бути представлено як, скажімо, список цілих чисел, тепер може бути представлено як клас з усіма видами будівельних риштувань, з шумом і суєтою.
Інша приваблива риса ООП у цьому, що методи дають вам певний ефект функцій першого класу. Але це не новина для програмістів на Lisp'ах. Коли у вас є справжні функції першого класу, ви можете просто використовувати їх у будь-який спосіб, який відповідає поставленій задачі замість того, щоб проштовхувати все в шаблон із класів та методів.
Я думаю, що це означає для мовного дизайну, що ви не повинні надто глибоко вбудовувати ООП в нього. Може відповідь у тому, щоб пропонувати більш загальні, основні речі, і дозволити людям проектувати будь-які об'єктні системи у вигляді бібліотек.
3. Проектування комітетом
Якщо вашу мову проектує комітет, то ви у пастці, і не лише з причин, які всім відомі. Всім відомо, що комітети мають тенденцію створювати комкуватий, непослідовний дизайн мови. Але я думаю, що велика небезпека у тому, що вони не беруть на себе ризиків. Коли на чолі одна людина, він бере ризики, які комітет ніколи не погодиться взяти на себе.
Чи потрібно ризикувати, щоб створити хорошу мову? Багато людей можуть підозрювати, що проектування мови є тим, де ви повинні триматися досить близько до традиційної мудрості. Можу сперечатися, що це не так. У всьому іншому, що роблять люди, винагорода пропорційна до ризику. То чому ж у проектуванні мов має бути інакше?
Джерело: habr.com