Кіруючая філасофія
1. Мовы праграмавання для людзей
Мовы праграмавання гэта тое, як людзі гавораць з кампутарамі. Кампутар будзе рады пагаварыць на любой мове, які не будзе двухсэнсоўным. Прычына чаму ў нас ёсць высокаўзроўневыя мовы - таму што людзі не могуць справіцца з машыннай мовай. Сутнасць моў праграмавання ў тым, каб прадухіліць наш бедны далікатны чалавечы мозг ад перагрузкі масай дэталяў.
Архітэктары ведаюць, што некаторыя праблемы праектавання больш прызямлёныя, чым іншыя. Адны з самых ясных і абстрактных праблем праектавання гэта праектаванне мастоў. У гэтым выпадку ваша праца ў тым, каб ахапіць патрабаваную адлегласць як мага меншай колькасцю матэрыялу. На іншым канцы спектру - праектаванне крэслаў. Праекціроўшчыкі крэслаў павінны марнаваць свой час на разважанні аб чалавечых задніцах.
Распрацоўка софту мае падобнае адрозненне. Праектаванне алгарытмаў для маршрутызацыі дадзеных праз сетку - добрая, абстрактная праблема, як праектаванне мастоў. Тады як праектаванне моў праграмавання падобна праектаванню крэслаў: трэба спраўляцца з чалавечымі слабасцямі.
Большасці з нас гэта цяжка ўсведамляць. Праектаванне элегантных матэматычных сістэм гучыць значна больш прывабна для большасці з нас, чым патуранне чалавечым слабасцям. Роля матэматычнай элегантнасці ў тым, што некаторая ступень элегантнасці робіць праграмы прасцей для разумення. Але элегантнасцю ўсё не абмяжоўваецца.
І калі я кажу, што мовы павінны быць спраектаваны, каб улічваць чалавечыя слабасці, я не маю на ўвазе што мовы павінны быць спраектаваны для дрэнных праграмістаў. Насамрэч вы павінны праектаваць софт для лепшых праграмістаў, але нават лепшыя праграмісты маюць сваю мяжу. Я не думаю, што хоць каму-небудзь спадабаецца праграмаваць на мове, дзе ўсе зменныя абазначаліся б літарай "x" з цэлалікавымі індэксамі.
2. Праектуйце для сябе і для сваіх сяброў
Калі вы паглядзіце на гісторыю моў праграмавання, большасць з самых лепшых моў былі спраектаваны для выкарыстання сваімі ж аўтарамі, а большасць з горшых - спраектаваны для іншых людзей.
Калі мовы праектуюцца для іншых людзей, дык гэта заўсёды нейкая канкрэтная група людзей: людзі не такія разумныя, як стваральнікі мовы. Дык вы атрымліваеце мову, які гаворыць з вамі паблажліва. Cobol - самы яркі прыклад, але большасць моў прасякнуты гэтым духам.
Гэта не мае нічога агульнага з тым, наколькі высокаўзроўневай з'яўляецца мова. C – дастаткова нізкаўзроўневы, але ён быў створаны для выкарыстання яго аўтарамі, вось чаму хакеры любяць яго.
Аргумент у карысць праектавання моў для дрэнных праграмістаў у тым, што дрэнных праграмістаў больш, чым добрых. Мабыць, гэта так. Але гэтая невялікая колькасць добрых праграмістаў піша непрапарцыйна больш софту.
Мяне цікавіць пытанне, як стварыць мову, якая спадабаецца самым лепшым хакерам? Мне здаецца гэтае пытанне ідэнтычна пытанню, як стварыць добрую мову праграмавання?, але нават калі гэта не так, то прынамсі гэта цікавае пытанне.
3. Дайце праграмісту столькі кантролю, колькі магчыма
Многія мовы (асабліва тыя, якія створаны для іншых людзей) паводзяць сябе як нянькі: яны імкнуцца перасцерагчы вас ад рэчаў, якія, на іх думку, будуць вам не карысныя. Я прытрымліваюся супрацьлеглага меркавання: дайце праграмісту столькі кантролю колькі можаце.
Калі я ўпершыню вывучаў Lisp, больш за ўсё мне спадабалася тое, што мы размаўлялі на роўных. У іншых мовах, якія я на той момант вывучыў, была мова, а была мая праграма на гэтай мове, і яны існавалі даволі асобна. Але ў Lisp'е функцыі і макрасы, якія я напісаў, былі такімі ж на якіх была напісана сама мова. Я мог бы перапісаць саму мову, калі б захацеў. Ён меў такую ж прывабнасць, што і софт з адчыненым кодам.
4. Кароткасць - сястра таленту
Сцісласць недаацэнена і нават пагарджаецца. Але калі вы зазірніце ў сэрцы хакераў, вы ўбачыце, што яны вельмі кахаюць сцісласць. Колькі разоў вы чулі, як хакеры з каханнем кажуць аб тым, што, скажам, у APL яны могуць рабіць дзіўныя рэчы з дапамогай усяго толькі пары радкоў кода? Я мяркую, што па-сапраўднаму разумныя людзі насамрэч любяць зважаць на гэта.
Я мяркую, што амаль усё, што дазваляе зрабіць праграмы карацейшым — добра. Павінна быць мноства бібліятэчных функцый, усё, што можа быць няяўным - павінна такім быць; сінтаксіс павінен быць у большай ступені кароткім; нават імёны сутнасцяў павінны быць кароткімі.
І не толькі праграмы павінны быць кароткімі. Мануалы таксама павінны быць кароткімі. Добрая частка мануалаў напоўнена тлумачэннямі, агаворкамі, папярэджаннямі і асаблівымі выпадкамі. Калі вам спатрэбіцца скараціць мануал, лепшы варыянт гэта выправіць мову, які патрабуе так шмат тлумачэнняў.
5. Прызнайце, што такое хакерства
Многім людзям хацелася б, каб хакерства было б матэматыкай ці, хаця б, чымсьці падобным на натуральныя навукі. Я думаю, што хакерства больш падобна на архітэктуру. Архітэктура звязана з фізікай, у тым плане, што архітэктару трэба праектаваць будынак, які не ўпадзе, але сапраўдная мэта архітэктара ў тым, каб стварыць вялікі будынак, а не зрабіць адкрыцці ў галіне статыкі.
Што хакеры любяць, дык гэта ствараць вялікія праграмы. І я думаю, што, прынамсі, у нашых уласных думках, мы павінны памятаць, што пісаць выдатныя праграмы - гэта выдатна, нават калі гэтая праца нялёгка перакладаецца ў звычайную інтэлектуальную валюту навуковых прац. З інтэлектуальнага пункту гледжання, не менш важна як распрацоўваць мову, якую пакахаюць праграмісты, так і ствараць жудасны, які ўвасабляе ідэю, пра якую вы можаце апублікаваць артыкул.
Адкрытыя праблемы
Пытанні і заданні 1. Як арганізаваць вялікія бібліятэкі?
Бібліятэкі становяцца важнай часткай моў праграміравання. Яны становяцца настолькі вялікімі, што гэта можа быць небясьпечна. Калі патрабуецца больш часу, каб знайсці функцыю ў бібліятэцы, якая робіць тое, што вам трэба, чым напісаць гэтую функцыю самому, то ўвесь код не робіць нічога, акрамя патаўшчэнні вашага мануала. (Кіраўніцтва Symbolics былі таму прыкладам.) Так што нам давядзецца вырашыць праблему з арганізацыяй бібліятэк. У ідэале спраектаваць іх так, каб праграміст мог бы здагадацца, якая функцыя бібліятэкі падыдзе.
2. Людзі сапраўды напалоханы прэфіксным сінтаксісам?
Гэта адкрытая праблема ў тым сэнсе, што я думаў над ёй некалькі год і ўсё яшчэ не ведаю адказу. Прэфіксны сінтаксіс здаецца мне абсалютна натуральным, магчыма, акрамя выкарыстання яго ў матэматыцы. Але можа так, што большая частка непапулярнасці Lisp'аў проста з-за незнаёмага сінтаксісу… Ці варта нешта з гэтым рабіць, калі гэта праўда, гэта іншае пытанне.
3. Што вам трэба для сервернага софту?
Я думаю, што большасць прыкладанняў, якія будуць напісаны ў наступныя XNUMX гадоў будуць вэб-прыкладаннямі, у тым сэнсе, што праграмы будуць размешчаны на серверы і будуць мець зносіны з вамі праз вэб-браўзэр. І каб напісаць такія прыкладанні нам патрэбныя новыя штукі.
Адна з такіх рэчаў гэта падтрымка новага спосабу выпуску серверных дадаткаў. Замест аднаго ці двух вялікіх рэлізаў у год, як дэсктопны софт, серверны софт будзе выпускацца серыяй дробных змен. У вас можа быць пяць ці дзесяць рэлізаў у дзень. І ва ўсіх заўжды будзе апошняя версія.
Вы ведаеце як праектаваць праграмы, каб яны былі падтрымліваемымі? Серверны софт павінен быць спраектаваны здольным да змен. У вас павінна быць магчымасць змяняць яго лёгка, ці хаця б ведаць што значыць дробнае змяненне і што з'яўляецца важным.
Яшчэ адна рэч, якая можа быць карыснай у серверным софце, гэта, раптоўна, бесперапыннасць пастаўкі. У вэб-дадатку вы можаце выкарыстоўваць нешта накшталт , Каб атрымаць эфект ад падпраграм у 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