Русские языки программирования: О русском языке в программировании / Хабр

Содержание

О русском языке в программировании / Хабр

Введение

Начну с мелочи. Удобно ли сейчас организована типичная смена раскладки клавиатуры? В смысле переключения на русский/латинский? На мой взгляд, в смартфонах и то удобнее. Не надо нажимать одновременно все эти «Shift» и «Alt». На моем первом домашнем компьютере «Электроника-901» (он же ai-PC16) было даже две специальных «пустых» клавиши примерно там, где сейчас клавиши-«окна». Одна переключала на русскую раскладку постоянно, а другая — временно (на время нажатия). Это гораздо удобнее. Впрочем, самый удобный вариант переключения в свое время я сделал сам из массивной педали от швейной машинки «Тула», просто соединив ее двумя проводами с контактами DTR и DSR разъема RS-232. В этом случае если программно установить бит DTR в «1», то наличие сигнала DSR означает, что педаль нажата, иначе – отпущена. Переключать раскладку без рук оказалось очень эргономично. Увы, по мере распространения новых интерфейсов, RS-232 постепенно сошел на нет и сейчас в ноутбуке педаль просто некуда подключить.

Кстати, дарю идею фирмам, выпускающим всякую USB-ерунду, вроде пластикового хамелеона, периодически высовывающего язык: выпустить USB-устройство в виде педали, при нажатии на которую эмулируются нажатия заданных пользователем клавиш. Правда уже есть USB-руль с педалями, но там все-таки много лишнего. Наиболее очевидное использование нового простого устройства – переключение раскладки клавиатуры без помощи рук.

Справедливости ради: на некоторых клавиатурах есть отдельная клавиша переключения (на ней обычно нарисован глобус). Сложность в том, что на многих других компьютерах ее нет. В древнем текстовом редакторе «SideKick» я даже когда-то использовал обе клавиши «Shift», поскольку они есть всегда: правая переключала постоянно (и поэтому как «Shift» вообще не работала), а левая – временно, первые две секунды как «Shift», а уже затем как переключатель. Смысл в том, что тогда можно печатать, например, по-русски, затем, удерживая мизинцем клавишу, одно слово по-английски, затем отпустить и опять продолжать по-русски.

Но, повторю, громоздкое переключение — это мелочь, не проблема, а, скорее, следствие отношения к использованию русского языка как к чему-то второстепенному и не стоящему внимания. Хотя и эта мелочь нет-нет, да и напомнит о себе, хотя бы в виде модной, но глупой аббревиатуры КЫВТ (вместо RSDN) на форумах сайта RSDN.RU.

Настоящей проблемой, на мой взгляд, является появление на тех же компьютерных форумах обсуждений на тему: «мешает ли русский язык программированию». С точки зрения той части российских программистов, которые работают в западных фирмах или поставили себе такую цель (с возможным и желательным отъездом за границу) русский язык в программировании – это действительно зло, дополнительный барьер, мешающий быстрее адаптироваться в англоязычной среде. Но мне кажется, им мешает не русский язык в программировании, а русский язык вообще.

Естественность использования родного языка

Язык неразрывно связан с мышлением. Например, когда я пишу текст программы, я невольно мысленно произношу требуемое действие. Конечно, оно не звучит внутри голосом Левитана и даже не всегда это именно звуки, но что-то типа: «если и а и б нулевые, то уходим» в мыслях проносится. На типичном современном языке программирования эту мысль в виде программного текста я должен выразить как-нибудь так:

if (a==0 && b==0) return;

Т.е. мысленно про себя произношу «если», «уходим», а писать все-таки должен «if», «return». Незаметно приходится все время переводить, пусть и в самой простейшей форме. Поэтому для меня более естественна запись того же оператора в виде:

если a=0 и b=0 тогда возврат;

Я именно так и пишу. И это вовсе не псевдокод, а реальный оператор языка [1], где ключевые слова имеют русские эквиваленты, не требуется различать присваивание и сравнение (а, значит, не нужно удвоение символов), и логические операции можно писать просто как И, ИЛИ, НЕ. Оператор больше стал похож на мысленную фразу и перевод с «мысленного русского» на «программный английский» уже не требуется.

Для человека, который давно программирует, наверное, все это кажется несущественным и непривычным, поскольку с самого начала он учился составлять программный текст как последовательность специальных знаков и слов, не связанных с родным языком. Да, язык программирования никогда не совпадет с родным языком, но на этапе освоения (например, в школе) элементы родного языка очень помогают понять записываемые действия. Больше становится тех, кто быстро схватил суть и меньше тех, кто сразу же теряет интерес к изучению программирования потому, что сталкивается с цепочками непонятных иероглифов и иностранных слов.

Например, когда моя жена училась в Московском математическом техникуме, основы программирования им преподавали с помощью специального языка (нечто вроде псевдокода), который так и назывался: Русский Алгоритмический Язык, сокращенно РАЯ. (Смешно. Выходит, в нашей семье жена знакома с языком РАЯ, а муж с языком Ада). На мой взгляд, это был мудрый прием. Родной язык, конечно, не панацея и не обеспечивал выпуск суперпрограммистов, но то, что он способствовал более глубокому пониманию основ на самом важном начальном этапе – несомненно.

Разумные границы использования

Попытки превратить язык программирования в национальный или, наоборот, избавиться от национальных особенностей в тексте программы были предприняты еще более полувека назад. Я имею в виду языки Кобол и АПЛ.

Язык Кобол предполагал, что программу можно будет писать просто по-английски. Поэтому он имел большое число зарезервированных и даже «шумовых» (необязательных) слов. Но ничего хорошего из этого не вышло. Текст программ все равно получался не на английском, а на ломаном английском, а их анализ усложнялся. Точно так же не получится писать программы и на любом другом «настоящем», например, русском языке, поскольку обычный язык никогда не будет тождественен программному. Однако наличие некоторого множества слов и их частых сочетаний на родном языке все же улучшает и на интуитивном уровне облегчает понимание текста программы, ведь, в конце концов, человек не сканер транслятора и не анализирует текст посимвольно.

Другую крайность представлял язык АПЛ, имевший большое число специальных знаков для всяких операций. Запись программы на АПЛ внешне напоминала записи, которыми пользуются математики. АПЛ остался в истории знаменитым тем, что программу, записанную на одной строке, т.е. не более 80 знаков, можно было анализировать часами, т.е. долго разгадывать, что же, собственно говоря, она делает. Получалось, что кроме авторов в таких программах вообще никто не мог разобраться, и идея сверхкомпактной записи большим числом специальных знаков была заброшена.

На мой взгляд, программные тексты должны иметь золотую середину между этими крайностями. Они, конечно, не должны быть слишком многословными и этим напоминающими старинные поваренные книги, но и шарады из цепочек значков и скобок (можно вспомнить Лисп, где встречалось до двадцати скобок подряд) это тоже не идеал. А если в тексте программы все же используются не одни значки, но и слова, то лучше, чтобы они были на родном языке.

Опыт использования родного языка

Если обратиться к собственному опыту использования родного языка, то считаю, что мне в какой-то мере даже повезло: период обучения и освоения пришелся на время, когда русский язык использовался не то, чтобы широко, но вполне естественно, поскольку применялись программные и аппаратные средства отечественной разработки. Как программист я начинал с БЭСМ-6, операционной системы ОС-Диспак, транслятора БЭСМ-АЛГОЛ и диалоговой программы «Пульт» (при этом работа за терминалом VT-340 очень напоминала работу за первыми персональными компьютерами). В те времена даже в кодовой таблице сначала шел русский алфавит, а затем латинские буквы, отличающиеся по написанию от кириллицы. Вся документация была, естественно, на русском, например, в описании команд БЭСМ-6 все аббревиатуры команд были кириллицей, не было никаких «MOV» или «JMP».

В отличие от ЕС-ЭВМ, в направлении БЭСМ (и «Эльбрус») все оставалось «по-русски». Правда, до тех пор, пока не появилась разработка дубнинского ядерного центра – мониторная система «Дубна», в составе которой был ассемблер (тогда такие языки назывались автокодами) со странным именем «Мадлен». Так как транслятор сначала переводил на него, некоторые сообщения об ошибках выдавались на уровне ассемблера. И все они были по-английски! Получалось, что одни советские программисты писали сообщения для других советских программистов не на родном языке. Разумеется, «Дубна» изначально была предназначена для совместной работы где-нибудь в ЦЕРН, поэтому там и было все в «международном» варианте. Но нам она была поставлена как отечественная система и при этом бесцеремонно «отодвинула» от родного языка. Например, аббревиатуры команд в «Мадлен» стали не такими как в исходной документации на БЭСМ-6, что вызывало непонимание и раздражение.

Еще через несколько лет (для меня в 1987 году) в части родного языка все перевернулось с появлением американских персональных компьютеров. Объективно и естественно в первое время никакого русского языка там не было в принципе. Но поскольку это требовалось для набора текстов, приспосабливать их под родной язык все-таки пришлось. Т.е. пришлось перепрошивать ПЗУ видеокарт, наклеивать переводные картинки кириллицы на боковые стенки клавиш, учиться писать драйверы клавиатуры, попутно привыкая к аббревиатурам системы команд x86. Очень скоро «русификацией» компьютеров и принтеров уже занимались во многих организациях, имеющих ПК, и дело было поставлено буквально на поток. Но при этом «русификацией» получаемых вместе с компьютерами трансляторов обычно никто не занимался, в лучшем случае лишь переводились руководства.

Возможно, я стал одним из первых, кто озаботился этим и то лишь потому, что полученный вместе с IBM-PC/XT транслятор с языка PL/1 не позволял писать по-русски даже комментарии: все символы с кодом больше 7FН воспринимались им как управляющие. Из-за этого на первых порах комментарии выглядели как теперешние SMS «по-русски» с телефонов, не имеющих кириллицы. Но разрабатывать программы, не используя родной язык, было для меня совершенно недопустимым. Первое исправление транслятора, которое разрешило кириллицу, оказалось очень легким и привело к мысли дизассемблировать весь транслятор, чтобы стать полноправным владельцем и постепенно сделать его целиком «русским». Учитывая, что в PL/1 ключевые слова не зарезервированы, можно иметь одновременно два варианта слов: английский и русский. Поэтому уже написанные программы можно было оставить «английскими», зато новые программы можно было писать уже «по-русски».

