Начал я с имен переменных и функций. Реализовал многословные идентификаторы с поддержкой всех доступных человеческих языков.
Число 1 = 1;
Число номер 2 = 2;
Сумма = Число 1 + Число номер 2;
print Сумма; print;
function Открытие двери в поезде() {
print "Дверь открыта"; print;
}
Открытие двери в поезде();
Неплохо, да? Но явно не дотягивает до мечты. Поэтому пришлось добавить синонимы.
synonym "равно", "=";
synonym "равна", "=";
synonym "плюс", "+";
synonym "Вывод", "print";
synonym "Функция", "function";
Число 1 равно 1;
Число номер 2 равно 2;
Сумма равна Число 1 плюс Число номер 2;
Вывод Сумма; Вывод;
Функция Открытие двери в поезде() {
Вывод "Дверь открыта"; Вывод;
}
Открытие двери в поезде();
Текст программы преобразился к обычному человеческому языку. Данная особенность языка позволяет начать программировать человеку без специального образования. Можно отвлечься от изучения синтаксических конструкций языка, а сосредоточиться на изучении алгоритмов программирования. Даже самый сложный алгоритм, изложенный обычным языком, становится намного понятней. А более продвинутым пользователям язык предоставляет возможность работать с массивами любой размерности и объектами.
Эта простенькая программа выглядит просто изумительно. Не правда ли?
//
// Нахождение наибольшего общего делителя двух чисел
//
Первое число = 57;
Второе число = 1332;
while (Первое число <> 0 and Второе число <> 0)
{
if (Первое число > Второе число)
Первое число = Первое число % Второе число;
else
Второе число = Второе число % Первое число;
}
print(Первое число + Второе число);
В процессе реализации языка оказалось, что пространства имен переменных и функций не пересекаются. Это позволяет иметь переменную и функцию с одним и тем же именем.
function озеро() {}
озеро = "глубокое";
Описания функций можно размещать где угодно. Какое из них будет активно решается во время выполнения программы.
бухгалтер = "глупый";
if(бухгалтер = "глупый") {
function summa() {
return 10;
}
} else {
function summa() {
return 20;
}
}
print summa(); print;
Между словами в именах может стоять различное количество пробелов, символов табуляции или перевода строки.
Куда
будем
перемещать
этот стол = "на свалку";
print Куда будем перемещать этот стол; print;
Язык программирования имеет много самых различных встроенных функций. По крайней мере он может быть неплохой заменой бейсику. В настоящий момент существует только онлайн версия языка. Язык написан на PHP.
Все подробности вы можете найти на сайте Язык программирования.
Комментарии (78)
DoctorMoriarty
06.10.2019 12:11+5По ссылке в конце статьи: "Эбал (Ebal англ.) — язык программирования нового поколения".
По-моему, нас тонко троллят…
aamonster
06.10.2019 15:05Надеюсь, что да.
С языком, похожим на естественный, довелось иметь дело (AppleScript). Более неудобного языка программирования в жизни не видел.
KvanTTT
06.10.2019 23:35Это то, что будет делать с этим языком здоровый человек после ознакомления. Ну или что будет делать с мозгом код, написанный на таком языке.
profesor08
06.10.2019 12:28+2Ничего не изобретая.
<?php $первоеЧисло = 123; $второеЧисло = 234; $сумма = $первоеЧисло + $второеЧисло; print $сумма;
первоеЧисло = 123 второеЧисло = 234 сумма = первоеЧисло + второеЧисло alert(сумма)
Постоянное переключение между разными раскладками это полнейшая дичь, даже для написания трех строк.tvr
06.10.2019 15:05Постоянное переключение между разными раскладками это полнейшая дичь
А если учесть ещё одинаково выглядящие символы разных алфавитов, то это не просто дичь, а снятый с предохранителя взведённый пистолет, постоянно таскаемый за поясом.
fsmorygo
06.10.2019 13:30А ещё у Вас лексер не справляется с вложенными комментариями.
ar2rsoft
06.10.2019 14:16Не знаю почему, но после первого же примера и вопроса "Неплохо, да?" хочется ответить "нет".
Возможно действительно троллинг
podivilov
06.10.2019 19:32+4Знаете, мне когда было лет от силы 13-14, я на полном серьёзе продвигал в IT-сообществе идею перехода с шестнадцатеричной системы счисления на мою, альтернативную, с нескучными обоями и возможностью грабить караваны.
Её главным отличием от шестнадцатеричной было то, что она не содержала в себе цифр. Вообще. И я из-за какой-то засевшей во мне тогда навязчивой идеи просто будто помешался на этом: даже, помнится, пытался придумать этому логическое обоснование.
Конечно, люди были недовольны. Я тогда не понимал ещё, отчего. Мне в то время казалось, что любая идея (в том числе и моя) имеет право на жизнь, вне зависимости от того, будет она потом где применяться или нет. В чём-то я действительно был прав — например, любая идея действительно имеет место быть.
Но вот форсить это вовсе не обязательно. Из этой фантасмагории спустя несколько лет я извлёк важный урок — не всё, что кажется гениальным, — гениально в действительности.
Поэтому, вполне вероятен тот факт, что автор не тролль, а просто воодушевлённый своей задумкой человек. Возможно, пока что он просто не может осознать и принять свою ошибку.
Alex_ME
07.10.2019 01:48Так это вы были тем
малолетнем долбчеловеком, который форсил wct! Помню, этим были завалены сообщества в вк вроде "типичного программиста". Я не понимал, это так троллят или кто-то на полном серьезе топит за это.
DjPhoeniX
07.10.2019 03:20+1Каждый из нас когда-то был
${_тем_самым_}. Главное вовремя эволюционировать.
Vlad800
06.10.2019 14:16Ну, не сказал бы, что легче стало — даже читать трудно два языка одновременно. Тем более, что в школе проходят все имена переменных на латинице, и я себя так и не заставил отличать русские слова, как операторы (правда недолго пробовал, но ведь должно было быть легче?).
lair
06.10.2019 14:28Что из этого вышло судить вам.
Вы бы хоть сначала цели озвучили.
Неплохо, да?
Плохо. Как при чтении понять, где закончился идентификатор?
Текст программы преобразился к обычному человеческому языку.
… который, как известно, неоднозначен и избыточен — а это ровно то, чего мы в языках программирования избегаем. Вот и пример:
Вывод Сумма
Это один идентфиикатор "вывод сумма" или идентификатор "Вывод", за которым идет идентификатор "Сумма"?
(это не говоря о том, что это, на самом деле, не читается)
Данная особенность языка позволяет начать программировать человеку без специального образования.
Удивительно, но люди без специального образования программируют и без данной особенности. Интересно, как?
Можно отвлечься от изучения синтаксических конструкций языка, а сосредоточиться на изучении алгоритмов программирования.
Нет, нельзя. Синтаксис у вас все равно есть, и его все равно надо соблюдать.
Эта простенькая программа выглядит просто изумительно. Не правда ли?
Нет. Чем она лучше, чем
while a <> 0 and b <> 0: if a > b: a = a % b else: b = b % a print(a + b)
… тем, что надо постоянно переключать язык, на котором читаешь код?
assembled
06.10.2019 19:12В некоторых старых языках тоже позволяли пробелы в идентификаторах, и синтаксис от этого был немного запутанный. Из-за этого произошел даже знаменитый баг в программе на фортране, когда из-за поставленной точки вместо запятой (или наоборот, не помню точно) объявление цикла было принято за присваивание значения переменной.
А, например, в Алгол-68 синтаксис более однозначный: между идентификаторами всегда либо ключевые слова, либо операторы, либо спецсимволы; а ключевые слова и операторы отличались от идентификаторров — не содержали пробелов и набирались в верхнем регистре, либо брались в кавычки, либо выделялись жирным шрифтом (например в печати).
h0w4rd
09.10.2019 03:46> Это один идентфиикатор «вывод сумма» или идентификатор «Вывод», за которым идет идентификатор «Сумма»?
ЯП спокойно справляется с таким.
Первое = 12;
Первое число = 57;
print(Первое);
print(" ");
print(Первое число);
Вывод — «12 57»lair
09.10.2019 11:24Не справляется.
synonym "число", "="; Первое = 12; Первое число = 57; print(Первое); print(" "); print(Первое число);
Синтаксическая ошибка в строке 4 на символе '='.
И это даже без учета того, что синонимы (которые тоже идентификаторы) не могут содержать пробел:
synonym "равно справа", "=";
Ошибка времени выполнения в строке 1. Неверно задан синоним.AnotherFromSirius Автор
09.10.2019 13:30Синонимы не идентификаторы. Синонимы — это синонимы ключевых слов или символов. В документации все описано.
lair
09.10.2019 13:57+1Синонимы не идентификаторы.
Это называется "произвольное ограничение". В том смысле, что вы так сказали, но никакого логичного объяснения для внешнего пользователя в этом нет.
selotec
06.10.2019 15:06У меня дежавю, была тут уже давно статья про изобретение своего языка, и даже вроде как то похоже начиналась. Разве что не так быстро кончалась.
unnutz
06.10.2019 15:08Просто напрашивается...
Fen1kz
06.10.2019 18:00+3Вот и у меня были свои мечты
Данная особенность языка позволяет начать программировать человеку без специального образования.Серьезно? Вот честно признайтесь, вы хоть раз в языке своей мечты озвучивали поинт "чтобы на языке мог писать кто угодно без образования и обучения"
Текст программы преобразился к обычному человеческому языку
Эта штука никогда не работала. Объясните манию программировать на человеческом языке?
Даже если представить, что появится Идеальный_Все_понимающий_компилятор_русского_языка_в_машинный_код — вот вам охота писать такие программы?
Скажи "Здравствуй Мир"! Возьми из переменную окружения "Хост Программного Интерфейса" и запусти ППГ сервер. Прикрепи к нему следующие конечные точки: 1) /пользователь. К нему прикрепи обработчик конечной точки: Сохрани пришедший идентификатор под именем Айди. Дальше сделай запрос к базе данных "Получить пользователя" "База, база, получи мне пользователя с идентификатор Айди"
Тьфу ты, ну невозможно же. Тем не менее какая-то не здравая мечта писать программу человеческим языком живет.
androidovshchik
06.10.2019 19:39Если программу будет выполнять/интерпретировать ИИ, который понимает речь, то почему бы и нет) Тогда действительно все от мало до велика будут программистами
Lelushak
06.10.2019 20:16+2А мне нравится ваш пример. Писать, возможно, будет не слишком удобно, зато легко читать. Мы (ну, по крайней мере я) в любом случае при чтении кода в голове неявно преобразуем его во что-то подобное. Если оно будет уже так написано, то шаг с преобразованием исчезнет и немного ресурсов освободится
printf
07.10.2019 00:12Мне кажется, это классная идея для высокоуровневого кода. Например, какой-нибудь Jenkins job можно было бы описать:
Клонируем репозиторий git://github.com/милые/котятки в папку "тестовые_котятки" В папке "тестовые_котятки": - Устанавливаем зависимости командой "yarn" - Запускаем тесты командой "yarn test" В случае ошибки отправляем письмо Геннадию <геннадий@милота.рф> с темой "Вороны клюют твои посевы, Джузеппе!"
Получается словно и скрипт, и инструкция как это всё сделать руками, если Дженкинс окуклился.
lostmsu
10.10.2019 18:44Имхо, так кажется потому что идея DSL на нестандартном языке программирования — полное говно.
Denai
06.10.2019 19:14Сумма равна Число 1 плюс Число номер 2;
Если задать переменные «Число», «Число номер 2», «номер 2», то как эта строка отработает?
DesertFlow
06.10.2019 20:25Хех, это только для нас языки программирования выглядят как чужеродные конструкции, которые надо осваивать. А для англоязычных жителей все эти for, while, if самые обычные слова.
Но попытки переводить ключевые слова на русский язык проваливаются не из-за этого. А из-за того, что синтаксис все равно приходится соблюдать. И с английскими командами это делать даже проще. Они сразу выделяются.
А насчет программировать разговорным текстом… Это только на первый взгляд кажется, что будет так:
массив = 1, 2, 3 цикл массив: если элемент равен 2, то выход
А на практике это будет:
пусть массив будет от одного до трех. надо перебрать все элементы, и чтобы на двойке выйти. но не раньше
Ну и как прикажете такую фразу переводить в машинный код? И каждый будет перефразировать по-своему. Пока что парсить алгоритмы, написанные разговорным языком, нереально. А если заставлять учить синтаксис… То лучше с for, if, while. Они хотя бы короткие и хорошо выделяются в тексте.
Ser_Yoga
07.10.2019 07:26Пока что парсить алгоритмы, написанные разговорным языком, нереально.
А вот когда станет реально, разработкой будут заниматься аналитики, которые пишут требования.Lelushak
07.10.2019 09:21Ну нет. Аналитики пишут достаточно высокоуровневые требования. Чтобы их транслировать в код таки нужен сильный (И)И
samodum
06.10.2019 22:31Каждый программист хотя бы раз в своей жизни мечтал об идеальном языке программирования.
Абсолютно неверно.
Большинству программистов пофиг на идеальный язык программирования. И уж тем более, никто не хочет создавать свой собственный язык.
Это мечты джуниоров.printf
07.10.2019 00:14+2Мне кажется, большинство программистов хотя бы раз в жизни были джуниорами, так что все сходится.
GennPen
06.10.2019 23:07Можно отвлечься от изучения синтаксических конструкций языка, а сосредоточиться на изучении алгоритмов программирования.
Но даже в вашем «языке» есть синтаксическая конструкция, нарушив которую программа не скомпилируется.
Alex_ME
07.10.2019 01:52+1Я недавно столкнулся с Robot Framework, где тоже идентификаторы с пробелами и много всяких ненужных слов, так прям сил нет, какая хрень.
SerafimArts
07.10.2019 04:37+1Вот вы минусите. А у человека там судя по косвенным данным (по интерпретатору в веб-морде) — довольно большая работа проделана. Не обычный транспайлер вида "фигак-фигак", как делают новоиспечённые адепты секты "совершенных языков программирования", а примитивная виртуальная машина.
Я бы даже на исходники взглянул. Вдруг что интересное попадётся, всё же подобная реализация требует особых знаний на этом поприще. Тем более, судя по задаче — это реализация с КЗ-грамматикой (Тип 2 по иерархии Хомского), что повышает сложность парсера и семантического анализа.
P.S. А если там всё сделано ещё грамотно: лексер, парсер, ast, ir-код, таблица символов и прочие прелести, то вне зависимости от результата (как мы видим — довольно плачевного) — это очень круто.
P.P.S. Хотя, может я и ошибаюсь =)
AnotherFromSirius Автор
07.10.2019 07:25Два LR(1) парсера. Один для лексем, другой для грамматики. Тот что для лексем не стандартный, а немного переделанный. AST. Все по науке. Исходники не будут выложены никогда. Это тайна.
KvanTTT
07.10.2019 14:17А как вы парсите heredoc строки только с помощью LR парсера?
SerafimArts
07.10.2019 17:59Ну, объективно, HEREDOC можно считывать и обычной регулярной грамматикой:
<<<\h*(\w+)[\s\S]*?\n\h*\g{-1}
А внутрянку считывать дополнительным проходом уже после.
loki82
07.10.2019 07:26Очень похоже на 1с 7.7. Подиразбери почему уровень() метод, а наименование свойство. Подробностей не вспомню. Но там часто была путаница в этих понятия.
WhiteBlackGoose
07.10.2019 09:54-1Неплохо, но:
1) Засуньте куда-нибудь кириллицу, ее там не должно быть
2) Знак равенства для всех нормальных людей без образования все равно лучше чем писать "равно"
Ну и конечно то, что он написал на php, я так понимаю, массив из 10000 элементов он будет минуту заполнять? Если да, то это бесполезный язык. Переписывайте на что-то нормальное.WhiteBlackGoose
07.10.2019 09:57Я щас посчитал, python (медленный язык) 13'500'000 элементов массива в секунду. Ваш язык хотя бы четверть этой скорости осилит?
androidovshchik
07.10.2019 10:18Насколько знаю, медленный питон, php далеко нет, так как его реализация на плюсах сделана
WhiteBlackGoose
07.10.2019 10:33php вроде медленнее питона. Они оба на + реализованы. Но какая разница, если ТС писал не на +, а на нестроготипизированном интерпретируемом языке интерпретатор другого языка?
androidovshchik
07.10.2019 10:48-2спасибо за минус в карму
WhiteBlackGoose
07.10.2019 11:44Передаю от лица того, кто поставил вам минус: "пожалуйста". Впрочем, теперь я тоже это сделаю
SerafimArts
07.10.2019 14:50php вроде медленнее питона.
Так было в бородатых 2000х. Сейчас же на алгоритмических задачках (т.е. CPU-bound) PHP может вполне конкурировать с аналогичными на C, где питону по скорости до пыха как до луны, и тормоза возникают лишь в синхронном IO.
P.S. https://gist.github.com/dstogov/12323ad13d3240aee8f1
PHP7-JIT (JIT=on) 0.011 gcc -O2 (4.9.2) 0.013 ... python-2.7.8 1.128WhiteBlackGoose
07.10.2019 15:11Презабавнейше, не знал. Но стоит заметить, что все php кроме как jit (то есть скомпилированного) где-то там внизу. Ну хотя тс может и на jit писал
SerafimArts
07.10.2019 17:52Но стоит заметить, что все php кроме как jit (то есть скомпилированного) где-то там внизу.
Да, ровно после джавы. Т.е. можно считать на этом тесте самым быстрым интерпретируемым языком без JIT.
А если учитывать что это тест от 2015го года и после 7.0 ещё были 7.1, 7.2, 7.3 релизится 7.4 и в разработке 8.0, то тем более. Там по скорости не такие значительные отличия как между 5 и 7, то тоже скорость процентов на 20 повыше будет этих результатов.
P.S. А то что вы там внизу видите — это как бы PHP 5.0, о чём я и намекал, говоря о "бородатых 2000х", когда был PHP 4/5.
WhiteBlackGoose
07.10.2019 18:55Он может и самый быстрый, но все равно медленный для написания яп. Опять же, не рассматривая, если тс писал на jit
SerafimArts
07.10.2019 19:43Во-первых, "на JIT" никто не пишет. Это всего лишь флаг в настройках языка.
Во-вторых, согласен, естественно, что у подобной реализации скорость будет не той составляющей, которой можно хвастаться. НО.
Для начала в мире не существует ни одного языка общего назначения, который бы был медленным для "написания ЯП". Как бы ЯП — это всего лишь frontend компиляторов: Совокупность грамматики и IR-кода. А в качестве бека никто не мешает использовать какой-нибудь LLVM.
Если же вы хотели написать не ЯП, а "интерпретатора", то это вполне оправдано, когда разница по скорости раза в полтора два от сишной реализации не является критичной.
Согласен что на уровне языка не хватает возможностей прямой работы с памятью и инструкциями CPU, вроде AVX. Ну или другими узкими местами, вроде прямой работой с GPU для рендера сцен а-ля Crysis в 60 fps. Но это и не критично особо, а всякие фичи обмазываются FFI-бриджами.
Хотя народ упарывается, это да: https://stitcher.io/blog/php-jit
А если говорить про опыт, то больше всего производительности мне удалось выжимать за счёт оптимизации алгоритмов. Например, ускорение в 36 раз за счёт перехода с LL(k) с построением AST из трейса парсера на метод рекурсивного спуска с параллельным построением AST (я хрен знает как его назвать, потому что сам выдумывал и реализация ближе к парсер-комбинаторам, нежели к классическому LL):
Заголовок спойлера
WhiteBlackGoose
07.10.2019 21:02Кстати я вообще не понимаю, почему я решил, что тс интерпретатор пишет. Впрочем, как неочевидно и обратное.
lair
07.10.2019 22:44Кстати я вообще не понимаю, почему я решил, что тс интерпретатор пишет.
Иначе достаточно мало смысла в утверждении "Так это же PHP. Что вы хотели?"
AnotherFromSirius Автор
07.10.2019 10:21Массив из 1000 элементов заполняет в среднем за 0.001 сек. (сервера Google очень быстрые). В онлайн версии установлено ограничение на количество элементов массива — 1000 элементов максимум. Скорость можете сами проверить.
a = adim(1000);
afill(a, 10);
WhiteBlackGoose
07.10.2019 10:32Ну я имел ввиду цикл вообще-то, а не встроенную функцию.
Но даже без цикла — 1'000'000 в секунду, это в 13 раз медленнее питона.
hunroll
07.10.2019 10:38Куда
будем
перемещать
этотстолязык программирования= «на свалку»;
print Куда будем перемещать этотстолязык программирования; print;
AnotherFromSirius Автор
07.10.2019 10:43-1Цикл за 0.01 сек.
a = adim(1000);
while(i <= 1000) begin i = 1; step i = i + 1; {
a[i] = i;
}
Так это же PHP. Что вы хотели?Jack_Taylor
07.10.2019 11:42+1Что вы хотели?
Чтобы выгоды от использования языка перекрывали его недостатки.
Какие конкретно плюсы вашего языка перекрывают минусы в виде низкой скорости выполнения, закрытого исходного кода и сложности печати (постоянно переключать раскладку) и чтения (постоянно переключать мозг)?
WhiteBlackGoose
07.10.2019 11:47Как интересно, а мне кинули, что за 0.001. Ну тогда разговор ни о чем)
SerafimArts
10.10.2019 17:58Так это же PHP. Что вы хотели?
У меня на рабочем ноуте этот цикл отрабатывает за 0.01мс (0.000013 сек) без JIT, opcache и прочих приблуд. Есть подозрения, что это у вас реализация тормозит.
Да и даже если виртуальную машину написать скорость будет ~0.0003 сек (извиняюсь за говнокод): https://gist.github.com/SerafimArts/ce7e0ca28b325e4c8794aede4ffd8a74
AnotherFromSirius Автор
10.10.2019 21:18Возможно и так. Мне все равно. Это прототип языка. Задача получить высокую скорость не стоит. Когда буду вылизывать ассемблерный код, тогда и буду думать как повысить производительность. Но до этого еще очень далеко…
vilgeforce
Кажется, кто-то переизобрел Literate Programming
n1ger
А мне это очень похоже на 1С и 1С++.