Език за програмиране - Блог

Този превод на една статия Artoma Chistyakova "Езикът на програмирането", довела до интересни дискусии по HackerNews и Reddit.

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

Учителят продължи да разчитам на програмата ред по ред. Избягването на превода от английски, тя се определя на всеки знак стойност и ни мотивира да ги помня. След известно време, ще погледна на програмата, и да го тълкува, както ако той е бил написан emodzhi.

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

абстрактно програмиране

Още десет години, а аз - ученик на алгоритми и структури от данни. Пишем C / C ++, както и всички в някаква степен знаят английски. Но всички наши забележки за руски и стандартни имена на библиотечните функции представени без никаква следа от първоначалната им стойност. В уводната лекция на професора е "Здравей, свят!" и други проста програма C. Той казва, че всяко име функция бавно, да я пиша на дъската. В своята интерпретация на getch () звучеше като "Get-Che" и clrscr () - "ке-льо-ъ-ове-хе-Скрит." Сега е по-трудно да се повярва, но преди да ми нещо кликнали и видях "получи характер" и "чист екран", времето е преминал. Тогава аз споделих това, което видя със съучениците си, и те бяха точно толкова изненадан.

Поглеждайки назад, аз сега разбирам как да се прекъсне с езика на оригиналния връзката ни лиши нещо полезно. Въпреки, че този метод на изучаване на език за програмиране - добър, защото е много близо до абстрактни математика. Той беше този, който ни насърчава да бъде знак * strstr (Конст Чар * купа сено, Конст Чар * игла), както со (X, Y). Дори ако функцията има объркващо име, никой от нас не забеляза, защото тя не е твърде различен от другите произволни символи, които ние трябваше да си спомня. Когато програмирате по такъв начин, документацията - на царя, а името - препратка към концепциите.

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

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

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

Нека да разгледаме всяка кауза.

Английски - комплекс

В тази книга, "Английски беше за мен болезнена тема за 15 години", създател на Redis, Salvatore Sanfilippo (Salvatore Sanfilippo) разказва историята на дългогодишната борба с опитите да се изразяват мисли на английски език. Мнение написана от човек, който построи един от основните елементи на модерен комплекс технологии за интернет:

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

Предполагам, че средно един сравнително голям на API, събрани роден английски език ще бъде по-изразителен от същото и от не-носител със средно ниво. Почти съм убеден, че когато за пръв път се сблъскват с Clojure. Rich Hiki (Rich Hickey) е известен с разумното използване на речник. В Clojure * прост примитивен (прост) не е лесно * Не е трудно (лесно), колекции (колекции) не е последователността (последователностите), и функциите с имена като правя конкретен или трансдуцират - често срещано явление.

Дори въоръжен с речник или обратна речника. средно на чужд език и ще бъде мъчен, за да съответстват на семантичните умения богат. Но в действителност, ние можем да видим, че Google Translate и именуване конвенции може да ви помогне и случайни грешки, като isHided. видими елементи. unexisting - не е критично да се снима оценка на GitHub.

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

Имената на всяка стъпка

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

Програмистите могат да превъзхождат във всяко едно отношение, когато се дават имената на различни обекти. Chef (Chef) - рамка за управление на конфигурацията, с помощта на набор от кулинарни метафори: книгата с рецепти, кухня, нож и др. Буря (Буря) - интерактивна компютърна система, използва неща, като например потоци, торнадо и мълния. С по-малко практична страна, Heroku (платформа облак) забавлява всички генерирани от имената на хост сървъра, като например "flexile-sentry.heroku.com". Някои твърдят, че това наистина смешни имена и метафори помагат на разработчика да се подобри или просто обърка основните понятия, но това е извън обхвата на тази статия. Долната линия е, че разработчиците прекарват много време идва с имената на различни парчета. Понякога, бих казал, че се отразява отрицателно на тяхната производителност.

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

Джули работи по илюстрация.

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

Ако по-късно решите да преименувате експеримент-2 SpaceElevator - късмет. Дори и най-модерната в IDE Ruby, RubyMine, може да манивела трик като обикновен (на пръв поглед) за преименуване на проекта. И това е само върхът на айсберга. Ако мислите, че "диамантите са завинаги", никога не е трябвало да обясни схема 10-годишният базата данни на новия служител. Най-лошото име никога няма да ви остави на мира.

Е, сега всичко ясно: за име - е трудно. Още по-трудно на чужд език. Промяна на името по-късно - още по-лошо, а понякога почти невъзможно. Как да се справим с това? Аз се интересувам от два въпроса, по-специално:

Активиране на специалисти в техните тесни области на приложение програмиране за подобряване на тяхната специализация.
За да се премахне различията в кода, написан от хората, говорещи различни езици.

По-малко име = по-малко именуване

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

структура функция
Кратко синтаксис форма за ламбда функции.
Споразумението за имената и "математически" нотация.

Обърнете внимание на Clojure фрагмент по-долу. В нея показах функция, която връща само условията (думи), които се срещат повече от предварително определен брой пъти в дадена низ.

За да се реализира това по-скоро сложна функция, трябваше да излезе с едно име: име на функция. Обадих уводна низ с. защото има конвенция използва всички функции на низ в Clojure, и след още един общ договор, н е един номер, това отнема функция. Събирането на множество функции от по-висок ред, аз се избегне повторение изрично и нейните странични продукти: индекси и временни променливи. Дори когато влиза функция ламбда (# (когато (> (Вал%) н) (ключов%))), Clojure синтаксис не е длъжна да го наричаме аргумент, което позволява достъп до нея, като се използва% (няколко аргумента могат да бъдат достъпни чрез 1%. 2%, и т.н.).

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

Какво е х?

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

Очевидният отговор - ние можем да положи мета-информация. Връщайки се към примера в Illustrator: генерираните имената на слоя са различни за различните видове обекти. В езиците за програмиране, тази роля може (до известна степен) да играе уточняване на видовете и пояснения. Нека да разгледаме една програма, написана на Haskell:

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

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

Изпълнение 2 прави веднага ясно всеки аргумент, за който говори английски запознат с идиома "игла в купа сено" (игла в купа сено). В същото време, ние се върне към въпроса, когато 1 и 2 са също толкова озадачаващо човек, който не говори английски.

Ограничения на обикновен текст

Когато това ни води? Функционално програмиране и напреднали тип система със сигурност се намали броя на елементите, които трябва да се измисли и не забравяйте да се създаде полезни програми. Но винаги има функции като strstr. които изглеждат мистериозно, ако не знаете контекста на естествените езици семантика, или не прочетете документацията. Английски език и в този момент, може би, да попитам защо тези бедни чужденци не пишат програмни езици със своя собствена лексика или азбука? Тя съществува. но подобни опити са обречени на изолация в професионалната сфера, Вградена да интегрира идеи.

Вместо това, нека да ви дам още един пример. В снимката по-долу - написан лист в Microsoft Excel руски локал. Странно нещо в рускоезичните Excel - вградената библиотечни функции просто са преведени, така че имената на функциите, които трябва да напишете на кирилица.

Кирилица имена на функции в MS Excel формули

Няма да те лъжа, тя изглежда скандално, дори и за мен. Но не за баща ми, строителен инженер, който не знае думата на английски език. Той плашещо избирателно във формули на Excel и да ги използва в документите на стотици страници, обрасли филтри, условия и осеви таблици. По-късно, изграждане на пътища и мостове към тези изчисления. Той не знаеше какво означава IF. но винаги използва МФ. Какво е готино, това е, когато той ще ви изпрати един от тези таблици, и ще го открие в оригиналната MS Excel, всяка формула се появява на английски език и ще работи точно както бе предвидено баща.

Сега си представете, че те са получили парче с хиляди редове "govnokoda", които показах по-горе. Може би искате да я компилирате, но късмет да се справят с API, събрани от Latinized български думи и гръцката азбука. Аз не знам как да се изравнят с Excel космополитизма от другата страна на "истински" език за програмиране. Изглежда, че това е един от случаите, когато текста без форматиране ограничения като основно средство за писане и разпространение на програмите, излезе на преден план. В Excel, това е възможно, защото те са под контрол, както и формата и среда за развитие.

Някои програмисти стават в отбранителна позиция, когато става въпрос за обсъждане на алтернативи на обикновен текст. В "Библията" на много от съвременните програмисти, книгата "прагматичен Софтуер" (The прагматичен Софтуер), което прочетох и направих преглед в своя блог. ясно описание на текст като шурикен прагматични програмисти, разпределят цял раздел. Но повече разпространението напреднали логическо устройство (което вече се скрият някои подробности за изпълнение), както и все по-често се адаптират нетекстовите програмни среди (като MIT Scratch или Unreal скици), изглежда все по-вероятно, че като практически инструмент за всяка програма, която ще събере на едно място всички тези идеята не е толкова далеч.

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

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