Впоследствии в транслятор было внесено множество доработок, приведенных в [1]. По части «русификации» были добавлены русские ключевые слова, включая И-ИЛИ-НЕ вместо знаков «&», «!» и «~». Такой перевод логических операций на «русский» сразу сделал тексты программ гораздо легче воспринимаемыми. Диагностические сообщения также были переведены и расширены. Много ли существует современных программных средств, которые выдают сообщения об ошибках на русском языке? А ведь это первое, с чем сталкиваются новички. Им и так-то бывает нелегко разобраться, что именно вызвало ошибку, а тут еще и сообщения не на родном языке. Поэтому часто даже вполне внятные сообщения начинают восприниматься ими одинаково: «транслятор ругается», а поиск ошибок в тексте производится бессистемным образом, вне связи с полученным сообщением.

В результате всех преобразований в части родного языка я практически вернулся в тот программный мир, в котором работал до эпохи ПК, тексты программ стали выглядеть даже лучше. Например, при записи программы (кроме имен импортируемых подпрограмм, всех этих GetEnhMetaFilePaletteEntries, выглядящих в русском тексте «китайской грамотой») я практически вообще могу не переключаться на латинский алфавит. Само собой, идентификаторам всегда стараюсь дать значимые имена по-русски.

Но большинство программистов моего поколения перешли на языки с Си-образным синтаксисом и практически перестали использовать в текстах программ кириллицу.

Заключение

На первый взгляд кажется, что сейчас никаких проблем с русским языком нет. Действительно, давно «локализованы» на национальные языки операционные системы, офисные программы и игры, а кириллица наносится на клавиши заводским способом. Но если обратиться к программированию, то здесь русский язык почти полностью вытеснен. Конечно, есть и исключения, например, «Бухгалтерия 1С». При этом я ни в коем случае не призываю создавать специально «русские» языки программирования (остряки сразу же добавят: «православные»). Напомню, что даже в самом первом международном документе по языку программирования [2] предполагалось три уровня его представления: эталонный, язык публикаций и конкретные представления. Т.е. с самого начала предполагалось, что «знаки языка могут быть различными в разных странах, однако должно быть сохранено однозначное соответствие с эталонным представлением».

Сам я использую язык PL/1, созданный на Западе (большей частью в Великобритании), наличие готового транслятора с которого было в свое время даже одним из аргументов принятия в СССР решения копировать IBM 360 в виде ЕС ЭВМ. Но, возможно, обоснованное на тот момент решение в своей программной части в дальнейшем не было подкреплено развитием первоначально скопированного «эталона». Конечно, сейчас с позиции послезнания легко советовать, что надо было делать тогда. Впрочем, и тогда многим это было понятно: «урок освоения ОС ЕС ясен: можно, и иногда нужно осваивать отдельные образцы зарубежного программного обеспечения, но нельзя становиться на путь постоянного следования за ними» [3].

Мой опыт энтузиаста-дилетанта (без профильного образования), показывает, что разобраться в существующем компиляторе не так уж и трудоемко. Коллектив из 4-5 человек где-нибудь в Академгородке сделал бы это быстро и качественно, например, с компилятором IBM для PL/1. Т.е. дизассемблировал бы его и научился транслировать и собирать точную копию исходного. И это надо было делать, конечно, не для «русификации», а для того, чтобы стать хозяином транслятора и с этой стартовой площадки продолжить его развитие дальше, уже независимо ни от кого, снабжая армию пользователей ЕС ЭВМ качественным и, главное, совершенствующимся продуктом. А перевод на русский язык компилятора и других утилит был бы всего лишь бонусом, облегчающим сопровождение и использование. Но транслятор с языка PL/1 на ЕС ЭВМ так и не был «освоен». Я делаю такой вывод потому, что он так и не был «русифицирован», хотя попытки развить язык и были [5].

Я «освоил» транслятор и сделал «русификацию» уже для ПК-версии языка, причем затраты на перевод на русский оказались пренебрежимо малы по сравнению с другими доработками транслятора. И при этом получилось то самое «конкретное представление», совпадающее с эталонным, поскольку результат трансляции в виде объектного модуля уже ничем не отличается от результата трансляции исходного текста программы в «эталонном» виде. И, кстати, простейшим «переводом» всегда можно вернуться к «эталонному» представлению исходного текста программы, т.е. такие представления обратимы.

Также аргументом против использования русского языка в программировании является утверждение, что использование английских слов превращает языки в универсальные научные, наподобие универсального отображения в математике или, например, в химии.

Однако, на мой взгляд, языки программирования имеют гораздо больше общих черт с обычными языками, чем абстрактное математическое или химическое представление. Если человек думает «по-русски», в большинстве случаев он никогда не начнет думать «по-английски». Запрещая использовать элементы родного языка при изучении основ программирования, мы изначально ставим наших школьников и студентов в отстающее положение по сравнению с их англоязычными сверстниками.

Зато появились уже поколения программистов, которые считают, что так и должно быть. Попадалась даже парадоксальная точка зрения, что не использование родного языка – это как раз наше преимущество над англоязычными программистами, потому, что собственно конструкции операторов программы не похожи, например, на текст комментариев, а, дескать, у них все это смешивается. По такой логике надо предложить англоязычным использовать в программах русские ключевые слова, чтобы, так сказать, «догнать» нас. А лучше сразу перейти на китайские иероглифы, чтобы все (кроме, разумеется, несчастных китайцев) имели это преимущество непохожести исходного кода на родной язык .

Использование русского языка отражает и общее состояние дел в развитии программирования. Пока в СССР шли собственные разработки — использовался, естественно, и русский язык, например, в таком выдающемся проекте, как «Эль-76», где были задействованы большие силы всей страны: в разработке ПО для «Эльбруса» участвовал ряд университетов, включая Таллин и Кишинев. Прекратились разработки – вот русский язык и исчез, а попытки возрождения, например, проект «Национальной Программной Платформы», терпят неудачу.

Русский язык – это то, что всех нас (и программистов и не программистов) объединяет. Использование родного языка в программировании является и признаком независимого развития этой отрасли и одновременно объективной базой такого развития.

Напоследок приведу исторический анекдот: когда Петр Первый организовывал выпуск нового российского рубля (монеты), ему советовали все надписи сделать на латыни, иначе, мол, такие деньги не будут принимать за границей. «Спасибо тому скажу, кто придумает, как оставить деньги в Отечестве, а не тому, кто выведет их иноземцам» ответил Петр.

Литература

1. Д.Ю. Караваев «К вопросу о совершенствовании языка программирования» RSDN Magazine #4 2011

2. А.П. Ершов, С.С. Лавров, М.Р. Шура-Бура «Алгоритмический язык АЛГОЛ-60. Пересмотренное сообщение». Москва «Мир» 1965

3. Г.С. Цейтин Доклад «Итоги освоения ОС ЕС (заметки пользователя)» 29.08.1983

4. В.М. Табаков «Специализированная система гиперпрограммирования для языка ПЛ/1» : диссертация кандидата физико-математических наук : 05.13.11. Калинин, 1984.

Русский язык программирования, а почему бы и нет?

На волне сегодняшнего поиска национальной идеи неплохо вспомнить о том, что когда-то мы успешно конкурировали в области IT-технологий с западными странами. Был ли когда-либо русский язык программирования?

Команды в программировании на русском языке

К сожалению, очень многие наши соотечественники, можно сказать, с пеной у рта доказывают, что никогда не существовало языков программирования с командами на русском языке.

Как будто никогда не было в русском языке программирования таких команд, как «ЕСЛИ», «ТО», «ИНАЧЕ» вместо «IF», «THEN», «ELSE». Или, например, вместо «GO TO» как будто не было команды «ИДТИ НА», без третьего слова, привычной для российского уха идиомы…

Что интересно, русские вычислительные машины понимали не только команду «ИДТИ», но и «ИТТИ», а также «ИЙТИ». Это не связано с неграмотностью разработчиков, которые создавали подобные языки программирования. Это было обусловлено тем, что трансляторы и интерпретаторы русских языков программирования срабатывали на первую букву команды, и уже было неважно, какие символы использовались далее.

Русский язык программирования Аналитик

Надо сказать, что разработчики «русских» языков программирования зашли намного дальше в разработке языков программирования, чем их западные конкуренты.

Например, существовал язык программирования АНАЛИТИК. Он работал на вычислительных машинах МИР не только с численными, но и с аналитическими выражениями. Как видим, название «МИР» использовалось не только для наименования космической станции.

Во всех языках программирования используются переменные величины. С помощью переменных, собственно говоря, и появляется возможность программировать. Однако абсолютно во всех языках программирования каждая переменная величина к моменту обработки выражения должна иметь конкретное значение (цифровое, текстовое, логическое и т.п.).

Разработчики АНАЛИТИКа сделали иначе. И это больше никто не смог повторить, а именно. Они установили, что в отсутствии значения переменной ее значением становится имя переменной!

Например, пусть переменная B равна 2, а значение переменной A не определено. Тогда во всех языках программирования выражение C=A+B автоматически приводит к ошибке в выполнении программы. Но только не в АНАЛИТИКе.

В этом «русском» языке программирования такое выражение присваивало переменной C значение (A+2). При этом никакой ошибки не возникало. Программа продолжала работать с подобными аналитическими выражениями.

Например, выражение D=C+C присваивало переменной D значение (2*A+4), так как:

если C=(A+2), то D=C+C=(A+2)+(A+2)=(2*A+4).

Что интересно, с подобными выражениями можно было осуществлять и более сложные операции. Например, алгебраические выражения можно было приводить к одной из 3-х форм:

с раскрытием скобок,
без раскрытия скобок,
с приведением подобных членов.

Русские команды Интегрировать и Дифференцировать

Также присутствовали команды языка программирования, которые могли вычислять первообразную функции (команда «ИНТЕГРИРОВАТЬ»), и определять производную функции (команда «ДИФФЕРЕНЦИРОВАТЬ»).

Скептики скажут, что подобные аналитические вычисления в настоящий момент не сильно востребованы благодаря бурному развитию численных методов. Однако, во-первых, не будем забывать, что это делалось в 1960-е – 1970-е годы, еще на заре кибернетики.

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

О перспективах

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

Конечно, наша беда – дураки и дороги, которые в вопросах кибернетики (и не только) происходят от того, что мы не научились делать массовые серийные продукты, легко продаваемые.

Один раз подковать блоху – это не то же самое, что массово серийно выпускать много одинаковых кибернетических блох. Это то, что еще нам предстоит научиться делать в неизбежной конкурентной борьбе с Западом.

Тем не менее, остается тот факт, что у нас были собственные разработки языков программирования. По тем временам такие разработки на порядок превосходили зарубежные аналоги. Кстати, они проводились на нашем собственном «железе», на нашей собственной элементной базе.

Это вселяет уверенность в том, что мы еще увидим кибернетические системы исключительно российского производства. Вполне возможно, что такие системы будут желанной добычей зарубежных хакеров, поскольку они будут отличаться от западных систем, как небо отличается от земли.

Другие интересные материалы:

1. Топ-6 катастроф, произошедших «по вине» программного обеспечения

2. Что такое переменная в программировании и чем она отличается от константы

3. Платное и бесплатное ПО: мысли вслух

4. Что такое программирование и кто такие программисты

Получайте актуальные статьи по компьютерной грамотности прямо на ваш почтовый ящик.
Уже более 3.000 подписчиков

Важно: необходимо подтвердить свою подписку! В своей почте откройте письмо для активации и кликните по указанной там ссылке. Если письма нет, проверьте папку Спам.

Автор: Юрий Воробьев

10 декабря 2016

Python ｜ Java ｜ c ++ эти три языка программирования, вы узнали это?

Искусственный интеллект является очень широкой областью, и многие языки программирования могут использоваться для развития искусственного интеллекта, поэтому трудно сказать, какой язык должен использоваться для развития искусственного интеллекта. Более широкий выбор также означает, что есть свои преимущества и недостатки, не каждый язык программирования может сэкономить время и усилия разработчиков.

Поэтому мы собрали три языка программирования, которые больше подходят для разработки искусственного интеллекта, и надеемся помочь вам.

Python

Python является одним из наиболее широко используемых языков программирования в области искусственного интеллекта благодаря своей простоте и удобству использования, и его можно легко использовать со структурами данных и другими обычно используемыми алгоритмами ИИ.

Причина, по которой Python является проектом AI, заключается в том, что в AI можно использовать много полезных библиотек, основанных на Python. Например, Numpy обеспечивает научную вычислительную мощность, продвинутые вычисления Scypy и машинное обучение Pybrain.

Кроме того, Python имеет много онлайн-ресурсов, поэтому кривая обучения не будет особенно крутой.

Java

Java также является хорошим выбором для проектов AI. Это объектно-ориентированный язык программирования, который фокусируется на предоставлении всех расширенных функций, необходимых для проектов ИИ, является переносимым и обеспечивает встроенную сборку мусора.

Кроме того, сообщество Java также является бонусом, а всесторонняя и богатая экология сообщества может помочь разработчикам запрашивать и решать проблемы, возникающие в любое время и в любом месте.

Для проектов ИИ алгоритмы — это почти душа. Будь то алгоритм поиска, алгоритм обработки естественного языка или нейронная сеть, Java может предоставить простой алгоритм кодирования. Кроме того, масштабируемость Java также является одной из необходимых функций проектов AI.

C ++

C ++ — самый быстрый язык программирования в мире, а его способность общаться на аппаратном уровне позволяет разработчикам сократить время выполнения программы. C ++ очень чувствителен ко времени, что очень полезно для проектов AI. Например, поисковые системы могут широко использовать C ++.

В проектах ИИ C ++ может использоваться для статистики, такой как нейронные сети. Кроме того, алгоритм также может быть широко и быстро выполнен на C ++. AI в игре в основном кодируется на C ++ для более быстрого выполнения и времени отклика.

Ниже я предоставлю вводную информацию о Python, обратите внимание на номер заголовка и отвечу на «информацию» или «Python» в фоновом личном сообщении, чтобы получить соответствующую информацию.

язык программирования — Translation into English — examples Russian

These examples may contain rude words based on your search.

These examples may contain colloquial words based on your search.

В 1995 компания Sun анонсировала новый язык программирования.

Rust — компилируемый язык программирования, разрабатываемый Mozilla Research.

Имеется в виду его работа в группе, разработавшей язык программирования Алгол.

This is a reference to the work he had done as a member of the team that developed the programming language ALGOL.

Система включает в себя новый язык программирования MQL5.

Возглавлял проект Formel в 1980-х годах, который разработал язык программирования Caml.

Squeak — язык программирования, диалект языка Smalltalk.

Microsoft Small Basic — язык программирования и среда разработки.

Первоначально известная под названием ОАК, она была в том же году переименована в «язык программирования Java».

Динамический язык программирования с открытыми исходными кодами сфокусированный на простоте и продуктивности.

А+ — это мощный и эффективный язык программирования.

Это не самостоятельный язык программирования, скрипты написанные на нем полностью зависят от браузера.

Ограничения, как правило, встроены в язык программирования или осуществляются через отдельные программные библиотеки.

Constraints are usually embedded within a programming language or provided via separate software libraries.

Внутренний Си-подобный язык программирования MQL4 позволяет запрограммировать торговые стратегии, индикаторы, сигналы.

The internal C-like programming language allows users to program trading strategies, indicators and signals.

Гипертекст — не язык программирования, это текст со ссылками на другие тексты.

К примеру, язык программирования BASIC имеет множество диалектов.

Noop — новый язык программирования, разрабатываемый компанией Google.

Специально для данного проекта Naughty Dog изобрела новый язык программирования, который использовался специально для серии Jak & Daxter.

Unusually for most games, Naughty Dog invented a new programming language, GOAL, which was only ever used for the Jak and Daxter series.

Objective-J — язык программирования, разрабатываемый как часть Cappuccino — фреймворка для веб-приложений.

Objective-J is a programming language developed as part of the Cappuccino web development framework.

Участники могут использовать любой язык программирования и среду разработки для решения задач.

Но как только Джастин Гатри обнаружил закодированный язык программирования, все стало серьёзно.

Crap! Какой язык программирования заставляет ругаться чаще? | GeekBrains

Трудно удержаться от мата, когда в 30 000 строк кода закралась ошибка и все пошло…

https://gbcdn.mrgcdn.ru/uploads/post/1654/og_cover_image/8550760d61facd9e0c1cb49adbe80a89

А в совместной работе над проектами ругаться сам рандом велел. Обнаруживая в коде ляпы коллег, любой человек зачастую не выбирает выражений, чтобы донести, каким общим завалом могут обернуться баги.

Поэтому в комментариях к коду часто появляются совсем не литературные слова. А раз международный язык общения программистов — английский, то и ругательства преимущественно англоязычные.

В этой статье выясним, какие языки программирования вызывают у разработчиков больше всего эмоций. Информацию для анализа возьмем с трех крупных веб-сервисов для совместной разработки: Github, Bitbucket и Googlecode. В качестве поисковика используем сервис Searchcode, который позволяет находить отдельные элементы в коде и комментариях к нему. Система утверждает, что в проверочной базе есть 20 млрд строк кода из 7 млн проектов. Пересчитывать не будем — поверим на слово. Найдем «горячие точки», где негодование программистов выражено вербально, и посмотрим, какая сложится статистика.

Да какие маты на английском? То ли дело на русском!

Существует миф, что в английском языке мало ругательств. Но на самом деле англичане преуспели в словесной брани не меньше, чем русские. Ведь массовая культура зародилась в Британии на 150 лет раньше, чем в Российской империи.

Причина этого мифа до банального проста: большинство русскоговорящих людей учит «академический» английский, который рассчитан на культурное общение. А нецензурную лексику мы преимущественно слышим в фильмах — а там она куда беднее, чем в жизни. Буквально пять ругательств и несколько десятков их производных.

В реальности идиоматических выражений в английском множество. Но наша статья посвящена не этой теме. Если интересуетесь, есть отличная книга «Вашу мать, сэр» (авторы Московцев и Шевченко): 480 страниц отборного английского мата, крепких выражений и сленговых фразочек. Советуем программистам, которые часто спорят с иностранными коллегами.

Для анализа в статье мы взяли 5 наиболее популярных ругательств английского языка:

Crap;

Fuck;

Shit;

Damn;

Cock.

Перевод угадать нетрудно — слова известные, близкие сердцу. Сначала соберем общую статистику с ресурсов. Затем разберемся, какое ругательство программисты используют чаще всего.

Уверенно лидирует слово «Crap», так что разберем его первым.

Crap

«Crap» не считается грубым ругательством. Это почти полный аналог русского «блин». Поэтому его и употребляют так часто.

Допустил ошибку в своем коде — «Crap!».

Увидел баг в чужом — «Crap!».

Не можешь найти общий язык с программистом — «Crap!».

Слово настолько плотно вошло в лексикон IT-специалистов, что появился специальный CRAP index (Change Risk Analysis and Prediction). Его формула прогнозирует, скажет ли программист «Oh, crap!», когда увидит, какой код ему предстоит поддерживать. CRAP-индекс на практике используют многие программисты — при тестировании, оптимизации и переписывании отдельных участков кода.

Больше всего «crap» используют на Bitbucket — 26 666 раз. При этом примерно 70% из них приходится на упоминание CRAP-индекса или его производных.

Такие фрагменты кода с аналогичными комментариями — норма. В остальных моментах «crap» используют, чтобы выразить отношение к коду или ситуации в целом.

На Googlecode «crap» встречается явно реже. То ли код там лучше пишут, то ли просто CRAP-индекс не используют.

C/C++ лидирует с большим отрывом — здесь «crap» звучит в три раза чаще, чем во всех остальных языках, вместе взятых. Видимо, кодить на С/С++ без ошибок крайне сложно. Или же англоязычное «блин» автоматически отлаживает код и дезинтегрирует ошибки.

Fuck

Продолжаем с самым распространенным ругательством английского языка — «Fuck». Общее количество употреблений — 15 628 раз (система учитывает все производные от слова, поэтому реальные показатели немного меньше).

При этом программисты используют «fuck» как оскорбление куда реже, чем как междометие и связующее звено в мыслях. Фразы «fuck you», «fuck off» или «motherfucker» встречаются совсем редко. Это радует: мы ведь тут работать пытаемся, а не унижать друг друга.

Google и здесь отличился. Если на Github и Bitbucket присутствует 7817 и 6888 использований соответственно, то на Googlecode — всего 607. В 10 раз меньше! Совпадение? Не думаю.

Статус наиболее «fucked»-языка неожиданно получил Vimscript.

Все объясняет одна-единственная фраза:

Удивительно, что наиболее распространенное ругательство английского языка заняло не первое место в нашем рейтинге. Все-таки в разработке своя атмосфера.

Зато C/C++ предсказуемо фигурирует в рейтинге. А стабильность — залог успеха.

Shit

Универсальное слово, которое показывает, что код, мягко говоря, не слишком хороший. Всего «shit» использовали 17 598 раз — это больше, чем «fuck», даже с учетом всех его словоформ. Эти слова часто используют вместе во фразе «fuck this shit», в окультуренном переводе — «нахрен вот это вот все». 1785 примеров!

Как думаете, на каком языке чаще всего делают «shit»?

Такая ситуация в С/С++ повторяется куда чаще, чем вы можете себе представить:

Дело в том, что в C/C++ есть много возможностей, нарушающих принципы типобезопасности. И маленькая ошибка в коде может обернуться большими проблемами. Компилятор не контролирует процесс, поэтому программистам приходится изворачиваться, и не все в этом преуспевают.

Что касается ресурсов, где больше пишут «shit», — абсолютно никаких странностей:

На Bitbucket немного больше, чем на Github, но это частности. Зато Google, как всегда, на высоте. И это совсем не потому, что там делают меньше проектов, чем на Github и Bitbucket, не-не-не. Там, конечно, разработчики культурнее.

Damn

Еще один аналог русского «блин» — даже более универсальный, чем «crap». Если «crap» имеет негативный оттенок, то «damn» в целом только эмоционально окрашивает фразу. И судя по частоте его использования в IT, разработчики — ой какой импульсивный народ.

Результат по ресурсам практически полностью повторяет статистику по слову «crap». Github и Bitbucket ругались, а Googlecode рядом стоял и надышался.

И аналитикой по языкам вас не удивим:

В этом туре в компанию затесался Assembly, но общей погоды он не меняет. С/С++ остается лидером из-за количества допускаемых ошибок, на которые нельзя спокойно реагировать.

Иллюстрация к мысли о том, что оптимизм — важная черта характера разработчика на С/С++. По-другому здесь не выжить.

Баги в HTML тоже часто попадаются, но их проще исправлять, и они не приводят к таким печальным последствиям, как одна ошибка в 8000 строках кода, из-за которой падает вся система. Поэтому косяки в HTML не вызывают такого всплеска эмоций.

Cock

Несмотря на то, что это ругательство очень популярно в реальной жизни, разработчики используют его не слишком часто. Возможно, именно потому, что им можно оскорбить человека, а вот описать ситуацию или фрагмент кода не получится.

Судя по статистике, обижать коллег любят программисты на Github. Но если быть совсем честными, именно это слово часто попадает в различные фильтры. И львиная доля от всего числа использований — именно оттуда. А другая часть непонятным образом пришла из описаний неведомых материалов категории «18+». Если смотреть объективно, реальных оскорблений немного.

Интересно, что нигде, кроме Github и Bitbucket, слово «cock» вообще не используют. 63 упоминания в Googlecode — это ни о чем. На других ресурсах и того меньше. Все же это ругательство не типично для программиста.

Здесь лидером рейтинга становится HTML.

Это предсказуемо: фильтры на нецензурные слова ставят там, описания тоже есть. Вот и получается, что все HTML-проекты скинулись и набрали на первое место.

А так выглядит фильтр цензуры на Python:

В стандартном фильтре примерно 550 строк, и там учтены практически все матерные выражения и их аналоги, которые используют пользователи.

И у нас есть победитель!

По статистике использования нецензурных слов и выражений побеждает С/С++ — с большим отрывом. Если бы такой был у бегуна-марафонца, он бы мог на дистанции попить кофейку с печеньками, вздремнуть часик-другой и все равно победить в забеге.

Все же сложность структуры языка влияет на эмоциональную стабильность программистов. И С/С++, судя по нашей статистике, не способствует душевной гармонии разработчиков. Одна ошибка — и ее придется ловить вручную. Встретите программиста на С/С++ — дайте ему конфету, поддержите.

А если это вы сам, помните, что ругаться — нормально. Во всяком случае, чтобы на самом деле не убить коллегу за ошибку, которую не можете найти уже 2 дня. Хорошего настроения и кода без багов!

Бонусы для читателей

Ловите бесплатный доступ на три месяца изучения английского на онлайн-курсах EnglishDom до 30 июля 2018 года.

Будем рады видеть вас на индивидуальных занятиях курса «Английский для IT-специалистов».

Добавление поддержки редактора для других языков — Visual Studio (Windows)

11/04/2016

Чтение занимает 2 мин

В этой статье

Узнайте, каким образом редактор Visual Studio поддерживает возможности чтения и перемещения по разным языкам программирования и как можно добавить поддержку редактора Visual Studio для других языков.

Раскраска синтаксиса, завершение операторов и поддержка функции «Перейти к»

Доступные в редакторе Visual Studio функции, такие как раскраска синтаксиса, завершение операторов (также известная как IntelliSense) и Перейти к, упрощают написание, чтение и редактирование кода. На следующем снимке экрана показан пример редактирования скрипта Perl в Visual Studio. Синтаксис автоматически выделяется цветом. Например, примечания в коде выделяются зеленым цветом, код — черным, пути — красным, операторы — синим. Редактор Visual Studio автоматически применяет цветовое выделение синтаксиса к любому поддерживаемому им языку. Кроме того, по мере ввода известного ключевого слова или объекта функция завершения операторов выводит список возможных операторов и объектов. Функция завершения операторов упрощает написание кода.

Сейчас Visual Studio поддерживает раскраску синтаксиса и завершение базовых операторов для следующих языков с помощью грамматик TextMate. Если предпочитаемый вами язык отсутствует в таблице, —его можно добавить.

Bat
F#
Java
Markdown
Rust
Visual Basic
Clojure
Go
JavaDoc
Objective-C
ShaderLab
C#
CMake
Groovy
JSON
Perl
ShellScript
Visual C++
CoffeeScript
HTML
LESS
Python
SQL-код
VBNet
CSS
INI
LUA
R
Swift
XML
Docker
Jade
Производитель
Ruby
TypeScript
YAML

Помимо раскраски синтаксиса и завершения основных операторов в Visual Studio также имеется функция Перейти к. Она позволяет быстро выполнять поиск в файлах кода, путях к файлам и символах кода. Visual Studio предоставляет поддержку функции «Перейти к» для указанных далее языков.

C#
C++
TypeScript
JavaScript
Visual Basic
Go
Java
PHP

Все эти типы файлов имеют описанные ранее функции, даже если поддержка для данного языка еще не была установлена. Установка специальной поддержки для некоторых языков может обеспечить дополнительную поддержку, например IntelliSense и другие расширенные языковые функции, такие как лампочки.

Добавление поддержки для неподдерживаемых языков

Visual Studio предоставляет языковую поддержку в редакторе с помощью грамматики TextMate. Если предпочитаемый вами язык программирования в настоящее время не поддерживается в редакторе Visual Studio, выполните поиск в Интернете. Пакет TextMate для этого языка уже может существовать. Если вы не можете найти пакет, добавьте для него поддержку самостоятельно, создав модель пакета TextMate для грамматики языка и фрагментов кода.

Добавьте новые грамматики TextMate для Visual Studio в следующую папку:

%userprofile%\.vs\Extensions

По этому базовому пути добавьте следующие папки, если они применимы в вашем случае.

Имя папки	Описание
\<language name>	Папка языка. Замените <language name> именем языка. Например, \Matlab.
\Syntaxes	Папка грамматики. Содержит файлы JSON грамматики для языка, например Matlab.json.
\Snippets	Папка фрагментов кода. Содержит фрагменты кода для языка.

В Windows %userprofile% разрешается в путь: C:\Users\<user name> . Если в системе папки Расширение не существует, ее необходимо создать. Если папка уже существует, она будет скрыта.

Совет

Если у вас есть файлы, открытые в редакторе, вам нужно закрыть и снова открыть их, чтобы увидеть выделение синтаксических конструкций после добавления грамматик TextMate.

Дополнительные сведения о создании грамматик TextMate см. в статьях TextMate — Introduction to Language Grammars (TextMate. Введение в грамматику языка) и Notes on how to create a Language Grammar and Custom Theme for a Textmate Bundle (Заметки о создании грамматики языка и пользовательской темы для пакета Textmate).

См. также

О русском языке в программировании

Введение

Естественность использования родного языка

if (a==0 && b==0) return;

если a=0 и b=0 тогда возврат;

Разумные границы использования

Опыт использования родного языка

Заключение

На первый взгляд кажется, что сейчас никаких проблем с русским языком нет. Действительно, давно «локализованы» на национальные языки операционные системы, офисные программы и игры, а кириллица наносится на клавиши заводским способом. Но если обратится к программированию, то здесь русский язык почти полностью вытеснен. Конечно, есть и исключения, например, «Бухгалтерия 1С». При этом я ни в коем случае не призываю создавать специально «русские» языки программирования (остряки сразу же добавят: «православные»). Напомню, что даже в самом первом международном документе по языку программирования [2] предполагалось три уровня его представления: эталонный, язык публикаций и конкретные представления. Т.е. с самого начала предполагалось, что «знаки языка могут быть различными в разных странах, однако должно быть сохранено однозначное соответствие с эталонным представлением».

Литература

1. Д.Ю. Караваев «К вопросу о совершенствовании языка программирования» RSDN Magazine #4 2011

3. Г.С. Цейтин Доклад «Итоги освоения ОС ЕС (заметки пользователя)» 29.08.1983

Автор: Dukarav

Источник

Y Studios — ИНФОРМАЦИЯ | Passion

CODE SPEAK

Изучая эту тему, мы также просматривали многочисленные форумы разработчиков, чтобы узнать точку зрения экспертов. Он выявил множество мнений программистов о том, почему они считают, что английский язык преобладает в программировании. Вот несколько вариантов цитат:

«Наличие английских ключевых слов позволяет абстрагировать программирование от обычного языка. для нас… Нам НЕ нужны ключевые слова на местном языке для программирования.Любой, кто создал свой собственный язык программирования в университете и попробовал использовать местные ключевые слова, согласится со мной в том, насколько сложно читать код ».

«Благодаря развитию высоких технологий английские слова используются чаще. Отчасти проблема в том, что недостаточно изменить ключевые слова. Иностранные грамматики могут сбить с толку заученный перевод утверждений. Порядок слов может сильно отличаться от одного языка к другому. ”

“ На рынке глобальной экономики, которым стала разработка компьютеров, общий язык, кажется, имеет наибольший смысл. ”

“ Одна из трудностей, позволяющих переключать ключевое слово на лету на другой язык, заключается в том, что ключевые слова должны быть «зарезервированы», чтобы их нельзя было использовать в качестве идентификаторов. Переключение языков на лету приведет к тому, что в игру вступит другой набор зарезервированных слов, что может привести к конфликтам. ”

“ Преимущество английского языка в том, что на нем говорят многие сотни миллионов людей. Язык, использующий неанглийские ключевые слова, вероятно, не будет иметь спроса, необходимого для его поддержки . Единственное исключение вроде бы китайцы. На нем говорят даже больше людей, чем на английском, и огромная разница между английским и китайским сделает изучение английского более серьезным препятствием для обучения программированию на китайском ».

“ Английский — международный язык бизнеса, люди пишут программы в первую очередь для своего рода бизнеса. ”

“ Английский язык является языком по умолчанию и стандартом де-факто. Если вы хотите охватить большую аудиторию, вы выбираете язык, на котором говорят многие. Мы учим английский, как медик изучает латынь. ”

“ Это потому, что программисты должны сообщать о своем коде. Это легко, если есть стандарт, а стандарт прост — это английский ».

«Это потому, что Английский язык является лингва-франка для мира полиглотов .Преобразовать списки зарезервированных слов в любой язык, который вы хотите, довольно просто, но никто не беспокоит, потому что это создает другие проблемы на платформе. Я говорю на 5 языках и работал во многих разных странах. Английский просто удобен и прост для большинства людей. ”

“ Английский язык кажется хорошо адаптированным для программирования. На большинстве родных языков поиск кратких эквивалентов ключевых слов может стать обузой. Некоторые языки могут соответствовать, но некоторые языки просто не выдерживают испытания ».

« Большинство широко используемых языков программирования основаны на английском, и большинство из них привлекают международную аудиторию ».

«Для самого кода … все на английском. Это имеет смысл, когда вы понимаете, что большинство онлайн-ресурсов находятся на английском языке, и тот факт, что делиться кодом с людьми из других культур также становится проще. ”

“ По большей части, Китайский код на «английском» (то есть они кодируются в той же версии языков программирования, которые используются в США, с английским языком. ключевые слова и так далее). Однако есть некоторые языки программирования, которые в разной степени обслуживают китайский язык, например ChinesePython ».

«Код написан на стандартных языках программирования, хотя комментарии (и, возможно, имена переменных) могут быть написаны на китайском языке. Нет смысла изобретать колесо заново (где «колесо» — это C ++, Perl, Python и т. Д.) , когда вы можете просто выучить несколько ключевых слов. ”

Конечно, похоже, что у большинства программистов во всем мире нет проблем с использованием английских ключевых слов для кодирования. Зачем создавать новый способ кодирования, если его никто не понимает? Если он не сломан, зачем его ремонтировать, правда?

Делаем упор. Спасибо.

(PDF) Обучение программированию: российская перспектива

эффективных) программ.Это касается как уровня кода (статическая безопасность и т. Д.), Так и правильного проектирования

(тщательное расслоение, инкапсуляция и т. Д.).

Эти соображения в конечном итоге привели меня к принятию с 1995 года

Oberon (в частности, вариант Component Pascal для Oberon-2, реализованный

в BlackBox Component Builder от Oberon Microsystems, Inc. [4]) для всех

мой алгоритм проектирования работы. Оберон / Компонентный Паскаль оказался превосходным выбором

для всего диапазона проблем, с которыми я сталкиваюсь — от различных вариантов символьной манипуляции

(крупномасштабная алгебра, графики, комбинаторика) до чисто численных приложений

( е.грамм. многомерная оптимизация и адаптивная интеграция Monte

Carlo). Типобезопасность, модульность, автоматическое управление памятью,

и быстрый компилятор в свободной среде разработки, способный работать с

на любом старом ПК или ноутбуке, практически в любом месте, приводят к удивительно продуктивному циклу разработки и экспериментов

даже для чисто числовые

проектов, которые в конечном итоге будут перенесены на Фортран. [4]

На самом деле, для творческой работы по разработке алгоритмов, особенно там, где эффективность работы

является главной проблемой, Oberon выходит за рамки роли простого «инструмента» и становится настоящим расширителем мозга

3. Несколько лет неудачных попыток найти соавторов для проектов на основе

Oberon (несмотря на искренний интерес: мои коллеги-теоретики слишком заняты

отладкой своих кодов fortran, C ++ и т. Д., А это меньше шутка, которую не мог бы подумать один

), убедил меня начать экспериментальный курс современных методов программирования

на физическом факультете Московского государственного университета

в весеннем семестре 2001 года. Опыт быстро показал, что:

— Различные курсы обычной учебной программы (которая охватывает первые два года

и включает обычные вводные курсы, практикум и мини-проект по физическому моделированию

) используют различные платформы программирования (от

MathLab до C ++) в соответствии с предпочтения конкретного профессора.

— Студенты тратят умственные способности на изучение синтаксических особенностей архаических систем

вместо того, чтобы осваивать основы построения систематической программы

(пошаговое уточнение, инварианты циклов, интерфейсы как контракты и т. Д.).

— В курсах полностью отсутствуют ключевые понятия программирования в

больших (эволюционируемость программного обеспечения, интерфейсы, шаблоны,…).

Короче говоря, сложность и несоответствие различных программных платформ, использованных

на протяжении всей учебной программы по программированию, оказывает чрезвычайно неблагоприятное влияние на то, что студенты

фактически узнают о программировании.

С другой стороны, ясный минимализм Oberon / Component Pascal позволил

вместить в семестр лекционный курс (формально аналогичный стандартному вводному курсу

) ряд современных методов программирования

, включая элементы дисциплины программирования Дейкстры, основные динамические структуры данных

, необходимые ООП, COP и базовые шаблоны (фабрика, перевозчик / райдер,

, отделение интерфейса от реализации), основы интерактивной графики

(MVC).Содержание курса может быть дополнительно обогащено по мере накопления опыта и библиотеки примеров программ

. Продолжительность только одного семестра

(16 лекций) продиктована посторонними обстоятельствами и, конечно же,

несколько слишком ограничивающая: было бы лучше посвятить полный семестр программированию

в малом и еще один, чтобы программирование в целом. Тем не менее

возможен даже односеместровый курс (он приобрел довольно стабильную форму по направлению к

Самые популярные языки программирования / Sudo Null IT News

Каждый месяц работодатели создают около 15000000 поисковых запросов на hh.RU. Мы проанализировали потребности компаний в конкретных программистах и составили рейтинг самых популярных языков программирования по запросам работодателей.
Итак, первая десятка самых востребованных программистов в Москве выглядит так:

Axapta, flash и ruby были очень близки к первой десятке.

UPD: по просьбам читателей добавлен Минск.

Стоит сразу уточнить, что это поисковые запросы работодателей для конкретных программистов в строке поиска hh.ru, не больше и не меньше. Рейтинг формировался следующим образом: сначала мы изучали, какие языки программирования работодатели вбивают в поиск на hh.ru, чтобы составить список наиболее часто встречающихся запросов. А потом поиск был максимально доработан, добавив к названию языка слова «программист», «разработчик», тимлид и их синонимы на русском и английском языках, чтобы быть уверенным, что это рейтинг востребованности программистов. , а запросы по 1С, например, не касаются бухгалтеров или консультантов.

Санкт-Петербург

Для сравнения приведем данные по некоторым другим городам России. Например, вот рейтинг популярных языков программирования среди работодателей Санкт-Петербурга:

В Санкт-Петербурге программисты 1С намного востребованы, чем в Москве (7 место). Стоит отметить гораздо меньшую популярность sql и Delphi (последний вообще не попал в рейтинг) по сравнению с Москвой.

Новосибирск

Продолжим и посмотрим, какие программисты популярны в Новосибирске:

В Новосибирске наиболее популярны php-программисты: запросов на них гораздо больше, чем на 1С, а тем более на java.Интересно, что рубин находится на 10-м месте, а не в первой десятке ни в Москве, ни в Санкт-Петербурге.

Казань

А теперь посмотрим на спрос на программистов в Казани:

Картина примерно такая же, но появление Axapta на десятом месте интересно, а отрыв 1С впечатляет. Кроме того, Казань — единственный город, где C # по спросу превзошел C ++.

Казахстан

В Казахстане у нас есть сайт hh.kz, сравним запросы их работодателей на программистов с российскими:

В Казахстане спрос на Delphi и 1С намного выше, чем в России, а в первой десятке нет ни одного рубина. Ни питон.

Минск

Сравнение с TIOBE

Теперь сравним запросы российских работодателей в Москве с данными индекса TIOBE:

(взято здесь: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html).

Что ж, сразу видно, что в рейтинг TIOBE не входит популярная 1С :). Но Java, C ++ и C #, очевидно, не случайно в России востребованы, в TIOBE они занимают 2, 4 и 5 места соответственно. С разницей в несколько позиций и Python, и мы оказались в первой десятке.Но востребованные в России Delphi, sql, net и даже javascript не входят в первую десятку TIOBE. Зато у них там на седьмом месте Visual Basic, который не пользуется спросом в России, и perl, который попал в первую десятку только в Санкт-Петербурге.

Бонус Самые экзотические языки

Мы разобрались с востребованными направлениями, но, например, для любителя — еще десяток самых экзотических языков программирования, тех, которые на hh.ru редко искали, но все же были.Данные полностью за 3 квартал этого года (июль-сентябрь):

Соискатели

Думаю, всем будет интересно посмотреть, на каких языках программирования соискатели загоняют в поиск на hh.ru, чтобы найти соответствующие вакансии, мучить не буду:

соискателей ежемесячно создают примерно 70000000 таких запросов . Например, такой: bit.ly/ WFvICw.

А про деньги

По любому из упомянутых языков программирования вы можете легко самостоятельно определить предлагаемую зарплату по методу, предложенному blv в предыдущем посте.

👨🏽‍🔬 📱 💖 Русский язык программирования ❌ 🏉 🐼

Начал разработку русского языка программирования.
Сокращенно: RNP.
Ну, а в итоге начал разработку интерпретатора РНП.
RNP напоминает язык KuMir, но будет иметь значительные отличия и преимущества по сравнению с другими языками.

Переменные не нужно объявлять, потому что при первом обнаружении переменной в листинге программы интерпретатор автоматически создаст переменную типа Double (действительное число) с этим именем.

Я пишу интерпретатор в 32-битной версии среды разработки Lazarus (язык программирования Паскаль).
В ряду, конечно же, есть зарезервированные слова: начало, конец, если, цикл.
Но в качестве имен переменных можно использовать зарезервированные слова!

Скачать архив можно по ссылке, он содержит бинарник (версия 0.2), программы простые: C и Pascal
архивы
уйдут, Python утонет, Java закопчится!

Бесплатно скачивайте и распространяйте, пишите программы, пишите мне о глюках.
Только прошу не делить на ноль! 🙂

ПРИЛОЖЕНИЕ 1 (28 февраля, 18:30 мск):
1) Кто-то посмеялся над названием языка, предложил свои варианты.
Прямо как маленькие дети 🙂
2) Кто-то вообще не захотел качать архив, наверное, даже не перешел по ссылке.
Кто тогда придумал URL и всю философию HTTP?
3) Кто-то не хочет отлаживать английский язык.
Наверное, и веселье только по-английски, используя такие слова, как запуск, совершение, ебать, лайфхак, гамбургер, толстовка.(возведение в степень),
% (процент), mod (остаток от деления на число) и (бит И), xor (исключающее ИЛИ бит),
или (ИЛИ бит), >> (сдвиг бит вправо).

Унарные команды : LINvert (LInvert; логическая инверсия переменной), round (округление; округление действительного числа до целого), show (показать; отобразить имя и значение переменной)

Вот код для вычисления простых чисел:

Результат:

PS На будущее:
— Механизм массивов.

— Вместо присвоения одной переменной можно написать формулу
, в левой части которой может стоять не только переменная, но и операция с другой переменной.

— Анализ кода.
Выдача подробных подсказок программисту.

— Автоматически переформатирует код в желаемый стиль.

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

— Иногда предполагается, что между конструкцией языка (цикл, если) и переменной нет пробела.

— Любой код можно записать в одну строку.

— Объединение нескольких файлов кода в один файл.

— Любое количество букв в названии языка дизайна.

ТГУ возрождает один из первых русских языков программирования

Ученые отдела информационной безопасности и криптографии работают над возрождением языка программирования LYaPAS (логический язык для представления алгоритмов синтеза [OU1]). По мнению разработчиков, программы, написанные на LYaPAS, могут быть более надежными, чем программы, использующие другие языки, поскольку они усложняют интеграцию в код скрытых функций шпионского ПО.

ЛЯПАС был разработан профессором Аркадием Закревским и его учениками в начале 1960-х годов в Сибирском физико-техническом институте при ТГУ. Тогда компьютер Урал-1 был в Томском университете и был первым за Уралом. Электронные вычислительные машины того времени были настроены на просчет арифметических задач, но при разработке ЛЯПАС ученые сделали упор на умение решать логические задачи.

Одно из главных преимуществ этого языка — его безопасность.

— С самого начала ЛЯПАС контролировал доступ к памяти, чего не было у таких языков того времени, в том числе того же Си, который является родоначальником многих современных популярных языков, — говорит Дмитрий Стефанцов, старший преподаватель кафедры Информационная безопасность и криптография. — Из-за того, что проблема изначально существовала в C, сегодня многие современные программы уязвимы. Появились некоторые аналоги защиты, но пока они есть только у нас.

Помимо безопасности, ЛЯПАС обладает еще такими качествами, как скорость и лаконичность.В названии функций вместо комбинации букв используются специальные символы. Благодаря этому программы, записанные на ЛЯПАС, в несколько раз короче, чем записанные на других популярных сегодня языках программирования. Это упрощает анализ написанных алгоритмов и, в частности, их проверку на наличие ошибок.

— Мы можем доверять написанному программному обеспечению, — подчеркнул Дмитрий Стефанцов. — Можно быть уверенным, что автор не заложил в программу что-то для обхода защиты.

Сегодня написаны средства разработки для ЛЯПАС. Создан прототип операционной системы на этом языке. Факультет прикладной математики и кибернетики провел спецкурс по программированию в ЛЯПАС. Ученые продолжают работать над его улучшением. В их ближайших планах — создание программного обеспечения для самой операционной системы.

В советское время язык программирования ЛЯПАС был одним из самых популярных в странах советского блока.За рубежом это называлось «Русский язык программирования». Со временем Советский Союз начал производить аналоги западных компьютеров, компьютерного оборудования и программного обеспечения, и из-за этого их собственные языки программирования потеряли популярность. Заведующий кафедрой информационной безопасности и криптографии профессор Геннадий Агибалов решил возродить один из первых русских языков программирования, созданный в ТГУ. Ученые и студенты кафедры работают в этом направлении около 7 лет.

Алгол 68 — 25 лет в СССР. Российский виртуальный компьютерный музей

Главная → Статьи → Алгол 68 — 25 лет в СССР

Булёнков Михаил Александрович, Рар Александр Ф., Терехов Андрей Николаевич

Первая информация об Алголе — тогда 67 — была принесена в нашу страну доктором Ершовым в 1966 году. Тогда в России возникли три фокуса, в которых внимательно наблюдалась текущая работа команды ван Вейнгаардена. Это группа доктора Ершова в Новосибирске, Dr.Лаврова в Подлипках Московской области, доктора Левинсона в Москве. В этих местах стали присылать многочисленные замечания по поводу языка и рассматривать его русскую терминологию. Процесс перевода отчета по Алгол 68 на русский язык следовал за процессом его обновления на английском языке настолько близко, что и отчет, и его русский перевод [1] были выпущены в том же 1969 году.

Еще раньше, в феврале 1968 года, в Бакуриани, Грузия, в специальной Зимней школе на Алголе 68 были проведены первые лекции по новому языку.

Позднее распространение языка в СССР было заметным, но ограниченным. Группы ярых приверженцев Алгола 68 появились в Киеве, Харькове (Украина), Ижевске, Казани, Томске, Бердске и других городах России. Самой сильной и плодотворной из этих групп была группа Ленинградского государственного университета. На протяжении многих лет Algol 68 был основным языком программирования, изучаемым на курсе информатики в Ленинградском университете. Ленинградские реализации Алгола 68 будут рассмотрены позже.Но все эти острова Алгола были редкостью в океане Фортрана, а затем и в морях Паскаля, Модулы, Ады.

Начиная с 1976 г. начала действовать официальная национальная организация по Алголу 68, под наблюдением которой были перевод Пересмотренного отчета, публикация литературы, тестирование и внедрение компиляторов. До 1982 года этот орган назывался «Научно-техническая комиссия» и возглавлялся А.П. Ершовым, а в последнее время стал «Рабочей группой» во главе с Г.С. Цейтиным.Последняя сессия группы состоялась в 1988 г., когда был принят национальный стандарт Алгола 68. С тех пор не было предпринято никаких попыток созвать новую сессию Группы.

Наша первая публикация Отчета, о которой упоминалось ранее, была двуязычной. Он содержал весь текст Отчета со всеми прагматическими замечаниями и фотографиями Винни-Пуха. Работа над русским переводом и особенно сложная работа по преобразованию синтаксических и метасинтаксических правил в русскую форму вызвали размышления о том, как формализовать правила для создания национальных вариантов Алгола 68.Также были рассмотрены методы построения синтаксических и метасинтаксических диаграмм Алгола 68, и правильно оформленные диаграммы сопровождали публикацию. Обе эти проблемы стали темами отчета, представленного на Рабочей конференции «Реализация Алгола 68», которую IFIP провел в Мюнхене в июле 1970 г. [2]. Соображения по построению национальных вариантов были приняты во внимание авторами Пересмотренного отчета и соответствующие предложения частично включены в данный отчет.

Перевод Пересмотренного отчета был выполнен не так быстро, как в случае с предыдущим отчетом.Он постоянно и тщательно создавался одним автором, а не четырьмя из них, но под неусыпным надзором национальной комиссии по Алгол 68, и окончательный результат был опубликован только в 1980 году [3].

Публикаций по Алгол 68 в нашей стране впоследствии было не так много. Можно упомянуть переводы «Неформального введения» К. Х. Линдсея и С. Г. ван дер Мейлена [4] и «Практического руководства» Ф. Г. Пагана [5]. Что касается оригинальных книг по языку, то можно упомянуть краткие описания А.Маслова [6], В. А. Васильева [7], а также «Введение в Алгол 68» А. Н. Терехова, которое является частью книги, описывающей ленинградский компилятор [8].

Как было сказано ранее, национальный стандарт Алгола 68 был принят в 1988 году. Текст этого стандарта был текстом русского перевода Пересмотренного отчета с некоторыми незначительными изменениями по форме, но не по существу. В то же время был принят другой национальный стандарт, а именно «Стандарт расширенного Алгола 68».В этом документе использованы предложения IFIP по модулям и раздельной компиляции, а также предложения Г.С. Цейтина по обработке исключений.

Сложность Algol 68, присущая ему, способствовала тому, что язык был вложен в основном в академическую и университетскую среду и не нашел большой поддержки в отрасли. Возникла опасность, что Алгол 68 мог стать объектом чисто математических исследований со всей присущей им близостью. Члены Рабочей группы четко осознавали эту проблему и уделили значительное внимание практической реализации Алгола 68 как основного способа его распространения.Не проводилось ни одной сессии Группы, на которой не были бы опущены проблемы языковой реализации.

Было несколько попыток внедрить Алгол 68 в СССР. По некоторым причинам, которые будут кратко упомянуты ниже, только одна из них, а именно Ленинградская, уцелела, но действительно получила широкое распространение.

Одна из первых реализаций Algol 68 была сделана на киевском заводе по производству компьютеров в конце семидесятых годов для компьютеров Siemens. Его авторы — С.И. Штительман, М.Г. Штейнбух, Л. А. Макогон. Реализация была ориентирована на систему управления информацией под названием «СТАРТ», для которой Algol 68 был единственным языком, который она использовала. Авторов проекта интересовал Algol 68 прежде всего как источник языка базы данных. Киевская реализация предвосхищали многие особенности современных языков такого рода: постоянные объекты, продуманную систему типов, ортогональный дизайн, большую долю интерпретативности и т. д. Система типов и ортогональность на самом деле были обусловлены самим Algol 68, но настойчивостью Функция требует некоторых исправлений языка.А именно был введен «вечный блок», предназначенный для сохранения между запусками программы тех объектов, которые могли использоваться разными программами. Фактически это была база данных. Некоторые другие варианты также были сделаны без какого-либо отношения к стандартизации усилия для Algol 68: все массивы считались гибкими, управляющая переменная цикла была long int, а не int, комплексные значения отсутствовали и т. д. Принятая Рабочей группой в 1979 году эта система больше не существует из-за замены оборудование на заводе.

Параллельно реализовывался Алгол 68 на базе архитектуры DEC. Эта реализация выполнялась под руководством доктора М. Левинсона. Хотя и незаконченный, он привнес в технику реализации оригинальные идеи. Основное отличие этой реализации заключалось в проверке области видимости: время жизни любого объекта не ограничивалось временем выполнения блока, в котором объект был объявлен.

Реализация компилятора Algol 68 для вычислительного комплекса «Эльбрус» была разработана В.В. Брол, В. М. Гущин, В. Б. Яковлев (Москва). Его исходным языком является полный Алгол 68, определенный в Пересмотренном отчете и расширенный некоторыми средствами обработки модулей. Компилятор обеспечивает хорошее качество объектного кода, достаточно полную диагностику ошибок. Он хорошо использует сходство между основными концепциями Алгола 68 и концепций архитектуры и операционной системы «Эльбрус». Компилятор был принят национальной рабочей группой в 1985 году. Ленинградская группа принимала активное участие в тестировании этого компилятора.Около десяти больших пакетов приложений, разработанных в Ленинградском университете, практически без проблем были перенесены на «Эльбрус», но трагедия компилятора «Эльбрус» заключалась в том, что это были практически единственные реально существующие программы, которые он обрабатывал.

Многообещающий «БЕТА-проект» в Новосибирске, первоначально разработанный доктором А.П. Ершовым, М. Шварцманом, А.А. Бэрсом, предназначался для создания компиляторов из описаний языков почти автоматически, и в качестве первых в нем использовались Algol 68, PL / I и Simula 67. цели [9].Система действительно создана, но не в той форме, о которой изначально задумывались, и теперь она охватывает следующие языки: Simula 67, Pascal (эти языки реализованы Г.Г. Степановым и С.Б. Покровским), Modula 2 (Л.А. Захаров), подмножество Ada (SV Ten), но не Algol 68 или PL / I [10]. Тем не менее, концепции Algol 68 использовались в системе BETA для создания как универсальной схемы компиляции, так и внутреннего языка.

Наибольшее развитие получили работы по внедрению Алгола 68 в Ленинградском университете в группе, возглавляемой доктором В.Цейтин Г.С. и Терехов А.Н. В первую очередь эти работы согласовывались с работой по системе BETA в рамках стратегии, разработанной Рабочей группой. Предполагалось, что ленинградская группа построит отладочный компилятор, своего рода авангард, призванный завоевать новые области применения для основных сил, а именно базовый компилятор, который будет построен в Новосибирске. Естественно предполагалось, что любая прикладная программа, отлаженная с помощью Ленинградского компилятора, должна работать на Новосибирском компиляторе без необходимости модификации.

Как уже было сказано, Ленинградский проект изначально был ориентирован на практическое использование, что определило как его принципиальные решения, так и его историю.

Первая версия Ленинградского компилятора была завершена к 1976 году. Его анализирующая часть была написана на Алголе 60 и запускалась на компьютере ODRA 1204. Его генерирующая часть была написана на Макроассемблере и работала на мэйнфрейме IBM.

После этого весь компилятор был переписан на Алголе 68 и расширен: каждая процедура компилятора (их более 1000) переведена на ODRA с Алгола 68 на промежуточный язык (IL), полученная перфолента была введена на компьютер IBM и переведен из IL в объектный код IBM.Перевод средней процедуры занимал 10 минут на ODRA и 20 минут на IBM. Поскольку отладка этих процедур требовала их повторной модификации и перекомпиляции, потребовалось еще больше времени. Результатом этого процесса начальной загрузки стал резидентный компилятор, который компилировал каждую процедуру в течение 2-3 минут.

В 1978 году была произведена первая начальная загрузка, и получившийся в результате компилятор был предоставлен многим пользователям в различных областях (математическая физика, радиолокационные методы, моделирование).Сразу после этого началась вторая бутстреппинг. В этот момент разработчики осознали необходимость библиотечных прелюдий и отдельной компиляции процедур. Поэтому в Algol 68 была добавлена новая конструкция, которая выглядела скорее как гнездо, еще не известное авторам.

Потребовались большие усилия для оптимизации вызовов процедур. Размер кода уменьшен с 16 до 6 байтов на вызов. Для сравнения: компилятор PL / I-F принимает 150 команд на вызов, а оптимизирующий PL / I — 30 команд.Десять лет спустя возникла идея изменить направление стека, что привело к значительному сокращению кода для вызовов процедур.

Вторая начальная загрузка была завершена к 1979 году, и эта версия просуществовала более 10 лет с минимальными модификациями. В то время разработчики были заняты в основном технологией программирования, поскольку оказалось, что Алгол 68 слишком сложен, чтобы быть языком для простых задач, но что касается больших задач (например, реального времени), только языковых возможностей недостаточно.Но не были забыты и проблемы компиляции: скомпилирован десяток кросс-компиляторов для разных специализированных компьютеров, доработана методика оптимизации, компилятор интегрирован с другими техническими средствами.

В тот момент стало ясно, что появление базового компилятора маловероятно. Таким образом, в компилятор Leningrad был включен новый этап, а именно этап оптимизации. В отличие от того, что планировалось в проекте BETA, Ленинградский компилятор использовал только локальные оптимизации, потому что введение глобальной оптимизации потребовало бы значительного пересмотра структуры компилятора.Позже статистика показала, что даже среди всех локальных оптимизаций наиболее эффективными являются только две — для передачи параметров и для индексации массивов.

В некотором смысле реализация Algol 68 подорвала социальную основу глобальной оптимизации: в большинстве случаев результаты глобальной оптимизации могут быть выражены на одном языке.

В 1980 году к Ленинградской группе обратилось научно-производственное объединение «Красная Заря» (крупнейшее телефонное производственное предприятие в СССР) с предложением о сотрудничестве в программировании большого класса задач управления и связи и, в частности, , для разработки функционального программного обеспечения для телефонных станций, управляемых специализированными компьютерами.Потребовалось несколько лет, чтобы вникнуть в специфику новой области, разработать прототипы реализации и решить организационные вопросы. Ленинградцы на своем предыдущем опыте убедились, что использование языков программирования высокого уровня абсолютно необходимо. Однако начать им пришлось с повышения культуры программирования прикладных программистов. Это связано с тем, что традиционно в области разработки встроенного ПО реального времени используются компьютеры с нестандартной архитектурой, ориентированные на прикладную область.(На самом деле не очевидно, какой должна быть эта ориентация. Например, если специализированный компьютер хорошо выполняет некоторые специальные операции, но плохо работает с ветвлениями и вызовами процедур, что происходит в тысячу раз чаще, чем специализированные операции, тогда можно было бы рассмотреть быть ориентированным на этот домен приложения?). Нестандартная архитектура и небольшое количество специализированных компьютеров приводят к отсутствию достаточно развитых операционных систем, компиляторов, отладчиков и других распространенных инструментов программирования.Таким образом, группе пришлось иметь дело с перфокартами и коммутаторами.

За короткое время были разработаны новый кросс-ассемблер и интерпретатор, которые вместе с системой документации и некоторыми сервисными программами составили основу первой промышленной технологической системы на базе Алгола 68 и которая интенсивно использовалась сотнями прикладных программистов. Естественно, технология была ограничена, но по-прежнему популярна по следующим объективным причинам:

Вместо специализированных компьютеров использовался широко доступный мэйнфрейм с широким спектром услуг.
Богатые средства отладки интерпретатора, которые были невозможны на специализированном компьютере.
Понимание прикладными программистами необходимости документации и простоты ее подготовки, исправления и копирования в новой среде.
Практически безграничные возможности для развития технологии. Это было удивительно быстро принято прикладными программистами и дало обратную связь с идеями и предложениями.

В настоящее время Ленинградская группа имеет большой опыт использования Алгола 68 в различных областях применения.Используемый в качестве инструмента реализации компилятор A68LGU имеет вполне удовлетворительные характеристики надежности, времени компиляции и качества объектного кода. Однако недавно авторы Algol 68 предложили новые интересные расширения языка, касающиеся модульности, раздельной компиляции и обработки исключений. С другой стороны, оказалось, что компилятор A68LGU не подходит для включения новых технологических инструментов, которые не были предусмотрены с точки зрения проектирования, например отладка по исходному тексту.В ходе длительной эксплуатации компилятора были обнаружены и другие мелкие недостатки (например, слишком узкий диапазон целых чисел), а также более серьезные ошибки, такие как в некоторых случаях неправильное выделение памяти. Это привело к решению разработать новую систему программирования, которая получила название WBC.

Отличительными чертами новой системы программирования являются целостность и интерактивный стиль работы. Имеет специальные средства для управления конфигурацией и поддержки разработки крупных проектов.Еще одна особенность системы WBC — ее одновременная ориентация на нескольких компьютерах (мэйнфрейм IBM, архитектура DEC, CAMCOH, PS 1001, совместимые с ПК и некоторые специализированные компьютеры). На базе компилятора A68LGU реализовано несколько кросс-компиляторов. Был опыт портирования компилятора на разные компы. Сам факт, что большая часть компилятора написана на Алголе 68, наводит на мысль о его переносимости. Однако реальное портирование оказалось намного сложнее.Необходимо было реорганизовать всю структуру компилятора и его динамическую среду, точно указать части, которые зависят от оборудования или операционной системы, унифицировать механизмы взаимодействия. Интерфейс с таблицами компилятора был задан таким образом, чтобы различные блоки, реализующие интерфейс, были возможны даже на одном и том же компьютере в зависимости от задач конкретного компилятора.

Все компиляторы систем WBC имеют следующие общие компоненты и функции:

синтаксис промежуточных языков;
структура таблиц компилятора и процедур доступа;
программ режима независимого и зависимого от режима анализа, фрагментов фазы оптимизации, генерации листинга, отладчика и монитора;
алгоритма распределения памяти и регистров;
методика генерации кода;
поддержка во время выполнения, включая процедуры ввода-вывода;
способ выбора вариантов компиляции языковых конструкций;
Алгол 68 как язык реализации.

Такая унификация делает систему открытой для расширения на другие компьютеры, и прогресс на пути от мэйнфрейма IBM к архитектуре DEC, к CAMCOH, к IBM PC и т. Д. Может быть оправданием для этого.

Список литературы

Отчет по алгоритмическому языку Алгола 68, русский перевод А. А. Бэрса, А. П. Ершова, А. Ф. Рара и Л. Л. Змиевской. «Кибернетика», Киев, Часть 6 1969 г. и Часть 1 1970 г.
А.А. Бэрс, А.П. Ершов, А.Ф.Рар. Об описании синтаксиса Algol 68 и его национальных вариантов. В: «Реализация Алгола 68», под редакцией Дж. Э. Л. Пека, Н. Х. Publ. Co., Амстердам-Лондон, 1971.
Пересмотренный отчет по алгоритмическому языку Алгола 68. А. ван Вейнгаарден, Б. Дж. Майлу, Дж. Э. Л. Пек, К. Х. А. Костер, М. Синцов, К. Х. Линдси, Л. Г. Л. Т. Меертенс и Р. Г. Фискерс (ред.). Русский перевод А. А. Бэрса, Издательство «МИР», Москва, 1980.
К. Х. Линдси и С. Г. ван дер Мейлен.Неформальное введение в Алгол 68. Русский перевод Л. Лейфмана, Издательство «МИР», Москва, 1977.
Ф. Г. Пэган. Практическое руководство по Алголу 68. Русский перевод А. Ф. Рара, Издательство «МИР», Москва, 1979.
А. Н. Маслов. Алгол 68. Структура программ, МГУ, 1978.
В. А. Васильев. Язык Алгол 68. Основные понятия. Издательство «Наука», Москва, 1972.
Г. Дейкало, А. Н. Терехов и др.Новые инструменты программирования для ES EVM. Издательство «Финансы и статистика», Москва, 1984.
А.П. Ершов. Многоязычная система программирования, ориентированная на описание языка и универсальные алгоритмы оптимизации. В: «Реализация Алгола 68».
Л. А. Захаров, С. Б. Покровский, Г. Г. Степанов, С. В. Тен. Многоязычная система компиляции. Вычислительный центр Сибирского отделения Академии наук СССР, Новосибирск, 1987.

Александр Ф.Рар — Новосибирск, Институт системной информатики;
Терехов Андрей Николаевич — Санкт-Петербургский государственный университет

Конференция по языкам программирования в России

24.05.2017 ::

Автор: Артем Пеленицын

3–5 апреля я принял участие в русскоязычной конференции, посвященной исключительно языкам программирования: языки программирования и компиляторы (переводная версия сайта Google). Я был членом оргкомитета, у меня там была газета.

Это первая конференция в России, сфокусированная на нашей области PL. По крайней мере, последние несколько десятилетий (думаю, в СССР были подобные конференции). Конференция была посвящена памяти выдающегося советского исследователя PL из Ростова-на-Дону Адольфа Фуксмана, который работал над идеями, весьма схожими с тем, что мы называем аспектно-ориентированным программированием еще в 70-х годах.

Конференцию разработали и провели вместе с моими коллегами из Института математики, механики и информатики им. И.И. Воровича Южного федерального университета (Ростов-на-Дону, Россия).Мы стремились собрать как можно больше исследователей PL и энтузиастов из академических кругов России. Одним из следствий поставленной цели стало решение проводить конференцию на русском языке. Хотя нам не хватало опыта наших коллег, не говорящих по-русски, мы получили всестороннее участие со всей России:

Санкт-Петербург, Москва, Новосибирск, Красноярск, Екатеринбург, Казань и др.

Я упоминаю только города с населением более 1 млн. населения в порядке убывания количества участников конференции (и, конечно, без самого Ростова).

Мне особенно понравились выступления приглашенных спикеров. При поиске таких мы ориентировались на россиян, которые работают в известных университетах и / или имеют некоторую известность на международном уровне. В итоге у нас остались два исследователя: Илья Сергей (Университетский колледж Лондона) и Екатерина Комендантская (Heriot-Watt U., Эдинбург, Великобритания). Интересно, что их переговоры были довольно близки друг к другу:

И. Сергей, Зависимые типы для верификации реальных программ,
Э.Комендантская, Автоматизированное доказательство теорем для вывода типов, Конструктивно.

Оба они говорили о типах как о логическом инструменте, обеспечивающем правильность программы.

Самым большим открытием на этой конференции для меня стала команда из лаборатории языковых инструментов JetBrains. Наверняка вы слышали о JB: либо об их знаменитой IDE, IntelliJ IDEA, либо о языке программирования Kotlin (который, кстати, сейчас одобрен для разработки под Android). Вы также могли заметить, что JB стали спонсорами ECOOP и OPLSS в этом году.Так что у нас появилась целая команда исследователей из петербургского офиса JB. Среди их тем: OCaml , встраивание miniKanren (некоторые результаты были представлены на ML Workshop 2016), библиотеки комбинаторов синтаксического анализатора для OCaml и запросы ограниченного графа (это не является конкретной проблемой PL, подробности см. В arXiv: 1502.02242) .

В остальном спектр тем, представленных на конференции, был довольно широк, вот некоторые:

Статический анализ с PVS-studio (выступление спонсора),
суперкомпиляция (доклад исследователей из Переславля-Залесского, где тема активно разрабатывается десятилетиями),
C ++ и выше (член комитета ISO C ++),
архитектурно-независимые языки параллельного программирования и методы компиляции для параллельных архитектур,
семантика игр и онтологии для семантики PL,
программный анализ,
архитектур компилятора.

Полная программа со ссылками на слайды на русском языке доступна здесь.

Позвольте мне упомянуть мою работу: это была совместная работа с моим учеником по исследованию пространства дизайна для библиотек синтаксических анализаторов с использованием языка программирования с прямой поддержкой системы эффектов, а именно Фрэнка. Юлия Белякова также приняла участие в конференции с ее работой над Coq-сертифицированным интерпретатором для расширения лямбда-исчисления с концептуальными параметрами (модульные вещи). Продолжение этой работы принято на семинаре FTfJP в этом году.Вы также можете послушать ее по этой теме на NEPLS на следующей неделе.

Я надеюсь, что мы найдем источники, время и, самое главное, качественные материалы для PLC – 2018.

«Твитнуть»
.

О русском языке в программировании / Хабр

Введение

Естественность использования родного языка

Разумные границы использования

Опыт использования родного языка

Заключение

Русский язык программирования, а почему бы и нет?

Команды в программировании на русском языке

Русский язык программирования Аналитик

Русские команды Интегрировать и Дифференцировать

О перспективах

Python ｜ Java ｜ c ++ эти три языка программирования, вы узнали это?

язык программирования — Translation into English — examples Russian

Crap! Какой язык программирования заставляет ругаться чаще? | GeekBrains

Да какие маты на английском? То ли дело на русском!

Crap

Fuck

Shit

Damn

Cock

И у нас есть победитель!

Бонусы для читателей

Добавление поддержки редактора для других языков — Visual Studio (Windows)

В этой статье

Раскраска синтаксиса, завершение операторов и поддержка функции «Перейти к»

Добавление поддержки для неподдерживаемых языков

См. также

О русском языке в программировании

Введение

Естественность использования родного языка

Разумные границы использования

Опыт использования родного языка

Заключение

Y Studios — ИНФОРМАЦИЯ | Passion

CODE SPEAK

(PDF) Обучение программированию: российская перспектива

Самые популярные языки программирования / Sudo Null IT News

Санкт-Петербург

Новосибирск

Казань

Казахстан

Минск

Сравнение с TIOBE

Бонус Самые экзотические языки

Соискатели

А про деньги

👨🏽‍🔬 📱 💖 Русский язык программирования ❌ 🏉 🐼

ТГУ возрождает один из первых русских языков программирования

Алгол 68 — 25 лет в СССР. Российский виртуальный компьютерный музей

Конференция по языкам программирования в России

Добавить комментарий Отменить ответ